moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

1.4rc4

Browse Source
This commit is contained in:
stpeter 2011-04-14 15:27:34 -06:00
parent 159f27cea9
commit 3c85b4a96e
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
xep-0178.xml
View File

@ -24,8 +24,8 @@
&stpeter; &stpeter;
&pgmillard; &pgmillard;
<revision> <revision>
<version>1.1rc3</version> <version>1.1rc4</version>
<date>in progress, last updated 2011-04-12</date> <date>in progress, last updated 2011-04-14</date>
<initials>psa</initials> <initials>psa</initials>
<remark><p>Updated to reflect RFC 6120 and RFC 6125.</p></remark> <remark><p>Updated to reflect RFC 6120 and RFC 6125.</p></remark>
</revision> </revision>
@ -196,7 +196,7 @@
</li> </li>
<li> <li>
<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> <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> <ol style='list-style-type:lower-alpha'>
<li> <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 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[ <code><![CDATA[
@ -222,7 +222,7 @@
</li> </li>
<li> <li>
<p>Server determines whether to allow authentication and authorization of user.</p> <p>Server determines whether to allow authentication and authorization of user.</p>
<ol> <ol style='list-style-type:lower-alpha'>
<li> <li>
<p>If (1) the certificate presented by the client contains only one valid XMPP address that corresponds to a registered account on the server and (2) the client did not pass an authorization identity in the SASL exchange, then the server SHOULD allow authentication and authorization of that JID.</p> <p>If (1) the certificate presented by the client contains only one valid XMPP address that corresponds to a registered account on the server and (2) the client did not pass an authorization identity in the SASL exchange, then the server SHOULD allow authentication and authorization of that JID.</p>
<code><![CDATA[ <code><![CDATA[
@ -323,7 +323,7 @@
</li> </li>
<li> <li>
<p>Server2 validates certificate in accordance with the rules from <cite>RFC 6120</cite> and <cite>RFC 6125</cite>.</p> <p>Server2 validates certificate in accordance with the rules from <cite>RFC 6120</cite> and <cite>RFC 6125</cite>.</p>
<ol> <ol style='list-style-type:lower-alpha'>
<li> <li>
<p>If certificate is unacceptable for the reasons explained in <cite>RFC 6120</cite> and <cite>RFC 6125</cite>, Server2 closes Server1's TCP connection.</p> <p>If certificate is unacceptable for the reasons explained in <cite>RFC 6120</cite> and <cite>RFC 6125</cite>, Server2 closes Server1's TCP connection.</p>
</li> </li>
@ -364,24 +364,24 @@
]]></code> ]]></code>
</li> </li>
<li> <li>
<p>Server1 considers EXTERNAL to be its preferred SASL mechanism. Here it includes a base-64-encoded authorization identity as the XML character data of the &lt;auth/&gt; element, setting it to the same value as the 'from' address on the stream header it sent to Server2.</p> <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>
<code><![CDATA[ <code><![CDATA[
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='EXTERNAL'>Y29uZmVyZW5jZS5leGFtcGxlLm9yZwo=</auth> <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='EXTERNAL'>=</auth>
]]></code> ]]></code>
<p>(In this case, the authorization identity is "conference.example.org".)</p>
<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 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>
</li> </li>
<li> <li>
<p>Server2 determines if hostname is valid.</p> <p>Server2 determines if hostname is valid.</p>
<ol> <ol style='list-style-type:lower-alpha'>
<li> <li>
<p>If the 'from' attribute of 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 returns success.</p> <p>If the 'from' attribute of 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 returns success.</p>
<code><![CDATA[ <code><![CDATA[
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
]]></code> ]]></code>
<p>Implementation Note: If Server2 needs to assign an authorization identity during SASL negotiation, it SHOULD use the value of the 'from' attribute of the stream header sent by Server1.</p>
</li> </li>
<li> <li>
<p>Else server MUST return a &notauthorized; stream error and close the stream.</p> <p>Else Server2 MUST return a &notauthorized; stream error and close the stream.</p>
<code><![CDATA[ <code><![CDATA[
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<not-authorized/> <not-authorized/>