Subject: Re: [xmpp] 3920bis: authentication identity

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 06 Mar 2010 20:49:15 -0700

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 [email-masked]. 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
> [email-masked] instead of just localpart. IMHO we need to clarify
> this in draft-ietf-xmpp-3920bis.
> 
> The use of localpart instead of [email-masked] 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 [email-masked] 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/

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 07 Mar 2010 18:13:34 +0000

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

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

>>the field "authcid" is described as "free-form" and we never clarified
I would agree that mechanism definitions could be clearer.

>>   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
Right. But the realm is not even used in many DIGEST-MD5 
implementations. Cyrus SASL has a hardcoded realm and allows 
<local>@<domain> form.

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

>(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
As I explained earlier, I don't think this sentence is accurate.

>authentication identity that is the localpart only, not the bare JID.
The last sentence suggests that the previous MUST should be a SHOULD 
instead.

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 7 Mar 2010 11:50:15 -0800

On Mar 7, 2010, at 10:13 AM, Alexey Melnikov wrote:

> DIGEST-MD5, CRAM-MD5, SCRAM and PLAIN are all using "simple usernames" for authentication identities.

From a protocol specification (and implementation) perspective, one cannot assume that there is any relationship between credentials used in one mechanism with credentials used in another mechanism.

From a deployment perspective, it is good practice to relate credentials used in one mechanism with those in other mechanisms.  But that's a deployment issue (which will depend highly on implementation details, such as whether we're only talking password-based realm-less mechanisms and the server implementation utilizes a mechanism-independent user/password database store.  (Once you throw concepts like DIGEST-MD5's realm things get messy fast.)

I rather not detail what some might consider "best deployment practices" or "best implementation practices", especially with the core RFCs, as these might be taken as normative statements intended to restrict what today is left to implementors.

-- Kurt

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 07 Mar 2010 19:26:16 -0700

On 3/7/10 11:13 AM, Alexey Melnikov wrote:

<snip/>

> XMPP, then it would become acceptable to me.

I meant:

"The predecessor to this specification did not define the exact form of
the authentication identity provided during SASL negotiation in XMPP."

Clearly we are not legislating for SASL or for any other protocol that
uses SASL, only for XMPP's use of SASL.

> generalizing this to arbitrary authentication identities would not be.

So as a general approach, if we change "authentication identity" back to
"simple username" we should be OK (with appropriate other changes in
wording)?

> not intended by the SASL spec.

Understood. I've fixed that up a bit in my working copy (complete text
pasted at the end of this message).

> The last sentence suggests that the previous MUST should be a SHOULD

IMHO we can say MUST as our go-forward policy and even if this means
that older implementations are no longer compliant (it's not as if we
are changing the requirement, only specifying something that was left
unspecified before). Practically speaking, it doesn't make much of a
difference because if implementations currently have code that appends
the domainpart to the localpart then they'll probably have such code
forever. But SHOULD might be better if there are legitimate scenarios in
which you would not want to send a bare JID but instead send a localpart
only. So I'll change it to SHOULD for now and we can discuss in Anaheim
or on the list.

Updated text:

***

7.2.7.  Simple Username

The predecessor to this specification did not define the exact form of
the so-called "simple username" provided during SASL negotiation in XMPP.

The matter is unambiguous for server-to-server communication, since the
only simple username 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 leaves the precise
form of the simple username up to the SASL mechanism and because the
various SASL mechanisms have described simple usernames in an
inconsistent way. For example, the CRAM-MD5, DIGEST-MD5, and SCRAM
mechanisms seem to imply that the simple username would be the localpart
of an XMPP address, whereas the EXTERNAL mechanism seem to imply that
the simple username 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 simple username provided by an XMPP client to an
XMPP server during SASL negotiation SHOULD 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 a
simple username that is the localpart only, not the bare JID.

***

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 07 Mar 2010 19:33:14 -0700

On 3/7/10 12:50 PM, Kurt Zeilenga wrote:
>> DIGEST-MD5, CRAM-MD5, SCRAM and PLAIN are all using "simple
>> usernames" for authentication identities.
> 
> From a protocol specification (and implementation) perspective, one
> cannot assume that there is any relationship between credentials used
> in one mechanism with credentials used in another mechanism.
> 
> From a deployment perspective, it is good practice to relate
> credentials used in one mechanism with those in other mechanisms.
> But that's a deployment issue (which will depend highly on
> implementation details, such as whether we're only talking
> password-based realm-less mechanisms and the server implementation
> utilizes a mechanism-independent user/password database store.  (Once
> you throw concepts like DIGEST-MD5's realm things get messy fast.)
> 
> I rather not detail what some might consider "best deployment
> practices" or "best implementation practices", especially with the
> core RFCs, as these might be taken as normative statements intended
> to restrict what today is left to implementors.
> 
> -- Kurt

Well, "leave it up to implementors" is sometimes just another way to say
for "accept interoperability problems caused by bad specs". I'd rather
that the spec be explicit if at all possible.

What breaks if the client always provides a bare JID even if the server
actually uses only the localpart on the back end?

Would the server ever return an error to the client because the simple
username was other than what the server actually uses? If not, then the
server will if necessary either remove the @domainpart from the simple
username (if it was a bare JID but the server used only the localpart)
or append a domainpart to the simple username (if it was a localpart but
the server used a bare JID).

IMHO it is simpler for the client to always provide either a bare JID or
a localpart, but not have to guess about which one. The server can do
the necessary processing to produce whatever it needs on the backend.
(Simple clients and all that.)

For use in virtual hosting environments, I think it's better to always
send the bare JID, not the localpart, so I would prefer to define it
that way in the spec.

Peter

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 7 Mar 2010 19:10:07 -0800

On Mar 7, 2010, at 6:33 PM, Peter Saint-Andre wrote:

> for "accept interoperability problems caused by bad specs".

I disagree, at least in this case.

> I'd rather

I don't know of any authentication mechanism which takes as its authentication identity a JID of any sort.

Some take simple user names, but they these are not syntactically or semantically the same as a JID of any form.

The user is suppose to provide the credentials he's been told to use by administrator (or possibly an administrative service).

This is consistent across all application protocols using SASL.

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 7 Mar 2010 19:18:54 -0800

> Some take simple user names, but they these are not syntactically or semantically the same as a JID of any form.

For instance, my PLAIN id might well be "kdz" while my bare JID is "[email-masked]".  My DIGEST-MD5 id might be "kdz@x" in the realm "y@z".   

While in some deployments it might make sense to use the bare JID as the simple user name in various mechanisms, there are a wide range of reasons for them to be different.  For instance, the site might want to use operating system names as authentication identities. 

> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 7 Mar 2010 19:48:45 -0800

On Mar 7, 2010, at 10:13 AM, Alexey Melnikov wrote:

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

Another for instance,  it might be desirable at some deployments to allow the user to enter their Kerberos principal instead of their JID as the "simple user name".

We should not be legislating particulars of simple user names as used in XMPP (or any application level protocol).

-- Kurt

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 07 Mar 2010 21:58:17 -0700

On 3/7/10 8:48 PM, Kurt Zeilenga wrote:
>> 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.
> 
> Another for instance,  it might be desirable at some deployments to
> allow the user to enter their Kerberos principal instead of their JID
> as the "simple user name".
> 
> We should not be legislating particulars of simple user names as used
> in XMPP (or any application level protocol).

I see your point.

Would you recommend, therefore, removing this section entirely?

Peter

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

---

From: Tobias Markmann <[email-masked]>
Date: Mon, 8 Mar 2010 09:54:38 +0100

And this time to the whole ML.

> header is sent over an unencrypted stream.

Haven't we been doing this for over 10 years? I'm not saying that if this is a major security flaw it shouldn't be fixed; just wondering.

> Feedback is welcome.

What advantages do we get if username is a bare JID instead of just the node part? As you've already mentioned one could get the domain part from the stream header. I'm not against allowing a bare JID as username, wouldn't be that much code to change. However I think just the node part should still be allowed for interoperability purposes.

Cheers,
Tobias

--
Tobias Markmann
http://ayena.de

---

From: Jehan Pagès <[email-masked]>
Date: Mon, 8 Mar 2010 20:14:31 +0900

Hi,

> send the bare JID, not the localpart, so I would prefer to define it

For my own, I fully agree with all this. Leaving uncertaincy in the
spec is not a good idea. A choice must be done on the spec side.
Otherwise clients will just have to make a "try and see" logic because
they cannot guess the kind of credential chosen by a server.  And
really this kind of programming logic is not nice. As a consequence I
think that the authentication identity has to be defined with a "MUST"
and not a "SHOULD" in the spec.

So a clear choice has to be made: only the JID OR only the localpart,
but not possibly both (just a warning than older implementations may
still use a wrong credential of course, but only to leave
implementations time to update, still remain strict for the long run).

And for this choice, I think that the bare jid is clearly the best
solution, especially now that more and more implementations propose
multi-domain possibility, or that some delegated XMPP services are
coming in the game. And I think it is not so good to rely on the
initial stream tag for the service domain (can be security issue as we
said, but also less clear and maybe blocker for further improvements
of the protocol in the coming years that we might not foresee right
now).

Don't forget also that scenarios of how XMPP is used evolve a lot, and
we get more and more new projects using it in ways most people never
thought of. In such a context, it is far better to have a spec being
very strict than not enough. With a bare JID, we know we will never
have problem in any case (or at least obviously less than with just
the localpart). It is easier for implementers, clearly less subject to
bugs (and in such a matter, it is potentially security bugs because we
are dealing with the credentials, what identify a user), etc.
This is how I see the matter.
Bye.

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Mar 2010 07:37:21 -0700

On 3/8/10 1:54 AM, Tobias Markmann wrote:
>> 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.
> 
> Haven't we been doing this for over 10 years? I'm not saying that if
> this is a major security flaw it shouldn't be fixed; just wondering.

If the domain is taken from the very first stream header (unprotected by
TLS) then the 'to' address could be tampered with.

>> Feedback is welcome.
> 
> 
> What advantages do we get if username is a bare JID instead of just
> the node part? As you've already mentioned one could get the domain
> part from the stream header. I'm not against allowing a bare JID as
> username, wouldn't be that much code to change. 

I think there is value in consistency, which makes life easier for
client developers. Leaving it unspecified makes it more likely that
we'll have interoperability problems.

> However I think just
> the node part should still be allowed for interoperability purposes.

As I said, in practice servers will probably accept just the localpart
for a long time.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Mar 2010 07:47:55 -0700

>> in XMPP (or any application level protocol).

I've given it some more thought and I've realized that I don't see your
point. From the application (XMPP) perspective, there might be value in
specifying this consistently because it simplifies life for clients --
just hand off your bare JID to the SASL library and be done with it, you
don't have to guess or have an if-statement based on the particular SASL
mechanism that might get used (and given authentication retries the
client might first try a SASL mechanism that expects a bare JID and then
fall back to a SASL mechanism that expects a localpart -- does the
client code need to handle that?). True, the XMPP server then might need
to parse the localpart out of the bare JID when feeding it to an
authentication back end, but that's outside the context of the XMPP
application itself. Perhaps the term we're looking for is not
"authentication identity" or "simple user name", which seem to come with
some baggage in the SASL world. Or perhaps we're poking around where we
don't belong and we should just leave this up to the SASL library?

Peter

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 8 Mar 2010 06:49:33 -0800

The problem today is that client developers are assuming that the authentication identity has some relationship to the JID.
It doesn't necessarily.  The client developers should be asking the user separately for the credential information each mechanism requires.

For instance, for DIGEST-MD5, the user needs to be asked for both a simple user name and optional realm, neither of which may have anything to do with the user's JID.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Mar 2010 07:54:01 -0700

On 3/8/10 7:49 AM, Kurt Zeilenga wrote:
> The problem today is that client developers are assuming that the
> authentication identity has some relationship to the JID. It doesn't
> necessarily.  The client developers should be asking the user
> separately for the credential information each mechanism requires.
> 
> For instance, for DIGEST-MD5, the user needs to be asked for both a
> simple user name and optional realm, neither of which may have
> anything to do with the user's JID.

Are you thinking of cases where the JID is constructed on the server
side without any knowledge on the part of the user as to what the final
JID will be? One example: a system in which you provide a certificate
for authentication and the server to which you connect uses the data in
the certificate to construct a local JID on the server even though you
don't have a registered JID on that server.

Peter

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 8 Mar 2010 06:58:31 -0800

On Mar 8, 2010, at 6:47 AM, Peter Saint-Andre wrote:

> just hand off your bare JID to the SASL library

Now you are making assumptions about what the SASL library wants.  Consider DIGEST-MD5 v. PLAIN.  You seem to be expecting the SASL library to split the JID into a simple user name AND a realm for DIGEST-MD5, but expecting it to use the whole JID as the simple user name in PLAIN.  Or what.

> and be done with it, you
> client code need to handle that?).

No, the client should obtain the information it needs to perform authentication via a mechanism from the user.  Period.  The client should not assume any relationship between the user's JID and the user's credentials.

Look at most decent email clients.  They don't silently using the user's email address in the credentials (unless configured to do so), they generally provide a facility for the user to enter their credentials (e.g., simple user name, a realm if needed, a password).

XMPP client should be the same way.

-- Kurt

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Mar 2010 08:04:01 -0700

On 3/8/10 7:58 AM, Kurt Zeilenga wrote:

> Look at most decent email clients.  They don't silently using the
> user's email address in the credentials (unless configured to do so),
> they generally provide a facility for the user to enter their
> credentials (e.g., simple user name, a realm if needed, a password).
> 

Sure. But the text we're discussing talks about simple user names. What
is a simple user name? Is it a localpart or localpart@domainpart? As far
as I can see, that is unclear or inconsistent in the specs for the
various SASL mechanisms. If you're saying that it's always a localpart,
then great. If you're saying that the meaning of simple user name
differs depending on the SASL mechanism in play, then IMHO that's an
unfortunate inconsistency across various SASL specs but we can't say
anything useful about it in rfc3920bis and it would be better to mention
that it's up to the SASL mechanism.

Peter

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 8 Mar 2010 07:06:58 -0800

On Mar 8, 2010, at 6:54 AM, Peter Saint-Andre wrote:

> JID will be?

I'm thinking of the cases where the JID string, or any component string, appears in the user's credentials.

A JID, say [email-masked], does say anything about what my credentials are.  My simple user name might be "kdz" or "[email-masked]".  My realm (for DIGEST-MD5) might be "HOME@ISODE" (note the at sign). 

SASL is designed such that credentials need not be tied to application protocol identifiers.  This allows a user using multiple application protocols to use the same credentials regardless of which protocol they are using.

Application protocols specifications are suppose to be mechanism neutral.  You are going down a road which will make the specification not neutral, because you cannot do what you want to do with making assumptions of what information is needed by mechanisms.

-- Kurt

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 9 Mar 2010 00:12:40 +0900

Hi,

> For instance, for DIGEST-MD5, the user needs to be asked for both a simple user name and optional realm, neither of which may have anything to do with the user's JID.

Waw. So you imply that you would prefer that the the login is indeed
not the JID, nor even the localpart but could be something completely
different? Like my jid is [email-masked] but I would log with
"login"?

For which reason could this case be interesting? (though as I say,
sometimes you don't see first)

What annoys me a lot here is that it would make things extra
complicated. People are already startled as they don't understand the
domain concept, and why is there a resource, etc. Now you would like
that clients asks users to enter a login AND a localpart (which would
be different)?
Really I don't think it is a good idea for the sake of simplicity.
Bye.

Jehan

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 8 Mar 2010 07:17:11 -0800

On Mar 8, 2010, at 7:04 AM, Peter Saint-Andre wrote:

> is a simple user name?

It's a string that identifies a user, with context specific scope.  That is "A" in mech Y1 to server Z may or may not identify the same user as "A" in mech Y2 in server Z.  Nor may simple user name "A" in any mech identify the user identified by protocol-specific identifier "A".

It's not tied to any other identifier form.
 
> Is it a localpart or localpart@domainpart?

From a protocol perspective, there is not specified relationship to the user's JID.

Deployments might relate portions of JIDs with the simple user name (and/or realm and/or other aspects of mechanism credentials), but that's a local matter.

> As far
> various SASL mechanisms.

Because you are assume there must be a consistent relationship when SASL expects application protocols to be mechanism neutral.

> If you're saying that it's always a localpart,

I suggest only a note to client developers that, formally, mechanism credentials (which includes simple user names, realms, passwords, etc.) and JIDs are logically separate pieces of information which they should separately request from the user.

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 8 Mar 2010 08:25:14 -0800

On Mar 8, 2010, at 7:12 AM, Jehan Pagès wrote:

> not the JID,

I'm stating that per the specifications, the information required to authenticate with any particular mechanism is not necessarily related to anything in the application protocol.  For XMPP, that includes the user's JID.  For LDAP, that includes the user's DN.  For IMAP/Submission, that includes any of the user's email address.

This is SASL.

> sometimes you don't see first)

There are many reasons for the separation, but two key ones are flexibility and ability to use same credentials across multiple application protocols.

> complicated.

No more complicate than what we see in the email and directory clients, and they seem to have managed fine.

> People are already startled as they don't understand the

Well, I don't see it wrong for a client to default to using the user's bare jid as a simple user name in a range of mechanisms (just as email clients often default to use of email addresses), but clients should provide means (e.g., advanced configuration) which provides control over the credentials used.

Clients which don't provide such a option won't be usable in all deployments.  It is fairly common to use simple user names which have no relationship to the user's email address, JID, and DN.  For instance, the user's computer login name might be used.

> Really I don't think it is a good idea for the sake of simplicity.

At the expense of flexibility... and violating the SASL separation of mechanisms and application protocols.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Mar 2010 09:34:05 -0700

On 3/8/10 9:25 AM, Kurt Zeilenga wrote:
>>> authentication identity has some relationship to the JID. It
>>> doesn't necessarily.  The client developers should be asking the
>>> user separately for the credential information each mechanism
>>> requires.
>>> 
>>> For instance, for DIGEST-MD5, the user needs to be asked for both
>>> a simple user name and optional realm, neither of which may have
>> Waw. So you imply that you would prefer that the the login is
>> indeed not the JID,
> 
> I'm stating that per the specifications, the information required to
> authenticate with any particular mechanism is not necessarily related
> to anything in the application protocol.  For XMPP, that includes the
> user's JID.  For LDAP, that includes the user's DN.  For
> IMAP/Submission, that includes any of the user's email address.
> 
> This is SASL.
> 
>> 
> There are many reasons for the separation, but two key ones are
> flexibility and ability to use same credentials across multiple
> application protocols.
> 
> No more complicate than what we see in the email and directory
> clients, and they seem to have managed fine.
> 
>> People are already startled as they don't understand the domain
>> concept, and why is there a resource, etc. Now you would like that
>> clients asks users to enter a login AND a localpart (which would be
>> different)?
> 
> Well, I don't see it wrong for a client to default to using the
> user's bare jid as a simple user name in a range of mechanisms (just
> as email clients often default to use of email addresses), but
> clients should provide means (e.g., advanced configuration) which
> provides control over the credentials used.
> 
> Clients which don't provide such a option won't be usable in all
> deployments.  It is fairly common to use simple user names which have
> no relationship to the user's email address, JID, and DN.  For
> instance, the user's computer login name might be used.
> 

Is the following text acceptable?

***

Some SASL mechanisms have the concept of a "simple username" (e.g.,
CRAM-MD5, DIGEST-MD5, EXTERNAL, and SCRAM). The exact nature and form of
a simple username is mechanism-specific, and a simple username does not
necessarily map to an application identifier. Although it is reasonable
for an XMPP application to default the simple username to an XMPP
domainpart (for server-to-server authentication) or to a bare JID (for
client-to-server authentication), an application SHOULD provide a means
for a human user to configure the simple username in cases where the
default is not appropriate.

***

Peter

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 8 Mar 2010 09:05:54 -0800

> default is not appropriate.

Four suggestions:

1) remove EXTERNAL from the list.  There is no authentication identifier (of any sort) carried in EXTERNAL exchange.

