Re: [xmpp] 3920bis: authentication identity

[Alexey Melnikov <[e-mail]>]

Hi Peter,
I should have paid more attention to this thread ;-).

Peter Saint-Andre wrote:

>On 12/18/09 4:49 PM, Peter Saint-Andre wrote:  
>
>>RFC 3920 does not specify whether the authentication identity in XMPP's
>>use of SASL is localpart or [e-mail]. Someone reported to me
>>earlier today that this has been interpreted differently by different
>>XMPP software implementations. Both RFC 3920 and draft-ietf-xmpp-3920bis
>>have examples only of localpart, however it is not clearly specified in
>>the text -- and in the case of a server that provides virtual hosting
>>one could argue that the authentication identity should be the bare JID
>>[e-mail] instead of just localpart. IMHO we need to clarify
>>this in draft-ietf-xmpp-3920bis.
>>
>>The use of localpart instead of [e-mail] seems to be
>>consistent with the following SASL mechanisms:
>>
DIGEST-MD5, CRAM-MD5, SCRAM and PLAIN are all using "simple usernames" 
for authentication identities. The simplified explanation for it is 
something that looks like: <lhs>[@<domain>]. So in fact both "just local 
part" and "full form" are allowed here.

>>1. DIGEST-MD5 (RFC 2831), where the field "username" is described as
>>"the user's name in the specified realm".
>>
>>2. CRAM-MD5 (draft-ietf-sasl-crammd5), which also specifies a "username"
>>field.
>>
>>3. SCRAM (draft-ietf-sasl-scram), which states that field "n" is "the
>>name of the user whose password is used for authentication".
>>
>>The use of [e-mail] seems to be consistent with the
>>following SASL mechanism:
>>
>>4. EXTERNAL (RFC 4422 and XEP-0178) given that id-on-xmppAddr in a
>>client certificate is supposed to be a bare JID.
>>
>>By contrast, the SASL PLAIN mechanism (RFC 4616) is ambiguous, because
>>the field "authcid" is described as "free-form" and we never clarified
>>this in RFC 3920.
>>
I would agree that mechanism definitions could be clearer.

>>The core SASL spec (RFC 4422) states that authentication identities are
>>"mechanism specific" and also says:
>>
>>   However, the precise form(s) of the authentication identities (used
>>   within the server in its verifications, or otherwise) and the precise
>>   form(s) of the authorization identities (used in making authorization
>>   decisions, or otherwise) are beyond the scope of SASL and this
>>   specification.
>>
To clarify: this is talking about canonicalized authentication and 
authorization identities that are used internally by applications once 
authentication completes successfully. In particular, it declares 
representation of identities in access control lists out of scope for 
the SASL spec.

>>In some circumstances, the precise identity forms
>>   used in some context outside of the SASL exchange may be dictated by
>>   other specifications.  For instance, an identity assumption
>>   authorization (proxy authorization) policy specification may dictate
>>   how authentication and authorization identities are represented in
>>   policy statements.
>>
>>Some would argue that the exact domain name could be encapsulated in the
>>"realm" but not all SASL mechanisms use "realm" (e.g., it is not part of
>>PLAIN or SCRAM), so we can't depend on that.
>>
Right. But the realm is not even used in many DIGEST-MD5 
implementations. Cyrus SASL has a hardcoded realm and allows 
<local>@<domain> form.

>>Another approach would be to take the domain from the 'to' address of
>>the initial stream header that the server receives from the client, but
>>that strikes me as a bit messy, especially in the case where the stream
>>header is sent over an unencrypted stream.
>>    
>>
This sounds like an implementation detail. A 
DIGEST-MD5/CRAM-MD5/SCRAM/PLAIN implementation that sees an 
authentication identity consisting of only the localpart can chose to do 
that to canonicalize the authentication identity. Or it might choose to 
disallow localpart-only usernames.

>>A third approach would be to say that the "username"
>>
Username usually equates with the authorization identity. Do you mean it 
here?

>>in XMPP's use of
>>SASL is always a bare JID. I think I would prefer that because we can
>>make it consistent across all SASL mechanisms, but in practice many
>>clients are probably sending a localpart only because that's what the
>>examples show in RFC 3920 and draft-ietf-xmpp-3920bis.
>>
>
>To clarify this point, I have rewritten the old section on "Simple
>Usernames" to read as follows.
>
>***
>
>7.2.7.  Authentication Identity
>
>The predecessor to this specification did not define the exact form of
>the authentication identity provided during SASL negotiation.
>
Well, this is in violation of RFC 4422. However, if you rephrase this 
section as recommending which form of simple usernames should be used in 
XMPP, then it would become acceptable to me.

Note that wording this in terms of "simple usernames" would be Ok, but 
generalizing this to arbitrary authentication identities would not be. 
Authentication identities are mechanism specific. For example, if we 
take GSSAPI or GS2-KRB5 SASL mechanisms, the authentication identity is 
a Kerberos principal. It might look like a SASL simple username, but it 
is from an entirely different namespace.

>The matter is unambiguous for server-to-server communication, since the
>only authentication identity that the initiating entity could provide is
>its sending domain, which usually is a fully qualified domain name as
>contained in an XMPP domainpart.
>
>Unfortunately, the matter is ambiguous for client-to-server
>communication because the core SASL specification states that the
>precise form of an authentication identity is beyond the scope of SASL
>(perhaps leaving it up to the using protocol)
>
While I agree with the beginning of this sentence, the part in () was 
not intended by the SASL spec.

>and because the various
>SASL mechanisms have described authentication identities in an
>inconsistent way. For example, the CRAM-MD5, DIGEST-MD5, and SCRAM
>mechanisms seem to imply that the authentication identity would be the
>localpart of an XMPP address (sometimes also called a "simple
>username"), whereas the EXTERNAL mechanism seem to imply that the
>authentication identity would be a bare JID <localpart@domainpart>.
>
As I explained earlier, I don't think this sentence is accurate.

>For the sake of consistency and interoperability (as well as provision
>of virtual hosting at XMPP server deployments), this specification
>stipulates that the authentication identity provided by an XMPP client
>to an XMPP server during SASL negotiation MUST be a bare JID
><localpart@domainpart>, not the localpart only. However, because this
>matter was unspecified in the predecessor to this specification, it is
>possible that implementations based on that predecessor will send
>authentication identity that is the localpart only, not the bare JID.
>
The last sentence suggests that the previous MUST should be a SHOULD 
instead.