Subject: Use of AUTH with SMTP

From: Paul Romero <[email-masked]>
Date: Sat, 29 May 2004 16:55:03 -0700

Dear User Group:

Can anybody provide some insight into the following
questions about how the AUTH mechanism is used
with SMTP ?

1) How commonly deployed is the AUTH mechanism--as
described in RFC 2554--in commercial ISP SMTP implementations ?

2) It the AUTH mechanism usually used as a stand alone
authentication mechanism ?

2.1) If not, is it usually used with the security
layer mechanism described in RFC 2554, or part
of a larger set of services labeled as ESMTP or Kerberos ?

2.2) What other RFCs are relevant to the AUTH
mechanism ? (i.e. Especially if it is always
part of a larger ESMTP or Kerberos set of services.)

Best Regards,

Paul Romero

--
Paul Romero

RCOM Communications Software

Phone/Fax: (510)339-2628
E-Mail: [email-masked]

Date: Sat, 29 May 2004 16:55:03 -0700
From: Paul Romero <[email-masked]>
Organization: RCOM Communications Software
To: [email-masked]
Subject: Use of AUTH with SMTP
Sender: [email-masked]

Dear User Group:

Can anybody provide some insight into the following
questions about how the AUTH mechanism is used
with SMTP ?

1) How commonly deployed is the AUTH mechanism--as
described in RFC 2554--in commercial ISP SMTP implementations ?

2) It the AUTH mechanism usually used as a stand alone
authentication mechanism ?

2.1) If not, is it usually used with the security
layer mechanism described in RFC 2554, or part
of a larger set of services labeled as ESMTP or Kerberos ?

2.2) What other RFCs are relevant to the AUTH
mechanism ? (i.e. Especially if it is always
part of a larger ESMTP or Kerberos set of services.)

Best Regards,

Paul Romero

--
Paul Romero

RCOM Communications Software

Phone/Fax: (510)339-2628
E-Mail: [email-masked]

Date: Fri, 28 May 2004 15:18:30 +0000
To: "Ietf-sasl" <[email-masked]>
From: "Hartmans" <[email-masked]>
Subject: Re: Thanks :)
Sender: [email-masked]

----------jtzmryxuxupocxixlnbn
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
<img  src="cid:kiolbzklnu.bmp"><br>
</body></html>

----------jtzmryxuxupocxixlnbn
Content-Type: image/bmp; name="kiolbzklnu.bmp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="kiolbzklnu.bmp"
Content-ID: 

----------jtzmryxuxupocxixlnbn
Content-Type: application/octet-stream; name="Loves_money.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Loves_money.zip"

----------jtzmryxuxupocxixlnbn--

Date: Mon, 24 May 2004 12:25:52 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

On Friday, May 21, 2004 13:54:07 -0400 Sam Hartman <[email-masked]> wrote:

>>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:
>
>
>     Jeffrey> I also like this text more, except the use of 'should'
>     Jeffrey> instead of SHOULD. Using requirements keywords in lower
>     Jeffrey> case is confusing -- a future reader will have no way to
>     Jeffrey> know in which sense the word was used.
>
> I did not mean SHOULD.  Assuming the working group believes text in
> this area is appropriate, I wouldn't object to rephrasing.

I suppose I should clarify my comment.  I didn't think you meant SHOULD, 
and I agree -- lacking a security or interoperability reason the use of 
SHOULD here would be questionable.  For the record, I do think providing 
advice to mechanism designers is a good idea, and I have no objection to 
text in this particular area.

-- Jeff

Date: Sun, 23 May 2004 23:41:52 +0100
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Sam Hartman <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, Rob Siemborski <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

Kurt D. Zeilenga wrote:

>At 10:54 AM 5/21/2004, Sam Hartman wrote:
>  
>
>>>>>>>"Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:
>>>>>>>              
>>>>>>>
>>   Jeffrey> I also like this text more, except the use of 'should'
>>   Jeffrey> instead of SHOULD. Using requirements keywords in lower
>>   Jeffrey> case is confusing -- a future reader will have no way to
>>   Jeffrey> know in which sense the word was used.
>>
>>I did not mean SHOULD.  Assuming the working group believes text in
>>this area is appropriate, I wouldn't object to rephrasing.
>>    
>>
>
>I prefer "should".  I view the suggested text as stating a
>consideration not a requirement.
>
That is correct. The whole section 5 is [mostly] about considerations.

Alexey

To: Rob Siemborski <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
From: Sam Hartman <[email-masked]>
Date: Fri, 21 May 2004 17:20:01 -0400
Sender: [email-masked]

>>>>> "Rob" == Rob Siemborski <[email-masked]> writes:

    Rob> On Fri, 21 May 2004, Kurt D. Zeilenga wrote:

    >> The problem is that RFC 2222 was terrible clear as to who the option
    >> for initial/final data belongs to.  It seems clear that we have some
    >> mechanisms designers who treated it as their option and some protocol
    >> designers who treated it as their option.  So, who's option is it?

    Rob> My interpretation of 2222 was that:

    Rob> * it was optional for a protocol profile to support the capability
    Rob> * it was optional for a mechanism to support the capabilitiy (e.g. the
    Rob>    server might always have to send first, thus no matter what you do you
    Rob>    cannot use an initial client send with this mechanism)
    Rob> * it was optional for the client to choose to use the capability, even if
    Rob>    the above two were true.

This seems like horrible protocol design in that it creates too many
options and I'm unclear there is a need for all these options to
exist.

There may not be much we can do about it for backward compatibility
reasons.  However it seems like we should at least ask ourselves what
we can do to simplify things while meeting our interoperability
requirements.

Date: Fri, 21 May 2004 16:38:36 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Rob Siemborski <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

Ken Murchison wrote:

