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

From: Kevin Smith <[email-masked]>
Date: Mon, 7 Jun 2010 09:46:51 +0100

Sorry about jumping back into this thread - I'm trying to do a review
today (yes, I'm running late).

On Mon, Mar 8, 2010 at 9:37 PM, Justin Karneges <[email-masked]> wrote:
> On Monday 08 March 2010 11:55:13 Kevin Smith wrote:
>> On Mon, Mar 8, 2010 at 7:53 PM, Justin Karneges <[email-masked]> wrote:
>> > 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?
>>
>> It actually is, if you know which mechanism your client is going to pick.
>
> 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.

Or, and this is the solution that's working fine in the real world,
and was a SHOULD in the original RFC3920, using a JID derivative and
having simple clients and a clean experience for the users.

I accept that there may be different credentials necessary for
different mechs in a hypothetical situation, but that's covered by the
SHOULD in 3920 - specialised deployments can always use more
fully-featured clients (and they do exist - in a controlled
environment Psi will do the necessary).

This way we don't have a protocol that forces complex UIs on simple Users.

For reference, I've only heard of a single deployment that's ever
wanted to not use the JID (or node) identity for this. Can someone
(Peter?) with more experience than me say whether they know of a
significant number of real-world deployments where this is an issue?
For one deployment wanting to do something different, I think a SHOULD
here is fine. Servers SHOULD use the JID - we can even add that
clients SHOULD allow it to be something else if we need to (although I
don't think that's true).

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 07 Jun 2010 16:05:35 -0600

On 6/7/10 2:46 AM, Kevin Smith wrote:
> and was a SHOULD in the original RFC3920, 

Is this the text from RFC 3920 that you're referencing?

   For client-to-server communications, the "bare JID" (<node@domain>)
   SHOULD be the authorization identity, derived from the authentication
   identity, as defined in [SASL], if no authorization identity was
   specified during SASL negotiation (Section 6); the resource
   identifier portion of the "full JID" (<node@domain/resource>) SHOULD
   be the resource identifier negotiated by the client and server during
   Resource Binding (Section 7).

> using a JID derivative and

Agreed.

> don't think that's true).

On the public XMPP network, I have never encountered a server that
needed anything other than localpart or localpart@domainpart. Perhaps
that's a skewed sample (all those IM users), but realistically it's what
we find deployed now.

Perhaps it makes sense to follow RFC 3920 here, then adjust it further
based on further implemenation and deployment experience when we try to
push these specs from Proposed to Draft...

/psa

---

From: Kevin Smith <[email-masked]>
Date: Tue, 8 Jun 2010 07:17:27 +0100

>   Resource Binding (Section 7).

Yes - there's also text about the simple user name.

> push these specs from Proposed to Draft...

That seems sensible to me.

/K

---

From: Kevin Smith <[email-masked]>
Date: Tue, 8 Jun 2010 10:44:53 +0100

> Yes - there's also text about the simple user name.

6.2.7 in bis, it seems.

/K

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 22 Jun 2010 16:33:59 +0900

Hi,

even though there have been updates in the SASL section, it seems that
the result of this mailing list discussion (but have we really come to
an agreement?) has not been updated into the last draft, which is
strange as earlier in the discussion, Peter submitted some text which
I definitely don't see in the draft.

The use of autorization identity is defined as "MUST be a bare JID"
for instance but not the authentication identity, which is the one we
were interested about here.

It looks that the text for authentication identity became the small
section "6.2.7 Simple Username". So a few remarks:

1/ it is more often called "authentication identity" in SASL rfcs. And
in particular in the SCRAM draft and the PLAIN RFC, which are our 2
mandatory-to-implement mechanisms, this is called "authentication
identity" (moreover you quoted a few RFC between parentheses as having
this concept... but searching the documents, they don't have the words
"simple username"). So I would suggest changing the wording or
clarifying that these are synonyms for us.

