moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-25 18:52:23 -05:00
Code Issues Releases Wiki Activity

1.4rc5

Browse Source
This commit is contained in:
stpeter 2011-04-20 09:30:57 -06:00
parent 7692f448e2
commit abe842366c
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
xep-0178.xml
View File

@ -24,10 +24,10 @@
&stpeter; &stpeter;
&pgmillard; &pgmillard;
<revision> <revision>
<version>1.1rc4</version> <version>1.1rc5</version>
<date>in progress, last updated 2011-04-14</date> <date>in progress, last updated 2011-04-20</date>
<initials>psa</initials> <initials>psa</initials>
<remark><p>Updated to reflect RFC 6120 and RFC 6125.</p></remark> <remark><p>Updated to be consistent with RFC 6120 and RFC 6125.</p></remark>
</revision> </revision>
<revision> <revision>
<version>1.0</version> <version>1.0</version>
@ -97,7 +97,7 @@
</revision> </revision>
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<p>XMPP as specified in &rfc3920; and updated in &rfc6120; allows the use of any SASL (&rfc4422;) mechanism in the authentication of XMPP entities. This document specifies a recommended protocol flow for use of the SASL EXTERNAL mechanism with PKIX (&rfc5280;) certificates <note>This specification focuses on the use of the SASL EXTERNAL mechanism with X.509 certificates. Future specifications may document best practices for use of SASL EXTERNAL outside the context of the X.509 infrastructure, for example via Internet Protocol Security (IPSec) as specified in &rfc4301;.</note>, expecially when an XMPP service indicates that TLS is mandatory-to-negotiate. <note>The protocol flows when TLS is not required are more complicated (e.g., alternate flows involving server dialback) and may be described in a future version of this document.</note></p> <p>XMPP as specified in &rfc3920; and updated in &rfc6120; allows the use of any SASL (&rfc4422;) mechanism in the authentication of XMPP entities. This document specifies a recommended protocol flow for use of the SASL EXTERNAL mechanism with PKIX (&rfc5280;) certificates <note>This specification focuses on the use of the SASL EXTERNAL mechanism with X.509 certificates. Future specifications may document best practices for use of SASL EXTERNAL outside the context of the X.509 infrastructure, for example via Internet Protocol Security (IPSec) as specified in &rfc4301;.</note>, expecially when an XMPP service indicates that TLS is mandatory-to-negotiate.</p>
</section1> </section1>
<section1 topic='Client-to-Server Recommendation' anchor='c2s'> <section1 topic='Client-to-Server Recommendation' anchor='c2s'>
<p>As specified in <cite>RFC 3920</cite> and updated in <cite>RFC 6120</cite>, during the stream negotiation process an XMPP client can present a certificate (a "client certificate"). If a JabberID is included in a client certificate, it is encapsulated as an id-on-xmppAddr Object Identifier ("xmppAddr"), i.e., a subjectAltName entry of type otherName with an ASN.1 Object Identifier of "id-on-xmppAddr" as specified in Section 13.7.1.4 of <cite>RFC 6120</cite>.</p> <p>As specified in <cite>RFC 3920</cite> and updated in <cite>RFC 6120</cite>, during the stream negotiation process an XMPP client can present a certificate (a "client certificate"). If a JabberID is included in a client certificate, it is encapsulated as an id-on-xmppAddr Object Identifier ("xmppAddr"), i.e., a subjectAltName entry of type otherName with an ASN.1 Object Identifier of "id-on-xmppAddr" as specified in Section 13.7.1.4 of <cite>RFC 6120</cite>.</p>
@ -353,7 +353,7 @@
]]></code> ]]></code>
</li> </li>
<li> <li>
<p>Server2 advertises SASL mechanisms. If the 'from' attribute of the stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from <cite>RFC 6125</cite>, Server2 SHOULD advertise the SASL EXTERNAL mechanism. If no match is found, Server2 closes Server1's TCP connection.</p> <p>Server2 advertises SASL mechanisms. If the 'from' attribute of the stream header sent by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from <cite>RFC 6125</cite>, Server2 SHOULD advertise the SASL EXTERNAL mechanism. If no match is found, Server2 MAY either close Server1's TCP connection or continue with a &xep0220; negotiation.</p>
<code><![CDATA[ <code><![CDATA[
<stream:features> <stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
@ -364,7 +364,7 @@
]]></code> ]]></code>
</li> </li>
<li> <li>
<p>Server1 considers EXTERNAL to be its preferred SASL mechanism. For server-to-server authentication the &lt;auth/&gt; element MUST NOT include an authorization identity (thus Server1 includes an empty response of "=" as shown in <cite>RFC 6120</cite>).</p> <p>Server1 considers EXTERNAL to be its preferred SASL mechanism. For server-to-server authentication, the &lt;auth/&gt; element MAY include an authorization identity, however a future version of this specification might disallow use of the authorization identity in server-to-server authentication (in the following example, Server1 includes an empty response of "=" as shown in <cite>RFC 6120</cite>).</p>
<code><![CDATA[ <code><![CDATA[
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='EXTERNAL'>=</auth> <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='EXTERNAL'>=</auth>
]]></code> ]]></code>