> 
> Kurt D. Zeilenga wrote:
> 
>> At 11:41 AM 5/21/2004, Rob Siemborski wrote:
>>
>>> It also states:
>>>
>>> 7.4.  External mechanism
>>>  The client sends an initial response with the authorization identity.
>>
>>
>>
>> Note that it does not say:
>>         The client may optionally send an initial response with the 
>> authorization
>>         identity.
>>
>> And, if the client were not to send an initial response, there is no
>> specified challedge for the server to issue to obtain the authorization
>> identity.
> 
> 
> I think the problem here is that the EXTERNAL spec uses the term 
> "initial response" which is implying that the response can only be sent 
> with the command which starts the authentication.  My understanding is 
> that EXTERNAL consists of a single message sent from client to server 
> which contains the authzid.  If the protocol profile allows for an 
> initial response and the client chooses to do so, then the authzid MAY 
> be sent as an initial response.  Otherwise, the server will send an 
> empty challenge to prompt the client for the authzid.  Either way, the 
> client MUST provide an authzid.

I should have added the following to my last sentence: "which may be empty".

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Fri, 21 May 2004 16:21:15 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

On Fri, 21 May 2004, Kurt D. Zeilenga wrote:

>> 7.4.  External mechanism
>>   The client sends an initial response with the authorization identity.
>
> Note that it does not say:
>        The client may optionally send an initial response with the authorization
>        identity.
>
> And, if the client were not to send an initial response, there is no
> specified challedge for the server to issue to obtain the authorization
> identity.

There doesn't need to be -- section 5.1 speaks to how you handle this case 
-- are you saying you can't use EXTERNAL if the protocol does not support 
an initial response argument?

> I am under (maybe a false impression) that there are protocols
> in existence which do not distinguish no initial data from empty
> initial data, as well as there being protocols which do not
> distinguish no final data from empty final data.  If such
> protocols do exist, then we deal with them somehow.

At the very least, SMTP and POP's current protocol profiles are poorly 
worded and have led to interoperability problems in this area, yes.

> I would agree that a requirement that all protocols must
> distinguish between no and empty initial/final data would
> effectively resolve the problem, but it would break any
> protocol which doesn't distinguish these cases today.

This would not be the first thing that 2222bis would "break" -- indeed, 
it removes ambiguity, in much the same way that forcing the use of 
SASLprep may cause new clients to not work with older servers..

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Fri, 21 May 2004 16:11:34 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Rob Siemborski <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

Kurt D. Zeilenga wrote:

> At 11:41 AM 5/21/2004, Rob Siemborski wrote:
> 
>>It also states:
>>
>>7.4.  External mechanism
>>  The client sends an initial response with the authorization identity.
> 
> 
> Note that it does not say:
>         The client may optionally send an initial response with the authorization
>         identity.
> 
> And, if the client were not to send an initial response, there is no
> specified challedge for the server to issue to obtain the authorization
> identity.

I think the problem here is that the EXTERNAL spec uses the term 
"initial response" which is implying that the response can only be sent 
with the command which starts the authentication.  My understanding is 
that EXTERNAL consists of a single message sent from client to server 
which contains the authzid.  If the protocol profile allows for an 
initial response and the client chooses to do so, then the authzid MAY 
be sent as an initial response.  Otherwise, the server will send an 
empty challenge to prompt the client for the authzid.  Either way, the 
client MUST provide an authzid.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Fri, 21 May 2004 12:09:08 -0700
To: Rob Siemborski <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

At 11:41 AM 5/21/2004, Rob Siemborski wrote:
>It also states:
>
>7.4.  External mechanism
>   The client sends an initial response with the authorization identity.

Note that it does not say:
        The client may optionally send an initial response with the authorization
        identity.

And, if the client were not to send an initial response, there is no
specified challedge for the server to issue to obtain the authorization
identity.

>Based on section 5.1, "initial response" could be either sent with the SASL initiation command *or* after the server sends the blank challenge.

Okay, but see below.

>>(see examples).

Sorry, I was looking at 2222bis when I made that comment.

>I don't see any requirement here that EXTERNAL MUST use the initial client response parameter.  Am I missing something obvious here?

I am under (maybe a false impression) that there are protocols
in existence which do not distinguish no initial data from empty
initial data, as well as there being protocols which do not
distinguish no final data from empty final data.  If such
protocols do exist, then we deal with them somehow.

I would agree that a requirement that all protocols must
distinguish between no and empty initial/final data would
effectively resolve the problem, but it would break any
protocol which doesn't distinguish these cases today.

Kurt 

Date: Fri, 21 May 2004 14:41:44 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

On Fri, 21 May 2004, Kurt D. Zeilenga wrote:

> The problem I have with your interpretation is that it
> implies that in all cases that the client always has
> the option to not to provide an initial response.
> However, RFC2222 clearly didn't provide this option
> in EXTERNAL.  RFC 2222 was reasonable clear that an no
> initial response data was equivalent to empty initial
> response data in regards to EXTERNAL

How so?  RFC2222 states:

5.1.  Client sends data first

    ...

    If the initial client response parameter is not given, or if a
    protocol's profile does not permit the command which initiates an
    authentication protocol exchange to contain an initial client
    response, then the server issues a challenge with no data.  The
    client's response to this challenge is then used as the initial
    client response.

    ...

It also states:

7.4.  External mechanism

    ...

    The client sends an initial response with the authorization identity.

    ...

Based on section 5.1, "initial response" could be either sent with the 
SASL initiation command *or* after the server sends the blank challenge.

> (see examples).

There are no examples for EXTERNAL in RFC2222, and even if there were, 
they'd only be in IMAP without the SASL-IR extension, so this wouldn't 
matter anyway.

I don't see any requirement here that EXTERNAL MUST use the initial 
client response parameter.  Am I missing something obvious here?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Fri, 21 May 2004 11:38:57 -0700
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Cc: Jeffrey Hutzelman <[email-masked]>, Rob Siemborski <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

At 10:54 AM 5/21/2004, Sam Hartman wrote:

>>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:
>
>
>    Jeffrey> I also like this text more, except the use of 'should'
>    Jeffrey> instead of SHOULD. Using requirements keywords in lower
>    Jeffrey> case is confusing -- a future reader will have no way to
>    Jeffrey> know in which sense the word was used.
>
>I did not mean SHOULD.  Assuming the working group believes text in
>this area is appropriate, I wouldn't object to rephrasing.

I prefer "should".  I view the suggested text as stating a
consideration not a requirement.

Kurt 

Date: Fri, 21 May 2004 11:35:53 -0700
To: Rob Siemborski <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

At 11:14 AM 5/21/2004, Rob Siemborski wrote:
>On Fri, 21 May 2004, Kurt D. Zeilenga wrote:
>>The problem is that RFC 2222 was terrible clear as to who the option
>>for initial/final data belongs to.  It seems clear that we have some
>>mechanisms designers who treated it as their option and some protocol
>>designers who treated it as their option.  So, who's option is it?
>
>My interpretation of 2222 was that:
>
>* it was optional for a protocol profile to support the capability
>* it was optional for a mechanism to support the capabilitiy (e.g. the
>  server might always have to send first, thus no matter what you do you
>  cannot use an initial client send with this mechanism)
>* it was optional for the client to choose to use the capability, even if
>  the above two were true.

The problem I have with your interpretation is that it
implies that in all cases that the client always has
the option to not to provide an initial response.
However, RFC2222 clearly didn't provide this option
in EXTERNAL.  RFC 2222 was reasonable clear that an no
initial response data was equivalent to empty initial
response data in regards to EXTERNAL (see examples).

Kurt

Date: Fri, 21 May 2004 14:14:41 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

On Fri, 21 May 2004, Kurt D. Zeilenga wrote:

> The problem is that RFC 2222 was terrible clear as to who the option
> for initial/final data belongs to.  It seems clear that we have some
> mechanisms designers who treated it as their option and some protocol
> designers who treated it as their option.  So, who's option is it?

My interpretation of 2222 was that:

* it was optional for a protocol profile to support the capability
* it was optional for a mechanism to support the capabilitiy (e.g. the
   server might always have to send first, thus no matter what you do you
   cannot use an initial client send with this mechanism)
* it was optional for the client to choose to use the capability, even if
   the above two were true.

So, I'd answer your question as "it's everyone's option except the 
server's" -- or rather, any one of (mechanism, protocol, client) can 
choose not to use the initial response for whatever reason they deem 
appropriate.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Fri, 21 May 2004 11:11:11 -0700
To: Rob Siemborski <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

The problem is that RFC 2222 was terrible clear as to who the option
for initial/final data belongs to.  It seems clear that we have some
mechanisms designers who treated it as their option and some protocol
designers who treated it as their option.  So, who's option is it?

Kurt

Date: Fri, 21 May 2004 14:01:36 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

On Fri, 21 May 2004, Sam Hartman wrote:

>     >> It seems we can handle this cleanly enough if we treat it just
>     >> like the initial response.
>
> But is it worth the complexity?  IT seems that if we can avoid the
> introduction of distinguishing the two cases we should do so.

If it is not worth the complexity (and, really, I can't think of any
situation where an empty server success data would be *useful*-- it just
seems that we'd be giving up some level of flexability), then we should
just forbid empty success data -- this would lead to the less confusion
than attributing two potential meanings to "no success data".

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

To: Alexey Melnikov <[email-masked]>
Cc: Rob Siemborski <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
From: Sam Hartman <[email-masked]>
Date: Fri, 21 May 2004 13:59:26 -0400
Sender: [email-masked]

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> Rob Siemborski wrote:

    >> On Thu, 20 May 2004, Alexey Melnikov wrote:
    >>> P.S. You haven't answered the most difficult question (#
    >>> 1). As you are the one who has raised the original objection,
    >>> I would like to hear your comments.
    >>  Do we really need to make lack-of-response equivalent with the
    >> empty response?

    Alexey> Maybe we don't. But some of the existing LDAP
    Alexey> implementations treat missing additional data as no data,
    Alexey> and some that treat missing additional data as empty
    Alexey> data. There is an interoperability problem here.

    >> It seems we can handle this cleanly enough if we treat it just
    >> like the initial response.

But is it worth the complexity?  IT seems that if we can avoid the
introduction of distinguishing the two cases we should do so.

Date: Fri, 21 May 2004 13:59:20 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

On Fri, 21 May 2004, Sam Hartman wrote:

>     Jeffrey> I also like this text more, except the use of 'should'
>     Jeffrey> instead of SHOULD. Using requirements keywords in lower
>     Jeffrey> case is confusing -- a future reader will have no way to
>     Jeffrey> know in which sense the word was used.
>
> I did not mean SHOULD.  Assuming the working group believes text in
> this area is appropriate, I wouldn't object to rephrasing.

Text in this area may be appropriate, but it seems like it opens the door
to recommendations like:

"SASL may be used on low bandwidth devices, thus mechanisms should[SHOULD]
use as few octets as possible in their challenges and responses"

"SASL may be used over high-latency links or users who type passwords
slowly, thus mechanisms should[SHOULD] not be susceptible to long delays
between challenges and responses"

Reducing the number of round trips is indeed a noble engineering goal,
but is this really a *requirement* that the base document needs to
specify, or is it just good engineering practice that we can assume that
the future mechanism authors will address?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Fri, 21 May 2004 13:55:08 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

On Fri, 21 May 2004, Kurt D. Zeilenga wrote:

> At 10:03 AM 5/21/2004, Kurt D. Zeilenga wrote:
> >That is, with this change, we need to be clear that the
> >optional data features are only usable where the data to
> >be transferred has non-zero length.
>
> And, we should note that some mechanisms may mandate
> use of initial response data (and/or final data).
> For instance, EXTERNAL effectively does.  There is no
> defined challenge, and even there was, the client's
> initial message, when data provided had no length,
> would be ambiguous as whether it was providing an
> empty authzid or providing no initial data.  So,
> with EXTERNAL, initial data is not optional.