2/ So the conclusion of this discussion seems to be that we don't
clarify anything, as I read:
«
a simple username does not necessarily map to an application
identifier such as a JID or a JID component.
»
Is that really what we want? It means that generic clients should try
both the localpart only then the bare jid until it works (so we ask a
random methodology?), or that the server should accept both
authentication identities as valid (which does not sound like a
security restriction to me: "let's just accept any authentication!")?
Or worse having a new field for the user to manually set a
(potentially completely different) authentication identity (I remember
we had such a discussion, and I agree this can be useful in very
specific XMPP environment, but in my opinion might exist only like a
well hidden "advanced feature", as we want to avoid configuration
hassle, don't we)?

3/ Our two mandatory-to-implement mechanisms (PLAIN and SCRAM-*) does
not have the realm concept, so really for me asking implementers to
use the bare jid as the authentication identity still seems the only
valid and secure authentication logics, especially as (1) servers now
more and more have multi-domain configuration, (2) if the stream is
not encrypted, taking the domain from the stream header is not secure,

Maybe I don't get something, but it looks to me that this discussion
did not result in any clear decision at all. At least it is not
reflected in the draft.

Sorry to wake up so late for this review.

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Jun 2010 21:32:31 -0600

On 6/22/10 1:33 AM, Jehan Pagès wrote:
> an agreement?) 

It's not clear to me that we had consensus.

> has not been updated into the last draft, which is

Which text? I submitted text several times in that thread (from newst to
oldest):

http://www.ietf.org/mail-archive/web/xmpp/current/msg00789.html

http://www.ietf.org/mail-archive/web/xmpp/current/msg00673.html

http://www.ietf.org/mail-archive/web/xmpp/current/msg00588.html

http://www.ietf.org/mail-archive/web/xmpp/current/msg00570.html

http://www.ietf.org/mail-archive/web/xmpp/current/msg00566.html

Which of those did you have in mind?

> section "6.2.7 Simple Username". 

To understand that evolution, you need to read the entire thread
starting here:

http://www.ietf.org/mail-archive/web/xmpp/current/msg00566.html

> So a few remarks:
> "simple username"). 

See RFC 4422.

> So I would suggest changing the wording or

Our SASL experts can correct me if I'm wrong, but a "simple username" is
not quite the same as an "authentication identity" (to be precise, it
might be an instance of "authentication identity"). But see also the
longer discussion at the end of this email message.

> random methodology?), 

Not exactly random.

> or that the server should accept both

Not that!

> well hidden "advanced feature", as we want to avoid configuration

I think so.

> valid and secure authentication logics, 

Other approaches are valid and secure, but not developer-friendly or
user-friendly.

> especially as (1) servers now
> more and more have multi-domain configuration, 

True.

> (2) if the stream is

Yes, we have a note about that. Do TLS before you trust those values.

> did not result in any clear decision at all. At least it is not

The discussion did not result in any clear decision, in part because
Kurt and others introduced deployment scenarios that are extremely
uncommon in XMPP, at least on the public XMPP network (e.g., things like
Kerberos).

Now to the longer part of the discussion. :) Here I'll reproduce section
2 of RFC 4422 in its entirety...

###

