XEP-0257: Client Certificate Management for SASL EXTERNAL

Abstract:This specification defines a method to manage client certificates that can be used with SASL External to allow clients to log in without a password.
Author:Dirk Meyer
Copyright:© 1999 - 2010 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:Deferred
Type:Standards Track
Version:0.2
Last Updated:2009-02-12

WARNING: Consideration of this document has been Deferred by the XMPP Standards Foundation. Implementation of the protocol described herein is not recommended.

Table of Contents


1. Introduction
2. Certificate Management
    2.1. Add X.509 Certificate
    2.2. Request a list of all Certificates
    2.3. Disable a Certificate
    2.4. Revoke a Certificate
3. SASL EXTERNAL
4. Security Considerations
    4.1. Stream Characteristics
    4.2. Changing the Password
5. IANA Considerations
6. XMPP Registrar Considerations
    6.1. Protocol Namespaces
    6.2. Protocol Versioning
7. XML Schema

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

1. Introduction

An XMPP client typically needs a user name and a password to log into an account. Many clients provide a mechanism to store these credentials to automatically log in into an account. While this practice is very user friendly, it is a security risk for some devices. Mobile devices like a phone or a laptop may get stolen, providing the thief with the required password. Mobile phones are particularly insecure: providing the password on the keypad for each log in is too complicated and the risk of losing the phone is high.

A solution to this problem is to allow a client to log in without knowing the password. XMPP as specified in RFC 3920 [1] and provisionally clarified in rfc3920bis [2] allows the use of any SASL mechanism (see RFC 4422 [3]) in the authentication of XMPP entities, including the SASL EXTERNAL mechanism. Best Practices for Use of SASL EXTERNAL [4] defines the usage of X.509 certificates used in the TLS handshake.

XEP-0178 assumes that the certificates used for SASL EXTERNAL are signed by a trusted CA. This could be a problem for the average user: signing a certificate is both an expensive and a complicated procedure. If the device gets stolen, the user also needs to provide the required information to the CA to revoke the certificate, and the server needs to keep its list of revoked certificates up-to-date. The end-to-end security mechanism described in C2C Authentication Using TLS [5] relies on self-signed certificates (although CA-issued certificates are allowed). A client capable of secure end-to-end communicate already has a self-signed X.509 certificate for that purpose. The same client certificate should be used for a client to log in. Since the certificates are not signed by a trusted CA, the server must be aware of the list of certificates that are used by the users' clients. This document describes how to manage the list of client certificates.

2. Certificate Management

From the user's point of view the initial client configuration is the same. The user needs to provide the user name and the password for the client to connect to the XMPP server. The main difference is that the client MUST NOT store the password for later use and MUST create an X.509 certificate for future logins. It does not matter if the certificate is self-signed or issued by a trusted third party.

2.1 Add X.509 Certificate

After the client has logged in and created the certificate, it uploads the certificate to the server. The XML representation of the certificate from Public Key Publishing [6] is used to describe a certificate. The client also SHOULD provide a name for the certificate to make it possible for the user to manage the different client certificates.

Example 1. Client Uploads an X.509 Certificate

<iq type='set'
    from='hamlet@shakespeare.lit/denmark'
    id='append'>
  <append xmlns='urn:xmpp:saslcert:0'>
    <name>Mobile Client</name>
    <keyinfo xmlns='urn:xmpp:tmp:pubkey'>
      <name>428b1358a286430f628da23fb33ddaf6e474f5c5</name>
      <x509cert>
        MIICCTCCAXKgAwIBAgIJALhU0Id6xxwQMA0GCSqGSIb3DQEBBQUAMA4xDDAKBgNV
        BAMTA2ZvbzAeFw0wNzEyMjgyMDA1MTRaFw0wODEyMjcyMDA1MTRaMA4xDDAKBgNV
        BAMTA2ZvbzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0DPcfeJzKWLGE22p
        RMINLKr+CxqozF14DqkXkLUwGzTqYRi49yK6aebZ9ssFspTTjqa2uNpw1U32748t
        qU6bpACWHbcC+eZ/hm5KymXBhL3Vjfb/dW0xrtxjI9JRFgrgWAyxndlNZUpN2s3D
        hKDfVgpPSx/Zp8d/ubbARxqZZZkCAwEAAaNvMG0wHQYDVR0OBBYEFJWwFqmSRGcx
        YXmQfdF+XBWkeML4MD4GA1UdIwQ3MDWAFJWwFqmSRGcxYXmQfdF+XBWkeML4oRKk
        EDAOMQwwCgYDVQQDEwNmb2+CCQC4VNCHesccEDAMBgNVHRMEBTADAQH/MA0GCSqG
        SIb3DQEBBQUAA4GBAIhlUeGZ0d0msNVxYWAXg2lRsJt9INHJQTCJMmoUeTtaRjyp
        ffJtuopguNNBDn+MjrEp2/+zLNMahDYLXaTVmBf6zvY0hzB9Ih0kNTh23Fb5j+yK
        QChPXQUo0EGCaODWhfhKRNdseUozfNWOz9iTgMGw8eYNLllQRL//iAOfOr/8
      </x509cert>
    </keyinfo>
  </append>