2) the form of the simple user name is not really mechanism specific.  The form of simple user names used in a mechanism is actually a local matter. That is, some sites might have simple user names which contain only contain alphanumeric characters, some might use simple user names that look like email addresses (or jids), others might have simple user names that look like ....

So I suggest, s/exact nature and form of a simple username/form of the simple user name used in any particular mechanism is a local matter/

I dropped "nature" from this as that's another matter.  For instance, the nature of simple user names in PLAIN and DIGEST-MD5 can be viewed as being different, as the latter places simple user names in realms, a concept which PLAIN doesn't have.

3) s/application identifier/application identifier (e.g., JID or JID component)/.

4) last part replacement suggestion:
	SHOULD provide a means to configure the simple username, as well as other
	aspects of credentials (e.g., realm), in cases where the client's default behavior
	is inappropriate.

-- Kurt

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Mar 2010 10:24:11 -0700

On 3/8/10 10:05 AM, Kurt Zeilenga wrote:
>> Some SASL mechanisms have the concept of a "simple username"
>> (e.g., CRAM-MD5, DIGEST-MD5, EXTERNAL, and SCRAM). The exact nature
>> and form of a simple username is mechanism-specific, and a simple
>> username does not necessarily map to an application identifier.
>> Although it is reasonable for an XMPP application to default the
>> simple username to an XMPP domainpart (for server-to-server
>> authentication) or to a bare JID (for client-to-server
>> authentication), an application SHOULD provide a means for a human
>> user to configure the simple username in cases where the default is
>> not appropriate.
> 
> Four suggestions:
> 
> 1) remove EXTERNAL from the list.  There is no authentication
> identifier (of any sort) carried in EXTERNAL exchange.

