XEP-xxxx: Account Management

Abstract
This specification provides a collection of stream features meant to manage one's account, in particular for account registration, deletion and change of password.
Author
Jehan Pages
Copyright
© 2011 – 2011 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status

ProtoXEP

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <https://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.
Supersedes
XEP-0077
Type
Standards Track
Version
0.0.1 (2011-07-17)
Document Lifecycle
  1. Experimental
  2. Proposed
  3. Stable
  4. Final

1. Introduction

The XMPP protocols has long had an extension for in-band account management (In-Band Registration (XEP-0077) [1]). 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 [2]); 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.

2. Issues with XEP-0077

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) [3]). 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".

2.1 Design Issues

XMPP Design Guidelines (XEP-0134) [4] 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.

2.2 Lack of Flexibility

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.

2.2.1 Rigid Syntax

Extensions are allowed through the use of Data Forms (XEP-0004) [5] 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 [6] 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.

3. Requirements

Account Management, defined herein as a collection of stream features, is designed to meet the following requirements:

  1. if a credentials exchange is necessary, render this exchange as secure as possible;
  2. define the management protocol as flexible as possible, in order to allow new features, as well as improvement of existing features;
  3. account registration in particular should be possible without being authenticated, as a stream feature.

4. Glossary

Account Management
Gestion of a client XMPP account on a given server deployment. An account is being defined by the locale part of the JID, and by the authentication mechanisms available for this account.
In-Band
Capacity of acting directly through a XMPP stream. As a consequence, an In-Band Account Management MAY allow users to bootstrap the existence of their account, and oppositely to end it, or modify it, without ever having to use another medium (like the web for instance), or without the existence of a previous account.
Storage Mechanism
The internal logics of a server to store authentication data.

5. Use Cases

5.1 Account Creation

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.

Example 1. After successful TLS encryption, server sends SASL and account registration stream features.
<stream:features>
  <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
    <mechanism>SCRAM-SHA-1</mechanism>
    <mechanism>SCRAM-SHA-1-PLUS</mechanism>
    <mechanism>SCRAM-SHA-256</mechanism>
    <mechanism>SCRAM-SHA-256-PLUS</mechanism>
    <mechanism>PLAIN</mechanism>
  </mechanisms>
  <registration xmlns='urn:xmpp:account:0'>
    <storage>SCRAM-SHA-1</storage>
    <storage>SCRAM-SHA-256</storage>
    <storage>PLAIN</storage>
  </registration>
</stream:features>

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.

Example 2. client sends a registration demand, using 2 storages.
<register xmlns='urn:xmpp:account:0'>
  <storage>SCRAM-SHA-256</storage>
  <storage>SCRAM-SHA-1</storage>
</register>
Example 3. The server accepts both storages and sends along some instructions.
<proceed xmlns='urn:xmpp:account:0'>
  <instructions>Try a long password, which is not a dictionnary word,
    using at least one uppercase, one lowercase, one number and one special character.</instructions>
  <storage>SCRAM-SHA-256</storage>
  <storage>SCRAM-SHA-1</storage>
</proceed>

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.

Example 4. The client sends the storage data for these mechanisms.
<complete xmlns='urn:xmpp:account:0'>
  <login>jehan</login>
  <store mechanism="SCRAM-SHA-256">
    <stored-key>XXXX</stored-key>
    <server-key>YYYY</server-key>
  </store>
  <store mechanism="SCRAM-SHA-1">
    <stored-key>XXXX</stored-key>
    <server-key>YYYY</server-key>
  </store>
</complete>

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

Example 5. Case 1: the server acknowledges the completion of the registration.
<registered xmlns='urn:xmpp:account:0'>
  <login>jehan@shakespeare.lit</login>
  <stored mechanism="SCRAM-SHA-1"/>
  <stored mechanism="SCRAM-SHA-256"/>
</registered>

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

Example 6. Case 2: server informs of failure
<failure xmlns='urn:xmpp:account:0' />

5.2 Account Deletion

If a server wishes to provide in-band account deletion, it MUST advertize the <deletion/> feature, qualified with the protocol namespace, after authentication.

