RFC 3920 does not specify whether the authentication identity in XMPP's
use of SASL is localpart or localpart@domain.tld. 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
localpart@domain.tld instead of just localpart. IMHO we need to clarify
this in draft-ietf-xmpp-3920bis.

The use of localpart instead of localpart@domain.tld 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 localpart@domain.tld 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.

Feedback is welcome.

Peter

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