Done.

> 2) the form of the simple user name is not really mechanism specific.
> The form of simple user names used in a mechanism is actually a local
> matter. That is, some sites might have simple user names which
> contain only contain alphanumeric characters, some might use simple
> user names that look like email addresses (or jids), others might
> have simple user names that look like ....
> 
> So I suggest, s/exact nature and form of a simple username/form of
> the simple user name used in any particular mechanism is a local
> matter/

Done.

> I dropped "nature" from this as that's another matter.  For instance,
> the nature of simple user names in PLAIN and DIGEST-MD5 can be viewed
> as being different, as the latter places simple user names in realms,
> a concept which PLAIN doesn't have.

Sure.

> 3) s/application identifier/application identifier (e.g., JID or JID

Done.

> 4) last part replacement suggestion: SHOULD provide a means to
> configure the simple username, as well as other aspects of
> credentials (e.g., realm), in cases where the client's default
> behavior is inappropriate.

Yes, I had thought about that. There might be a better place to talk
about configuration of credentials in general (this paragraph is about
the simple username) but I've added it here since I can't find a more
generic paragraph and I'm running out of time to work on this further
before the I-D deadline later today.

Peter

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

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 9 Mar 2010 02:32:58 +0900

Hi,

> At the expense of flexibility... and violating the SASL separation of mechanisms and application protocols.

