Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XEP-0484: Add an XML Schema and fix some indentation #1352

Merged
merged 5 commits into from
Jul 1, 2024
Merged

XEP-0484: Add an XML Schema and fix some indentation #1352

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
500f909
XEP-0484: Add an XML Schema
linkmauve Jun 30, 2024
2f8c977
XEP-0484: 'count' is now an attribute, not an element
linkmauve Jun 30, 2024
efbce1d
XEP-0484: Fix indentation in two examples
linkmauve Jun 30, 2024
5cce10a
XEP-0484: Release version 0.1.1
linkmauve Jun 30, 2024
883fb08
Merge branch 'master' into xep-0484
iNPUTmice Jul 1, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
97 changes: 76 additions & 21 deletions xep-0484.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,18 @@
<supersededby/>
<shortname>fast</shortname>
&mwild;
<revision>
<version>0.2.0</version>
<date>2024-06-30</date>
<initials>egp</initials>
<remark>
<ul>
<li>Added an XML Schema.</li>
<li>Fixed text where 'count' was assumed to be an element, not an attribute.</li>
<li>Fixed indentation in a few examples.</li>
</ul>
</remark>
</revision>
<revision>
<version>0.1.1</version>
<date>2024-05-24</date>
Expand Down Expand Up @@ -96,21 +108,21 @@
</inline>
</authentication>
</stream:features>
]]></example>
]]></example>
</section2>
<section2 topic='Client performs initial authentication' anchor='initial-auth'>
<p>Initially, the client won't have any FAST token to authenticate with. To obtain a token, it MUST first authenticate using another method, e.g. using a password.</p>
<p>To request a FAST token, a client MUST include a &lt;request-token/> element qualified by the 'urn:xmpp:fast:0' namespace. The element MUST contain a 'mechanism' attribute, the value of which MUST be one of the FAST mechanisms advertised by the server.</p>
<p>In the following example, the client authenticates with SCRAM-SHA-1-PLUS using a password, but requests a token for fast reauthentication in the future, using the HT-SHA-256-ENDP mechanism.</p>
<example caption=''><![CDATA[
<authenticate xmlns='urn:xmpp:sasl:2' mechanism='SCRAM-SHA-1-PLUS'>
<initial-response>[base64 encoded SASL data]</initial-response>
<bind xmlns='urn:xmpp:bind:0'>
<tag>AwesomeXMPP</tag>
</bind>
<request-token xmlns='urn:xmpp:fast:0' mechanism='HT-SHA-256-ENDP'/>
<initial-response>[base64 encoded SASL data]</initial-response>
<bind xmlns='urn:xmpp:bind:0'>
<tag>AwesomeXMPP</tag>
</bind>
<request-token xmlns='urn:xmpp:fast:0' mechanism='HT-SHA-256-ENDP'/>
</authenticate>
]]></example>
]]></example>
</section2>
<section2 topic='Server provides token to client' anchor='token-response'>
<p>Upon receiving a token request and successfully authenticating the client, the server generates a new unique token, valid for the requested mechanism, and includes it in the SASL2 &lt;success/> response in a &lt;token/> element qualified by the 'urn:xmpp:fast:0' namespace.</p>
Expand All @@ -136,23 +148,23 @@
</metadata>
</bound>
<token xmlns='urn:xmpp:fast:0'
expiry='2020-03-12T14:36:15Z'
token='WXZzciBwYmFmdmZnZiBqdmd1IGp2eXFhcmZm' />
expiry='2020-03-12T14:36:15Z'
token='WXZzciBwYmFmdmZnZiBqdmd1IGp2eXFhcmZm' />
</success>
]]></example>
]]></example>
</section2>
<section2 topic='Client authenticates using FAST' anchor='fast-auth'>
<p>The client authenticates normally using SASL2, using the FAST SASL mechanism it previously selected, and the token provided by the server. To indicate that it is providing a token, the client MUST include a &lt;fast/> element qualified by the 'urn:xmpp:fast:0' namespace, within its SASL2 authentication request.</p>
<p>If the server indicated support for TLS 0-RTT data, the client MAY send its authentication request within the TLS 0-RTT payload of its handshake. If it does this, it MUST also include a 'count' attribute on the &lt;fast/> element. The value of this attribute MUST be a positive integer, which is incremented by the client on every authentication attempt with this token (it SHOULD be reset to zero when the token changes).</p>
<p>Servers MUST reject any authentication requests received via TLS 0-RTT payloads that do not include a &lt;count/> element, or where the count is less than or equal to a count that has already been processed for this token. This protects against replay attacks that 0-RTT is susceptible to.</p>
<p>Servers MUST reject any authentication requests received via TLS 0-RTT payloads that do not include a 'count' attribute, or where the count is less than or equal to a count that has already been processed for this token. This protects against replay attacks that 0-RTT is susceptible to.</p>
<p>Servers MUST bind tokens to the mechanism selected by the client in its original request, and reject attempts to use them with other mechanisms. For example, if the client selected a mechanism capable of channel binding, an attempt to use a mechanism without channel binding MUST fail even if the token would otherwise be accepted by that mechanism.</p>
<example caption='Client authenticates successfully using a FAST token'><![CDATA[
<authenticate xmlns='urn:xmpp:sasl:2' mechanism='HT-SHA-256-ENDP'>
<initial-response>[base64 encoded SASL data]</initial-response>
<bind xmlns='urn:xmpp:bind:0'>
<tag>AwesomeXMPP</tag>
</bind>
<fast xmlns='urn:xmpp:fast:0' count='123' />
<initial-response>[base64 encoded SASL data]</initial-response>
<bind xmlns='urn:xmpp:bind:0'>
<tag>AwesomeXMPP</tag>
</bind>
<fast xmlns='urn:xmpp:fast:0' count='123' />
</authenticate>

<success xmlns='urn:xmpp:sasl:2'>
Expand All @@ -164,7 +176,7 @@
</metadata>
</bound>
</success>
]]></example>
]]></example>
</section2>
<section2 topic='Server initiates token rotation' anchor='token-rotation'>
<p>If the authentication succeeded, but the token is due for rotation (e.g. it is close to expiry), the server will generate a new token and provide it to the client in the &lt;success/> response (even if the client did not explicitly request a token):</p>
Expand All @@ -181,7 +193,7 @@
expiry='2020-03-31T14:36:15Z'
token='R3VyIHpiZmcgbnl2aXIgdmYgZ3VyIGp2eXFyZmcu' />
</success>
]]></example>
]]></example>
<p>When the server provides a new token to the client in this way, it MUST NOT invalidate the existing token until the new token is actually used by the client. This ensures that if the client gets disconnected before receiving the newer token from the server, it can still successfully authenticate on its next connection attempt.</p>
<p>Upon successful use of any token, the server MUST invalidate all tokens issued to the same client with an earlier expiry than the current token (even if those tokens have not yet reached their expiry time).</p>
<p>Additionally, upon providing a new token to the client, the server SHOULD invalidate any tokens previously generated that have not been used.</p>
Expand All @@ -197,7 +209,7 @@
<initial-response>[base64 encoded SASL data]</initial-response>
<fast xmlns='urn:xmpp:fast:0' count='123' invalidate='true'/>
</authenticate>
]]></example>
]]></example>
</section2>
</section1>
<section1 topic='Business Rules' anchor='rules'>
Expand Down Expand Up @@ -244,10 +256,53 @@
</section1>

