Subject: Pending changes to the base SASL document

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 May 2004 22:00:57 +0100

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