2. Identity Concepts

   In practice, authentication and authorization may involve multiple
   identities, possibly in different forms (simple username, Kerberos
   principal, X.500 Distinguished Name, etc.), possibly with different
   representations (e.g., ABNF-described UTF-8 encoded Unicode character
   string, BER-encoded Distinguished Name).  While technical
   specifications often prescribe both the identity form and
   representation used on the network, different identity forms and/or
   representations may be (and often are) used within implementations.
   How identities of different forms relate to each other is, generally,
   a local matter.  In addition, the forms and representations used
   within an implementation are a local matter.

   However, conceptually, the SASL framework involves two identities:

      1) an identity associated with the authentication credentials
         (termed the authentication identity), and

      2) an identity to act as (termed the authorization identity).

   SASL mechanism specifications describe the credential form(s) (e.g.,
   X.509 certificates, Kerberos tickets, simple username/password) used
   to authenticate the client, including (where appropriate) the syntax
   and semantics of authentication identities carried in the
   credentials.  SASL protocol specifications describe the identity
   form(s) used in authorization and, in particular, prescribe the
   syntax and semantics of the authorization identity character string
   to be transferred by mechanisms.

   The client provides its credentials (which include or imply an
   authentication identity) and, optionally, a character string
   representing the requested authorization identity as part of the SASL
   exchange.  When this character string is omitted or empty, the client
   is requesting to act as the identity associated with the credentials
   (e.g., the user is requesting to act as the authentication identity).

   The server is responsible for verifying the client's credentials and
   verifying that the identity it associates with the client's
   credentials (e.g., the authentication identity) is allowed to act as
   the authorization identity.  A SASL exchange fails if either (or
   both) of these verifications fails.  (The SASL exchange may fail for
   other reasons, such as service authorization failure.)

   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.

###

In practice, almost all XMPP implementations and deployments to date
(especially on the public XMPP network) have assumed that the user's
identity is a bare JID and that the user's registered account has a
stored password associated with it on the server. This traditional
username/password credential form is by no means mandatory for XMPP (and
certainly not for SASL or even any given SASL mechanism), but it is by
far the most common for us. Therefore I think it is appropriate for the
XMPP specification to mention that, in the absence of local information
provided by the server, the client SHOULD assume that the authentication
identity is a username/password (where the username is a bare JID).

Having thought about this further and looked at RFC 4422 and the specs
for various SASL mechanisms, I have to say that the concept of a "simple
username" is unclear to me. It seems to me that a simple username is one
kind of authentication identity. I tend to agree with Kurt that we can't
really say what form an authentication identity might take because there
are many forms (e.g., "X.509 certificates, Kerberos tickets, simple
username/password" as mentioned in Section 2 of RFC 4422), but I
disagree with his hesitance about saying something more definitive about
simple username/password credentials in XMPP. IMHO the simple username
for us is in 99% (or even all) of the cases a bare JID (however, we
can't see whether a bare JID would ever appear in a SASL mechanism for
X.509 certs or Kerberos or whatever). Therefore I would propose the
following text:

###

6.2.7.  Simple Username

6.2.7.  Simple Username

   Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify
   that the authentication identity used in the context of such
   mechanisms is a "simple username" combined with a password (see
   Section 2 of [SASL]).  The exact form of the simple username in any
   particular mechanism or deployment thereof is a local matter, and a
   simple username does not necessarily map to an application identifier
   such as a bare JID or a JID component (e.g., a localpart).  However,
   in the absence of local information provided by the server, an XMPP
   client SHOULD assume that the authentication identity for such a SASL
   mechanism is a username/password combination, where the simple
   username is a bare JID of the form <localpart@domainpart>.

###

Peter

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

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 24 Jun 2010 14:20:21 +0900

Hi,

> It's not clear to me that we had consensus.

Not to me indeed, but I thought the RFC would still be slightly more
updated on the matter. :-)

> Which of those did you have in mind?

