<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>
<p>XMPP as specified in &rfc3920; and provisionally clarified in &rfc3920bis; 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>As specified in <cite>RFC 3920</cite> and provisionally clarified in <cite>rfc3920bis</cite>, during the stream negotiation process an XMPP client can present a certificate (here called an "end-user certificate"). If a JabberID is included in an end-user 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 5.1.1. of <cite>RFC 3920</cite> and Section 13.7.1.4 of <cite>rfc3920bis</cite>.</p>
<p>There are three possible cases:</p>
<ol>
<li>The certificate includes one xmppAddr.</li>
<li>The certificate includes more than one xmppAddr.</li>
<li>The certificate includes no xmppAddr.</li>
</ol>
<p>This specification includes recommendations that address all three cases.</p>
<p>Server advertises SASL mechanisms. Here the server offers and prefers the SASL EXTERNAL mechanism (see Section 6.2.4 of <cite>rfc3920bis</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. Here the client does not include an authorization identity and therefore sets the XML character data of the <auth/> element to "=", indicating an empty response (see Section 6.2.8 of <cite>rfc3920bis</cite> for recommendations regarding the conditions under which to include an authorization identity).</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), then the server SHOULD allow authentication and authorization of the JID specified as the authorization identity in the SASL exchange.</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 MUST return a SASL failure condition of <invalid-authzid/> and close the stream.</p>
<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>rfc3920bis</cite>.</p>
<p><cite>RFC 3920</cite> specified that if a JabberID is included in a certificate intended for use by an XMPP server (here called a "domain certificate"), it shall be encapsulated as an xmppAddr. That recommendation is udpated in <cite>rfc3920bis</cite> through a reference to &certid;, 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.</p>
<p>If certificate is unacceptable for the reasons explained in <cite>rfc3920bis</cite> and <cite>draft-saintandre-tls-server-id-check</cite>, Server2 closes Server1's TCP connection.</p>
<p>Server2 advertises SASL mechanisms. If Server2 expects that Server1 will be able to authenticate and authorize as the identity provided in the certificate that Server1 already provided, then Server2 SHOULD advertise the SASL EXTERNAL mechanism.</p>
<p>Server2 considers EXTERNAL to be its preferred SASL mechanism. Here it includes a base-64-encoded authorization identity as the XML character data of the <auth/> element, setting it to the same value as the 'from' address on the stream header it sent to Server2.</p>
<p>If the authorization identity provided by Server1 can be matched against one of the identifiers provided in the certificate following the matching rules from <cite>draft-saintandre-tls-server-id-check</cite>, Server2 returns success.</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>