Example 7. After successful SASL authentication, server advertizes the resource binding, the deletion and the account modification stream features.
<stream:features>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
  <deletion xmlns='urn:xmpp:account:0' />
  <modification xmlns='urn:xmpp:account:0'>
    <storage>EXTERNAL</storage>
    <storage>SCRAM-SHA-1</storage>
    <storage>SCRAM-SHA-256</storage>
  </modification>
</stream:features>

After stream features have been advertized, a user can require the deletion of one's account.

Example 8. client sends a deletion demand
<delete xmlns='urn:xmpp:account:0' />

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.

Example 9. Case 1: server informs of successful deletion
<deleted xmlns='urn:xmpp:account:0'>
  <instructions>Too bad! Hope to see you back soon in our services!</instructions>
  <login>juliet@shakespeare.lit</login>
</deleted>

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

Example 10. Case 2: server informs of failure
<failure xmlns='urn:xmpp:account:0' />

5.3 Account modification

An account modification is used for three reasons:

  1. the user wants to change its password;
  2. the user wants to change the storage mechanisms;
  3. the server wants to force or encourage users to change their password or their storage mechanisms.

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

Example 11. client sends a modification demand, using 2 storages.
<modify xmlns='urn:xmpp:account:0' />
  <storage>SCRAM-SHA-256</storage>
  <storage>SCRAM-SHA-1</storage>
</modify>

The rest of the exchange highly ressembles an account creation process.

Example 12. The server accepts both storages and sends along some instructions.
<proceed xmlns='urn:xmpp:account:0'>
  <instructions>Try a long password, which is not a dictionnary word,
    using at least one uppercase, one lowercase, one number and one special character.</instructions>
  <storage>SCRAM-SHA-256</storage>
  <storage>SCRAM-SHA-1</storage>
</proceed>
Example 13. The client sends the storage data for these mechanisms.
<complete xmlns='urn:xmpp:account:0'>
  <store mechanism="SCRAM-SHA-256">
    <stored-key>XXXX</stored-key>
    <server-key>YYYY</server-key>
  </store>
  <store mechanism="SCRAM-SHA-1">
    <stored-key>XXXX</stored-key>
    <server-key>YYYY</server-key>
  </store>
</complete>
Example 14. Case 1: server informs of successful modification
<modified xmlns='urn:xmpp:account:0'>
  <instructions>Credentials successfully modified!</instructions>
  <stored>SCRAM-SHA-1</stored>
  <stored mechanism="SCRAM-SHA-256"/>
</modified>
Example 15. Case 2: server informs of failure
<failure xmlns='urn:xmpp:account:0' />

6. Detailed Protocol Description

The following section describes exhaustively the possibilities of the three features described in this extension and possibilities of extensions.

6.1 Registration Feature

6.1.1 Feature Advertising

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) [7]), 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.

Example 16. The server acknowledges two alternative registration methods.
<stream:features>
  [...]
  <registration xmlns='urn:xmpp:account:0'>
    <alternative>
      <x xmlns='jabber:x:oob'>
        <desc>To register, visit https://www.shakespeare.lit/register.html</desc>
        <url>https://www.shakespeare.lit/register.html</url>
      </x>
    </alternative>
    <alternative>
      <instructions>In case of any problem to register, contact our support at support@shakespeare.lit!</instructions>
    </alternative>
  </registration>
  [...]
<stream:features>

If in-band registration is possible, the available <storage/> mechanisms MUST be advertised as childs of the <registration/> tag.

Example 17. The server acknowledges two different storage mechanisms.
<stream:features>
  [...]
  <registration xmlns='urn:xmpp:account:0'>
    <storage>PLAIN</storage>
    <storage>SCRAM-SHA-1</storage>
  </registration>
  [...]
<stream:features>

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.

6.1.2 Request a Registration

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.

Example 18. The server acknowledges requests a SCRAM-SHA-1 storage.
<register xmlns='urn:xmpp:account:0'>
  <mechanism>SCRAM-SHA-1</mechanism>
</register>

6.1.3 Optional: additional informations

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.

