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

[Peter Saint-Andre <stpeter@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/14/09 4:17 AM, Tom Yu wrote:
> This message commences a WG Last Call on the following Internet-Draft:
> 
> 	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
> 	Author(s)       : A. Menon-Sen, et al.
> 	Filename        : draft-ietf-sasl-scram-02.txt
> 	Pages           : 33
> 	Date            : 2009-07-08
> 
> This Last Call will expire on 03 August 2009.  This document is
> intended for the Standards Track.  Please review this document and
> send technical feedback to the WG mailing list, and editorial comments
> to the authors.

Some nits...

SECTION 2

Typo: "family of mechanism" => "family of mechanisms"

The second paragraph references security layers, which are not
previously defined (and no reference is made to RFC 5056 here).

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.

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

SECTION 4

Typo: "hashed function" => "hash function"

I think the following text is slightly ambiguous:

   The "-PLUS" suffix is used only when the server supports channel
   binding to the external channel.  In this case the server will
   advertise both, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS, otherwise the
   server will advertise only SCRAM-SHA-1.  The "-PLUS" exists to allow
   negotiation of the use of channel binding.  See Section 6.

This could be read to mean that if a server does not support channel
bindings, then it will advertise only all and only SCRAM-SHA-1 (but
never, say, SCRAM-SHA-256). I think we mean that if a server does not
support channel bindings, then it will advertise only mechanisms of the
form SCRAM-SHA-length and never mechanisms of the form
SCRAM-SHA-length-PLUS (thus not forbidding support for hash functions
other than SHA-1).

SECTION 5

There is an example of "tls-server-end-point" but no reference for this
channel binding type.

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?

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

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?

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

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?

SECTION 6

Typo: "MUST chose" => "MUST choose"

SECTION 8.2

Typo: "SHALL BE" => "SHALL be"

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.

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpwOWQACgkQNL8k5A2w/vz7DQCgnMe2cKkgYMVDpr2ASq12qZtq
HmIAoIfo0DVjeOLyJkZvVnc7UsCxa+f9
=smy1
-----END PGP SIGNATURE-----