[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-sasl-rfc2222bis-02 comments
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