Ok I can agree on this. But then this is advanced or very specific
server installation. And there should be a default for the case when
the user will not specify an alternate login (in the "advanced
configuration" typically as you advance). Because we cannot, in my
opinion, leave the default unspecified, so that some server would
require the bare JID, while others the localpart, etc. So let's just
say "the default is XXX unless an explicit alternate login has been
specified by the user".

In fact I was the one raising this issue to Peter because I saw a
strange credential in a SASL PLAIN authentication, and there was
nothing detailed in the XMPP spec on this while the SASL PLAIN spec
was explicitely leaving the choice to the upper protocol (so XMPP). So
let's just make this choice because just having random default login
is not very nice.
But I agree that it is nice to leave flexibility for specific
implementation which would require particular type of logins.
Bye.

Jehan

---

From: Paul Aurich <[email-masked]>
Date: Mon, 08 Mar 2010 09:58:14 -0800

> TLS) then the 'to' address could be tampered with.

If a connection upgrades to TLS, the spec already says that both sides
MUST discard any information gleaned prior to TLS, so the server should
already be relying on the 'to' address on the inner (protected by TLS)
stream header.

> we'll have interoperability problems.

My understanding is that currently, basically all clients specify the
node part as the username (when using a JID), so I don't see a need to
change the behavior (I agree with Tobias that the stream header 'to' is
already enough for multi-domain hosting environments), and to me,
consistency implies we use what (almost?) everyone is already doing.

