Management and Use of Client Certificates for the Extensible Messaging and Presence Protocol (XMPP)Universitaet Bremen TZIdmeyer@tzi.deCiscopsaintan@cisco.com
Applications
Extensible Messaging and Presence ProtocolXMPPJabberSASLThis document defines methods for managing and using client certificates in the Extensible Messaging and Presence Protocol (XMPP). These methods, which make use of the EXTERNAL mechanism of the Simple Authentication and Security Layer (SASL) protocol, enable an XMPP client to log in to an XMPP server without providing a password.An XMPP client typically needs a user name and a password to log in to an XMPP server. Many clients provide a mechanism to store these credentials so that a human user can automatically log in without being prompted for the password. While this practice is very user friendly, it can be a security risk, especially for some devices. Mobile devices like a mobile phone or a laptop might get stolen, providing the thief with the required password. Mobile phones are particularly insecure: providing the password on the keypad for each login 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 allows the use of any Simple Authentication and Security Layer mechanism in the authentication of XMPP entities, including the SASL EXTERNAL mechanism. Therefore this document defines two methods that will enable password-free login for XMPP clients:How a client generates an X.509 certificate , manages the list of client certificates, and informs the server of its authorized certificates.How a client presents a certificate during the Transport Layer Security handshake and refers to it during SASL negotiation using the EXTERNAL mechanism.The overall process is as follows:Client logs in to server using standard password-based authentication methods (or a previously authorized certificate).Client generates or obtains a certificate.Client informs server of the certificate.On subsequent login attempts, client can use the authorized certificate.The client can also retrieve the list of authorized certificates, remove a certificate, or revoke a certificate.These use cases are explained in the following sections.Note: The following capitalized keywords are to be interpreted as described in : "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".On first login, the client has not yet authorized a certificate and therefore cannot use SASL EXTERNAL to authenticate. (There is a possible exception if the client already has a valid certificate issued by a certificate authority ("CA") that is recognized by the server, but we ignore that case here because it is relatively rare.) Therefore the client would authenticate using standard XMPP methods as described in . If the client will attempt to upload and authorize a certificate for subsequent login attempts, it MUST protect the client-to-server stream using channel encryption via Transport Layer Security as described in .In order to upload and authorize a certificate, the client needs to generate or obtain a certificate. Here we assume that the client generates a self-signed certificate since this is also a requirement of ; however, it is also possible for the client to obtain a CA-issued certificate. The client certificate MUST include a JID as described in section 15.2.1.2 of , where the JID will be represented as an XmppAddr. The JID can be either a bare JID of the form "user@domain.tld" or a full JID of the form "user@domain.tld/resource".After the client has logged in and generated a certificate, it shall upload the certificate to its XMPP server. This is done by sending an XMPP IQ stanza of type "set" containing an <upload/> element qualified by the 'urn:xmpp:saslcert:0' namespace; this element in turn MUST contain at least one <item/> element, which in turn MUST contain a <certificate/> child element and SHOULD contain a <name/> child element. The XML character of the <certificate/> element is the X.509 certificate in DER encoding, Base64-encoded as specified in Section 4 of for sending over the XML stream. The XML character data of the <name/> element is a human-readable name for the certificate (thus making it easier for a human user to manage the different certificates); the name does not have to be unique, since the certificate's fingerprint provides a truly unique identifier. A client can upload multiple certificates with each certificate defined in one individual <item/> element.If the server can process the certificate, it returns an empty IQ result.(Error cases will be described in a future version of this specification, although the normal XMPP stanza errors apply.)Once the server has accepted the certificate, a client can use that certificate to authenticate the user using SASL EXTERNAL on subsequent logins. Therefore the client MUST NOT store the password for subsequent login attempts.The client that uploads the certificate does not need to be the client that subsequently uses the certificate. For example, a user might use a full-featured client to upload a certificate for subsequent use by a "bot" (e.g., an automated service or a device such as a set-top box). The bot creates its certificate and private key, and the user uploads the certificate to the server with a different client. After that procedure the bot can log in to the server and even participate in secure end-to-end communication without ever knowing the user's password.An optional element <no-cert-management/> inside the <item/> 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.The RECOMMENDED protocol flow for client-to-server use of SASL EXTERNAL with end-user certificates is as follows:Client initiates stream to the server.
Server replies with stream header.
Server advertises TLS stream feature.
Client sends STARTTLS command to the server.
Server tells the client to proceed.
During TLS handshake, the server requests a certificate and the client presents its certificate.TLS negotiation completes successfully.Client initiates a new stream header to the server.
Server replies with stream header.
Server advertises SASL mechanisms. If the server expects that the client will be able to authenticate and authorize as the identity provided in the presented certificate, then the server SHOULD advertise the SASL EXTERNAL mechanism; otherwise, if presented certificate is unacceptable (e.g., because the certificate is expired, not yet valid, or revoked), the server MUST NOT offer the EXTERNAL mechanism.
Because the client presented a certificate, it SHOULD consider EXTERNAL to be its preferred SASL mechanism. If the client certificate includes only one XMPP address and the user wishes to authorize as the identity that has been authenticated by the TLS layer (i.e., the XMPP address that is contained in the client certificate), then the client SHOULD NOT include an authorization identity (i.e., the XML character data for the <auth/> element SHOULD be "=", indicating an empty response); if the client certificate contains more than one XMPP address or if the user wishes to authorize as another identity, then the client MUST include an authorization identity; if the client certificate contain no XMPP address, then the client SHOULD include an authorization identity (but MAY omit the authorization identity if it does not know its identity, instead having it assigned by the server).
Server determines whether to allow authentication and authorization of user.
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. For the purpose of client authentication and authorization with a server, a valid XMPP address is a JID encapsulated as a subjectAltName entity of type otherName with an ASN.1 Object Identifier of "id-on-xmppAddr" as specified in Section 15.2.1.3 of .
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.
If no authorization identity is included, then the server MUST return a SASL failure case of <invalid-authzid/> and close the stream.
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 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.
If JID mapping is unsuccessful, then the server MUST return a SASL failure case of <not-authorized/> and close the stream.
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 case of <invalid-authzid/> and close the stream.
If SASL authentication succeeded, the client opens a new stream, then the client and server proceed with resource binding as described in . If the XmppAddr in the certificate is a full JID then the server MUST force the client to use the defined 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 the specified resource name, it SHOULD be logged out by the server.A client can request the list of all certificates that are authorized to authenticate for its bare JID using SASL EXTERNAL. This is done by sending an XMPP IQ stanza of type "get" containing a <list/> element qualified by the 'urn:xmpp:saslcert:0' namespace.The server then returns the list of all known certificates, including the provided name. Each certificate is contained in a separate <item/> element and uniquely identified by the value of the 'id' attribute. In the following example the 'id' is the SHA1 value in hex of the certificate. The 'id' is used for the client to remove or revoke a certificate.A client needs to create a new certificate before its current one expires. After the new certificate is uploaded to the server, it might want to remove the old certificate to keep the list of certificates short (otherwise the list will grow indefinitely, making certificate handling more difficult for the user). The client removes a certificate by sending an XMPP IQ stanza of type "set" containing a <remove/> element that in turn contains an empty <item/> whose 'id' attribute uniquely identifies the certificate as retrieved from the server with the <list/> IQ stanza. Similar to the upload procedure a client can remove multiple certificates by adding more than one <item/> element.Once a certificate has been removed it can no longer be used for SASL EXTERNAL. A server MAY automatically remove expired certificates from the list.The user can revoke a certificate for a stolen or compromised device. The mechanism is similar to removing a certificate. The difference is that if a client is logged in with the compromised certificate using SASL EXTERNAL, the server SHOULD close the stream to that client thus forcing that client to log out. The client revokes a certificate by sending an XMPP IQ stanza of type "set" containing a <revoke/> element that in turn contains an empty <item/> whose 'id' attribute uniquely identified the certificate.This specification defines a method whereby a user can authorize self-signed certificates for login. In accordance with local security policies, a given XMPP deployment can refuse to support this feature, can allow only clients that have authenticated with CA-issued certificates to upload self-signed certificates, can accept self-signed certificates only for full JIDs, etc.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.The server MUST check if the JID in the subjectAltName of the certificate matches the bare JID of the user. A user MUST NOT be allowed to upload certificates for a different user. 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. If the client has logged in with the current password, the server MAY change the password without a form as specified in XEP-0077.If a client is allowed to change the password without knowing the current password, the additional security provided by this document is compromised.Extensible Messaging and Presence Protocol (XMPP): CoreThis document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements for the purpose of exchanging structured information in close to real time between any two or more network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions. This document also specifies the format for XMPP addresses, which are fully internationalizable. This document obsoletes RFC 3920.The Base16, Base32, and Base64 Data EncodingsThis document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS TRACK]Simple Authentication and Security Layer (SASL)<p>The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.</p><p> This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.</p><p> This document obsoletes RFC 2222. [STANDARDS TRACK]</p>Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS TRACK]ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication FrameworkIn-Band RegistrationXMPP Software FoundationExtensible Messaging and Presence Protocol (XMPP) End-to-End Encryption Using Transport Layer Security ("XTLS")TZI, Universitaet BremenCiscoThis document specifies "XTLS", a protocol for end-to-end encryption of Extensible Messaging and Presence Protocol (XMPP) traffic via an application-level usage of Transport Layer Security (TLS). XTLS treats the end-to-end exchange of XML stanzas as a virtual transport and uses TLS to secure that transport, thus enabling XMPP entities to communicate in a way that is designed to prevent eavesdropping, tampering, and forgery of XML stanzas. The protocol can be used for secure end-to-end messaging as well as any others application such as file transfer.The following schema is not normative.Regarding this entire document or any portion of it, the authors make no guarantees and are not responsible for any damage resulting from its use. The authors grant irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information. Derivative works need not be licensed under similar terms.