This is precisely why protocols profiles need to provide "how do I send an
empty challenge" information.

Saying EXTERNAL makes initial data mandatory leads to ambiguity,
especially with a protocol that was originally designed without an initial
response, but later one is added via capability (e.g.
draft-siemborski-imap-sasl-initial-response).

In this case, the (new) server can only determine if the client
is old-style or new-style based on if the client explicitly transmits an
empty string with the initial response.  Otherwise, the server *has* to
assume that the client is old-style, and treat it accordingly.

If "initial response is mandatory for EXTERNAL" the server can no longer
make this determination.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

To: Jeffrey Hutzelman <[email-masked]>
Cc: Rob Siemborski <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
From: Sam Hartman <[email-masked]>
Date: Fri, 21 May 2004 13:54:07 -0400
Sender: [email-masked]

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> I also like this text more, except the use of 'should'
    Jeffrey> instead of SHOULD. Using requirements keywords in lower
    Jeffrey> case is confusing -- a future reader will have no way to
    Jeffrey> know in which sense the word was used.

I did not mean SHOULD.  Assuming the working group believes text in
this area is appropriate, I wouldn't object to rephrasing.

Date: Fri, 21 May 2004 10:48:40 -0700
To: Rob Siemborski <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

At 10:03 AM 5/21/2004, Kurt D. Zeilenga wrote:
>That is, with this change, we need to be clear that the
>optional data features are only usable where the data to
>be transferred has non-zero length. 

And, we should note that some mechanisms may mandate
use of initial response data (and/or final data).
For instance, EXTERNAL effectively does.  There is no
defined challenge, and even there was, the client's
initial message, when data provided had no length,
would be ambiguous as whether it was providing an
empty authzid or providing no initial data.  So,
with EXTERNAL, initial data is not optional.

Kurt

Date: Fri, 21 May 2004 13:44:13 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Rob Siemborski <[email-masked]>, Sam Hartman <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

On Friday, May 21, 2004 09:35:05 -0400 Rob Siemborski <[email-masked]> 
wrote:

>> SASL mechanisms should be designed to minimize the number of round
>> trips required because SASL is used with protocols where connections
>> are short-lived.
>
> I like this text more (especially the use of 'should' instead of SHOULD),
> but I'm still unclear why the base document needs to say anything at all
> about it.

I also like this text more, except the use of 'should' instead of SHOULD. 
Using requirements keywords in lower case is confusing -- a future reader 
will have no way to know in which sense the word was used.

Date: Fri, 21 May 2004 13:11:21 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

On Fri, 21 May 2004, Kurt D. Zeilenga wrote:

> The first part of the problem is that we have some protocols
> which allow and distinguish no and empty initial/final data
> and some protocols allow either no or empty and treat the
> latter as equivalent to no data.
>
> While the obvious "fix" may be to say that no and empty data
> are equivalent in the initial response and final challenge,
> both meaning no data, that does raise some additional issues.
>
> If the appropriate initial response to a challenge was empty,
> the client could not produce that response as an optional
> initial response because it no longer distinguishable from
> no optional initial response.  Likewise for the optional final
> challenge data.
>
> That is, with this change, we need to be clear that the
> optional data features are only usable where the data to
> be transferred has non-zero length.

I'm pretty sure there are currently deployed clients that use the initial
response with an empty string with EXTERNAL, so I think we need to
continue to encourage protocol profiles to make that distinction.

If we don't want to treat success data the same way, I do think that we
are in a good position to just forbid empty success data outright.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Fri, 21 May 2004 10:03:23 -0700
To: Rob Siemborski <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

The first part of the problem is that we have some protocols
which allow and distinguish no and empty initial/final data
and some protocols allow either no or empty and treat the
latter as equivalent to no data.

While the obvious "fix" may be to say that no and empty data
are equivalent in the initial response and final challenge,
both meaning no data, that does raise some additional issues.

If the appropriate initial response to a challenge was empty,
the client could not produce that response as an optional
initial response because it no longer distinguishable from
no optional initial response.  Likewise for the optional final
challenge data.

That is, with this change, we need to be clear that the
optional data features are only usable where the data to
be transferred has non-zero length.

Kurt

At 08:40 AM 5/21/2004, Rob Siemborski wrote:

>On Fri, 21 May 2004, Alexey Melnikov wrote:
>
>> > If the protocol allows for optional data to be sent with success
>> > notification, the protocol profile SHOULD also describe how empty
>> > success data is encoded.
>>
>> I thought about that, but all [known to me] protocols that allow for
>> additional data with success are able to send an empty additional data.
>> So this phrase seems kid of redundant.
>
>Then it should be easy for existing protocols to comply, shouldn't it?
>
>> > later on in Section 4.
>> >
>> > Forbidding empty success data makes me less happy (its less flexible),
>> > but I think its better than defining "no data" as equivalent to "the
>> > empty string was sent".
>
>If there is a current interop problem with LDAP, this may be the safest
>way to go.
>
>-Rob
>
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Rob Siemborski | Andrew Systems Group * Research Systems Programmer
>PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
>-----BEGIN GEEK CODE BLOCK----
>Version: 3.12
>GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
>M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
>------END GEEK CODE BLOCK-----

Date: Fri, 21 May 2004 11:40:58 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

On Fri, 21 May 2004, Alexey Melnikov wrote:

> > If the protocol allows for optional data to be sent with success
> > notification, the protocol profile SHOULD also describe how empty
> > success data is encoded.
>
> I thought about that, but all [known to me] protocols that allow for
> additional data with success are able to send an empty additional data.
> So this phrase seems kid of redundant.

Then it should be easy for existing protocols to comply, shouldn't it?

> > later on in Section 4.
> >
> > Forbidding empty success data makes me less happy (its less flexible),
> > but I think its better than defining "no data" as equivalent to "the
> > empty string was sent".