</iq>

The server either returns an empty result or an error. From now on the client can use that certificate to authenticate the user using SASL EXTERNAL.

The client adding the certificate does not need to be the client using it. A user may use a client to upload a certificate for a bot. The bot creates its certificate and private key, and the user uploads the certificate to the server (and may also sign the certificate outside the X.509 infrastructure to be used in Public Key Publishing [7]). After that procedure the bot can log in to the XMPP network and even participate in secure end-to-end communication without ever knowing the user's password.

An optional element <no-cert-management/> inside the keyinfo element indicates that a client logged in with that certificate is not allowed to add or remove certificates from the list. A server MAY allow such a client to query the list of certificates.

Example 2. X.509 Certificate Upload (no-cert-management)

<iq type='set'
    from='hamlet@shakespeare.lit/denmark'
    id='nocert'>
  <append xmlns='urn:xmpp:saslcert:0'>
    <name>Simple Bot</name>
    <keyinfo xmlns='urn:xmpp:tmp:pubkey'>
      <name>89d099a3428481cc63fe3fa44e7df2d002b4ce44</name>
      <no-cert-management xmlns='urn:xmpp:saslcert:0'/>
      <x509cert>
          ...
      </x509cert>
    </keyinfo>
  </append>
</iq>

2.2 Request a list of all Certificates

A user may want to get a list of all certificates that can be used for SASL EXTERNAL. The client can query the list of the items by sending an items iq stanza.

Example 3. Client requests List of X.509 Certificates

<iq type='get'
    from='hamlet@shakespeare.lit/denmark'
    id='query'>
  <items xmlns='urn:xmpp:saslcert:0'/>
</iq>

The server then returns the list of all known certificates including the user provided name.

Example 4. Server sends List of known X.509 Certificates

<iq type='result'
    to='hamlet@shakespeare.lit/denmark'
    id='query'>
  <items xmlns='urn:xmpp:saslcert:0'>
    <item id='428b1358a286430f628da23fb33ddaf6e474f5c5'>
      <name>Mobile Client</name>
      <keyinfo xmlns='urn:xmpp:tmp:pubkey'>
        <name>428b1358a286430f628da23fb33ddaf6e474f5c5</name>
        <x509cert>
	...
        </x509cert>
      </keyinfo>
    </item>
    <item id='571b23d99892f4566017426e92c377288ed6c983'>
      <name>Laptop</name>
      <keyinfo xmlns='urn:xmpp:tmp:pubkey'>
        <name>571b23d99892f4566017426e92c377288ed6c983</name>
        <x509cert>
	...
        </x509cert>
      </keyinfo>
    </item>
  </items>
</iq>

2.3 Disable a Certificate

A client has to create a new certification before its current one expires. After the new certificate is added to the server, it MAY want to disable the old certificate to keep the list of certificates short. Without that, the list will grow indefinitely, making the certificate handling for the user more difficult. Once a certificate is removed it can no longer be used for SASL EXTERNAL. A server MAY automatically remove expired certificates for this list.

Example 5. Client disables an X.509 Certificate

<iq type='set'
    from='hamlet@shakespeare.lit/denmark'
    id='disable'>
  <disable xmlns='urn:xmpp:saslcert:0'/>
    <item id='428b1358a286430f628da23fb33ddaf6e474f5c5'/>
  </disable>
</iq>

2.4 Revoke a Certificate

The user may want to revoke a certificate from a stolen or compromised device. The mechanism is similar to disabling a certificate. The difference is that if a client is logged in with that compromised certificate using SASL EXTERNAL, the server SHOULD close the stream to that client forcing a log out of the client.

Example 6. Client revokes an X.509 Certificate

<iq type='set'
    from='hamlet@shakespeare.lit/denmark'
    id='revoke'>
  <revoke xmlns='urn:xmpp:saslcert:0'/>
    <item id='428b1358a286430f628da23fb33ddaf6e474f5c5'/>
  </revoke>
</iq>

3. SASL EXTERNAL

The protocol flow is similar to the one described in XEP-0178. Only step 9 is different: the certificate does not need to be signed by a trusted entity if the certificate was uploaded by the user. The server still MUST reject the certificate if it is expired. In a company environment the server MAY only accept signed certificates; the behavior depends on the company's security policy. A free public XMPP server MUST allow self-signed certificates and certificates signed by a CA unknown to the server.

