Subject: ANONYMOUS vs. UNIQUE in XMPP

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 1 Mar 2005 21:08:16 -0600

RFC 3920 [1] specifies that after an XMPP client authenticates with an 
XMPP server, it must bind a resource to the XML stream so that XML 
stanzas can be routed to the client. There are really three resource 
binding scenarios:

1. The client specifies a desired resource identifier and the server 
   accepts it.

2. The client specifies a desired resource identifier but the server 
   does not accept it, instead overruling the client and assigning a 
   resource identifier.

3. The client asks the server to assign a resource identifier and the 
   server does so.

No matter which scenario is enacted, at the end of the process the server
informs the client of its full JID (node@domain/resource).

In some deployments of XMPP, it might be helpful for an XMPP server to 
assign a full JID to the client (i.e., not just the resource identifier) 
if it authenticates with SASL ANONYMOUS, and to ensure that the "bare JID"
(node@domain portion) is unique in the context of the domain served by the 
server. The protocol flow is envisioned to be as follows:

1. Client authenticates via SASL ANONYMOUS

   C: <stream:stream 
        xmlns:stream='http://etherx.jabber.org/streams' 
        xmlns='jabber:client' 
        to='example.com' 
        version='1.0'>

   S: <stream:stream 
        xmlns:stream='http://etherx.jabber.org/streams' 
        xmlns='jabber:client' 
        id='c2s_234' 
        from='example.com' 
        version='1.0'>

   S: <stream:features>
        <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
          <mechanism>DIGEST-MD5<mechanism>
          <mechanism>ANONYMOUS<mechanism>
        </mechanisms>
      </stream:features>

   C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
            mechanism='ANONYMOUS'/>

   S: <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>

   C: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>

[ note: it is recommended for the client to send an empty response ]

   S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
  
2. Server tells entity that resource binding is required

   C: <stream:stream
        xmlns:stream='http://etherx.jabber.org/streams'
        xmlns='jabber:client'
        to='example.com'
        version='1.0'>
  
   S: <stream:stream
          xmlns:stream='http://etherx.jabber.org/streams'
          xmlns='jabber:client'
          id='c2s_345'
          from='example.com'
          version='1.0'>
      <stream:features>
        <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
      </stream:features>

3. Client requests that server create a resource for it

   C: <iq type='set' id='bind_1'>
        <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
      </iq>

4. Server replies with full JID

   S: <iq type='result' id='bind_1'>
        <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
          <jid>[email-masked]/someresource</jid>
        </bind>
      </iq>

The question arises: if a server assigns unique JIDs as a result of such
a protocol flow, is that overloading the SASL ANONYMOUS mechanism? It has
been suggested that it might be necessary to define a new SASL mechanism
(perhaps named "UNIQUE"), but as far as I can see the protocol flow for
UNIQUE would be indistinguishable from ANONYMOUS, with the only difference
being how the XMPP server handles the resource binding process. However,
we are open to defining a new SASL mechanism if that is deemed necessary.

Feedback welcome.

/psa

NOTES

[1] http://www.ietf.org/rfc/rfc3920.txt
[2] http://www.ietf.org/internet-drafts/draft-ietf-sasl-anon-05.txt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 01 Mar 2005 23:24:02 -0800

>we are open to defining a new SASL mechanism if that is deemed necessary.

As shown above, I think not, because the assignment of the JID is
not loaded onto the ANONYMOUS exchange, e.g., its not done as an
integral part of step 1.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 2 Mar 2005 10:11:20 -0600

> At 07:08 PM 3/1/2005, Peter Saint-Andre wrote:

<snip/>

> not loaded onto the ANONYMOUS exchange, e.g., its not done as an

OK, so my understanding is that we will continue to use ANONYMOUS in
XMPP (with some implementations / deployments creating unique JIDs as
a result of authenticating via ANONYMOUS), unless of course there are 
further objections.

Thanks for the review.

Peter

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Mar 2005 19:22:51 -0500

>>>>> "Peter" == Peter Saint-Andre <[email-masked]> writes:

    Peter> On Tue, Mar 01, 2005 at 11:24:02PM -0800, Kurt D. Zeilenga
    >> At 07:08 PM 3/1/2005, Peter Saint-Andre wrote:

    Peter> <snip/>

    >> >The question arises: if a server assigns unique JIDs as a
    >> result of such >a protocol flow, is that overloading the SASL
    >> ANONYMOUS mechanism? It has >been suggested that it might be
    >> necessary to define a new SASL mechanism >(perhaps named
    >> "UNIQUE"), but as far as I can see the protocol flow for
    >> >UNIQUE would be indistinguishable from ANONYMOUS, with the
    >> only difference >being how the XMPP server handles the resource
    >> binding process. However, >we are open to defining a new SASL
    >> mechanism if that is deemed necessary.
    >> 
    >> As shown above, I think not, because the assignment of the JID
    >> is not loaded onto the ANONYMOUS exchange, e.g., its not done
    >> as an integral part of step 1.

    Peter> OK, so my understanding is that we will continue to use
    Peter> ANONYMOUS in XMPP (with some implementations / deployments
    Peter> creating unique JIDs as a result of authenticating via
    Peter> ANONYMOUS), unless of course there are further objections.

I tend to agree with Kurt here.  The authentication identity (and
authorization identity) in the anonymous mechanism are abstractly
defined but have no concrete representations.  The properties we know
from the abstract definition is that two anonymous users may not
actually represent the same entity.  That is at an abstract level the
authcid from one anonymous authentication may not represent the same
entity as the authcid from another anonymous authentication.

I think that having an application protocol treat this as a unique
part would be fine.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 01 Mar 2005 23:24:02 -0800

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 2 Mar 2005 10:11:20 -0600

<snip/>

Thanks for the review.

Peter

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Mar 2005 19:22:51 -0500

Peter> <snip/>