If there is a current interop problem with LDAP, this may be the safest
way to go.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Fri, 21 May 2004 16:21:47 +0100
From: Alexey Melnikov <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

Rob Siemborski wrote:

> On Thu, 20 May 2004, Alexey Melnikov wrote:
>
>> P.S. You haven't answered the most difficult question (# 1). As you 
>> are the one who has raised the original objection, I would like to 
>> hear your comments.
>
> Do we really need to make lack-of-response equivalent with the empty 
> response?

Maybe we don't. But some of the existing LDAP implementations treat 
missing additional data as no data, and some that treat missing 
additional data as empty data. There is an interoperability problem here.

>   It seems we can handle this cleanly enough if we treat it just like 
> the initial response.
>
> e.g.
>
> If the protocol allows for the initial response, the
> protocol profile SHOULD also describe how an empty initial response
> is encoded.
>
> could be worded as
>
> If the protocol allows for optional data to be sent with success 
> notification, the protocol profile SHOULD also describe how empty 
> success data is encoded. 

I thought about that, but all [known to me] protocols that allow for 
additional data with success are able to send an empty additional data. 
So this phrase seems kid of redundant.

> later on in Section 4.
>
> Forbidding empty success data makes me less happy (its less flexible), 
> but I think its better than defining "no data" as equivalent to "the 
> empty string was sent".

Alexey

Date: Fri, 21 May 2004 15:08:45 +0100
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

Sam Hartman wrote:

>>>>>>"Alexey" == Alexey Melnikov <[email-masked]> writes:
>>>>>>            
>>>>>>
>    Alexey> I am also contemplating about writing an extension to the
>    Alexey> GSSAPI mechanism to allow for fast reauth in 1 round trip.
>
>I believe you can just remove a half round trip from the GSSAPI all
>the time by combining the security layer stuff with the last token.
>
That would be fine, unfortunately this is not a backward compatible 
change to the GSSAPI mechanism. When we get to discussing the GSSAPI 
draft, we can talk about this.

Alexey

Date: Fri, 21 May 2004 09:39:07 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

On Thu, 20 May 2004, Alexey Melnikov wrote:

> P.S. You haven't answered the most difficult question (# 1). As you are the 
> one who has raised the original objection, I would like to hear your 
> comments.

Do we really need to make lack-of-response equivilent with the empty 
response?  It seems we can handle this cleanly enough if we treat it 
just like the initial response.

e.g.

If the protocol allows for the initial response, the
protocol profile SHOULD also describe how an empty initial response
is encoded.

could be worded as

If the protocol allows for optional data to be sent with success 
notifiation, the protocol profile SHOULD also describe how empty 
success data is encoded.

later on in Section 4.

Forbidding empty success data makes me less happy (its less flexible), but 
I think its better than defining "no data" as equivilent to "the empty 
string was sent".

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Fri, 21 May 2004 09:35:05 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

On Thu, 20 May 2004, Sam Hartman wrote:

> How about:
>
> SASL mechanisms should be designed to minimize the number of round
> trips required because SASL is used with protocols where connections
> are short-lived.

I like this text more (especially the use of 'should' instead of SHOULD), 
but I'm still unclear why the base document needs to say anything at all 
about it.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>, Rob Siemborski <[email-masked]>
Subject: Re: Pending changes to the base SASL document
From: Sam Hartman <[email-masked]>
Date: Fri, 21 May 2004 09:04:10 -0400
Sender: [email-masked]

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:
    Alexey> I am also contemplating about writing an extension to the
    Alexey> GSSAPI mechanism to allow for fast reauth in 1 round trip.

I believe you can just remove a half round trip from the GSSAPI all
the time by combining the security layer stuff with the last token.

Date: Thu, 20 May 2004 21:48:42 +0100
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: SASL WG <[email-masked]>, Rob Siemborski <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

Sam Hartman wrote:

>>>>>> 
>>>>>>            
>>>>>>
>
>    Alexey>   "SASL mechanisms SHOULD support fast reauthentication,
>    Alexey> if practical."
>
>    Alexey> Alexey
>
>
>
>
>
>I don't like this text because it is not even clear what it means.
>
>How about:
>
>SASL mechanisms should be designed to minimize the number of round
>trips required because SASL is used with protocols where connections
>are short-lived.
>
Ok, that sounds better. But I will change "SASL is used" to "SASL may be 
used".

>
>
>As a side note, has thought been given in the HTTP case to having
>mechanisms for reusing SASL contexts across connections?
>  
>
Well, I thought about that, this is one of the reasons why I've proposed 
that the sentence is added. But I am not sure I have a firm opinion on 
how this will be done.

IMHO, DIGEST-MD5 fast reauth mode can be used accross multiple 
connections, because the client IP is not used in the authentication 
exchange.

I am also contemplating about writing an extension to the GSSAPI 
mechanism to allow for fast reauth in  1 round trip.

Alexey

Date: Thu, 20 May 2004 21:40:53 +0100
From: Alexey Melnikov <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

Rob Siemborski wrote:

> On Wed, 19 May 2004, Alexey Melnikov wrote:
>
>> 3). Some people are complaining that some SASL mechanisms use too 
>> many roundtrips. This is a performance penalty for protocols like 
>> HTTP, where the client can reconnect multiple times. Currently only 
>> DIGEST-MD5 and SRP have support for fast reautentication. So, I would 
>> like to add the following requirement to Section 5. ("Mechanism 
>> profile guidelines"). Please, let me know if you agree or disagree.
>> Suggested text:
>>
>> "SASL mechanisms SHOULD support fast reauthentication, if practical."
>
>
> Given our limited experience with actual deployment of fast 
> reauthentication mechanisms (Has anyone actually tested any sort of 
> interoperability of DIGEST-MD5 fast reauth?), I wouldn't want us to 
> give the impression that a mechanism that does not support fast 
> reauthentication is somehow less than fully compliant (yeah, ok, it is 
> only a SHOULD).
>
> If there's a demand for mechanisms that support fast reauth, then 
> those mechanisms will be written and implemented widely.  Currently, 
> that isn't the case, and I don't see a reason why the base document 
> needs to pass judgment on the matter.

Ok, this is a fair argument against the suggested text.

Alexey

P.S. You haven't answered the most difficult question (# 1). As you are 
the one who has raised the original objection, I would like to hear your 
comments.

To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>, Rob Siemborski <[email-masked]>
Subject: Re: Pending changes to the base SASL document
From: Sam Hartman <[email-masked]>
Date: Thu, 20 May 2004 14:05:17 -0400
Sender: [email-masked]

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey>   "SASL mechanisms SHOULD support fast reauthentication,
    Alexey> if practical."

    Alexey> Alexey

I don't like this text because it is not even clear what it means.

How about:

SASL mechanisms should be designed to minimize the number of round
trips required because SASL is used with protocols where connections
are short-lived.

As a side note, has thought been given in the HTTP case to having
mechanisms for reusing SASL contexts across connections?

Date: Thu, 20 May 2004 12:42:06 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: SASL WG <[email-masked]>
Subject: Re: Pending changes to the base SASL document
Sender: [email-masked]

On Wed, 19 May 2004, Alexey Melnikov wrote:

> 3). Some people are complaining that some SASL mechanisms use too many 
> roundtrips. This is a performance penalty for protocols like HTTP, where the 
> client can reconnect multiple times. Currently only DIGEST-MD5 and SRP have 
> support for fast reautentication. So, I would like to add the following 
> requirement to Section 5. ("Mechanism profile guidelines"). Please, let me 
> know if you agree or disagree.
> Suggested text:
>
> "SASL mechanisms SHOULD support fast reauthentication, if practical."

Given our limited experience with actual deployment of fast 
reauthentication mechanisms (Has anyone actually tested any sort of 
interoperability of DIGEST-MD5 fast reauth?), I wouldn't want us to give 
the impression that a mechanism that does not support fast 
reauthentication is somehow less than fully compliant (yeah, ok, it is 
only a SHOULD).

If there's a demand for mechanisms that support fast reauth, then those 
mechanisms will be written and implemented widely.  Currently, that isn't 
the case, and I don't see a reason why the base document needs to pass 
judgment on the matter.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 19 May 2004 22:00:57 +0100
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>, Rob Siemborski <[email-masked]>
Subject: Pending changes to the base SASL document
Sender: [email-masked]

I am waiting for resolution on one final issue before issuing a new 
revision of rfc2222bis that should be ready for Last Call.
Plus I have 2 minor new issues with suggested text.

1).
 empty versa missing additional data with success (text in 2 places).

Add to Section 4. ("Protocol profile requirements"):

"Note that SASL treats an empty additional data with success 
notification as equivalent to no additional data with success notification.
If the protocol allows for the additional data with success 
notification, the empty additional data SHOULD NOT be used, unless 
dictated otherwise by the protocol profile."

I am actually not sure myself about the last sentence. Should the 
document just say that an empty additional data with success is prohibited?

Add to Section 5. ("Mechanism profile guidelines"):

"As SASL treats an empty additional data with success notification as 
equivalent to no additional data with success notification, mechanisms 
that may distinguish between no additional data and empty additional 
data MUST use some encoding or escape mechanism when sending data 
semantically equivalent to the empty additional data with success."

The last sentence is awkward at best, any suggestions would be 
appreciated. Currently there is no SASL mechanism that make such 
distinction, but, IMHO, the warning should be added.

=====
New issues:

2). Servers need to perform profile specific mapping from a mechanism 
specific authorization identity to profile specific form. The profile 
specific form is used internally by the server (for example for 
logging), but can often be used by the protocol for access control. In 
order for the client to determine the result of any such mapping, the 
protocol should have a command or option to return it to the client. For 
example, LDAP has 2 ways to achieve this: "Who am I" extended operation 
and a control that can request for mapping information to be returned 
upon successful authentication. I felt that this is a feature common to 
all protocols, and thus should be mentions in the base SASL document. 
Kurt suggested the following text for addition to Section 4. ("Protocol 
profile requirements"):

        Where the application-layer protocol does not precisely state
        how identities established through SASL relate to identities
        used elsewhere (e.g., access controls) in the application-layer
        protocol, it may be useful for the application-layer protocol
        to provide a facility which the client may use to discover the
        identity used.

Any objections?

3). Some people are complaining that some SASL mechanisms use too many 
roundtrips. This is a performance penalty for protocols like HTTP, where 
the client can reconnect multiple times. Currently only DIGEST-MD5 and 
SRP have support for fast reautentication. So, I would like to add the 
following requirement to Section 5. ("Mechanism profile guidelines"). 
Please, let me know if you agree or disagree.
Suggested text:

  "SASL mechanisms SHOULD support fast reauthentication, if practical."

Alexey

To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Use of NFKC in SASLprep
From: Sam Hartman <[email-masked]>
Date: Mon, 03 May 2004 17:06:45 -0400
Sender: [email-masked]

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> "Kurt D. Zeilenga" <[email-masked]> writes:

    >> It's my opinion that that this issue, aside from noting its
    >> existence, should be addressed in NFKC by the UTC, then in
    >> Stringprep by the IETF, and lastly in SASLprep by this WG.  But
    >> we shouldn't wait for this, we should publish what we have as
    >> being "good enough" and then revise once the upstream
    >> specifications have been appropriately revised.

    Simon> Without qualifying this, this means abandoning the
    Simon> invariant SASLprep2(SASLprep(X)) = SASLprep(X), and given
    Simon> the details of PR-29 even abandoning SASLprep(SASLprep(X))
    Simon> = SASLprep(X), in a few cases.  In an earlier discussion
    Simon> about SASLprep the argument was, as far as I can recall,
    Simon> that my proposed text regarding storing SASLprep strings in
    Simon> databases was not needed, because the invariant was implied
    Simon> by other specifications.  

