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

[Peter Saint-Andre <stpeter@xxxxxxxxxx>]

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

On 7/30/09 11:12 AM, Alexey Melnikov wrote:
> Peter Saint-Andre wrote:
> 
>> Some nits...
>>  
>>
> Some of there are more than just nits :-).

Well, they're not huge issues. :)

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

I suppose it's fine just to say "the client". My nit was directed elsewhere.

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

My concern is that "the name of the user" could be construed to mean
"localpart", which is commonly called the "username" portion of an address.

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

Again, my concern is that some other preparation rule might be
appropriate (e.g., in XMPP localpart@xxxxxxxxxx is prepared according to
two separate rules because there is one rule for localpart and another
rule for domain).

Thanks!

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/

iEYEARECAAYFAkpxyHYACgkQNL8k5A2w/vyrqACg6XRsoSbUDGztW/1umvLduyHt
frEAn0Fhj9Sq01Yke87BLik6IVhmMdZD
=h6jA
-----END PGP SIGNATURE-----