<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>
</di>
<di><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></di>
<di><dt>Storage Mechanism</dt>
<dd>The internal logics of a server to store authentication data.</dd></di>
</dl>
</section1>
<section1topic='Use Cases'anchor='usecases'>
@ -481,13 +481,13 @@
<li>For a better user experience, it is important to provide <challenge/> fallbacks rather than directly fail with a <failure/> on the first user error. <cite>XEP-0158</cite> for instance proposes to fail directly on a wrong answer to a CAPTCHA challenge, while it is well known that many actual human users regularly fails, sometimes even several, captchas before succeeding one. As a consequence, in such a case or other similar challenge, it is better to return a new challenge (a new CAPTCHA for instance) rather than cancelling the negotiation, doing so eventually only after a few retries.</li>
<li>The storage mechanism does not mean necessarily that credentials have to be stored in the given form, in particular when the server estimates a storage mechanism being stronger than the one desired by the user, and still without losing any authentication possibility. For instance if a client was to exchange credentials in PLAIN, and if the server usually provides SCRAM-SHA1, SCRAM-SHA-256 and PLAIN authentication mechanisms, then it would be wise to store it as both SCRAM-SHA-1 and SCRAM-SHA-256 instead of PLAIN. This way the security of the password is highly renforced in the case of the database being stolen and the three authentication mechanisms are still available to this user. Of course it would have been even more secure for the client itself to exchange the credentials as SCRAM-SHA-1 and SCRAM-SHA-256 from the start, because by exchanging PLAIN data, possibility is given to a man-in-the-middle attack to steal directly the password during this one-time account registration.</li>
<li>Security may have a price. If you were to store credentials with SCRAM-SHA-256 only, and later you change to a client which supports only PLAIN and SCRAM-SHA-1, you may fall in a case where you force yourself to log in using PLAIN. For this reason, a good client implementation SHOULD be able to determine such edge case. In the previous case, if possible, it SHOULD have stored both SCRAM-SHA-1 and SCRAM-SHA-256 on registration or silently modify later its storage.</li>
<li>When registering a new account, considering that the user has obviously not been authenticated yet, the server MUST NOT rely on the 'from' value of the initiating stream. In particular:</li>
<li>When registering a new account, considering that the user has obviously not been authenticated yet, the server MUST NOT rely on the 'from' value of the initiating stream. In particular:
<ul>
<li>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).
<br />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.</li>
<li>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.
<br/>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.</li>
</ul>
<li><p>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).</p>
<p>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.</p></li>
<li><p>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.</p>
<p>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.</p></li>
@ -117,7 +117,7 @@ Examples for balancing algorithms include:
<section1topic='Protocol'anchor='protocol'>
<section2topic='Discovering Support'>
An entity advertises support for this protocol by including the 'urn:xmpp:cmr:0' feature in its service discovery information features as specified in Service Discovery (XEP-0030) or section 6.3 of Entity Capabilities (XEP-0015).
<p>An entity advertises support for this protocol by including the 'urn:xmpp:cmr:0' feature in its service discovery information features as specified in Service Discovery (XEP-0030) or section 6.3 of Entity Capabilities (XEP-0015).</p>
<examplecaption='Service discovery information request'><![CDATA[
<iqxmlns='jabber:client'
@ -217,7 +217,7 @@ If the server is unable to change the message routing algorithm, then an error &
<section2topic='Message Routing Hints'>
If allowed and supported by the server, clients are able to annotate message stanza with a routing hint, that SHOULD affect the used message routing algorithm for the annotated stanza.
<p>If allowed and supported by the server, clients are able to annotate message stanza with a routing hint, that SHOULD affect the used message routing algorithm for the annotated stanza.</p>
<section3topic='Determing support'>
@ -306,7 +306,7 @@ The CMR state, ie. the used routing algorithm, is identical for every session of
Deliver to all non-negative resources with share the same maximum priority. And if message type is 'chat', only to those that have opted in to receive chat messages.
<p>Deliver to all non-negative resources with share the same maximum priority. And if message type is 'chat', only to those that have opted in to receive chat messages.</p>
</section3>
@ -314,7 +314,7 @@ Deliver to all non-negative resources with share the same maximum priority. And
<p>To signal the type of communication that is desired, the entity that first decloaks MAY include a 'reason' attribute on the <decloak/> element. The following values for the 'reason' attribute are defined:</p>
<dl>
<dt>media</dt>
<dd>Presence is requested for a voice and/or video call, e.g. via &xep0167;.</dd>
<dt>text</dt>
<dd>Presence is requested for a plaintext or &xep0071; conversation, e.g. with end-to-end encryption (which requires capabilities to be disclosed).</dd>
<dt>file</dt>
<dd>Presence is requested for one or more file transfers, e.g. via &xep0234; or &xep0095;.</dd>
<di>
<dt>media</dt>
<dd>Presence is requested for a voice and/or video call, e.g. via &xep0167;.</dd>
</di>
<di>
<dt>text</dt>
<dd>Presence is requested for a plaintext or &xep0071; conversation, e.g. with end-to-end encryption (which requires capabilities to be disclosed).</dd>
</di>
<di>
<dt>file</dt>
<dd>Presence is requested for one or more file transfers, e.g. via &xep0234; or &xep0095;.</dd>
</di>
</dl>
<p>Inclusion of the 'reason' attribute can be interpreted by the receiving client as a signal that communication is about to start; for instance, a call accept/reject dialog could double as a UI for accepting or rejecting a decloaking request.</p>
<p>If a MUC service supports distributed rooms, it MUST return a feature of "urn:xmpp:dmuc:0"&NSVER; in response to &xep0030; information requests.</p>
<p>If a MUC service supports distributed rooms, it MUST return a feature of "urn:xmpp:dmuc:0" in response to &xep0030; information requests.</p>
<!ENTITY DATETIME "<span class='ref'><linkurl='http://tools.ietf.org/html/rfc3339'>DATETIME</link></span><note>RFC 3339: Date and Time on the Internet Timestamps <<linkurl='http://tools.ietf.org/html/rfc3339'>http://tools.ietf.org/html/rfc3339</link>>.</note>" >
<!ENTITY XMLDSIG "<span class='ref'><linkurl='http://www.w3.org/TR/xmldsig-core/'>XMLDSIG</link></span><note>XML Signature Syntax and Processing, W3C Recommendation, 10 June 2008 <<linkurl='http://www.w3.org/TR/xmldsig-core/'>http://www.w3.org/TR/xmldsig-core/</link>>.</note>" >
<!ENTITY E2EEncrypt "<span class='ref'><linkurl='http://datatracker.ietf.org/doc/draft-miller-3923bis'>E2EEncrypt</link></span><note>End-to-End Object Encryption for the Extensible Messaging and Presence Protocol (XMPP), Miller, M. and P. Saint-Andre, work in progress <<linkurl='http://datatracker.ietf.org/doc/draft-miller-3923bis'>http://datatracker.ietf.org/doc/draft-miller-3923bis</link>>.</note>" >
<section2topic='Unsubscribing a subscription'anhor='unsubscribe'>
<section2topic='Unsubscribing a subscription'anchor='unsubscribe'>
<p>
To unsubscribe a subscription, send the <strong>unsubscribe</strong> element in a request to the Thing with the <strong>seqnr</strong> sequence number corresponding to the
subscription. The Thing responds with an empty response to acknowledge the un-subscription, regardless if the subscription existed or not.
<em>In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services.</em>
<p><em>In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services.</em></p>
</section2>
<section2topic="Jingle Client Searches for Services on a Retrieved Tracker Service"anchor="clientcheckownserver">
<p>A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on the known Tracker Services.</p>
@ -139,7 +139,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<em>In this example 'capulet.lit' returned an empty service list, meaning that it does NOT known ANY Relay or Tracker Services.</em>
<p><em>In this example 'capulet.lit' returned an empty service list, meaning that it does NOT known ANY Relay or Tracker Services.</em></p>
</section2>
<section2topic="Jingle Client Searches for Services on online Roster Entries"anchor="clientcheckownserver">
<p>A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on his Roster Items until find the desired amount of Relay Services, or while it does NOT exceed a search depth or ANY other Client implementation policy. The Client SHOULD keep a list of visited Tracker Services in order to avoid searching twice in same Service Entity.</p>
@ -161,7 +161,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
</services>
</iq> ]]></example>
<p>In this example 'juliet@capulet.lit/balcony' returned a Relay Service entry that is restricted to its roster. This Service is usable as the requester has 'juliet@capulet.lit/balcony' on its roster. Although, services with policy 'roster' MUST NOT be listed in Tracker Responses expects in Tracker Responses that comes from the Service Entity itself, in this case 'juliet@capulet.lit/balcony'.</p>
<em>In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.</em>
<p><em>In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.</em></p>
</section2>
<section2topic="Jingle Client Consuming the Relay Service"anchor="clientconsumingrelay">
<p>A Jingle Client with direct access to a public IP can potentially provide the Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, whitelist, blacklist, domain, etc...</p>
@ -372,15 +372,9 @@ All signalling, request, response and publishing is done via XMPP, not requiring
<p>Relay Channels auto expires MUST expire on traffic inactivity. The inactivity timeout recommended is 60 seconds.</p>
<p>It is heavily recommended that the Super Node implements throttle:</p>
<ul>
<p>
<li>Based on JID, allowing the control of how many concurrent channels an specific JID can have.</li>
</p>
<p>
<li>Based on JID, allowing the control of how many channel requests an specific JID can request in a time period.</li>
</p>
<p>
<li>Based on Bandwidth, allowing the control of how much bandwidth a channel can use. The maximum bandwidth SHOULD be included on the candidate element provided by a Super Node on the attribute maxkbps. If no attribute is present, it means that it has no bandwidth control.</li>
</p>
<li>Based on Bandwidth, allowing the control of how much bandwidth a channel can use. The maximum bandwidth SHOULD be included on the candidate element provided by a Super Node on the attribute maxkbps. If no attribute is present, it means that it has no bandwidth control.
<examplecaption="Channel Returned by a Node with bandwidth throttle (stub)"><
Jonas Wielicki
6 years ago