Example 19. The server sends a form challenge.
<challenge xmlns='urn:xmpp:account:0'>
  <x xmlns='jabber:x:data' type='form'>
    <title>User Information</title>
    <instructions>These information are only used for verification purpose and won't be ever divulgated to any third party.</instructions>
    <field type='text-single'
      label='Display name (optional)'
      var='display-name'/>
    <field type='text-single'
      label='Email (must be a valid email)'
      var='email'/>
  </x>
</challenge>

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.

Example 20. Case 1: the client does not understand the challenge.
<unknown-challenge xmlns='urn:xmpp:account:0'/>
Example 21. If it is considered a terminale error, the receiving entity returns a failure.
<failure xmlns='urn:xmpp:account:0'/>

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.

Example 22. Case 2: the client understands the challenge and the user fills the form.
<response xmlns='urn:xmpp:account:0'>
  <x xmlns='jabber:x:data' type='submit'>
    <field var='display-name'><value>Jehan</value></field>
    <field var='email'><value>jehan@shakespeare.lit</value></field>
  </x>
</challenge>

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

Example 23. The server sends a oob challenge.
<challenge xmlns='urn:xmpp:account:0'>
  <x xmlns='jabber:x:oob'>
    <desc>Thanks for your interest.
    If you want to know more about our services before registering,
    visit our website.</desc>
    <url>https://www.shakespeare.lit/our_im_service.html</url>
  </x>
</challenge>
Example 24. Case 2: the client acknowledges the challenge.
<response xmlns='urn:xmpp:account:0' />

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.

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

Example 25. The server asks the client to proceed with registration.
<proceed xmlns='urn:xmpp:account:0'>
  <instructions>Try a long password, which is not a dictionnary word, and using at least one uppercase, one lowercase, one number and one special character (for instance, an underscore, an hyphen, a period, a comma or a space).</instructions>
  <storage>SCRAM-SHA-1</storage>
</proceed>

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.

6.1.5 Optional: again additional information

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.

6.1.6 Registration Completed

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

Example 26. The server acknowledge the success of the registration.
<registered xmlns='urn:xmpp:account:0'>
  <instructions>Welcome to our services!
    To get more information, you can also visit our web site:
	https://shakespeare.li.</instructions>
  <login>jehan@shakespeare.lit</login>
  <stored mechanism="SCRAM-SHA1"/>
</registered>

6.1.7 Cancellation

At all time, the client can cancel the registration before the end by sending an <abort/>, to which the server must return a <failure/>

Example 27. The client cancels the registration.
<abort xmlns='urn:xmpp:account:0'/>

If cancellation comes from the server, this one directly sends a <failure/>.

6.2 Deletion Feature

6.2.1 Feature Advertising

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) [7]), 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.

6.2.2 Deletion Process

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.

6.3 Modification Feature

6.3.1 Feature Advertising

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) [7]), 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.

6.3.2 Modification Process

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

6.3.3 Mandatory Modification

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.

Example 28. After successful SASL authentication, server advertizes deletion (optional), account modification stream features (required), but no resource binding.
<stream:features>
  <deletion xmlns='urn:xmpp:account:0' />
  <modification xmlns='urn:xmpp:account:0'>
	<required/>
    <storage>EXTERNAL</storage>
  	<storage>SCRAM-SHA-1</storage>
  	<storage>SCRAM-SHA-256</storage>
  </modification>
</stream:features>

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 [9]) 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 [10]) 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.

Example 29. After successful SASL authentication, server advertizes deletion and resource binding, and recommend account modification.
<stream:features>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
  <deletion xmlns='urn:xmpp:account:0' />
  <modification xmlns='urn:xmpp:account:0'>
    <recommended>
      <instructions>We updated the storage of your password in a much more secure way, but it requires you to update it.</instructions>
    </recommended>
  	<storage>SCRAM-SHA-1</storage>
  	<storage>SCRAM-SHA-256</storage>
  </modification>
</stream:features>

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.

6.4 Defined Storage Mechanisms

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.

6.4.1 PLAIN mechanism

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.

Example 30. The client sends the storage data with PLAIN for password "Juliet, je t'M!".
<complete xmlns='urn:xmpp:account:0'>
  <login>jehan</login>
  <store mechanism="PLAIN">
    <password>SnVsaWV0LCBqZSB0J00h</password>
  </store>