The client certificate SHOULD include a JID as defined in sections 15.2.1.2. and 15.2.1.3. in rfc3920bis: a JID MUST be represented as an XmppAddr, i.e., as a UTF8String within an otherName entity inside the subjectAltName.

Example 7. subjectAltName using the "id-on-xmppAddr" format

    subjectAltName=otherName:id-on-xmppAddr;UTF8:hamlet@shakespeare.lit

If the subjectAltName contains a full JID the server MUST force the client to use the given resource during resource binding. The client is only allowed to use the provided resource name. If a client with the same resource name is currently logged in and that client is not forced to use that resource name, it SHOULD be logged out by the server.

4. Security Considerations

4.1 Stream Characteristics

This specification allows the user to manipulate an alternative way to log into the server. The certificates are not required to be signed and any certificate can be used. Therefore the server MUST reject any communication described in this document if the link between client and server is not secured with both STARTTLS and SASL to prevent a man-in-the-middle to modify the certificate.

4.2 Changing the Password

In-Band Registration [8] defines a mechanism to change the password without knowing the current one. If the server supports password change it MUST return not-authorized for clients logged in using SASL EXTERNAL and MAY include a password change form requiring the old password.

Example 8. Password Change

  <iq type='set' to='shakespeare.lit' id='change1'>
    <query xmlns='jabber:iq:register'>
      <username>hamlet</username>
      <password>newpass</password>
    </query>
  </iq>

If the sending client has logged in using SASL EXTERNAL and the server supports XEP-0077 password changes it returns a form to change the password. If the client has logged in with the current password, the server MAY change the password without a form as specified in XEP-0077.

Example 9. Server Returns Password Change Form With Error

<iq type='error' from='shakespeare.lit' to='hamlet@shakespeare.lit/denmark' id='change1'>
  <query xmlns='jabber:iq:register'>
    <x xmlns='jabber:x:data' type='form'>
      <title>Password Change</title>
      <instructions>Use this form to change your password.</instructions>
      <field type='hidden' var='FORM_TYPE'>
        <value>jabber:iq:register:changepassword</value>
      </field>
      <field type='text-single' label='Username' var='username'>
        <required/>
      </field>
      <field type='text-private' label='Old Password' var='old_password'>
        <required/>
      </field>
      <field type='text-private' label='New Password' var='password'>
        <required/>
      </field>
    </x>
  </query>
  <error code='405' type='cancel'>
    <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

If a client is allowed to change the password without knowing the current password, the additional security provided by this document is compromised

5. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [9].

6. XMPP Registrar Considerations

6.1 Protocol Namespaces

This specification defines the following XML namespace:

Upon advancement of this specification from a status of Experimental to a status of Draft, the XMPP Registrar [10] shall add the foregoing namespace to the registry located at <http://xmpp.org/registrar/namespaces.html>, as described in Section 4 of XMPP Registrar Function [11].

6.2 Protocol Versioning

If the protocol defined in this specification undergoes a revision that is not fully backwards-compatible with an older version, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

7. XML Schema

The XML schema will be provided in a later version of this document.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0257
Publisher: XMPP Standards Foundation
Status: Deferred
Type: Standards Track
Version: 0.2
Last Updated: 2009-02-12
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0178, XEP-0189
Supersedes: None
Superseded By: None
Short Name: NOT YET ASSIGNED
Source Control: HTML  RSS

Appendix B: Author Information

Dirk Meyer

Email: dmeyer@tzi.de
JabberID: dmeyer@jabber.org

Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright © 1999 - 2010 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <http://xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XMPP Standards Foundation, c/o Peter Saint-Andre, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

1. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.

2. rfc3920bis: proposed revisions to Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-ietf-xmpp-3920bis>. (work in progress)

3. RFC 4422: Simple Authentication and Security Layer (SASL) <http://tools.ietf.org/html/rfc4422>.

4. XEP-0178: Best Practices for Use of SASL EXTERNAL <http://xmpp.org/extensions/xep-0178.html>.

5. XEP-0250: C2C Authentication Using TLS <http://xmpp.org/extensions/xep-0250.html>.

6. XEP-0189: Public Key Publishing <http://xmpp.org/extensions/xep-0189.html>.

7. XEP-0189: Public Key Publishing <http://xmpp.org/extensions/xep-0189.html>.

8. XEP-0077: In-Band Registration <http://xmpp.org/extensions/xep-0077.html>.

9. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

10. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://xmpp.org/registrar/>.

11. XEP-0053: XMPP Registrar Function <http://xmpp.org/extensions/xep-0053.html>.

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 0.2 (2009-02-12)

(dm)

Version 0.1 (2009-01-05)

Initial published version.

(psa)

Version 0.0.2 (2008-11-28)

Add Security Considerations, improve reference to XEP-0178.

(dm)

Version 0.0.1 (2008-11-18)

First draft.

(dm)

END