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

[Peter Saint-Andre <stpeter@xxxxxxxxxx>]

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

On 7/30/09 6:38 PM, Alexey Melnikov wrote:
> Peter Saint-Andre wrote:
> 
>> On 7/30/09 11:12 AM, Alexey Melnikov wrote:
>>  
>>
>>> Peter Saint-Andre wrote:
>>>   
> [...]
> 
>>>> SECTION 5.1
>>>>     
>>>> 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.
>>  
>>
> Can you recommend a better text?

So I looked at this again. The concept of a "simple username" has always
been fuzzy to me. It is described in the SASLprep document, RFC 4013. It
seems to be the localpart, not <localpart>[@<domain>] (at least, all the
examples in RFC 4013 look like localparts).

In any case, Alexey and I just talked about this in Stockholm and I
think the confusion comes in from RFC 3920, so I need to fix this in
rfc3920bis.

>>>> 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).
>>  
>>
> This applies to authorization identities in XMPP. Authorization identity
> format is protocol specific.

I thought that "a" was authorization identity and "n" was authentication
identity, no? In any case, I think the fixes belong in rfc3920bis, so I
shall work on that and remain quiet about this issue in the SCRAM doc.

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/

iEYEARECAAYFAkpx17sACgkQNL8k5A2w/vyNnACgi6Pxy7hZ83tfGBDr/1ux8g7t
U00AoPqTXMsKkpuw3mxh7m2BrPdTZ0lV
=c1Ip
-----END PGP SIGNATURE-----