</complete>

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.

6.4.2 SCRAM-* mechanisms

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.

See RFC 5802 [11] for more information about the StoredKey and the ServerKey in the context of SCRAM-*. Both data are base64-encoded.

Example 31. The client sends the storage data with SCRAM-SHA1 for password "Juliet, je t'M!".
<complete xmlns='urn:xmpp:account:0'>
  <login>jehan</login>
  <store mechanism="SCRAM-SHA-1">
    <stored-key>XXXX</stored-key>
    <server-key>YYYY</server-key>
  </store>
</complete>

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

6.4.3 Certificate mechanism

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) [12]

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.

Example 32. The client sends a public certificate to be stored by the server.
<complete xmlns='urn:xmpp:account:0'>
  <login>jehan</login>
  <store mechanism="X509-CERT">
    <certificate>A certificate in PEM format</certificate>
  </store>
</complete>

6.5 Protocol Extensions

Account management can be extended in the following ways:

7. Business Rules

8. Internationalization Considerations

<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

9. Security Considerations

10. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [14].

11. XMPP Registrar Considerations

11.1 Protocol Namespaces

This specification defines the following XML namespace:

The XMPP Registrar [15] includes the foregoing namespace in its registry at <https://xmpp.org/registrar/namespaces.html>, as governed by XMPP Registrar Function (XEP-0053) [13].

11.2 Namespace Versioning

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.

12. XML Schema

REQUIRED for protocol specifications. TODO


Appendices

Appendix A: Document Information

Series
XEP
Number
xxxx
Publisher
XMPP Standards Foundation
Status
ProtoXEP
Type
Standards Track
Version
0.0.1
Last Updated
2011-07-17
Approving Body
XMPP Council
Dependencies
XMPP Core
Supersedes
XEP-0077
Superseded By
None
Short Name
NOT_YET_ASSIGNED

This document in other formats: XML  PDF

Appendix B: Author Information

Jehan Pages
Email
hysseo@zemarmot.net
JabberID
hysseo@zemarmot.net

Copyright

This XMPP Extension Protocol is copyright (c) 1999 - 2011 by the XMPP Standards Foundation (XSF).

Permissions

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.

Disclaimer of Warranty

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

Limitation of Liability

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.

IPR Conformance

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

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

Appendix D: Relation to XMPP

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.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

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

Appendix G: Notes

1. XEP-0077: In-Band Registration <https://xmpp.org/extensions/xep-0077.html>.

2. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.

3. XEP-0050: Ad-Hoc Commands <https://xmpp.org/extensions/xep-0050.html>.

4. XEP-0134: XMPP Design Guidelines <https://xmpp.org/extensions/xep-0134.html>.

5. XEP-0004: Data Forms <https://xmpp.org/extensions/xep-0004.html>.

6. RFC 4854: A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP) <http://tools.ietf.org/html/rfc4854>.

7. XEP-0066: Out of Band Data <https://xmpp.org/extensions/xep-0066.html>.

8. XEP-0158: CAPTCHA Forms <https://xmpp.org/extensions/xep-0158.html>.

9. RFC 2831: Using Digest Authentication as a SASL Mechanism <http://tools.ietf.org/html/rfc2831>.

10. RFC 6331: Moving DIGEST-MD5 to Historic <http://tools.ietf.org/html/rfc6331>.

11. RFC 5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms <http://tools.ietf.org/html/rfc5802>.

12. XEP-0178: Best Practices for Use of SASL EXTERNAL <https://xmpp.org/extensions/xep-0178.html>.

13. XEP-0053: XMPP Registrar Function <https://xmpp.org/extensions/xep-0053.html>.

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

Appendix H: Revision History

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

  1. Version 0.0.1 (2011-07-17)

    First draft.

    jp

Appendix I: Bib(La)TeX Entry

@report{pages2011xepxxxx,
  title = {Account Management},
  author = {Pages, Jehan},
  type = {XEP},
  number = {xxxx},
  version = {0.0.1},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-xxxx.html},
  date = {2011-07-17/2011-07-17},
}

END