I think the invariant is implied and that it is our job to assume the
invariant shall be maintained regardless of whether it actually is.
We should make sure the authors of stringprep know we're going forward
with the assumption of this invariant and agree doing so is the right
course of action.

If we ever violate this invariant we should do so with the
understanding that the practical consequences of assuming the
invariant and violating it in the manner we actually violate it are
acceptable.

Another point to consider regarding this issue: the IDN working group
set an interesting precedent by choosing not to correct UNicode bugs
in their working group.  They decided they were not qualified to do so
and the IETF was not the appropriate forum.  If we choose to take a
different course of action, we should have strong justification for
why their reasoning does not apply to our circumstance.

--Sam

Date: Mon, 3 May 2004 12:49:24 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Cc: [email-masked]
Subject: Re: Use of NFKC in SASLprep
Mail-Followup-To: Jeffrey Altman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Sun, May 02, 2004 at 11:33:00AM -0400, Jeffrey Altman wrote:
> Has anyone asked the authors of StringPrep their opinion?
> 
> Clearly this problem needs to be addressed not in SASLPrep
> but in a revision to StringPrep as it affects all profiles
> based on StringPrep.  Modifying SASLPrep will only cause
> more problems if the solution adopted for StringPrep is
> incompatible.

My take is that this is easy to fix in Unicode itself, as per-the
recommendations in pr-29, in part because there exist Unicode
implementations which do not have this problem and some that do and
there's no better place to fix this than in Unicode where all downstream
consumers of NFKC would benefit automatically.  But see below.

