moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

1.1rc6

Browse Source
This commit is contained in:
stpeter 2011-04-25 11:38:27 -06:00
parent d15901b449
commit c16468b544
1 changed files with 9 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
xep-0178.xml
View File

@ -24,10 +24,10 @@
&stpeter;
&pgmillard;
<revision>
<version>1.1rc5</version>
<version>1.1rc6</version>
<date>in progress, last updated 2011-04-20</date>
<initials>psa</initials>
<remark><p>Updated to be consistent with RFC 6120 and RFC 6125.</p></remark>
<remark><p>Updated text and examples to be consistent with RFC 6120 and RFC 6125.</p></remark>
</revision>
<revision>
<version>1.0</version>
@ -97,7 +97,7 @@
</revision>
</header>
<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.</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 might 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>, especially when an XMPP service indicates that TLS is mandatory-to-negotiate.</p>
</section1>
<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>
@ -198,7 +198,7 @@
<p>Client considers EXTERNAL to be its preferred SASL mechanism so it attempts to complete SASL negotiation using that mechanism. The following paragraphs illustrate several possible paths, depending on whether the client includes an authorization identity (for the official rules regarding when to include the authorization identity, see Section 6.3.8 of <cite>RFC 6120</cite>).</p>
<ol style='list-style-type:lower-alpha'>
<li>
<p>If the client certificate contains only one JID, then the client MAY include an authorization identity, but only if it desires to be authorized as a JID other than the address in the client certificate; else it MUST NOT include include an authorization identity (this is shown in the following example by setting the XML character data of the &lt;auth/&gt; element to "=").</p>
<p>If the client certificate contains only one JID, then the client MAY include an authorization identity, but only if it desires to be authorized as a JID other than the address in the client certificate; else it MUST NOT include an authorization identity (this is shown in the following example by setting the XML character data of the &lt;auth/&gt; element to "=").</p>
<code><![CDATA[
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='EXTERNAL'>=</auth>
@ -212,7 +212,7 @@
]]></code>
</li>
<li>
<p>If the client certificate does not contain a JID, then the client MAY include an authorization identity, but only if it desires to be authorized as a JID other than the address in the client certificate; else it MUST NOT include include an authorization identity (this is shown in the following example by setting the XML character data of the &lt;auth/&gt; element to "=").</p>
<p>If the client certificate does not contain a JID, then the client MAY include an authorization identity, but only if it desires to be authorized as a JID other than the address in the client certificate; else it MUST NOT include an authorization identity (this is shown in the following example by setting the XML character data of the &lt;auth/&gt; element to "=").</p>
<code><![CDATA[
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='EXTERNAL'>=</auth>
@ -265,7 +265,7 @@
</ol>
</li>
<li>
<p>If SASL authentication succeeded, the client opens new stream, then client and server proceed with resource binding as described in <cite>RFC 3920</cite> and <cite>RFC 6120</cite>.</p>
<p>If SASL authentication succeeded, the client opens a new stream, then client and server proceed with resource binding as described in <cite>RFC 6120</cite>.</p>
</li>
</ol>
</section1>
@ -366,9 +366,10 @@
<li>
<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[
<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>
<p>Interoperability Note: Previous versions of this specification relied on the authorization identity being present on the receiving server. Even though this is no longer required, the connecting server should include it for backward compability.</p>
<p>Interoperability Note: Previous versions of this specification stated that the receiving server always relied on the connecting server's inclusion of the authorization identity. Even though this is no longer required, the connecting server SHOULD include the authorization identity for backward compability.</p>
</li>
<li>
<p>Server2 determines if hostname is valid.</p>