I was referring to the 2 older emails in particular where we had a
section called "Authentication Identity" (now it is back to "Simple
Username") and where the username was adviced to be a bare JID (which
also disappeared in latter draft, but that you just added back right
now and that's nice!).

> http://www.ietf.org/mail-archive/web/xmpp/current/msg00566.html

Ok I will read this. I admit my mind might have wandered (which, as
you know, is something I do sometimes ;-) away from this topic when it
became so long (which is sad as I was the one who pointed you on this
topic through IM, as I recall!). I am sorry to come back after the hot
discussion.

>> this concept... but searching the documents, they don't have the words

Yes. I was more referring to the specific mechanisms you refered to
("e.g., CRAM-MD5, DIGEST-MD5, and SCRAM") in the section called
"Simple Username" whereas the corresponding RFC/drafts did not mention
this concept (if you make a search with "simple username" in these
documents, there is no result). But it is true that all these
documents tend somehow to use different names for the same things, or
sometimes for slightly nuanced concepts that don't exist from a
mechanism to another. So it is difficult to choose a right global
word. Thus that's ok for me to choose one (so why not "simple
username" indeed) and I guess it is worth to broaden its meaning for
XMPP.

>> both the localpart only then the bare jid until it works (so we ask a

Not exactly indeed, but it still meant that clients had to test two
unsure cases on the basic XMPP use while they could make one that they
are sure is right.

>> security restriction to me: "let's just accept any authentication!")?

Good to read.

> identity is a username/password (where the username is a bare JID).

Yes I definitely think that the bare JID should be the "default"
username, so that for instance generic public services all work the
same (and the user has nothing to configure in one's standard XMPP
client, except filling bare jid and password).

But I agree also that the concept of another authentication identity,
different from the jid (possibly even completely different) is
possible and interesting in some specific environment as long as it is
an advanced configuration (that most user will never see, hidden in
some configuration panel of their client). But only as long as we give
a default recommendation in absence of specific configuration details
(given by your service administrator). Default choices are always
important to keep the public federated network as easy as possible for
any user, and still remain secure (as "no default" implies several
choices, hence several unsure authentication tries, hence less
security).

>   username is a bare JID of the form <localpart@domainpart>.

That's very good to me. You give a default username value for
simplicity of most of the network, still giving liberty to specific
implementation/environment to use excentric names if they really wish
to (then they will document it to their users).
Perfect. Thanks.

Jehan

---

From: Paul Aurich <[email-masked]>
Date: Thu, 24 Jun 2010 00:27:51 -0700

> identity is a username/password (where the username is a bare JID).

Don't most deployed clients currently (on the public XMPP network)
assume the identity/username is a JID's localpart, not a bare JID?

~Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Jun 2010 15:50:17 -0600

> assume the identity/username is a JID's localpart, not a bare JID?

My bad. RFC 3920 said:

   6.  If provision of a "simple username" is supported by the selected
       SASL mechanism (e.g., this is supported by the DIGEST-MD5 and
       CRAM-MD5 mechanisms but not by the EXTERNAL and GSSAPI
       mechanisms), during authentication the initiating entity SHOULD
       provide as the simple username its sending domain (IP address or
       fully qualified domain name as contained in a domain identifier)
       in the case of server-to-server communications or its registered
       account name (user or node name as contained in an XMPP node
       identifier) in the case of client-to-server communications.

In updated language that would be "localpart".

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Jun 2010 15:57:28 -0600

> to (then they will document it to their users).

As Paul Aurich pointed out, we probably need to change bare JID to
localpart in that proposed text. The server can always get the
domainpart from the 'to' address of the stream header, if needed.

Peter

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

---

From: Jehan Pagès <[email-masked]>
Date: Fri, 25 Jun 2010 12:51:36 +0900

Oups not sent to the list, new try. ;-)

---------- Forwarded message ----------
From: Jehan Pagès <[email-masked]>
Date: 2010/6/25
Subject: Re: [xmpp] 3920bis: authentication identity
To: Peter Saint-Andre <[email-masked]>

Hi,

> domainpart from the 'to' address of the stream header, if needed.

I see. Apparently it changed from draft 4 to draft 5 (from localpart
to bare jid for the simple username format). So probably we have to
use the localpart as it was the original definition of simple username
in XMPP. At least we set a default so that's better than the current
text in the draft which just gives no format (I see that the default
format of simple username has been lost from the draft 5 to the draft
6), though I would have prefered using bare jid. But as it's
interoperability reason, I understand...

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 20:59:38 -0600

> interoperability reason, I understand...

Yes, that's called rough consensus. :)

Peter

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