Re: WG Last Call: draft-ietf-sasl-scram-02

[Alexey Melnikov <[e-mail]>]

Peter Saint-Andre wrote:

>Some nits...
>  
>
Some of there are more than just nits :-).
Thank you for the review!
I've responded/addressed most of your comments in my copy, I will reply 
to the rest in a separate message.

>SECTION 2
>
>Typo: "family of mechanism" => "family of mechanisms"
>
Fixed.

>The second paragraph references security layers, which are not
>previously defined
>
Added the reference to RFC 4422.

>(and no reference is made to RFC 5056 here).
>  
>
It is referenced in my copy.

>Under protocol features, the document says that "A standard attribute is
>defined to enable storage of the authentication information in LDAPv3"
>but I don't see where this attribute is defined in the spec.
>  
>
This needs an informative reference to another draft I am editing. I 
will add.

>SECTION 3
>
>The specification assumes that "the client is in possession of a
>username and password"; does it make sense to mention the fact that
>passwordless login can occur in this world (Kerb, X.509, etc.)?
>  
>
I don't think this would help readability. I've changed "the client" to 
"the SCRAM client" in my copy. Is it any better?

>SECTION 4
>
>Typo: "hashed function" => "hash function"
>  
>
 [...]

>SECTION 5
>
>There is an example of "tls-server-end-point" but no reference for this
>channel binding type.
>  
>
I will add an informative reference.

>SECTION 5.1
>
>For the definition of "n", the text says that "a client must include it
>in its first message to the server"; do we mean MUST here?
>
Sure.

>The "n" attribute specifies a username. Is it up to the using protocol
>define exactly what a username is? I am thinking of hosting providers
>that might host multiple domains for a given service, such that the the
>username is not a "local-part" but could include a domain name (XMPP is
>but one example; others might include IMAP).
>  
>
My copy already says:
    This attribute specifies the name of the
    user whose password is used for
    authentication (a.k.a. "authentication identity" <xref 
target='RFC4422'/>).

And according to RFC 4422, each mechanism defines how authentication 
identity looks like.
For SCRAM it is a "simple username" (i.e. <localpart>[@<domain>]), for 
Kerberos it is a Kerberos principal, etc.

>For the "n" attribute, "the server SHOULD prepare it using the
>"SASLPrep" profile". Under what circumstances is it appropriate for the
>server to not prepare the value according to SASLPrep?
>
This is a cut&paste from the DIGEST-MD5 update I was working on. If I 
remember correctly there was some objection to making this a MUST. To 
this day many implementors don't implement SASLPrep, so I think this is 
a reasonable compromise.

>Typo: "It is important that this be value" => "It is important that this
>value be"
>
>Typo: missing close paren after the reference to RFC 5056
>  
>
Both fixed.

>For the "i" attribute, the text says that it "must be sent by the server
>along with the user's salt"; do we mean MUST here?
>  
>
Yes.

>SECTION 6
>
>Typo: "MUST chose" => "MUST choose"
>
>SECTION 8.2
>
>Typo: "SHALL BE" => "SHALL be"
>  
>
Both fixed.

>APPENDIX A
>
>CRAM-MD5 is mentioned as another authentication mechanism, seemingly
>with the meaning that SCRAM is intended to obsolete CRAM-MD5. I recall
>an objection by John Klensin at the mic in San Francisco that in fact
>SCRAM is intended to obsolete DIGEST-MD5 but not CRAM-MD5. But perhaps
>that is a matter for draft-ietf-sasl-crammd5-to-historic, not this
>specification.
>  
>
Agree with the last sentence.