> As I said, in practice servers will probably accept just the localpart

I'm concerned about changing the recommended default going forward from
an interoperability perspective.  I know of at least one server today
that does not accept bare JIDs as the SASL username, which introduces
nasty chicken-and-the-egg problems for client developers trying to
update to a new spec while handling complaints from users who are no
longer able to log in to their years-old server at work.

~Paul

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 8 Mar 2010 10:25:35 -0800

On Mar 8, 2010, at 9:32 AM, Jehan Pagès wrote:

> was explicitely leaving the choice to the upper protocol (so XMPP).

What text are you referring to?  As the Editor of RFC 4616, I don't recall any such text or any such intention.

The form of the authcid is intended to be a local matter (possible determined in part by how server implementations might handle PLAIN's authcid in relationship to other mechanisms' credentials).

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 8 Mar 2010 10:36:30 -0800

One issue I see with this, which I haven't yet fully thought out, are issues due to different string preparation/matching rules of simple user names and JIDs (or JID components).

It may well be that two JIDs map to one SASLprep'ed simple user name.  Or that two representations of the same JID don't map to a single SASLprep'ed simple user name.

While a simple user name might look like a JID, it won't have the properties of a JID.

-- Kurt

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Mar 2010 11:39:44 -0700

On 3/8/10 11:36 AM, Kurt Zeilenga wrote:
> One issue I see with this, which I haven't yet fully thought out, are
> issues due to different string preparation/matching rules of simple
> user names and JIDs (or JID components).
> 
> It may well be that two JIDs map to one SASLprep'ed simple user name.
> Or that two representations of the same JID don't map to a single
> SASLprep'ed simple user name.
> 

