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

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 30 Sep 2003 22:48:12 +0200

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

> 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?

> 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?

> 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:-)

>    The identity derived from the client's authentication credentials is
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^

Could you briefly define what authentication is, as opposed to
authorization?

> 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.]

> 4.4.  Character string issues
>
>    Per IETF character set policy [CHARSET-POLICY], authentication
>    mechanisms SHOULD encode character strings in UTF-8 [UTF-8].

Paragrah break, or reformulate to make clear that the following does not
come from [CHARSET-POLICY].

>    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?

> 5.    Protocol profile requirements
>
>    In order to use this specification, a protocol definition MUST supply
>    the following information:

The following would be easier to scan through if it was formatted as a
list (e.g. with a * in front of each indented item) - up to but not
including the "Certain SASL mechanisms..." paragraph, I think.

>    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].

>    This
>    service name is made available to the authentication mechanism.

There should be no paragraph break here.

>    The registry is available at the URL
>    "http://www.iana.org/assignments/gssapi-service-names"

Instead, a paragraph break here.  (And a trailing '.'.)

>    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.

>    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

>    Certain SASL mechanisms, e.g. DIGEST-MD5 [SASL-DIGEST], use a concept
>    of realm. (...)  The realm value is a case-
>    insensitive string, generally assigned by the origin server, which

It seems to me it is not rfc2222bis' business to define realms as
case-insensitive.  The mechanism defintions can do that.  I think
rfc2222bis should only say that it usually is case-insensitive, or maybe
say that it "SHOULD" be.  As it is, a mechanism can define a "case-
sensitive realm" if it wants to anyway, provided it confuses the issue
by calling it something else than a "realm".

> 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.

> 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.

> 10.   Security considerations
>
>    The mechanisms that support integrity protection

What is integrity protection?  Please give a brief definition.

>    When the client selects a security layer
>    with at least integrity protection,
          ^^^^^^^^
I think you can strike "at least".  It looks strange and I don't see
what it gains to have it there.

And, as I mentioned, there should be an 'Obsoletes: rfc 2222' at the
top.

-- 
Hallvard