XEP-0031: A Framework For Securing Jabber Conversations

Abstract: Although the value and utility of contemporary instant messaging systems, like Jabber, are now indisputable, current security features to protect message data are generally inadequate for many deployments; this is particularly true in security conscious environments like large, commercial enterprises and government agencies. These current features suffer from issues of scalability, usability, and supported features. Furthermore, there is a lack of standardization. We present a protocol to allow communities of Jabber users to apply cryptographic protection to selected conversation data.
Author: Paul Lloyd
Copyright:© 1999 - 2014 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:Deferred
Type:Standards Track
Version:0.2
Last Updated:2002-07-09

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. Requirements And Considerations
    2.1. Security Requirements
       2.1.1. Data Protection Requirements
       2.1.2. Data Classification Requirements
       2.1.3. The End To End Requirement
       2.1.4. Trust Issues
       2.1.5. Cryptosystem Design Considerations
    2.2. Environmental Considerations
    2.3. Usability Requirements
    2.4. Development And Deployment Requirements
3. Protocol Specification
    3.1. Protocol Overview
    3.2. Definitions And Notation
    3.3. XML Processing
       3.3.1. Transporting Binary Content
       3.3.2. Transporting Encrypted Content
       3.3.3. HMAC Computation
       3.3.4. Performing Cryptographic Operations
    3.4. XML Namespaces
    3.5. Security Sessions
       3.5.1. Overview
       3.5.2. Security Session Negotiation
       3.5.3. DTDs
       3.5.4. Generating And Sending the session1 PDU
       3.5.5. Receiving And Processing the session1 PDU
       3.5.6. Generating And Sending the session2 PDU
       3.5.7. Receiving And Processing the session2 PDU
       3.5.8. Generating And Sending the session3 PDU
       3.5.9. Receiving And Processing the session3 PDU
       3.5.10. Session Key Material Derivation
    3.6. Key Transport
       3.6.1. Overview
       3.6.2. The Key Transport Mechanism
       3.6.3. DTDs
       3.6.4. Generating And Sending the keyTransport PDU
       3.6.5. Receiving and Processing the keyTransport PDU
    3.7. Message Protection
       3.7.1. Overview
       3.7.2. The Message Protection Mechanism
       3.7.3. DTD
       3.7.4. Generating And Sending the protectedMessage PDU
       3.7.5. Receiving and Processing the protectedMessage PDU
    3.8. Requesting Keys
    3.9. Conformance Profile
4. Diffie-Hellman Groups
    4.1. 1024 bit Group, modp1024
    4.2. 2048 bit Group, modp2048
    4.3. 4096 bit Group, modp4096
    4.4. 8192 bit Group, modp8192
5. Security Considerations
6. Examples
    6.1. Security Session
    6.2. Key Transport
    6.3. Message Protection
7. References

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

Instant messaging has clearly crossed the chasm from experimental to mainstream in a short amount of time. It is particularly interesting to note the extent to which the employees and affiliates of large enterprises have adopted instant messaging as part of their daily professional lives. IM is no longer simply used on Friday evening to select which movie to watch; it's now used on Monday morning to select which company to acquire.

While the benefits of IM are clear and compelling, the risks associated with sharing sensitive information in an IM environment are often overlooked. We need a mechanism that permits communities of users to protect their IM conversations. This document presents an extension protocol that can be incorporated into the existing Jabber protocol to provide such a mechanism. We hope that this protocol spurs both interest and further investigation into mechanisms to protect Jabber conversations. We also hope that the Jabber community can accelerate the adoption of standardized security mechanisms.

In addition to its ability to protect traditional messaging data, the proposed protocol may also serve as a foundation for securing other data transported via other Jabber extensions.

We use the following terms throughout this document to describe the most relevant aspects of the IM environment that we wish to address:

Other Jabber and IM terms are used in a traditional, intuitive fashion.

2. Requirements And Considerations

The proposed protocol is designed to address the specific requirements and considerations presented in this section.

2.1 Security Requirements

2.1.1 Data Protection Requirements

A secure IM system must permit conversation participants to preserve the following properties of their conversation data:

These are established, traditional goals of information security applied to the conversation data. In the IM environment, these goals protect against these attacks:

Preserving the availability of conversation data is not addressed by this protocol.

Preserving the anonymity of conversation participants is an interesting topic which we defer for future exploration.

Finally, note that this protocol does not concern any authentication between a Jabber node and a Jabber host.