<section1 topic='Acknowledgements' anchor='acks'>
<p>Many thanks to Daniel Gultsch and Thilo Molitor for their input, support, and implementations. Thanks also to Florian Schmaus for prior work on Instant Stream Resumption and the HT family of SASL mechanisms, which inspired and influenced this specification.</p>
<p>Many thanks to Daniel Gultsch and Thilo Molitor for their input, support, and implementations. Thanks also to Florian Schmaus for prior work on Instant Stream Resumption and the HT family of SASL mechanisms, which inspired and influenced this specification.</p>
</section1>

<section1 topic='XML Schema' anchor='schema'>
<p>TODO before reaching Stable.</p>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
xmlns='urn:xmpp:fast:0'
targetNamespace='urn:xmpp:fast:0'
elementFormDefault='qualified'>

<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
XEP-0484: https://xmpp.org/extensions/xep-0484.html
</xs:documentation>
</xs:annotation>

<xs:element name='fast'>
<xs:complexType>
<xs:sequence>
<xs:element ref='mechanism' minOccurs='0' maxOccurs='unbounded'/>
</xs:sequence>
<xs:attribute name='tls-0rtt' type='xs:boolean' use='optional'/>
<xs:attribute name='count' type='xs:int' use='optional'/>
<xs:attribute name='invalidate' type='xs:boolean' use='optional'/>
</xs:complexType>
</xs:element>

<xs:element name='mechanism' type='xs:string'/>

<xs:element name='request-token'>
<xs:complexType>
<xs:attribute name='mechanism' type='xs:string'/>
</xs:complexType>
</xs:element>

<xs:element name='token'>
<xs:complexType>
<xs:attribute name='expiry' type='xs:dateTime'/>
<xs:attribute name='token' type='xs:string'/>
</xs:complexType>
</xs:element>

</xs:schema>
]]></code>
</section1>
</xep>