Yes, the thought had crossed my mind. This is part of the larger
conversation about using or moving beyond stringprep in XMPP. Hopefully
we can discuss this at the Anaheim meeting.

Peter

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

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 9 Mar 2010 04:17:47 +0900

Hi,

> What text are you referring to?  As the Editor of RFC 4616, I don't recall any such text or any such intention.

Reading again the RFC, I guess this one in particular gave me this impression:

----
The form of the authzid production is specific to the application-
   level protocol's SASL profile [SASL].  The authcid and passwd
   productions are form-free.  Use of non-visible characters or
   characters that a user may be unable to enter on some keyboards is
   discouraged.
----

Yet in this text, it is true that it is rather authzid only which
depends on the application level protocol (which is XMPP here, isn't
it?). And in our current topic, the credentials we are writing about
are indeed rather the authcid (which is form-free). But I think it was
relevant at the time because my issue was about a server requiring
both a authzid (in the form of a bare jid) and a authcid (in the form
of a localpart). This is when I checked in the XMPP and the PLAIN
specs see more about PLAIN authentication and saw that there was not
much information to guide developers indeed (but still I think in the
basic XMPP use case anyway, there should not be any authzid provided).
This is why I think some guidance with appropriate defaults should be
written in the spec so that we don't see 10 different implementations.

