<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.</abstract>
<legal>
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2011 by the XMPP Standards Foundation (XSF).</copyright>
<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.</permissions>
<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. ##</warranty>
<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.</liability>
<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 <<linkurl='http://www.xmpp.org/extensions/ipr-policy.shtml'>http://www.xmpp.org/extensions/ipr-policy.shtml</link>> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).</conformance>
</legal>
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
<supersedes>XEP-0077</supersedes>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<author>
<firstname>Jehan</firstname>
<surname>Pages</surname>
<email>hysseo@zemarmot.net</email>
<jid>hysseo@zemarmot.net</jid>
</author>
<revision>
<version>0.0.1</version>
<date>2011-07-17</date>
<initials>jp</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>The XMPP protocols has long had an extension for in-band account management (&xep0077;). 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 &rfc6120;); 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.</p>
</section1>
<section1topic='Issues with XEP-0077'anchor='rules'>
<p><cite>XEP-0077</cite> 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 &xep0050;). 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 <cite>XEP-0077</cite>). The present extension plans on being this "successor protocol".</p>
<section2topic='Design Issues'anchor='design'>
<p>&xep0134; clearly states that "XMPP is Sacred", in the meaning that extensions MUST NOT break the basic design of XMPP. <cite>XEP-0077</cite> proposes to send IQ stanzas, qualified with the content namespace, on an incompletely negotiated stream, which is contradictory to <cite>RFC-6120</cite>'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.
<br/>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.</p>
</section2>
<section2topic='Lack of Flexibility'anchor='lack-flexibility'>
<p>Even though we could pass on the blasphemy over XMPP design, and would want to build over <cite>XEP-0077</cite> to support secure features of newer SASL mechanisms, it would require a way to extend <cite>XEP-0077</cite> 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.</p>
<section3topic='Rigid Syntax'anchor='rigidity'>
<p>Extensions are allowed through the use of &xep0004; only. <cite>Data Forms</cite> are flexible for humans, yet security requires explicit definitions and automatic computations of cryptographic algorithms, which is impossible with generic <cite>Data Forms</cite>. 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).</p>
<p>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 &rfc4854; 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.</p>
</section3>
<p>As a consequence of these various points, it makes more sense to design this new extension from scratch, adapted to XMPP design and flexibility.</p>
</section2>
</section1>
<section1topic='Requirements'anchor='reqs'>
<p><strong>Account Management</strong>, defined herein as a collection of stream features, is designed to meet the following requirements:</p>
<ol>
<li>if a credentials exchange is necessary, render this exchange as secure as possible;</li>
<li>define the management protocol as flexible as possible, in order to allow new features, as well as improvement of existing features;</li>
<li>account registration in particular should be possible without being authenticated, as a stream feature.</li>
</ol>
</section1>
<section1topic='Glossary'anchor='glossary'>
<dl>
<di>
<dt>Account Management</dt>
<dd>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.</dd>
<dt>In-Band</dt>
<dd>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.</dd>
<dt>Storage Mechanism</dt>
<dd>The internal logics of a server to store authentication data.</dd>
<p>A XMPP account usually consists of a <cite>JID</cite> and the <em>secret</em> necessary to impersonate it, in other words <strong>credentials</strong>. 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.</p>
<p>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.</p>
<examplecaption='After successful TLS encryption, server sends SASL and account registration stream features.'><![CDATA[
<p>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.</p>
<examplecaption='client sends a registration demand, using 2 storages.'><![CDATA[
<registerxmlns='urn:xmpp:account:0'>
<storage>SCRAM-SHA-256</storage>
<storage>SCRAM-SHA-1</storage>
</register>
]]></example>
<examplecaption='The server accepts both storages and sends along some instructions.'><![CDATA[
<proceedxmlns='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>
<p>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 (<cite>PLAIN</cite>, <cite>SCRAM-SHA-1</cite> and <cite>SCRAM-SHA-256</cite>), the server SHOULD answer to proceed only with <cite>SCRAM-SHA-1</cite> and <cite>SCRAM-SHA-256</cite>, the exchange being by far more secure, and equivalent in authentication posssibilities.</p>
<examplecaption='The client sends the storage data for these mechanisms.'><![CDATA[
<completexmlns='urn:xmpp:account:0'>
<login>jehan</login>
<storemechanism="SCRAM-SHA-256">
<stored-key>XXXX</stored-key>
<server-key>YYYY</server-key>
</store>
<storemechanism="SCRAM-SHA-1">
<stored-key>XXXX</stored-key>
<server-key>YYYY</server-key>
</store>
</complete>
]]></example>
<p>Note: following the same logics as <cite>RFC-6120</cite> (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 <cite>RFC-6120</cite>).</p>
<examplecaption='Case 1: the server acknowledges the completion of the registration.'><![CDATA[
<registeredxmlns='urn:xmpp:account:0'>
<login>jehan@shakespeare.lit</login>
<storedmechanism="SCRAM-SHA-1"/>
<storedmechanism="SCRAM-SHA-256"/>
</registered>
]]></example>
<p>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 <cite>RFC-6120</cite>, section 4.7.1).</p>
<examplecaption='Case 2: server informs of failure'><![CDATA[
<p>If a server wishes to provide in-band account deletion, it MUST advertize the <deletion/> feature, qualified with the protocol namespace, after authentication.</p>
<examplecaption='After successful SASL authentication, server advertizes the resource binding, the deletion and the account modification stream features.'><![CDATA[
<stream:features>
<bindxmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
<deletionxmlns='urn:xmpp:account:0'/>
<modificationxmlns='urn:xmpp:account:0'>
<storage>EXTERNAL</storage>
<storage>SCRAM-SHA-1</storage>
<storage>SCRAM-SHA-256</storage>
</modification>
</stream:features>
]]></example>
<p>After stream features have been advertized, a user can require the deletion of one's account.</p>
<examplecaption='client sends a deletion demand'><![CDATA[
<deletexmlns='urn:xmpp:account:0'/>
]]></example>
<p>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 <cite>RFC-6120</cite>, 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.</p>
<examplecaption='Case 1: server informs of successful deletion'><![CDATA[
<deletedxmlns='urn:xmpp:account:0'>
<instructions>Too bad! Hope to see you back soon in our services!</instructions>
<login>juliet@shakespeare.lit</login>
</deleted>
]]></example>
<p>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).</p>
<examplecaption='Case 2: server informs of failure'><![CDATA[
<p>An account modification is used for three reasons:</p>
<ol>
<li>the user wants to change its password;</li>
<li>the user wants to change the storage mechanisms;</li>
<li>the server wants to force or encourage users to change their password or their storage mechanisms.</li>
</ol>
<p>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).</p>
<examplecaption='client sends a modification demand, using 2 storages.'><![CDATA[
<modifyxmlns='urn:xmpp:account:0'/>
<storage>SCRAM-SHA-256</storage>
<storage>SCRAM-SHA-1</storage>
</modify>
]]></example>
<p>The rest of the exchange highly ressembles an account creation process.</p>
<examplecaption='The server accepts both storages and sends along some instructions.'><![CDATA[
<proceedxmlns='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>
<examplecaption='The client sends the storage data for these mechanisms.'><![CDATA[
<completexmlns='urn:xmpp:account:0'>
<storemechanism="SCRAM-SHA-256">
<stored-key>XXXX</stored-key>
<server-key>YYYY</server-key>
</store>
<storemechanism="SCRAM-SHA-1">
<stored-key>XXXX</stored-key>
<server-key>YYYY</server-key>
</store>
</complete>
]]></example>
<examplecaption='Case 1: server informs of successful modification'><![CDATA[
<p>The following section describes exhaustively the possibilities of the three features described in this extension and possibilities of extensions.</p>
<p>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.</p>
<p>By definition, this feature MUST always be considered as optional.</p>
<p>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 &xep0066;), 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.</p>
<examplecaption='The server acknowledges two alternative registration methods.'><![CDATA[
<instructions>In case of any problem to register, contact our support at support@shakespeare.lit!</instructions>
</alternative>
</registration>
[...]
<stream:features>
]]></example>
<p>If in-band registration is possible, the available <storage/> mechanisms MUST be advertised as childs of the <registration/> tag.</p>
<examplecaption='The server acknowledges two different storage mechanisms.'><![CDATA[
<stream:features>
[...]
<registrationxmlns='urn:xmpp:account:0'>
<storage>PLAIN</storage>
<storage>SCRAM-SHA-1</storage>
</registration>
[...]
<stream:features>
]]></example>
<p>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 <cite>PLAIN</cite> 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 <cite>SCRAM-SHA1</cite> storage will allow the use of the SASL <cite>SCRAM-SHA1</cite>, <cite>SCRAM-SHA1-PLUS</cite>, but also the <cite>PLAIN</cite> mechanisms.</p>
<p>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 <cite>Out-of-Band Data</cite> 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.</p>
</section3>
<section3topic='Request a Registration'anchor='request-registration'>
<p>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.</p>
<examplecaption='The server acknowledges requests a SCRAM-SHA-1 storage.'><![CDATA[
<p>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:</p>
<ul>
<li>a data form (as described in &xep0004;) <x/> tag as a direct child that the user is expected to fill. A deployment could therefore propose (or require) to enter various information, for instance real name, address, and so on;</li>
<li>an <instructions/> tag giving various human-readable information (without requiring any data to be filled);</li>
<li>an <cite>Out-of-Band Data</cite> link, with optional <desc/> can be used for instance to ask a user to click a given link before going further, which could be for instance an http link with a random question (captcha) to confirm you are not a machine;</li>
<p>Further versions of this protocol or other extensions may add new type of possible contents.</p>
<examplecaption='The server sends a form challenge.'><![CDATA[
<challengexmlns='urn:xmpp:account:0'>
<xxmlns='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>
<fieldtype='text-single'
label='Display name (optional)'
var='display-name'/>
<fieldtype='text-single'
label='Email (must be a valid email)'
var='email'/>
</x>
</challenge>
]]></example>
<p>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.</p>
<examplecaption='Case 1: the client does not understand the challenge.'><![CDATA[
<unknown-challengexmlns='urn:xmpp:account:0'/>
]]></example>
<examplecaption='If it is considered a terminale error, the receiving entity returns a failure.'><![CDATA[
<failurexmlns='urn:xmpp:account:0'/>
]]></example>
<p>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.</p>
<examplecaption='Case 2: the client understands the challenge and the user fills the form.'><![CDATA[
<p>If a challenge awaits for no response, for instance if the challenge consists only on <instructions> or <cite>Out-of-Band Data</cite>, 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).</p>
<examplecaption='The server sends a oob challenge.'><![CDATA[
<challengexmlns='urn:xmpp:account:0'>
<xxmlns='jabber:x:oob'>
<desc>Thanks for your interest.
If you want to know more about our services before registering,
<examplecaption='Case 2: the client acknowledges the challenge.'><![CDATA[
<responsexmlns='urn:xmpp:account:0'/>
]]></example>
<p>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.</p>
<p>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.</p>
<examplecaption='The server asks the client to proceed with registration.'><![CDATA[
<proceedxmlns='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>
]]></example>
<p>The client sends the credentials data. This part is discussed later in <linkurl='#mechanisms'>Defined Storage Mechanisms</link>.</p>
<p>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.</p>
</section3>
<section3topic='Optional: again additional information'anchor='additional-after'>
<p>After the Registration step, the server can again request new <challenge/> as described in <linkurl='#additional-before'>Optional: additional informations</link>.</p>
<p>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.</p>
<p>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).</p>
<examplecaption='The server acknowledge the success of the registration.'><![CDATA[
<registeredxmlns='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>
<storedmechanism="SCRAM-SHA1"/>
</registered>
]]></example>
</section3>
<section3topic='Cancellation'anchor='cancel'>
<p>At all time, the client can cancel the registration before the end by sending an <abort/>, to which the server must return a <failure/></p>
<examplecaption='The client cancels the registration.'><![CDATA[
<abortxmlns='urn:xmpp:account:0'/>
]]></example>
<p>If cancellation comes from the server, this one directly sends a <failure/>.</p>
<p>If the feature is implemented, it MUST be advertised as a stream feature <strong>after</strong> 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.</p>
<p>By definition, this feature MUST always be considered as optional.</p>
<p>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 &xep0066;), 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.</p>
<p>The full deletion process has no more options than described in <linkurl='#deletion'>Account Deletion</link>, except that -- same as for registration -- <linkurl='#additional-before'>additional <challenge/> tags</link> 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.</p>
<p>If the feature is implemented, it MUST be advertised as a stream feature <strong>after</strong> 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.</p>
<p>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 &xep0066;), 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.</p>
<p>The full modification process has no more options than described in <linkurl='#modification'>Account Modification</link>, except that -- same as for registration -- <linkurl='#additional-before'>additional <challenge/> tags</link> can be sent by the server and answered by the client between the <modify/> tag and the <proceed/> then between <complete/> and <modified/>.</p>
<p>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 <cite>RFC-6120</cite>. 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.</p>
<p>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.</p>
<p>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.</p>
<examplecaption='After successful SASL authentication, server advertizes deletion (optional), account modification stream features (required), but no resource binding.'><![CDATA[
<stream:features>
<deletionxmlns='urn:xmpp:account:0'/>
<modificationxmlns='urn:xmpp:account:0'>
<required/>
<storage>EXTERNAL</storage>
<storage>SCRAM-SHA-1</storage>
<storage>SCRAM-SHA-256</storage>
</modification>
</stream:features>
]]></example>
<p>Optionally the <required/> element MAY have a <instructions/> or a <cite>Out-of-Band Data</cite> child, in particular if the service wishes to give an explanation of this required change.</p>
<p>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.
<br/>Another use case could be when your service updated storage mechanisms and wish to propose you to update. For instance a server compliant to <cite>RFC-3920</cite> and which was mainly using DIGEST-MD5 (&rfc2831;) 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 &rfc6331;) and should be removed from usage as soon as possible.</p>
<p>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.</p>
<p>Optionally the <recommended/> element SHOULD have a <instructions/> or a <cite>Out-of-Band Data</cite> child, in particular if the service wishes to give an explanation of this recommended change.</p>
<examplecaption='After successful SASL authentication, server advertizes deletion and resource binding, and recommend account modification.'><![CDATA[
<stream:features>
<bindxmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
<deletionxmlns='urn:xmpp:account:0'/>
<modificationxmlns='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>
]]></example>
<p>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.</p>
<p>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.</p>
<section3topic="PLAIN mechanism"anchor="plain">
<p>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.</p>
<examplecaption='The client sends the storage data with PLAIN for password "Juliet, je t'M!".'><![CDATA[
<completexmlns='urn:xmpp:account:0'>
<login>jehan</login>
<storemechanism="PLAIN">
<password>SnVsaWV0LCBqZSB0J00h</password>
</store>
</complete>
]]></example>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>See &rfc5802; for more information about the StoredKey and the ServerKey in the context of SCRAM-*. Both data are base64-encoded.</p>
<examplecaption='The client sends the storage data with SCRAM-SHA1 for password "Juliet, je t'M!".'><![CDATA[
<completexmlns='urn:xmpp:account:0'>
<login>jehan</login>
<storemechanism="SCRAM-SHA-1">
<stored-key>XXXX</stored-key>
<server-key>YYYY</server-key>
</store>
</complete>
]]></example>
<p>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).</p>
<p>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 &xep0178;</p>
<p>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.</p>
<examplecaption='The client sends a public certificate to be stored by the server.'><