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

[Alexey Melnikov <alexey.melnikov@xxxxxxxxx>]

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.