But as I said in my previous email, I also agree with you when you
write about keeping flexibility (in my previous email, I was seeing
the matter slightly differently, but hey! we are here to discuss, not
to stay blindly on our first opinion). I just expect that specs should
give default guidance/behaviour (yet still allowing flexibility).
Bye.

Jehan

---

From: Justin Karneges <[email-masked]>
Date: Mon, 8 Mar 2010 11:53:10 -0800

On Sunday 07 March 2010 19:18:54 Kurt Zeilenga wrote:
> For instance, my PLAIN id might well be "kdz" while my bare JID is
> "[email-masked]".  My DIGEST-MD5 id might be "kdz@x" in the realm
> "y@z".

Can you give an example of how this situation might be handled in a client UI?  
If the usernames can differ between mechanisms in a server deployment, then 
you'd need some sort of mechanism-specific configuration.  Psi has 
a "username" field in the account settings which can be used to specify a 
single SASL username to be applied to all mechanisms.  I take it this is not 
good enough?

-Justin

---

From: Kevin Smith <[email-masked]>
Date: Mon, 8 Mar 2010 19:55:13 +0000

> single SASL username to be applied to all mechanisms.  I take it this is not

It actually is, if you know which mechanism your client is going to pick.

/K

---

From: Justin Karneges <[email-masked]>
Date: Mon, 8 Mar 2010 12:37:58 -0800

On Monday 08 March 2010 11:55:13 Kevin Smith wrote:
> >> "[email-masked]".  My DIGEST-MD5 id might be "kdz@x" in the
> >> realm "y@z".
> >
> > Can you give an example of how this situation might be handled in a
> > client UI? If the usernames can differ between mechanisms in a server
> > deployment, then you'd need some sort of mechanism-specific
> > configuration.  Psi has a "username" field in the account settings which
> > can be used to specify a single SASL username to be applied to all
> > mechanisms.  I take it this is not good enough?
>

Do you know what mechanism the client is going to pick?  Even an "apt-get 
upgrade" could shake things up, by bringing in SCRAM and affecting mechanism 
priority.  I suppose mechanism selection is deterministic if you have a 
controlled client environment.  Maybe that is enough?

To me it feels like clients should have mechanism-specific configuration, with 
ugly words like "DIGEST-MD5" appearing in the GUI.  Or it should be possible 
to configure clients to always use a specific mechanism, bypassing the magic 
selection done by SASL libraries based on security settings.