2.1.2 Data Classification Requirements

A secure IM system must support a data classification feature through the use of security labeling. Conversation participants must be able to associate a security label with each piece of conversation data. This label may be used to specify a data classification level for the conversation data.

2.1.3 The End To End Requirement

It is easy to imagine Jabber systems in which the servers play active, fundamental roles in the protection of conversation data. Such systems could offer many advantages, like:

Unfortunately, such systems have significant disadvantages when one considers the nature of instant messaging:

Furthermore, the widespread use of gateways to external IM systems is a further complication.

Based on this analysis, we propose that security be entirely controlled in an end to end fashion by the conversation participants themselves via their user agent software.

2.1.4 Trust Issues

We believe that, ultimately, trust decisions are in the hands of the conversation participants. A security protocol and appropriate conforming user agents must provide a mechanism for them to make informed decisions.

2.1.5 Cryptosystem Design Considerations

One of the accepted axioms of security is that people must avoid the temptation to start from scratch and produce new, untested algorithms and protocols. History has demonstrated that such approaches are likely to contain flaws and that considerable time and effort are required to identify and address all of these flaws. Any new security protocol should be based on existing, established algorithms and protocols.

2.2 Environmental Considerations

Any new IM security protocol must integrate smoothly into the existing IM environment, and it must also recognize the nature of the transactions performed by conversation participants. These considerations are especially important:

Addressing these considerations becomes especially crucial when selecting a conference keying mechanism.

2.3 Usability Requirements

Given the requirement to place the responsibility for the protection of conversation data in the hands of the participants, it is imperative to address some fundamental usability issues:

We note that, in practice, the design and construction of user agents will also have a major impact on ease of use.

2.4 Development And Deployment Requirements

To successfully integrate into the existing Jabber environment, an extension protocol for security must satisfy the following:

Failure to accommodate these will impede or prohibit adoption of any security protocol.

3. Protocol Specification

3.1 Protocol Overview

Ultimately, conversation data is protected by the application of keyed cryptographic operations. One operation is used to provide confidentiality, and a separate operation is used to provide integrity and data origin authentication. The keys used to parameterize these operations are called conversation keys. Each conversation should have its own unique set of conversation keys shared among the conversation participants.

Conversation keys are transported among the conversation participants within a negotiated security session. A security session allows pairs of conversation participants to securely share conversation keys throught all participants in the conversation as required.

3.2 Definitions And Notation

The following terms are used throughout this specification:

3.3 XML Processing

Since cryptographic operations are applied to data that is transported within an XML stream, the protocol defines a set of rules to ensure a consistent interpretation by all conversation participants.

3.3.1 Transporting Binary Content

Binary data, such as the result of an HMAC, is always transported in an encoded form; the two supported encoding schemes are base64 and hex.

Senders MAY include arbitrary white space within the character stream. Senders SHOULD NOT include any other characters outside of the encoding set.

Receivers MUST ignore all characters not in the encoding set.

3.3.2 Transporting Encrypted Content

Encrypted data, including wrapped cryptographic keys, are always wrapped per XML Encryption.

3.3.3 HMAC Computation

HMACs are computed over a specific collection of attribute values and character data; when computing an HMAC the following rules apply:

3.3.4 Performing Cryptographic Operations

The following algorithm is used to encrypt a character string, such as an XML element:

3.4 XML Namespaces

In order to integrate smoothly with the existing Jabber protocol, this protocol utilizes a new XML namespace, jabber:security.

3.5 Security Sessions

3.5.1 Overview

A security session is a pair-wise relationship between two users in which the users have achieved the following:

Security sessions are identified by a 3-tuple consisting of the following items:

Security sessions are used to transport conversation keys between the conversation participants.

Scalabilty is an immediate, obvious concern with such an approach. We expect this approach to be viable in practice because:

Other approaches, including the incorporation of more sophisticated conference keying algorithms, are a topic for future exploration.

3.5.2 Security Session Negotiation

Security sessions are negotiated using an authenticated Diffie-Hellman key agreement exchange. The two goals of the exchange are to perform the mutual authentication and to agree to a secret that is know only to each.

The exchange also allows the parties to negotiate the various algorithms and authentication mechanisms that will be used.

Once the pair agree on a shared secret, they each derive key material from the secret; this key material is used to securely transport the conversation keys, which are used to actually protect conversation data.

