The XMPP protocols has long had an extension for in-band account management (In-Band Registration (XEP-0077) ). Nevertheless, although this extension has known a wide, though usually incomplete, implementation and usage in servers and clients, it lacks the most basic security and flexibility. The present extension protocol defines a new approach, closer to XMPP's design; also it provides highly secure credential exchanges, made possible by late SASL technologies, such as the SCRAM family's mechanisms (Mandatory-To-Implement technology since RFC 6120 ); and finally it keeps an open design, in the great modular tradition of XMPP, so that future account management extensions will be easily added, without breaking previous implementations.
XEP-0077 is so widely implemented that it might seem undesirable to change it. Nevertheless it showed a lot of weaknesses over time and there are very few full implementations (often, only the account registration part is implemented. Account deletion and password management are usually dealt in other means, for instance with Ad-Hoc Commands (XEP-0050) ). This is why it predicted its own obsolecence: "Furthermore, this document should be deprecated as soon as a successor protocol is defined and implemented" (section 10. "Security Considerations" of XEP-0077). The present extension plans on being this "successor protocol".
XMPP Design Guidelines (XEP-0134)  clearly states that "XMPP is Sacred", in the meaning that extensions MUST NOT break the basic design of XMPP. XEP-0077 proposes to send IQ stanzas, qualified with the content namespace, on an incompletely negotiated stream, which is contradictory to RFC-6120's basic concepts (section 4.3.1): "At a minimum, the initiating entity needs to authenticate with the receiving entity before it is allowed to send stanzas to the receiving entity". This is not a specification violation as section 4.3.5 allows exceptions to this rule for stanzas sent to the initiating entity itself or its server, yet it can be seen as a contradictory philosophy.
Moreover it attempts to be considered as a stream feature, but indicates that the stream feature advertisement is not mandatory and the namespace advertised in the <stream:features/> is not reused during the feature negotiation. Finally the queries can be used either authenticated or unauthenticated. These various lacks of consistency are somewhat annoying.
Even though we could pass on the blasphemy over XMPP design, and would want to build over XEP-0077 to support secure features of newer SASL mechanisms, it would require a way to extend XEP-0077 without breaking existing implementations. This is unfortunately made impossible by built-in strict restrictions and a rigid syntax preventing us from doing any useful extension.
Extensions are allowed through the use of Data Forms (XEP-0004)  only. Data Forms are flexible for humans, yet security requires explicit definitions and automatic computations of cryptographic algorithms, which is impossible with generic Data Forms. Also we are not allowed to define new credential exchanges, other than with raw password, which is highly unsecure: "A host MUST NOT add new fields to the 'jabber:iq:register' namespace; instead, extensibility SHOULD be pursued via the Data Forms protocol as specified herein" (section 4. Extensibility).
The namespace has only one stream feature defined. In particular no differentiation is made between creation, deletion and modification of an account. Also the namespace does not follow RFC 4854  format, making versionning of the protocol impossible. Hence any client would be unable to determine whether the server understands or not the current extension, and which part, resulting inevitably in incompatible implementations, unless a new URN namespace was created, which is equivalent to create a new extension anyway.
As a consequence of these various points, it makes more sense to design this new extension from scratch, adapted to XMPP design and flexibility.
Account Management, defined herein as a collection of stream features, is designed to meet the following requirements:
A XMPP account usually consists of a JID and the secret necessary to impersonate it, in other words credentials. While this secret is most often a password, it may consists of other means, for instance a client certificate. Moreover even a password does not necessarily mean that the server should ever have knowledge of the actual password. Modern authentication mechanisms indeed allow a user to be recognized as the rightfull owner of an account by asymetric cryptographic algorithms or other similar technologies. The current extension allows an exchange of only the necessary data which the server should know to recognize an account owner, without ever accessing the actual password. For this to be possible, a server should be able to advertize the ways credentials can be stored.
In order to advertize these storage mechanisms, the server MUST list them as children of the account <registration/> feature, qualified with the protocol namespace, before authentication.
The user wants to create a new account, using a password. Storing data as both SCRAM-SHA-256 and SCRAM-SHA-1 garanties all authentication possibilities, still keeping a secure credential exchange. Hence the client requests to store in both mechanisms.
Note: the server could refuse one storage if another requested storage is compatible and more secure. In the current use case, if the user had requested the three storage (PLAIN, SCRAM-SHA-1 and SCRAM-SHA-256), the server SHOULD answer to proceed only with SCRAM-SHA-1 and SCRAM-SHA-256, the exchange being by far more secure, and equivalent in authentication posssibilities.
Note: following the same logics as RFC-6120 (section 6.3.7 "Simple User Name"), in the absence of specific information for a given server deployment, the client SHOULD assume that the login is the localpart of the desired JID. In the case of a server hosting several domains, the value of the 'to' attribute of the initiation opening stream MUST be used by the server to determine the service where the registration occurs ('to' is mandatory in initial stream headers, as described in section 4.7.2 or RFC-6120).
Following success of a registration, the stream MUST be restarted. If the 'from' parameter was empty in the previous stream opening tag, and if the current connection is encrypted, the new stream header SHOULD contain a 'from' attribute filled with the newly created JID (as described in RFC-6120, section 4.7.1).
If a server wishes to provide in-band account deletion, it MUST advertize the <deletion/> feature, qualified with the protocol namespace, after authentication.
After stream features have been advertized, a user can require the deletion of one's account.
Note: this protocol does not define management of other user's account, as could do an administrator on a server, but management of one's own account. As a consequence, even when a user has administration power, this feature provides no way to delete a user account other than the one currently authenticated (if needed, such a feature should be defined in another XEP, or may be implemented with generic capabilities as ad-hoc commands). Nevertheless as detailed in section 4.3.6 "Determination of Addresses" of RFC-6120, if an authorization identity different from the authentication identity is used during the SASL negotiation, the authorization identity is used to determine the client's address. Consequently an administrator who has the permissions to impersonate users through SASL authentication can delete a user account this way.
Note: after a successful deletion, if this JID had resources currently authenticated on the server, the server should close their stream with a 'not-authorized' stream error (with optional additional message to inform that the account has been closed).
An account modification is used for three reasons:
The two first reasons will lead basically to the same procedure. After the stream features have been advertized, a user might decide to change its credential, wherever he changes only the password, only the storage mechanism or both does not change in the server's point of view (in some storage mechanisms, the server may not be aware of the actual password, hence it may be unable to determine whether the password stayed the same).
The rest of the exchange highly ressembles an account creation process.
The following section describes exhaustively the possibilities of the three features described in this extension and possibilities of extensions.
If the feature is implemented, it MUST be advertised as a stream feature before the authentication. Though the feature MAY be advertised before any stream encryption, it is adviced to advertise it only after, for obvious security reasons.
By definition, this feature MUST always be considered as optional.
Even when any in-band account management is undesired on a given deployment, rather than disabling completely the feature altogether, it is preferred to advertise it and provide suitable alternatives, either a human readable message, a redirection (using Out-of-Band Data (XEP-0066) ), or both in order for a user to know how one can manage one's account. Note that only these two kinds of alternatives are defined in the present document, but other alternative contents may be defined in further versions of this protocol, or in other protocols. As a consequence, if an alternative is not understood, the client SHOULD silently ignore it.
If in-band registration is possible, the available <storage/> mechanisms MUST be advertised as childs of the <registration/> tag.
Note: though storage mechanisms actually look like SASL mechanisms, they are slightly different, which is why the "mechanism" keyword used by the SASL stream feature has not been re-used, in an attempt to clearly distinguish both. Indeed this extension wishes to differentiate the storage logics and the actual authentication mechanism used, because some storage logics allows several SASL mechanisms to be used. In particular the PLAIN storage, though the less secure password exchange and storage, is the most flexible as it allows any kind of SASL mechanism (with password) afterwards. On the other hand, the SCRAM-SHA1 storage will allow the use of the SASL SCRAM-SHA1, SCRAM-SHA1-PLUS, but also the PLAIN mechanisms.
Note 2: the <registration/> feature MUST contain at least one <storage> child, or one <alternative> child, or any mix of one of several <alternative> and <storage>. If only <alternative> children are available, then no In-Band registration is possible on this server, but a user wishing to register an account on this server should be presented with the different alternatives (which can be either a URI presented with an optional description, as described in Out-of-Band Data or a human-readable text in an <instructions> child). In this case, nothing is to be negotiated and the client SHOULD close the stream without an error.
If the client detects one or more known storage mechanisms that satisfies its security requirements, it MUST initiate the feature negotiation by a <register/> tag, qualified by the feature namespace, and containing the desired <storage> mechanisms.
As an optional step, before going further into registration, the server can request additional information in a <challenge> tag. The contents of this tag can be:
Further versions of this protocol or other extensions may add new type of possible contents.
A single <challenge> MUST contains only one child. If the client is not able to understand the contents of a challenge, it must return <unknown-challenge/>, to which the receiving entity can either answer by sending another <challenge/>, or with a <failure> if this <unknown-challenge> is considered a terminale failure.
Upon receiving a <failure>, the account creation failed and the feature negotiation ends. Unless the client can attempt another feature negotiation, it should close the XMPP stream.
If a challenge awaits for no response, for instance if the challenge consists only on <instructions> or Out-of-Band Data, the client must still return an empty <response/>in order to acknowledge the challenge and pass to the next one. For instance, if the challenge are instructions or a link, the <response/> MUST be sent only when the user acknowledged reading the instructions or the link (on a typical UI, usually by clicking a button).
Upon receiving a challenge response, the server can either send a <failure/> if the response is not considered acceptable and unrecoverable, another challenge (either because the previous challenge failed but the issue is recoverable, or because several challenge are necessary), or ends the challenge step.
After all pre-challenges are accepted, the server asks the client to <proceed/>. The children are the <storage> mechanisms which the user wants the client to exchange. These mechanisms MUST be a subset of the ones requested by the client in the <register/>. In particular, there can be less <storage/> if some of them are considered irrelevant when others will be exchanged. The server MAY add one or several human-readable <instructions/> depending on the kind of data expected to be presented by the user.
The client sends the credentials data. This part is discussed later in Defined Storage Mechanisms.
If the credentials sent by the client are not acceptable and the error is considered unrecoverable by the server, it must send a <failure/>. Otherwise it must send again <proceed/> with the same <storage/>, and preferrably updated <instructions/> detailing what was wrong in the previously provided data.
After the Registration step, the server can again request new <challenge/> as described in Optional: additional informations.
Note: during a single registration, a server can request challenges before the registration step, or after, or before-and-after, or none at all. Any combination is possible.
Once the registration is done and all challenges are answered, the server can finally acknowledge the successfull completion of the registration by a <registered/> tag. Its children will confirm the login in the form of the full JID as well as confirming the <stored/> mechanisms, and can optionally provide <instructions/> with human readable information.. Note that the registration is not complete as long as <registered/> has not been received (as such a registration can fail even after the user sent credentials).
At all time, the client can cancel the registration before the end by sending an <abort/>, to which the server must return a <failure/>
If cancellation comes from the server, this one directly sends a <failure/>.
If the feature is implemented, it MUST be advertised as a stream feature after the authentication. Though the feature MAY be used without any stream encryption, it is adviced to activate it only on encrypted stream, in order to prevent malevolent users from deleting highjacked accounts.
By definition, this feature MUST always be considered as optional.
Even when any in-band account management is undesired on a given deployment, rather than disabling completely the feature altogether, it is preferred to advertise it and provide suitable alternatives, either a human readable message, a redirection (using Out-of-Band Data (XEP-0066) ), or both in order for a user to know how one can delete one's account, especially as personal data deletion can be considered a security measure to protect private information and is legally mandatory in some countries. Note that only these two kinds of alternatives are defined in the present document, but other alternative contents may be defined in further versions of this protocol, or in other protocol. As a consequence, if an alternative is not understood, the client SHOULD silently ignore it.
The full deletion process has no more options than described in Account Deletion, except that -- same as for registration -- additional <challenge/> tags can be sent by the server and answered by the client between the <delete/> tag and the <deleted/> acknowledgement. This is particularly useful in order to protect users from inadvertently "click a button" and see their account definitely deleted. Of course a good client which is meant to be used by a human user should also provide protection to avoid this kind of mistake.
If the feature is implemented, it MUST be advertised as a stream feature after the authentication. Though the feature MAY be used without any stream encryption, it is adviced to activate it only on encrypted stream, in order to prevent malevolent users from modifying highjacked accounts credentials, hence preventing its rightful user to later log-in.
Even when in-band account modification is undesired on a given deployment, rather than disabling completely the feature altogether, it is preferred to advertise it and provide suitable alternatives, either a human readable message, a redirection (using Out-of-Band Data (XEP-0066) ), or both in order for a user to know how one can modify one's account, especially as credentials modification can be considered a security measure. Note that only these two kinds of alternatives are defined in the present document, but other alternative contents may be defined in further versions of this protocol, or in other protocol. As a consequence, if an alternative is not understood, the client SHOULD silently ignore it.
The full modification process has no more options than described in Account Modification, except that -- same as for registration -- additional <challenge/> tags can be sent by the server and answered by the client between the <modify/> tag and the <proceed/> then between <complete/> and <modified/>.
By default, this feature is optional. Nevertheless this protocol allows a modification to be a mandatory-to-negotiate feature before going further into stream negotiation by including an empty <required/> tag as recommended in section 4.3.2 of RFC-6120. This can be useful for instance on a service which has been targetted by an attack and it is believed some accounts may be compromised, hence the service would force any such account to modify their credentials.
Note: if the presumption of compromised accounts is very high, a fast move might be to reinitialize all passwords as soon as possible. But this is always not possible, for instance if the user has not provided any other way of contact (no other email, JID, address, etc.). In such a case, in order not to block user out of the service, it might be preferable to force them to make a new password themselves at their next connection.
Also some highly secure services would appreciate the possibility to force users to modify their credentials in a regular time span, even without any known compromision. For instance a governmental IM service could require the account credentials to be updated every three months.
Optionally the <required/> element MAY have a <instructions/> or a Out-of-Band Data child, in particular if the service wishes to give an explanation of this required change.
This protocol also defines an intermediary <recommended/> option meant to make users aware of security considerations. This can be used in particular if you wish to have your user aware of security issues about keeping the same password for too long, but without forcing them.
Another use case could be when your service updated storage mechanisms and wish to propose you to update. For instance a server compliant to RFC-3920 and which was mainly using DIGEST-MD5 (RFC 2831 ) could have stored the password in a hash which would be incompatible for authentication with the more secure SCRAM-* mechanisms; moreover DIGEST-MD5 is now a deprecated mechanism considered highly unsecured (see RFC 6331 ) and should be removed from usage as soon as possible.
In a <recommended/> use case, the server MAY want to propose part of the storage algorithms. For instance even when a server might still have a "DIGEST-MD5" storage mechanism implemented, when recommending a user to update to a better mechanism, it should obviously not propose the same problematic mechanism.
Optionally the <recommended/> element SHOULD have a <instructions/> or a Out-of-Band Data child, in particular if the service wishes to give an explanation of this recommended change.
A compliant client receiving such a stream feature SHOULD either automatically update the password choosing its prefered storage mechanism in the list, if it is a client without human user or if it is able to compute the storage data without prompting the user (for instance because the client stores the password as plain text, thus is able to compute any other storage data), or prompt the user, displaying the <instructions/> message so that one can decide whether or not to do the update before completing stream negotiation.
This specification will define three storage mechanisms, two of them corresponding to the mandatory-to-implement technologies for SASL authentication. Any further storage mechanism can be defined in extensions to the current protocol. These mechanisms are used either in the registration or the modification features.
The PLAIN mechanism simply sends the password as plain text, base64 encoded (to authorize characters which could be authorized in the password but would mess with XML). An empty password is obviously not authorized and will result in a <failure/> or a proposition to retry.
Note: using this storage mechanism does not mean that the implementation will necessarily be stored as plain text on the server. The server may encode this data using other more or less secure encryption scheme. Nevertheless it still means that the server has had the password at some point and that this one passed as plain text over the network.
The SASL SCRAM-* mechanism family has some very interesting features. In particular, it allows the server to store data enabling it to identify a user, without knowing the actual password, and even without being able to use this stored data to impersonate this user on another service. This is true even though the user may have used the same credentials on this third party service and if by extreme coincidence, this third party service used the same SASL mechanism, cryptographic hash function, salt and iteration count as the server. Thus this is a very secure mechanism which allows a user to trust a service for transmitting XMPP data, but avoiding to give it one's password (not necessarily because one think the service administrator may wish to impersonate you elsewhere, but also in case of database compromission). The following storage mechanism, named the same way as the corresponding SASL mechanism, allows the user to send only the strict required information for authentication to be possible without the server ever knowing the original password.
Note: the storage mechanism "SCRAM-XXX" for a given cryptographic hash function XXX, will allow a user to authenticate later to the service with the SASL mechanisms SCRAM-XXX, SCRAM-XXX-PLUS and PLAIN.
Note: when receiving the StoredKey and ServerKey, the server has no way to "test" these credentials, other than trying an authentication with the client. It is therefore the duty of the client to be sure of sending the right data, as corrupted data could block the user's account. Nevertheless the server can make a single minor check. Both StoredKey and ServerKey are the result of the hash computation, which has a defined result size. For instance, it will be 20 octets for SHA-1. As base64 codes 3 octets into 4 octets, both StoredKey and ServerKey will be 28 octets long for SCRAM-SHA1. If they are any other size, the account registration or modication must fail with <failure/> (and not be proposed for a retry. A client not able to output a rightly-sized output cannot be trusted on such a delicate operation).
X.509 certificates are very interesting as well, as they allow you to send a public certificate over the wire which cannot be used to authenticate to any service, but only to recognize you as its righful owner if you own the private key associated to it. This said, a client could generate such a certificate and send it to the server with the current protocol. Once this done, it can later authenticate with the certificate as described in Best Practices for Use of SASL EXTERNAL (XEP-0178) 
Note: this storage mechanism does not use a password on server side. The server stores only the public certificate. Yet there MAY still be a password on the private key (client side), as additional security.
Account management can be extended in the following ways:
<instructions/> elements or other similar human-readable elements should have 'xml:lang' attribute determined by the procedure in section 4.7.4 of RFC-6120
the server MUST NOT decide whether or not to propose the <registration/> feature based on the existence of the JID filled in 'from'. Doing so would leak away information about the existence of a JID which could therefore be sent undesirable messages. Being consistent on showing the feature forces to try to register which can already eliminates part of the risk if the challenge provides some bot protection (for instance CAPTCHAs).
A perfectly valid alternative would be to always provide the <registration/> feature when no "from" is filled but never provide it when a "from is filled" (no matter it is an existing JID or not). This consistent logics does not leak information.
Do not modify the SASL authentication's mechanisms listed in the <mechanisms/> feature depending on the 'from'. Even though a given JID might not be able to connect with some mechanisms because the credentials storage is incompatible, this would leak information on the kind of storage mechanism used for this user. This information would allow attackers to determine, then target, users whose storage would be weaker.
Of course this particular point might cause issues for users regularly changing their clients or log in from various computer. For instance the SCRAM-SHA-1 and SCRAM-SHA-256 storage are incompatible. If you first registered by specifying the SCRAM-SHA-256 storage, then on another client which does not support SCRAM-SHA-256 or even who supports it, but for some reason always try and gives priority to SCRAM-SHA-1, the user could be found in a situation where he never manages to authenticate while providing the right password. For this reason, it could be wiser for server deployments to choose compatible mechanisms, when possible. On client side, if they are provided a raw password, instead of pre-computed data for a specific mechanism, then they should intelligently try the various mechanisms, starting from the one they consider the stronger. Hence try SCRAM-SHA-256, then SCRAM-SHA-1 if the first failed, then only if both failed, tell the user that authentication failed (note that the client should not try PLAIN as a last fallback, because we remind that any SCRAM-* storage is compatible with the SASL PLAIN mechanism. Trying PLAIN would therefore be a security risk.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) .
This specification defines the following XML namespace:
If the protocol defined in this specification undergoes a revision that is not fully backwards-compatible with an older version, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.
REQUIRED for protocol specifications. TODO
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright (c) 1999 - 2011 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <email@example.com> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.
Errata can be sent to <firstname.lastname@example.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
14. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
15. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/