For secure client-to-client (C2C) communication the clients can use Link-Local Messaging (XEP-0174) [1] or Jingle XML Streams (XEP-0247) [2] to open a connection between the two clients. To open an XMPP connection End-to-End XML Streams (XEP-0246) [3] defines a stream setup similar to the setup used by client-server communications. To secure the communication the extension defines the use of Transport Layer Security as defined in RFC 5246 [4] for encryption and authentication. XEP-0246 suggest to use the OpenPGP TLS extension but does not specify how to negotiate if both peers support the extension and if they are able to verify the OpenPGP key. It makes no sense to use OpenPGP instead of X.509 certificates if there is also no trust on OpenPGP level. This document describes how to negotiate how to use TLS to exchange possible extensions and key fingerprints before the actual TLS handshake.
After the TLS handshake both communication partners MUST be sure that they are communicating with the correct person without a man-in-the-middle.
A client requires support for X.509 certificates or one or more TLS extension that can be used to verify the end-to-end character of the stream. The following list defines authentication mechanisms a client MAY support. The list depends on TLS extensions defined by the Transport Layer Security working group of the IETF. A future version of the document may include additional extension like Short Authentication String (SAS) or Kerberos. A client MUST ignore XML stanzas defining an authentication method it does not understand.
The classic usage of TLS is done with X.509 certificates. The certificate is the end of a certificate chain. A certificate should be either signed by another certificate from a third party or a well known certification authority installed on the client machine. In an enterprise scenario all client would be signed by a certificate from the company making it possible for all clients to verify the identity of the other.
Getting a signed certificate is a complex and expensive task unsuitable for normal users. It also raises the question why a client should trust a CA its user does not know. Instead they create a self-signed certificate. The certificate is signed by itself and can not be verified through a certificate chain. To use these certificates in a real scenario the user must know the fingerprint of the peer certificate to verify it. But comparing fingerprints is not very userfriendly and the user may not have the fingerprint before starting the communication.
Instead of relying on a certificate chain the users may rely on a web-of-trust as defined by RFC 4880 [5]. The TLS extension "OpenPGP Keys for Transport Layer Security" (RFC 5081 [6]) describes how to use OpenPGP keys in the TLS handshake. If users share a trusted friend who has signed both their keys they can open a secure connection based on that trust. If there is no trust relationship between the two peers, OpenPGP is as useless as self-signed certificates. The users can verify the fingerprint and communicate that fingerprint over a different medium (e.g. a real-life meeting), but the same problem that occurs with X.509 certificates exists: comparing fingerprints is far away from being userfriendly.
A third way to verify the identify of the peer is a shared secret. This secret could be exchanged on a personal meeting or could be described as riddle only the other person can answer before opening the c2c link. It is up to the user and a good user interface to make the secret exchange as painless as possible.
This document uses the Secure Remote Password (SRP) extension from RFC 5054 [7] when dealing with shared secrets and not the Pre-Shared Key Ciphersuites as defined in RFC4279. SRP allows the users to choose a much smaller password and it still verifies both clients to the other. The password (shared secret) is required by both to calculate the premaster secret which means both will notice if the peer is not who it should be. SRP requires a user name; since it is transmitted in plain text between client and server it has no value in this context. Both clients must use the same username for the calculations. For the TLS handshake using SRP both clients MUST use the bare JID of the initiator as username.
The main problem is what TLS extension to choose. It makes no sense to use OpenPGP if the clients have no trust-relationship or SRP if the users did not exchange a secret. To resolve this problem a client describes its extension in an offer to the peer. The offer lists all supported authentication methods including additional parameter like the certificate that will be used. Public Key Publishing (XEP-0189) [8] can be used to look-up the keys or the client can look in its OpenPGP keyring. A client could also know a certificate or password from an earlier connection. The following example contains the X.509 certificate and the OpenPGP key from the examples in XEP-0189.
<offer xmlns='urn:xmpp:tmp:c2ctls'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>428b1358a286430f628da23fb33ddaf6e474f5c5</name>
</keyinfo>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>89d099a3428481cc63fe3fa44e7df2d002b4ce44</name>
</keyinfo>
<srp/>
</offer>
Note: the keyinfo only contains the name and not the public key itself. If the peer does not know the key, it can not determine if it is an X.509 certificate or OpenPGP key. This does not matter because if the client does not know the key, it can not use it for secure communication.
If both clients know the offer of the other, they can determine what method to use to complete the TLS handshake without an error. Note: this information will be exchanged over an insecure communication channel and may be forged. If the information is altered it will be detected when doing the TLS handshake.
I client MAY want to know the supported extensions of the peer before opening the client-to-client stream. For serverless messaging this is not possible but for server based communication a client can exchange offers with the peer without using Jingle to open a client-to-client stream. The methods the peer supports depend on additional information from the client. Depending on the X.509 certificate of the client the peer may not support this extension because it can not verify the certificate. To receive the offer from the peer the client sends an IQ stanza with its own offer.
<iq type='get'
from='romeo@montague.net/b345687ba7607d3ddf401a0257464843a0a1c0b7'
to='juliet@capulet.com/da39a3ee5e6b4b0d3255bfef95601890afd80709'
id='info'>
<offer xmlns='urn:xmpp:tmp:c2ctls'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>RomeoX509CertificateHash</name>
</keyinfo>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>RomeoOpenPGPFingerprint</name>
</keyinfo>
<srp/>
</offer>
</iq>
The receiver sends its offer back to the client. It MUST only send the keyinfo elements that match a keyinfo of the offer. E.g. if the responder does not find an X.509 certificate it can verify in the offer it MUST NOT send its own X.509 certificate. In the following example the receiver supports SRP and X.509. OpenPGP is either not supported or skipped because the key can not be verified.
<iq type='result'
from='juliet@capulet.com/da39a3ee5e6b4b0d3255bfef95601890afd80709'
to='romeo@montague.net/b345687ba7607d3ddf401a0257464843a0a1c0b7'
id='info'>
<offer xmlns='urn:xmpp:tmp:c2ctls'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>JulietX509CertificateHash</name>
</keyinfo>
<srp/>
</offer>
</iq>
A client MAY support X.509 certificates it can not verify to be verified later. In that case it adds the authentication method <insecure>. In the following example the receiver supports SRP and X.509, but can not verify the certificate from the offer.
<iq type='result'
from='juliet@capulet.com/da39a3ee5e6b4b0d3255bfef95601890afd80709'
to='romeo@montague.net/b345687ba7607d3ddf401a0257464843a0a1c0b7'
id='info'>
<offer xmlns='urn:xmpp:tmp:c2ctls'>
<insecure/>
<srp/>
</offer>
</iq>
The offer information described above will be embedded into the XML based part of the STARTTLS handshake described in the XMPP core.
The recipient in the role of the XMPP server is the first one active in the XMPP TLS handshake. It offers the STARTTLS feature to the client. Instead of just offering the feature, it also SHOULD describe what TLS extensions it supports and what keys to expect. In the following example the recipient supports all possible identification mechanisms describe before.
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
<offer xmlns='urn:xmpp:tmp:c2ctls'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>RecipientX509CertificateHash</name>
</keyinfo>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>RecipientOpenPGPFingerprint</name>
</keyinfo>
<srp/>
</offer>
</starttls>
</stream:features>
If the recipient does not supply this additional information it is assumed that it does not support this extension and the TLS handshake continues as described in the XMPP core. If and how the users trust each other in that case is out of the scope of this document.
When the initiator starts the TLS feature it also enhances the STARTTLS with its supported extensions and additional key information based on the recipient's offer. In the following example the initiator can only verify one keyinfo. It also supports SRP.
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<offer xmlns='urn:xmpp:tmp:c2ctls'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>InitiatorX509CertificateHash</name>
</keyinfo>
<srp/>
</offer>
</starttls>
Similar to the feature announcement, if the initiator does not add an offer the recipient MUST assume the initiator does not support this XMPP extension and continue normal TLS handshake and hope it will work.
The next step for an recipient is to send an proceed message so the initiator can start with the TLS handshake. At this point the recipient knows what certificates or OpenPGP keys to expect from the peer and what the peer supports. The method that the initiator SHOULD use is added to the proceed.
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<offer xmlns='urn:xmpp:tmp:c2ctls'>
<srp/>
</offer>
</proceed>
The initiator now starts the TLS handshake.
If only SRP is possible the client should ask the user if they exchanged a shared secret. If this is not the case no suitable methods are left and the recipient MUST sends a failure and close the stream.
<failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> </stream:stream>
After the c2c connection is secure the clients MAY use this secure and trusted connection to update their information on each other. Using XEP-0189 "Requesting Public Keys Directly From Another Entity" or "Sending Public Keys Directly To Another Entity" they can bootstrap a different mechanisms for the next time. A SRP-based connection can bootstrap the trust of a self-signed certificate which will used the next time these two clients connect to each other. It can also be used to automatically sign an OpenPGP key with a minimum level of trust.
Usability Considerations will be provided in a future version of this document.
It is RECOMMENDED to always create a self-signed X.509 certificate for a client. It is of less value than an OpenPGP key also used by other applications and connected to a web-of-trust. It MAY also be stored on the users PC unencrypted like the XMPP password. This makes it possible to open secure communications without entering the OpenPGP password or the shared secret. Of cause, storing the X.509 certificate in plain text reduces the security. It all depends on how much the user trusts the PC.
Additional security considerations will be provided in a later version of this document.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [9].
XMPP Registrar considerations will be provided in a later version of this document.
The author would like to thank Eric Rescorla for suggesting TLS-SRP and others on the xmpp-security mailing list for the discussion.
The XML schema will be provided in a later version of this document.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).
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.
## 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. ##
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.
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 <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) 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.
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>.
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".
1. XEP-0174: Link-Local Messaging <https://xmpp.org/extensions/xep-0174.html>.
2. XEP-0247: Jingle XML Streams <https://xmpp.org/extensions/xep-0247.html>.
3. XEP-0246: End-to-End XML Streams <https://xmpp.org/extensions/xep-0246.html>.
4. RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 <http://tools.ietf.org/html/rfc5246>.
5. RFC 4880: OpenPGP Message Format <http://tools.ietf.org/html/rfc4880>.
6. RFC 5081: Using OpenPGP Keys for Transport Layer Security (TLS) Authentication <http://tools.ietf.org/html/rfc5081>.
7. RFC 5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication <http://tools.ietf.org/html/rfc5054>.
8. XEP-0189: Public Key Publishing <https://xmpp.org/extensions/xep-0189.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/>.
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
Use keyinfo from version 0.8 of XEP-0189.
Initial published version.
First draft.
END