<remark><p>Allowed client to not include an authorization identity if the certificate contains no XMPP address (thus depending on the server to assign the identity).</p></remark>
<remark><p>Clarified distinction between authentication and authorization; corrected handling of authorization identities; corrected conditions under which SASL EXTERNAL mechanism is offered; specified recommended formats for client and server certificates.</p></remark>
<remark><p>Modified XMPP address encapsulation methods per revisions to RFC 3920; clarified conditions for certificates to be considered acceptable.</p></remark>
<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>
<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>Server and client successfully complete the TLS negotiation and client initiates a new initial stream header to server over the encrypted TCP connection.</p>
<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>
<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>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 <auth/> element to "=").</p>
<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 <auth/> element to "anVsaWV0QGV4YW1wbGUuY29t", which is the base 64 encoding for "juliet@example.com").</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 specified during SASL negotiation; else it MUST NOT include an authorization identity (this is shown in the following example by setting the XML character data of the <auth/> element to "=").</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>
<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>
<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>
<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 <invalid-authzid/> and close the stream.</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>
<p><cite>RFC 3920</cite> specified that if a JabberID is included in a certificate intended for use by an XMPP server (a "server certificate"), it shall be encapsulated as an xmppAddr. That recommendation is updated in <cite>RFC 6120</cite> through a reference to &rfc6125;, which prefers use of a dNSName and/or SRVName entry in the Subject Alternative Name. The DNS domain name contained in the certificate can be a fully-qualified domain name ("FQDN") or a so-called "wildcard" with the '*' character as the complete left-most label (see <cite>RFC 6125</cite> for complete details).</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>
<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>
<p>Server1 considers EXTERNAL to be its preferred SASL mechanism. For server-to-server authentication, the <auth/> 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>
<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>
<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>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>
<p>Else Server2 SHOULD return a ¬authorized; error and either close Server1's TCP connection or continue with a Server Dialback (XEP-0220) [8] negotiation.</p>
<p>This document introduces no security considerations or concerns above and beyond those discussed in <cite>RFC 6120</cite> and <cite>RFC 6125</cite>.</p>
<p>Peter Millard, co-author of the initial version of this specification, died on April 26, 2006. The remaining author appreciates his assistance in defining the best practices described herein.</p>
