%ents; ]>
Remote Authentication This document defines an XMPP protocol extension that enables entities to use SASL for authentication with remote services (such as Multi-User Chat rooms). &LEGALNOTICE; XXXX ProtoXEP Standards Track Standards Council XMPP Core RFC 3920 RFC 4422 none &stpeter; 0.0.1 2010-12-01 psa

First draft.

At present, XMPP entities use SASL &rfc4422; for authentication of XML streams but do not have strong authentication methods available for authentication of interactions with remote entities. One glaring example is &xep0045;, which uses only plaintext passwords for authentication. Stronger authentication technologies would be preferable. This document defines one such approach: re-use of the XMPP-specific profile of SASL already defined in &xmppcore;.

This specification simply re-uses the existing XML namespace defined in XMPP Core, and encapsulates the interactions in XMPP &IQ; stanzas.

Consider an attempt by an XMPP client to join a MUC room:

]]>

As MUC is currently defined, the service would return a ¬authorized; stanza error:

]]>

The client would then log in with a plaintext password:

cauldronburn ]]>

This document proposes instead that the service would return a ¬authorized; stanza error along with an application-specific error condition &xep0182; of <sasl-required/>.

]]>

The client would then initiate an in-band SASL negotiation with the chatroom.

First, the client will request the mechanisms supported by the chatroom.

]]>

The service then returns its list of supported mechanisms.

EXTERNAL SCRAM-SHA-1 PLAIN ]]>

The client can then begin the authentication handshake using one of the advertised mechanisms.

biwsbj1qdWxpZXQscj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQQ== ]]>

The handshake proceeds through a series of challenges and responses.

cj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQWUxMjQ2OTViLTY5Y TktNGRlNi05YzMwLWI1MWIzODA4YzU5ZSxzPU5qaGtZVE0wTURndE5HWTBaaT AwTmpkbUxUa3hNbVV0TkRsbU5UTm1ORE5rTURNeixpPTQwOTY= ]]> Yz1iaXdzLHI9b01zVEFBd0FBQUFNQUFBQU5QMFRBQUFBQUFCUFUwQUFlMTI0N jk1Yi02OWE5LTRkZTYtOWMzMC1iNTFiMzgwOGM1OWUscD1VQTU3dE0vU3ZwQV RCa0gyRlhzMFdEWHZKWXc9 ]]> dj1wTk5ERlZFUXh1WHhDb1NFaVc4R0VaKzFSU289 ]]>

Having been authenticated, the client can now join the chatroom.

]]>

OPEN ISSUE: does the client need to provide a token of some kind here, or is it sufficient to send a stanza from the authenticated resource?

There is no guarantee that stanzas sent over multiple hops will be protected with regard to confidentiality or integrity across all hops. This failing leads to the possibility of man-in-the-middle attacks. No solution to that problem is proposed in this document.

This document requires no action on the part of &IANA;.

The ®ISTRAR; shall add an error condition of <sasl-required/> to its registry of application-specific error conditions located at &APPERRORS;. The registration is as follows:

urn:xmpp:errors sasl-required authentication via SASL is required in order to perform the requested action XEP-XXXX ]]>

The schema from RFC 3920 applies.