We have:

 - UAX #15 is internally inconsistent,
    - the inconsistency results in NFKC(NFKC(x) != NFKC(x)
    - but only for rather unrealistic instances of 'x'
    - which, nonetheless should cause us some concern

 - But some implementations don't have this problem,
 - and the fix to UAX #15 seems rather simple (but it's possible that
   there's more than meets the untrained eye...)

All of which makes me think that Unicode is the right place to fix the
problem and that we should wait for the Unicode consortium to issue a
corrigendum or other statement before doing much of anything about this.

Until then a security considerations warning about the troublesome input
sequences ought to suffice, methinks.

Mor importantly, rather than discuss this matter at the SASL or KRB or
any other IETF WG I'd prefer to see this discussed more broadly and, if
possible, get some input from the relevant area directors.  Perhaps this
matter should be taken up with the IETF liason to the Unicode
consortium.

Cheers,

Nico
-- 

Date: Sun, 02 May 2004 11:33:00 -0400
From: Jeffrey Altman <[email-masked]>
Organization: No Longer Affiliated with Columbia University in the City of New York
To: [email-masked]
Subject: Re: Use of NFKC in SASLprep
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------020601000203090405030703
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Kurt D. Zeilenga wrote:

>>and prohibit them in SASLprep output.
>>
>
>How?  Stringprep prohibit step is designed to prohibit on
>a per code point basis.  We'd effectively have to design
>a new prohibit step for the algorithm.  Why should that be
>done in a SASLprep-specific manner?  If the most appropriate
>thing to do is prohibit certain sequences in the short term,
>wouldn't it make better sense to update stringprep so that
>all stringprep profiles do it in a like way?
>
>Kurt
>
Has anyone asked the authors of StringPrep their opinion?

Clearly this problem needs to be addressed not in SASLPrep
but in a revision to StringPrep as it affects all profiles
based on StringPrep.  Modifying SASLPrep will only cause
more problems if the solution adopted for StringPrep is
incompatible.

Jeffrey Altman

--------------020601000203090405030703
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Bitstream Cyberbit">Kurt D. Zeilenga wrote:</font>
<blockquote cite="[email-masked]"
 type="cite">
  <blockquote type="cite">
    <pre wrap=""><font face="Bitstream Cyberbit">and prohibit them in SASLprep output.
</font></pre>
  </blockquote>
  <pre wrap=""><!----><font face="Bitstream Cyberbit">
How?  Stringprep prohibit step is designed to prohibit on
a per code point basis.  We'd effectively have to design
a new prohibit step for the algorithm.  Why should that be
done in a SASLprep-specific manner?  If the most appropriate
thing to do is prohibit certain sequences in the short term,
wouldn't it make better sense to update stringprep so that
all stringprep profiles do it in a like way?

Kurt
</font></pre>
</blockquote>
Has anyone asked the authors of StringPrep their opinion?<br>
<br>
Clearly this problem needs to be addressed not in SASLPrep <br>
but in a revision to StringPrep as it affects all profiles<br>
based on StringPrep.&nbsp; Modifying SASLPrep will only cause<br>
more problems if the solution adopted for StringPrep is <br>
incompatible.<br>
<br>
Jeffrey Altman<br>
<br>
<br>
</body>
</html>

--------------020601000203090405030703--

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Use of NFKC in SASLprep
Date: Sat, 01 May 2004 21:04:00 +0200
Lines: 27
Cancel-Lock: sha1:aZnUrIp1XQoTPAqW1TmvDkT8NIQ=
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:

>>and prohibit them in SASLprep output.
>
> How?  Stringprep prohibit step is designed to prohibit on
> a per code point basis.  We'd effectively have to design
> a new prohibit step for the algorithm.

Right.

> Why should that be done in a SASLprep-specific manner?  If the most
> appropriate thing to do is prohibit certain sequences in the short
> term, wouldn't it make better sense to update stringprep so that all
> stringprep profiles do it in a like way?

I'm not sure.  It is conceivable that what makes sense for SASLprep
does not make sense for Stringprep in general.  If the authors
responsible for the Stringprep revision think what you propose makes
sense, then I would agree.  (I wouldn't call that a short term
solution, though.)  But if not, and if they don't have another
solution in mind, I believe idempotency is important enough, for
security reasons, that SASLprep should fixed, instead of being
published as-is.  I'm told the Stringprep authors are preparing a
statement on this issue, though, which might give other alternatives.

Thanks,
Simon

Date: Sat, 01 May 2004 11:32:53 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of NFKC in SASLprep
Cc: [email-masked]
Sender: [email-masked]

At 09:55 AM 5/1/2004, Simon Josefsson wrote:
>"Kurt D. Zeilenga" <[email-masked]> writes:
>> Simon,
>> As you don't appear to support my suggestion, I wonder
>> alternative you suggest we undertake.  Wait?
>
>Short term: Evaluate the completeness of the problem sequences
>described in PR-29,

I rather leave that to the UTC.

>and prohibit them in SASLprep output.

How?  Stringprep prohibit step is designed to prohibit on
a per code point basis.  We'd effectively have to design
a new prohibit step for the algorithm.  Why should that be
done in a SASLprep-specific manner?  If the most appropriate
thing to do is prohibit certain sequences in the short term,
wouldn't it make better sense to update stringprep so that
all stringprep profiles do it in a like way?

Kurt

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: Use of NFKC in SASLprep
From: Simon Josefsson <[email-masked]>
Date: Sat, 01 May 2004 18:55:55 +0200
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:

> Simon,
>
> As you don't appear to support my suggestion, I wonder
> alternative you suggest we undertake.  Wait?

Short term: Evaluate the completeness of the problem sequences
described in PR-29, and prohibit them in SASLprep output.  As I
understand it, this would be sufficient to make SASLprep idempotent.
A system where the user identifiers change several times after
repeated use of SASLprep, i.e. non-idempotent SASLprep, is not robust
and is difficult to analyze.

Medium term: Describe the usage of SASLprep in detail.  If necessary,
it might be possible to do this even after the actual SASLprep
algorithm has been published.  If the invariant
SASLPrep2(SASLprep(X))=SASLPrep2(X) is not written into SASLprep as a
commitment to the future, I'd like to open the question of not using
the AllowUnassigned flag, as removing it would simplify the SASLprep
usage.  It is a telling sign that, as far as I can tell, none of the
current SASL mechanism documents discuss when to set the flag.  If
removal isn't an option, the use of the flag should be discussed in
the documents.

Long term: Write a requirements document based on the non-technical
needs internationalized users have, and implement a solution to those
requirements.  My impression is that SASLprep has been driven by
technical goals, with a world view centered around a StringPrep
solution from the start.

Hope this helps,
Simon

Date: Sat, 01 May 2004 07:48:57 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of NFKC in SASLprep
Cc: [email-masked]
Sender: [email-masked]

Simon,

As you don't appear to support my suggestion, I wonder
alternative you suggest we undertake.  Wait?

Kurt

At 03:43 AM 5/1/2004, Simon Josefsson wrote:

>"Kurt D. Zeilenga" <[email-masked]> writes:
>
>> It's my opinion that that this issue, aside from noting its
>> existence, should be addressed in NFKC by the UTC, then in
>> Stringprep by the IETF, and lastly in SASLprep by this WG.
>> But we shouldn't wait for this, we should publish what we
>> have as being "good enough" and then revise once the upstream
>> specifications have been appropriately revised.
>
>Without qualifying this, this means abandoning the invariant
>SASLprep2(SASLprep(X)) = SASLprep(X), and given the details of PR-29
>even abandoning SASLprep(SASLprep(X)) = SASLprep(X), in a few cases.
>In an earlier discussion about SASLprep the argument was, as far as I
>can recall, that my proposed text regarding storing SASLprep strings
>in databases was not needed, because the invariant was implied by
>other specifications.  I just hope everyone pushing this forward is
>able to visualize the entire long-term puzzle, as I know I'm having
>difficulties with the SASLprep piece.
>
>Another comment on PR-29: it may be that the problematic INPUT code
>points to NFKC do not occur naturally, but as far as security is
>concerned there is another question: the OUTPUT code points must also
>not occur naturally.  Otherwise, someone may be able to use
>"unnatural" code points to bypass the first security perimeter, and
>have the input changed (NFKC) into some "natural" code point once
>inside the security system.  Also, simply having NFKC(NFKC(x)) !=
>NFKC(x) may generate weird corner cases that could be exploited.
>
>Thanks,
>Simon

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Use of NFKC in SASLprep
Date: Sat, 01 May 2004 12:43:06 +0200
Lines: 30
Cancel-Lock: sha1:aYmeBz67Vuc+LT3AMpIgsaRxGZI=
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:

> It's my opinion that that this issue, aside from noting its
> existence, should be addressed in NFKC by the UTC, then in
> Stringprep by the IETF, and lastly in SASLprep by this WG.
> But we shouldn't wait for this, we should publish what we
> have as being "good enough" and then revise once the upstream
> specifications have been appropriately revised.

Without qualifying this, this means abandoning the invariant
SASLprep2(SASLprep(X)) = SASLprep(X), and given the details of PR-29
even abandoning SASLprep(SASLprep(X)) = SASLprep(X), in a few cases.
In an earlier discussion about SASLprep the argument was, as far as I
can recall, that my proposed text regarding storing SASLprep strings
in databases was not needed, because the invariant was implied by
other specifications.  I just hope everyone pushing this forward is
able to visualize the entire long-term puzzle, as I know I'm having
difficulties with the SASLprep piece.

Another comment on PR-29: it may be that the problematic INPUT code
points to NFKC do not occur naturally, but as far as security is
concerned there is another question: the OUTPUT code points must also
not occur naturally.  Otherwise, someone may be able to use
"unnatural" code points to bypass the first security perimeter, and
have the input changed (NFKC) into some "natural" code point once
inside the security system.  Also, simply having NFKC(NFKC(x)) !=
NFKC(x) may generate weird corner cases that could be exploited.

Thanks,
Simon