Re: [xmpp] 3920bis: authentication identity

[Peter Saint-Andre <[e-mail]>]

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:
> 
> 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.
> 
> 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.  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.
> 
> 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.
> 
> A third approach would be to say that the "username" 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.

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

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.

***

Peter

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