-Justin

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 8 Mar 2010 14:59:16 -0800

On Mar 8, 2010, at 11:17 AM, Jehan Pagès wrote:

> it?).

> And in our current topic, the credentials we are writing about
> of a localpart).

I would argue that that's an example of a poor server implementation.  One should only assert an authzid if one is desiring to assume the identity of another.  IIRC, some text in this area was added (or is to be added).

> This is when I checked in the XMPP and the PLAIN

I don't mind adding guidance.  I mind adding bad guidance.  :-)

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Mar 2010 16:35:09 -0700

On 3/8/10 3:59 PM, Kurt Zeilenga wrote:
>> And in our current topic, the credentials we are writing about are
>> indeed rather the authcid (which is form-free). But I think it was 
>> both a authzid (in the form of a bare jid) and a authcid (in the
>> form of a localpart).
> 
> I would argue that that's an example of a poor server implementation.
> One should only assert an authzid if one is desiring to assume the
> identity of another.  IIRC, some text in this area was added (or is
> to be added).

We already have text about that:

   If the
   initiating entity wishes to act on behalf of another entity and the
   selected SASL mechanism supports transmission of an authorization
   identity, the initiating entity MUST provide an authorization
   identity during SASL negotiation.  If the initiating entity does not
   wish to act on behalf of another entity, it MUST NOT provide an
   authorization identity.

Peter

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 8 Mar 2010 19:02:19 -0800

On Mar 8, 2010, at 11:53 AM, Justin Karneges wrote:

> you'd need some sort of mechanism-specific configuration.

Well, is that always needed?  Some where on the client side, you need to have some knowledge of what facilities each mechanism provides (or can provide) and what credentials it requires.  Often one defers this to a "SASL Library".  There's a wide range of ways a SASL library could expose this application code using it.

> Psi has 
> single SASL username to be applied to all mechanisms.
> I take it this is not good enough?

While technically there is no formal relationship between credentials used in one mechanism and credentials used in another mechanisms, credentials used at a site need to have some level of consistency for security reasons.  It would be bad, for instance, for CRAM-MD5 authcid = "bob" w/ password to refer to different user than PLAIN authcid = "bob" w/ the same password.  At nearly all sites, PLAIN "bob" and CRAM-MD5 "bob", regardless of password, refer to the same user.

But DIGEST-MD5 throws in a realm concept.  One fairly common approach is for the DIGEST-MD5 authcid and realm are combined and used as the authcid in PLAIN and CRAM-MD5.  Another is to have no realm.  My favorite is to disable DIGEST-MD5 in favor of TLS+SCRAM (or even TLS+CRAM-MD5 or TLS+PLAIN).

I would argue that the client issue is more of a how many (most?) clients go about mechanism negotiation.  Many (most?) client do mechanism negotiation every time the connect.  I personally think this is bad as it makes them prone to downgrade attack.  I think it better for clients to do mechanism negotiation when the account is setup and only re-negotiate when the client sees new mechanisms, the authentication fails, or the user requests it.  Implemented in this manner, the client which cache credentials need to do so only for one mechanism.

-- Kurt

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 09 Mar 2010 13:42:36 -0700

> already be relying on the 'to' address on the inner (protected by TLS)

True, but unspecified in 3920bis as a best security practice. We need to
add a note about that.

> consistency implies we use what (almost?) everyone is already doing.

On further reflection, I think you're right.

> longer able to log in to their years-old server at work.

I think it would be good to have further discussion about this on the
list and at the Anaheim meeting, but I'm now leaning back to saying that
the simple username for c2s should default to the localpart.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Mar 2010 13:02:46 -0600

> True, but unspecified in 3920bis as a best security practice. We need to

I've updated the section on determination of addresses to read:

   For server-to-server communication, the initiating server's JID MUST
   be the authorization identity (as defined by [SASL]), either (1) as
   directly communicated by the initiating server during SASL
   negotiation (Section 6) or (2) as derived by the receiving server
   from the authentication identity if no authorization identity was
   specified during SASL negotiation (Section 6).  In the absence of
   SASL negotiation (e.g., when the older server dialback protocol is
   used as specified in [XEP-0220]), the receiving server MAY consider
   the authentication identity to be the 'from' address on the initial
   stream header (preferably only the stream header sent after TLS
   negotiation, because otherwise the 'from' address can be spoofed).

Peter

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