The protocol data units (PDUs) that comprise the exchange are transported within existing Jabber protocol elements.

3.5.3 DTDs

Example 1.


<!ELEMENT session1
          (nonce, keyAgreement, algorithms, authnMethods) >
<!ATTLIST session1
          version CDATA #REQUIRED
          initiator CDATA #REQUIRED
          responder CDATA #REQUIRED
          sessionId CDATA #REQUIRED
          hmac (hmac-sha1) #REQUIRED >

<!ELEMENT nonce
          (#PCDATA)* >
<!ATTLIST nonce
          encoding (base64 | hex) #REQUIRED >

<!ELEMENT keyAgreement
          (dh) >

<!ELEMENT dh
          (publicKey) >
<!ATTLIST dh
          group (modp1024 | modp2048 | modp4096 | modp8192) #REQUIRED >

<!ELEMENT publicKey
          (#PCDATA)* >
<!ATTLIST publicKey
          encoding (base64 | hex) #REQUIRED >

<!ELEMENT algorithms
          (algorithm)+ >

<!ELEMENT algorithm
          (confAlg, hmacAlg) >

<!ELEMENT confAlg EMPTY >
<!ATTLIST confAlg
          cipher (3des-cbc | aes-128-cbc | aes-256-cbc) #REQUIRED >

<!ELEMENT hmacAlg EMPTY >
<!ATTLIST hmacAlg
          alg (hmac-sha1 | hmac-md5) #REQUIRED>

<!ELEMENT authnMethods
          (authnMethod)+ >

<!ELEMENT authnMethod
          (digSig | passphrase) >

<!ELEMENT digSig
          (certificate+, caCertificate*) >
<!ATTLIST digSig
          alg (rsa) #REQUIRED>

<!ELEMENT certificate
          (#PCDATA)* >
<!ATTLIST certificate
          type (x509 | pkcs7) #REQUIRED
          encoding (base64 | hex) #REQUIRED >

<!ELEMENT caCertificate
          (#PCDATA)* >
<!ATTLIST caCertificate
          type (x509 | pkcs7) #REQUIRED
          encoding (base64 | hex) #REQUIRED >

<!ELEMENT passphrase EMPTY >
<!ATTLIST passphrase
          passphraseId CDATA #REQUIRED >


<!ELEMENT session2
          (nonce, keyAgreement, algorithm, authnMethod, authenticator) >
<!ATTLIST session2
          version CDATA #REQUIRED
          initiator CDATA #REQUIRED
          responder CDATA #REQUIRED
          sessionId CDATA #REQUIRED
          hmac (hmac-sha1) #REQUIRED >

<!ELEMENT authenticator
          (#PCDATA)* >
<!ATTLIST authenticator
          encoding (base64 | hex) #REQUIRED>


<!ELEMENT session3
          (authenticator, keyTransport*) >
<!ATTLIST session3
          version CDATA #REQUIRED
          initiator CDATA #REQUIRED
          responder CDATA #REQUIRED
          sessionId CDATA #REQUIRED
          hmac (hmac-sha1) #REQUIRED >

3.5.4 Generating And Sending the session1 PDU

The initiator's user agent employs the following algorithm to generate the session1 PDU:

These values are then used to prepare the XML session1 element; this element is transmitted via the existing Jabber iq mechanism:

Example 2.

<iq from="initiator's JID" to="responder's JID" type="get" id="whatever">
   <query xmlns="jabber:security:session">
      <session1>...</session1>
   </query>
</iq>

3.5.5 Receiving And Processing the session1 PDU

The responder's user agent employs the following algorithm to process each session1 PDU:

If any errors occur during processing, the session negotiation fails, and the error is communicated via the existing Jabber iq mechanism:

Example 3.

<iq from="responder's JID" to="initiator's JID" type="error" id="whatever">
   <error code="???">...</error>
</iq>

If no errors occur, then the responder's user agent proceeds with the session2 PDU.

3.5.6 Generating And Sending the session2 PDU

The responder's user agent employs the following algorithm to generate the session2 PDU:

These values are then used to prepare the XML session2 element; this element is transmitted via the existing Jabber iq mechanism:

Example 4.

<iq from="responder's JID" to="initiator's JID" type="result" id="whatever">
   <query xmlns="jabber:security:session">
      <session2>...</session2>
   </query>
</iq>

3.5.7 Receiving And Processing the session2 PDU

The initiator's user agent employs the following algorithm to process each session2 PDU:

If any errors occur during processing, the session negotiation fails, and the error is communicated via the existing Jabber iq mechanism:

Example 5.

<iq from="initiator's JID" to="responder's JID" type="error" id="whatever">
   <error code="???">...</error>
</iq>

If no errors occur, then the initiator's user agent proceeds with the session3 PDU.

3.5.8 Generating And Sending the session3 PDU

The initiator's user agent employs the following algorithm to generate the session3 PDU:

These values are then used to prepare the XML session3 element; this element is transmitted via the existing Jabber iq mechanism:

Example 6.

<iq from="initiator's JID" to="responder's JID" type="result" id="whatever">
   <query xmlns="jabber:security:session">
      <session3>...</session3>
   </query>
</iq>

3.5.9 Receiving And Processing the session3 PDU

The responder's user agent employs the following algorithm to process each session3 PDU:

If any errors occur during processing, the session negotiation fails, and the error is communicated via the existing Jabber iq mechanism:

Example 7.

<iq from="responder's JID" to="initiator's JID" type="error" id="whatever">
   <error code="???">...</error>
</iq>

3.5.10 Session Key Material Derivation

TBA

3.6 Key Transport

3.6.1 Overview

Conversation keys are used to protect conversation data.

3.6.2 The Key Transport Mechanism

Conversation keys are transported using the symmetric key wrap feature of XML Encryption embedded in the keyTransport PDU.

3.6.3 DTDs

Example 8.

<!ELEMENT keyTransport
          (convId, payload, hmac) >
<!ATTLIST keyTransport
          version CDATA #REQUIRED
          initiator CDATA #REQUIRED
          responder CDATA #REQUIRED
          sessionId CDATA #REQUIRED >

<!ELEMENT convId
          (#PCDATA)* >

<!-- These are actually instances of xenc:EncryptedKey -->
<!ELEMENT payload
          (confKey, hmacKey) >

<!ELEMENT hmac
          (#PCDATA)* >
<!ATTLIST hmac
          encoding (base64 | hex) #REQUIRED >

3.6.4 Generating And Sending the keyTransport PDU

The sender's user agent employs the following algorithm to generate the keyTransport PDU:

These values are then used to prepare the XML keyTransport element; this element is transmitted via the existing Jabber iq mechanism:

Example 9.

<iq from="sender's JID" to="receiver's JID" type="set" id="whatever">
   <query xmlns="jabber:security:keyTransport">
      <keyTransport>...</keyTransport>
   </query>
</iq>

3.6.5 Receiving and Processing the keyTransport PDU

The receiver's user agent employs the following algorithm to process each keyTransport PDU:

If any errors occur during processing, the error is communicated via the existing Jabber iq mechanism:

Example 10.

<iq from="receiver's JID" to="sender's JID" type="error" id="whatever">
   <error code="???">...</error>
</iq>

3.7 Message Protection

3.7.1 Overview

The ultimate goal is, of course, the protection of conversation data. The protocol exchanges described above allow the conversation participants to cryptographically protect their conversation data using the conversation keys that they share.

3.7.2 The Message Protection Mechanism

A protected message is defined as a traditional Jabber message whose body content is extended to include the transport of a cryptographically protected message body. The two key features are

This mechanism has the advantages of allowing transparent integration with existing Jabber servers and existing Jabber clients.

3.7.3 DTD

Example 11.

<!ELEMENT protectedMessage
          (securityLabel?, payload, hmac) >
<!ATTLIST protectedMessage
          version CDATA #REQUIRED
          from CDATA #REQUIRED
          to CDATA #REQUIRED
          convId #REQUIRED
          seqNum #REQUIRED >

<!ELEMENT securityLabel
          (#PCDATA)* >

<!-- this is actually an instance of xenc:EncryptedData -->
<!ELEMENT payload
          (#PCDATA)* >

<!ELEMENT hmac
          (#PCDATA)* >
<!ATTLIST hmac
          encoding (base64 | hex) #REQUIRED >

3.7.4 Generating And Sending the protectedMessage PDU

The sender's user agent employs the following algorithm to generate the protectedMessage PDU:

These values are then used to prepare the XML protectedMessage element; this element is transmitted via the existing Jabber message mechanism:

Example 12.

<message from="sender's JID" to="reveiver's JID" id="whatever">
   <body>The real body is protected.</body>
   <x xmlns="jabber:security:message">
      <protectedMessage>...</protectedMessage>
   </x>
</iq>

3.7.5 Receiving and Processing the protectedMessage PDU

The receiver's user agent employs the following algorithm to process each protectedMessage PDU:

If any errors occur during processing, the error is communicated via the existing Jabber iq mechanism:

Example 13.

<iq from="receiver's JID" to="sender's JID" type="error" id="whatever">
   <error code="???">...</error>
</iq>

3.8 Requesting Keys

TBA

3.9 Conformance Profile

The following block encryption algorithms are required, as specified by XML Encryption:

The following symmetric key wrap algorithms are required, as specified by XML Encryption:

4. Diffie-Hellman Groups

This protocol makes use of the following Diffie-Hellman groups adopted from IKE.

4.1 1024 bit Group, modp1024

The hexidecimal value of the prime, p, is

Example 14.

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF

The decimal value of the generator, g, is 2.

4.2 2048 bit Group, modp2048

The hexidecimal value of the prime, p, is

Example 15.

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AACAA68 FFFFFFFF FFFFFFFF

The decimal value of the generator, g, is 2.

4.3 4096 bit Group, modp4096

The hexidecimal value of the prime, p, is

Example 16.

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7
88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA
2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6
287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED
1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9
93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
FFFFFFFF FFFFFFFF

The decimal value of the generator, g, is 2.

4.4 8192 bit Group, modp8192

The hexidecimal value of the prime, p, is

Example 17.

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7
88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA
2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6
287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED
1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9
93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD
F8FF9406 AD9E530E E5DB382F 413001AE B06A53ED 9027D831
179727B0 865A8918 DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B
DB7F1447 E6CC254B 33205151 2BD7AF42 6FB8F401 378CD2BF
5983CA01 C64B92EC F032EA15 D1721D03 F482D7CE 6E74FEF6
D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F BEC7E8F3
23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328
06A1D58B B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C
DA56C9EC 2EF29632 387FE8D7 6E3C0468 043E8F66 3F4860EE
12BF2D5B 0B7474D6 E694F91E 6DBE1159 74A3926F 12FEE5E4
38777CB6 A932DF8C D8BEC4D0 73B931BA 3BC832B6 8D9DD300
741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C 5AE4F568
3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B
4BCBC886 2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A
062B3CF5 B3A278A6 6D2A13F8 3F44F82D DF310EE0 74AB6A36
4597E899 A0255DC1 64F31CC5 0846851D F9AB4819 5DED7EA1
B1D510BD 7EE74D73 FAF36BC3 1ECFA268 359046F4 EB879F92
4009438B 481C6CD7 889A002E D5EE382B C9190DA6 FC026E47
9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
60C980DD 98EDD3DF FFFFFFFF FFFFFFFF

The decimal value of the generator, g, is 2.

5. Security Considerations

This entire document is about security.

This version of the protocol deliberately incorporates only a minimal amount of cryptographic choice. Examples of possible choices that can readily added in future drafts include:

Furthermore, additional credential formats, such as OpenPGP, may be addressed in future drafts.

This version of the protocol includes a mechanism that derives a cryptographic key from a passphrase shared by a community of users. It is impossible to overstate the security issues that such a mechanism raises.

This version of the protocol does not include a specific rekeying capability. Data volumes in IM environments are expected to be small, and the protocol prefers to simply instantiate new conversation keys. It is straightforward to extend the security session protocol to enable negotiation of a new key.

6. Examples

6.1 Security Session

Example 18.

<iq from='initiator@some.tld'
    to='responder@other.tld'
    type='get'
    id='whatever' >
    <x xmlns='jabber:security:session>
       <session1 version='1.0'
                 initiator='initiator@some.tld'
                 responder='responder@other.tld'
                 sessionId='session11223344556677@some.tld'
                 hmac='hmac-sha1'>
         <nonce encoding='hex'>
            ...
         </nonce>
         <keyAgreement>
            <dh group='modp4096'>
               <publicKey encoding='base64'>
                  ...
               </publicKey>
            </dh>
         </keyAgreement>
         <algorithms>
            <algorithm>
               <confAlg cipher='3des-cbc'/>
               <hmacAlg alg='hmac-sha1'/>
            </algorithm>
         </algorithms>
         <authnMethods>
            <authnMethod>
               <digSig alg='rsa'>
                  <certificate type='x509' encoding='base64'>
                     ...
                  </certificate>
               </digSig>
            </authnMethod>
         </authnMethods>
      </session1>
   </x>
</iq>

<iq from='responder@other.tld'
    to='initiator@some.tld'
    type='result'
    id='whatever' >
    <x xmlns='jabber:security:session>
       <session2 version='1.0'
                 initiator='initiator@some.tld'
                 responder='responder@other.tld'
                 sessionId='session11223344556677@some.tld'
                 hmac='hmac-sha1'>
         <nonce encoding='hex'>
            ...
         </nonce>
         <keyAgreement>
            <dh group='modp4096'>
               <publicKey encoding='base64'>
                  ...
               </publicKey>
            </dh>
         </keyAgreement>
         <algorithm>
            <confAlg cipher='3des-cbc'/>
            <hmacAlg alg='hmac-sha1'/>
         </algorithm>
         <authnMethod>
            <digSig alg='rsa'>
               <certificate type='x509' encoding='base64'>
                  ...
               </certificate>
            </digSig>
         </authnMethod>
         <authenticator encoding='base64'>
            ...
         </authenticator>
      </session2>
   </x>
</iq>

<iq from='initiator@some.tld'
    to='responder@other.tld'
    type='result'
    id='whatever' >
    <x xmlns='jabber:security:session>
       <session3 version='1.0'
                 initiator='initiator@some.tld'
                 responder='responder@other.tld'
                 sessionId='session11223344556677@some.tld'
                 hmac='hmac-sha1'>
         <authenticator encoding='base64'>
            ...
         </authenticator>
      </session3>
   </x>
</iq>

6.2 Key Transport

Example 19.

<iq type='set' >
   <x xmlns='jabber:security:key>
      <keyTransport version='1.0'
                    initiator='initiator@some.tld'
                    responder='responder@other.tld'
                    sessionId='session11223344556677@some.tld'>
         <convId>
            44d2d2d2d2@some.tld
         </convId>
         <EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
                        Type='http://www.w3.org/2001/04/xmlenc#Content'>
            <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#kw-tripledes>
            </EncryptionMethod>
            <CipherData>
               <CipherValue>
                  ...
               </CipherValue>
            </CipherData>
         </EncryptedKey>
         <EncryptedKey xmlns='http://www.w3.org/2001/04/xmlenc#'
                        Type='http://www.w3.org/2001/04/xmlenc#Content'>
            <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#kw-tripledes>
            </EncryptionMethod>
            <CipherData>
               <CipherValue>
                  ...
               </CipherValue>
            </CipherData>
         </EncryptedKey>
         <hmac encoding='hex'>
            ...
         </hmac>
      </keyTransport>
   </x>
</iq>

6.3 Message Protection

Example 20.

<message from='initiator@some.tld'
         to='responder@other.tld'>
   <body>
      The real body is protected.
   </body>
   <x xmlns='jabber:security:message'>
      <protectedMessage version='1.0'
                        from='initiator@some.tld'
                        to='responder@other.tld'
                        convId='44d2d2d2d2@some.tld'
                        seqNum='1'>
         <securityLabel>
            Confidential
         </securityLabel>
         <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
                        Type='http://www.w3.org/2001/04/xmlenc#Element'>
            <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc>
            </EncryptionMethod>
            <CipherData>
               <CipherValue>
                  ...
               </CipherValue>
            </CipherData>
         </EncryptedData>
         <hmac encoding='hex'>
            ...
         </hmac>
      </protectedMessage>
   </x>
</message>

7. References

"XML Encryption Syntax and Processing"; http://www.w3.org/TR/xmlenc-core

more to be added


Appendices


Appendix A: Document Information

Series: XEP
Number: 0031
Publisher: XMPP Standards Foundation
Status: Deferred
Type: Standards Track
Version: 0.2
Last Updated: 2002-07-09
Approving Body: XMPP Council
Dependencies: None
Supersedes: None
Superseded By: None
Short Name:
Source Control: HTML
This document in other formats: XML  PDF


Appendix B: Author Information

Paul Lloyd

Email: paul_lloyd@hp.com
JabberID: paul_lloyd@jabber.hp.com (private)


Appendix C: Legal Notices


Appendix D: Relation to XMPP

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.


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


Appendix H: Revision History

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

Version 0.2 (2002-07-09)

updated to reflect group consensus to incorporate XML Encryption, as well as other group comments from Draft 0.9. ( PCL )

Version 0.1 (2002-05-07)

initial version ( PCL )

END