moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00
Code Issues Releases Wiki Activity

1.1rc7

Browse Source
This commit is contained in:
stpeter 2011-05-11 09:14:05 -06:00
parent c73893d844
commit d951d1fb8d
1 changed files with 62 additions and 64 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

126
xep-0178.xml
View File

@ -24,8 +24,8 @@
&stpeter;
&pgmillard;
<revision>
<version>1.1rc6</version>
<date>in progress, last updated 2011-04-25</date>
<version>1.1rc7</version>
<date>in progress, last updated 2011-05-11</date>
<initials>psa</initials>
<remark><p>Updated text and examples to be consistent with RFC 6120 and RFC 6125.</p></remark>
</revision>
@ -112,18 +112,18 @@
<ol>
<li>
<p>Client initiates stream to server.</p>
<code><![CDATA[
<example><![CDATA[
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:client'
from='juliet@example.com'
to='example.com'
version='1.0'>
]]></code>
]]></example>
</li>
<li>
<p>Server replies with stream header.</p>
<code><![CDATA[
<example><![CDATA[
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:client'
@ -131,47 +131,47 @@
from='example.com'
to='juliet@example.com'
version='1.0'>
]]></code>
]]></example>
</li>
<li>
<p>Server advertises TLS stream feature, which might indicate that TLS is mandatory-to-negotiate.</p>
<code><![CDATA[
<example><![CDATA[
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
</stream:features>
]]></code>
]]></example>
</li>
<li>
<p>Client sends STARTTLS command to server.</p>
<code><![CDATA[
<example><![CDATA[
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
]]></code>
]]></example>
</li>
<li>
<p>Server informs client to proceed.</p>
<code><![CDATA[
<example><![CDATA[
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
]]></code>
]]></example>
</li>
<li>
<p>Server requests, and client presents, the client certificate during TLS negotiation.</p>
</li>
<li>
<p>Server and client successfully complete the TLS negotiation and client initiates a new initial stream header to server over the encrypted TCP connection.</p>
<code><![CDATA[
<example><![CDATA[
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:client'
from='juliet@example.com'
to='example.com'
version='1.0'>
]]></code>
]]></example>
</li>
<li>
<p>Server replies with response stream header.</p>
<code><![CDATA[
<example><![CDATA[
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:client'
@ -179,44 +179,43 @@
from='example.com'
to='juliet@example.com'
version='1.0'>
]]></code>
]]></example>
</li>
<li>
<p>Server advertises SASL mechanisms. Because the client presented a client certificate, here the server offers the SASL EXTERNAL mechanism (see Section 6.3.4 of <cite>RFC 6120</cite> for recommendations regarding the conditions under which to offer the SASL EXTERNAL mechanism).</p>
<code><![CDATA[
<example><![CDATA[
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>EXTERNAL<mechanism>
<mechanism>DIGEST-MD5<mechanism>
<mechanism>ANONYMOUS<mechanism>
<required/>
</mechanisms>
</stream:features>
]]></code>
]]></example>
</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>
<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 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[
<example><![CDATA[
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='EXTERNAL'>=</auth>
]]></code>
]]></example>
</li>
<li>
<p>If the client certificate contains more than one JID, then the client MUST include an authorization identity so that the server can determine which JID to use (this is shown in the following example by setting the XML character data of the &lt;auth/&gt; element to "anVsaWV0QGV4YW1wbGUuY29t", which is the base 64 encoding for "juliet@example.com").</p>
<code><![CDATA[
<example><![CDATA[
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='EXTERNAL'>anVsaWV0QGV4YW1wbGUuY29t</auth>
]]></code>
]]></example>
</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 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[
<example><![CDATA[
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='EXTERNAL'>=</auth>
]]></code>
]]></example>
</li>
</ol>
</li>
@ -225,42 +224,42 @@
<ol style='list-style-type:lower-alpha'>
<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>
<code><![CDATA[
<example><![CDATA[
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
]]></code>
]]></example>
</li>
<li>
<p>If the certificate contains more than one valid XMPP address that corresponds to a registered account on the server (e.g., because the server offers virtual hosting), then the server SHOULD allow authentication and authorization of the JID specified as the authorization identity in the SASL exchange.</p>
<code><![CDATA[
<p>If the certificate contains more than one valid XMPP address that corresponds to a registered account on the server (e.g., because the server offers virtual hosting) and during the SASL exchange the client specified an authorization identity that corresponds to one of the JIDs presented in the client certificate, then the server SHOULD allow authentication and authorization of the JID specified as the authorization identity.</p>
<example><![CDATA[
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
]]></code>
]]></example>
<p>If no authorization identity is included, then the server SHOULD return a SASL failure case of &lt;invalid-authzid/&gt; and close the stream.</p>
<code><![CDATA[
<example><![CDATA[
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<invalid-authzid/>
</failure>
</stream:stream>
]]></code>
]]></example>
</li>
<li>
<p>If the certificate does not contain an XMPP address, then the server MAY attempt to determine if there is a registered account associated with the user, for example by performing an LDAP lookup based on the Common Name or other information presented by the client in the certificate; if such a JID mapping is successful and the mapped JID matches the authorization identity provided, then the server SHOULD allow authentication and authorization of that mapped JID.</p>
<code><![CDATA[
<example><![CDATA[
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
]]></code>
<p>If JID mapping is unsuccessful, then the server MUST return a SASL failure condition of &lt;not-authorized/&gt; and close the stream.</p>
<code><![CDATA[
]]></example>
<p>If JID mapping is unsuccessful, then the server SHOULD return a SASL failure condition of &lt;not-authorized/&gt; and close the stream.</p>
<example><![CDATA[
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<not-authorized/>
</failure>
</stream:stream>
]]></code>
<p>If JID mapping is successful but the mapped JID does not match the authorization identity provided (if any), then the server MUST return a SASL failure condition of &lt;invalid-authzid/&gt; and close the stream.</p>
<code><![CDATA[
]]></example>
<p>If JID mapping is successful but the mapped JID does not match the authorization identity provided (if any), then the server SHOULD return a SASL failure condition of &lt;invalid-authzid/&gt; and close the stream.</p>
<example><![CDATA[
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<invalid-authzid/>
</failure>
</stream:stream>
]]></code>
]]></example>
</li>
</ol>
</li>
@ -275,18 +274,18 @@
<ol>
<li>
<p>Server1 initiates stream to server2.</p>
<code><![CDATA[
<example><![CDATA[
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
from='conference.example.org'
to='example.com'
version='1.0'>
]]></code>
]]></example>
</li>
<li>
<p>Server2 replies with stream header.</p>
<code><![CDATA[
<example><![CDATA[
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
@ -294,29 +293,29 @@
from='example.com'
to='conference.example.org'
version='1.0'>
]]></code>
]]></example>
</li>
<li>
<p>Server2 advertises TLS stream feature, which might indicate that TLS is mandatory-to-negotiate.</p>
<code><![CDATA[
<example><![CDATA[
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
</stream:features>
]]></code>
]]></example>
</li>
<li>
<p>Server1 sends STARTTLS command to Server2.</p>
<code><![CDATA[
<example><![CDATA[
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
]]></code>
]]></example>
</li>
<li>
<p>Server2 informs Server1 to proceed.</p>
<code><![CDATA[
<example><![CDATA[
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
]]></code>
]]></example>
</li>
<li>
<p>Server2 requests, and Server1 presents, Server1's certificate during TLS negotiation.</p>
@ -329,20 +328,20 @@
</li>
<li>
<p>Else Server2 completes successful TLS negotiation and Server1 sends a new initial stream header to Server2 over the encrypted TCP connection.</p>
<code><![CDATA[
<example><![CDATA[
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
from='conference.example.org'
to='example.com'
version='1.0'>
]]></code>
]]></example>
</li>
</ol>
</li>
<li>
<p>Server2 replies with stream header.</p>
<code><![CDATA[
<example><![CDATA[
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
@ -350,25 +349,24 @@
from='example.com'
to='conference.example.org'
version='1.0'>
]]></code>
]]></example>
</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 MAY either close Server1's TCP connection or continue with a &xep0220; negotiation.</p>
<code><![CDATA[
<example><![CDATA[
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>EXTERNAL<mechanism>
<required/>
</mechanisms>
</stream:features>
]]></code>
]]></example>
</li>
<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[
<example><![CDATA[
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='EXTERNAL'>=</auth>
]]></code>
]]></example>
<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>
@ -376,19 +374,19 @@
<ol style='list-style-type:lower-alpha'>
<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>
<code><![CDATA[
<example><![CDATA[
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
]]></code>
]]></example>
<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>
<p>Else Server2 MUST return a &notauthorized; stream error and close the stream.</p>
<code><![CDATA[
<p>Else Server2 SHOULD return a &notauthorized; stream error and close the stream.</p>
<example><![CDATA[
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<not-authorized/>
</failure>
</stream:stream>
]]></code>
]]></example>
</li>
</ol>
</li>