Re: draft-ietf-sasl-rfc2222bis-02 comments

[Alexey Melnikov <Alexey.Melnikov@xxxxxxxxx>]

Hallvard B Furuseth wrote:

> Sorry about coming with these comments so late.  I have just discovered
> the SASL list, and there was a lot to read:-)
> Feel free to ignore comments that have already been discussed.  
>
> > 4.    Authentication mechanisms
> >
> >   SASL mechanisms are named by
> >    
>
> ASCII
>
>  
>
> >   strings,
> >   (...)
> >   mech-char    = %x41-5A / DIGIT / "-" / "_"
> >                  ; mech names restricted to uppercase
> >    
>
> ASCII
Ok.

> > letters,
> >                  ; digits, "-" and "_"    
> >
> >   SASL mechanism names must be registered with the IANA.
> >   IETF Standards Track documents may override this registration
> >   requirement by reserving a portion of the SASL mechanism namespace
> >   for their own use;
> >    
>
> Huh?  So I must search through all Standards Track RFCs as well as the
> IANA registry in order to find out if a mechanism name is reserved?
> Why not register these name reservations with IANA too?
IMHO, this was the intent. I will try to clarify this.

> > 4.1.  Authentication protocol exchange
> >
> >   A SASL mechanism is responsible for conducting an authentication
> >   protocol exchange.  This consists of a series of server challenges
> >   and client responses,    
>
> Does this mean that the initial auth command from the client is not
> considered part of the authentication protocol exchange?
Does it matter in this section?

> > 4.2.  Authorization identities and proxy authentication
> >
> >   (...)
> >   The character encoding scheme used for transmitting an authorization
> >   identity over protocol is specified in each authentication mechanism
> >   (with the authentication mechanism's blob being further
> >    
>                                          ^^^^
>
> What's a blob?  I don't think it's 'something ill-defined or amorphous',
> like the dictionary says:-)
I've changed this to "data".

> > 4.3.  Security layers
> >
> >   If use of a security layer is negotiated by the authentication
> >   protocol exchange, the security layer is applied to all subsequent
> >   data sent over the connection    
>
> ... until another security layer or no security layer is negotiated.
>
> [Added according to section 6.3.]
>
>  
Done.

> >   In
> >   order to avoid noninteroperability due to differing normalizations,
> >   when a mechanism specifies that a string authentication identity or
> >   password used as input to a cryptographic function (or used for
> >   comparison) it SHOULD specify that the string first be prepared using
> >   the "SASLPrep" profile [SASLPrep], of the "stringprep" algorithm
> >   [StringPrep].  This should be done by both the client (upon getting
> >   user input or retrieving a value from configuration) and by the
> >   server (upon receiving the value from the client).
> >    
>
> What's the point of this duplicate preparation?  Why not do it only
> at the server side?
>  
Because if the client doesn't do that, the hash calculated on the server 
will not match the one calculated on the client.

> >   A service name, to be selected from the IANA registry of "service"
> >   elements for the GSSAPI host-based service name form. [GSSAPI]    
>
> Nitpick: I think the period should be after [GSSAPI].
Fixed.

> >   This
> >   service name is made available to the authentication mechanism.
> >    
>
> There should be no paragraph break here.
Fixed.

> >   The registry is available at the URL
> >   "http://www.iana.org/assignments/gssapi-service-names";
> >    
>
> Instead, a paragraph break here.  (And a trailing '.'.)
>  
Fixed.

> >   A definition
> >   of the command to initiate the authentication protocol exchange.
> >    
> >
> >   The command SHOULD have a method for the server to include an
> >   optional challenge with a success notification.
> >    
>
> I suggest you rename "an optional challenge" to "optional data", or
> put "challenge" in quotes.
>  
Ok.

> >   A protocol profile MAY further refine the definition of an
> >   authorization identity by adding additional syntactic restrictions
> >   and protocol-specific semantics.
> >    
>
> Add a paragraph break here, since the following is a new item.  Remove
> "A protocol profile MUST specify" to just make the following a new item
> in the list of things that must be specified.
>
>  
>
> >   A protocol profile MUST specify the
> >   form of the authorization identity (as it is protocol specific, as
> >   
I would rather not do this, as this is a single logic item.

>  
>
> > 6.3.  Multiple authentications
> >
> >   Unless otherwise stated by the protocol's profile, only one
> >   successful SASL negotiation may occur in a protocol session.
> >    
>
> This should be mentioned in the "Protocol profile requirements" section.
I agree.

> > 7.1.  Formal syntax
> >
> >   initial-response  = *( UTF8-char-no-null )
> >    
>
> Why is initial-response required to be UTF-8 when the character encoding
> scheme of the rest of the exchange is left to the specifications of the
> individual mechanisms?  I would think that either initial-response
> merely "SHOULD" be UTF-8, like the rest of the exchange.
This is specific to EXTERNAL.
I've changed "initial-response" to "extern-init-resp" in order to avoid 
confusion.

> And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the
> top.
I've added a sentence about this in the introduction section.

Alexey

>