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:

• dynamic communities. The members of a community are defined in near real time by the existing members.
• dynamic conversations. Conversations may involve any possible subset of the entire set of community members.

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

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:

• Overall ease of use is a requirement. For protocol purposes, one implication is that some form of authentication via passphrases is necessary. While we recognize that this can have appalling consequences, especially when we realize that a passphrase may be shared by all of the community members, we also recognize its utility.
• PKIs are well established in many large organizations, and some communities will prefer to rely on credentials issued from these authorities. We must allow the use of existing PKI credentials and trust models rather than impose closed, XMPP-specific credentials.
• Performance must not be negatively impacted. This is particularly true if we consider that most communities are composed of human users conversing in real time. For protocol purposes, one obvious implication is the desire to minimize computationally expensive public key operations.

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

• It must be an optional extension of the existing XMPP protocol.
• It must be transparent to existing XMPP servers.
• It must function gracefully in cases where some community members are not running a user agent that supports the protocol.
• It must make good use of XML.
• It must avoid encumbered algorithms.
• It must be straightforward to implement using widely available cryptographic toolkits.
• It must not require a PKI.

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.

When used to extend existing XMPP construct, the container element is an <x/> element. Each <x/> element could have one <SecurityAssociation/> to refer to a particular security session, one <KeyAgreement/> element which would contain the information for an an exchange of keys. The <x/> element could have its content authenticated by one <Signature/> element which contains the information about signature of information exchanged between two nodes. The <x/> element may contains one <KeyTransport/> element which contains the information about keys to be securely exchanged between two nodes.

When used in an IQ XMPP construct, the container element is a <query/> element. Each <query/> element could have one <SecurityAssociation/> to refer to a particular security session, one <KeyAgreement/> element which would contain the information for an an exchange of keys. The <query/> element could have its content authenticated by one <Signature/> element which contains the information about signature of information exchanged between two nodes. The <query/> element may contains one <KeyTransport/> element which contains the information about keys to be securely exchanged between two nodes.

Each <SecurityAssociation/> element may have <DigestMethod/>, <EncryptionMethod/> and <SignatureMethod/> elements to specify the actual algorithms set that will be used in a key exchange.

Each <KeyAgreement/> element may have a <DHKeyValue/> and a < DHParamters/> elements to specify the actual data and parameters used in the key exchange. It may also contain a <KA-Nonce/> element to specify a nonce to be used in a key exchange.

The base key agreement (BKE) is an implementation of the "Diffie-Hellman Method For Key Agreement" (DH). It allows two nodes to create and share a secret key.

DH is not an encryption mechanism as we normally think of them, in that we do not typically use it to encrypt data. Instead, it is a method to securely exchange the keys that encrypt data. DH accomplishes this secure exchange by creating a "shared secret", sometimes called a "key encryption key", between two nodes. The shared secret then encrypts the symmetric key, or "data encryption key" - DES, Triple DES, CAST, IDEA, Blowfish, etc, for secure transmission.

Two nodes intending to agree on a secret key shall employ the first phase of the agreement independently to produce the public values outputs PV and PV'. The nodes shall exchange the outputs.

The nodes shall then employ the second phase independently with the other nodes's public value as input. The mathematics of Diffie-Hellman key agreement ensure that the resulting outputs SK of the second phase are the same for both entities.

1) First the nodes must get the "Diffie-Hellman parameters". A prime number, 'p' (larger than 2) and "base", 'g', an integer that is smaller than 'p'. They can either be hard coded or fetched from a server.

Diffie-Hellman groups are used to determine the length of the base prime numbers used during the key exchange. The strength of any key derived depends in part on the strength of the Diffie-Hellman group the prime numbers are based on:

• Group 2 (medium) is stronger than Group 1 (low). Group 1 will provide 768 bits of keying material, while Group 2 will provide 1,024 bits. If mismatched groups specified on each peer, negotiation will fail. The group cannot be switched during the negotiation.
• A larger group results in more entropy and therefore a key which is harder to break.

2) The nodes each secretly generate a private number called 'x', which is less than "p - 1".

3) The nodes next generate the ephemeral public keys, 'y'. They are created with the function:

y = g^x mod p

4) The two nodes now exchange the public keys ('y') and the exchanged numbers are converted into a secret key, 'z'.

z = y^x mod p

'z' can now be used as the key for whatever encryption method is used to transfer information between the two nodes. Mathematically, the two nodes should have generated the same value for 'z'.

z = (g^x mod p)^x' mod p = (g^x' mod p)^x mod p

All of these numbers are positve integers

x^y means: x is raised to the y power

xmody means: x is divided by y and the remainder is returned

Suppose two nodes want to agree on a shared secret key to exchange information securely, they will exchange their public keys in order to encrypt that information. To this goal, the transport XMPP packet SHOULD include an extension of the form:

In this extension, the only negotiable parameter is the key length that is passed in the length attribute of the <KeyAgreement/> tag. The length attribute is used to retrieve the DH parameter group and the associated prime and generator values. We are using DH groups derived from the Internet Key Exchange protocol (IKE) which is used by IPSec. A summary of these groups and the associated parameters are described later in this document.

The Diffie-Hellman key agreement algorithm [10] provides a mechanism to allow key establishment in a scalable and secure way. It allows two parties to agree on a shared value without requiring encryption. An Authenticated Key Agreement (AKE) is a secure protocol ensuring that in addition to securely sharing a secret, the two parties can be certain of each other’s identities, even when an active attacker exists.

This AKE uses a hybrid protocol derived from the Internet Key Exchange (IKE) [1] and the OAKLEY key determination protocol [2]. The purpose is to negotiate and provide authenticated key material for security association (SA) in a protected manner. The basic mechanism is the Diffie-Hellman Key Exchange. It provides the following addition to base key agreement:

• it uses weak address validation mechanism (cookies) to avoid denial of service attacks.
• it provides negotiation of mutually agreeable supporting algorithm for the protocol, such as the encryption method, the key derivation method and the authentication method.
• the authentication does not depend on encryption using the DH exponentials, but instead validates the binding of the exponential to the identities of the parties.
• it does not require the computation of the shared exponential before the authentication.
• it provides additional security to the derivation of encryption keys, as it is made to depend not only of the DH algorithm but also on the cryptographic method used to securely authenticate the parties to each other.

This key agreement protocol is used to establish a shared key with an assigned identifier and associated identities for two parties. The resulting common keying information state comprise a key name, secret keying material, the identification of the two parties, and three algorithms for use during authentication:

• encryption for privacy,
• hashing for protecting the integrity of message and for authentication of message fields
• authentication to mutually authenticate the parties

The anti clogging tokens, or cookies, provide a weak form of source address identification for both parties. The cookies exchange can be completed before they perform the expensive computations later in the protocol. The cookies are used also for key naming.

• The construction of the cookies is implementation dependent. It is recommended to make them the result of a one-way function applied to a secret value (changed periodically), and the local and remote addresses. In this way, the cookies remain stateless and expire periodically. Note that this would cause the KEYID's derived from the secret value to also expire, necessitating the removal of any state information associated with it.
• The encryption functions must be cryptographic transforms which guarantee privacy and integrity for the message data. They include any that satisfy this criteria and are defined for use with RFC2406 [3].
• The one-way hash functions must be cryptographic transform which can be used as either keyed hash (pseudo-random) or non keyed transforms. They include any that are defined for use with RFC2406 [3].
• Where nonces are indicated they will be variable precision integers with an entropy value that match the strength attribute of the DH group used in the exchange.

The main exchange has three optional features:

• stateless cookie exchange,
• perfect forward secrecy for the keying material,
• use of signatures (for non-repudiation).

The two parties can use any combination of these features. The general outline of processing is that the Initiator of the exchange begins by specifying as much information as he wishes in his first message. The Responder replies, supplying as much information as he wishes. The two sides exchange messages, supplying more information each time, until their requirements are satisfied.

The choice of how much information to include in each message depends on which options are desirable. For example, if stateless cookies are not a requirement, and perfect forward secrecy for the keying material are not requirements, and if non- repudiatable signatures are acceptable, then the exchange can be completed in three messages. Additional features may increase the number of roundtrips needed for the keying material determination.

The three components of the key determination are:

• Cookies exchange
• DH half key exchange
• Authentication

The initiator can supply as little information as a bare exchange request, carrying no additional information. On the other hand the initiator can begin by supplying all the necessary information for the responder to authenticate the request and complete the key determination quickly, if the responder choose to accept this method. If not the responder can reply with a minimum amount of information.

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

Public keys are transported embedded in the KeyTransport PDU.

The ultimate goal is 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.

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

• the usual body element contains some arbitrary text.
• the message contains a XMPP x element defining the xmpp:sec namespace; this element transports the protected message.

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

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

• The security association identifier is assembled.
• The actual message body is encoded into a character string corresponding to a XMPP message body element. This character string is then wrapped in an instance of xenc:EncryptedData as follows:

1. The Type attribute of the xenc:EncryptedData element MUST indicate 'element'.
2. The Id, MimeType and Encoding attributes of the xenc:EncryptedData element MUST NOT be present.
3. The xenc:EncryptionMethod element MUST be present, and the Algorithm attribute MUST indicate a valid block encryption algorithm.
4. The ds:KeyInfo element MUST NOT be present. The key to be used is the confidentiality key indicated by the convId attribute.
5. The xenc:CipherData element MUST be present, and it MUST use the CipherValue choice.

• Using the HMAC key indicated by the security association, the HMAC is computed. A digital signature requires calculating:

1. HMAC = prf(sKEYID_d, key name | JID from | JID to | message id | message type | message thread | message subject | message body)

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

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

• The values of initiator, responder, and key name MUST indicate an existing security association. An invalid security association results in an error of 406-Unacceptable.
• The payload, which consists of the actual message body, is unwrapped. Any failures result in an error code of 406-Unacceptable.
• The body of the HMAC element is decoded into the actual HMAC octet string.
• Using the HMAC key indicated by the security association, the HMAC is computed. A digital signature requires calculating:

1. HMAC = prf(sKEYID_d, key name | JID from | JID to | message id | message type | message thread | message subject | message body)

• The HMAC is validated. An invalid HMAC results in an error code of 406-Unacceptable.

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

This standard describes a method for implementing Diffie-Hellman key agreement, whereby two parties, without any prior arrangements, can agree upon a secret key that is known only to them (and, in particular, is not known to an eavesdropper listening to the dialogue by which the parties agree on the key). This secret key can then be used, for example, to encrypt further communications between the parties.

The intended application of this standard is in protocols for establishing secure connections, such as those proposed for OSI's transport and network layers [ISO90a][ISO90b].

Details on the interpretation of the agreed-upon secret key are outside the scope of this standard, as are details on sources of the pseudorandom bits required by this standard.

X.208 CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.

X.509 CCITT. Recommendation X.509: The Directory—Authentication Framework. 1988.

[DH76] W. Diffie and M.E. Hellman. New directions in cryptography. IEEE Transactions on Information Theory, IT-22:644-654, 1976.

[Sch90] C.P. Schnorr. Efficient identification and signatures for smart cards. In G. Brassard, editor, Advances in Cryptology—CRYPTO '89 Proceedings, volume 435 of Lecture Notes in Computer Science, pages 239-251. Springer-Verlag, New York, 1990.

[ISO90a] ISO. JTC1/SC6/N6285: Draft Transport Layer Security Protocol. Draft, November 1990.

[ISO90b] ISO. JTC1/SC6/N2559: Draft Network Layer Security Protocol. Draft, September 1990.

For the purposes of this standard, the following definitions apply.

AlgorithmIdentifier: A type that identifies an algorithm (by object identifier) and any associated parameters. This type is defined in X.509.

ASN.1: Abstract Syntax Notation One, as defined in X.208.

Diffie-Hellman parameters: Prime and base.

Diffie-Hellman: The Diffie-Hellman key-agreement protocol, elsewhere called "exponential key agreement," as defined in [DH76].

Upper-case italic symbols (e.g., PV) denote octet strings; lower-case italic symbols (e.g., g) denote integers.

The next four sections specify parameter generation, two phases of Diffie-Hellman key agreement, and an object identifier.

A central authority shall generate Diffie-Hellman parameters, and the two phases of key agreement shall be performed with these parameters. It is possible that more than one instance of parameters may be generated by a given central authority, and that there may be more than one central authority. Indeed, each entity may be its own central authority, with different entities having different parameters. The algorithm identifier for Diffie-Hellman key agreement specifies which Diffie-Hellman parameters are employed.

Two entities intending to agree on a secret key shall employ the first phase independently to produce outputs PV and PV', the public values. The entities shall exchange the outputs.

The entities shall then employ the second phase independently with the other entity's public value as input. The mathematics of Diffie-Hellman key agreement ensure that the outputs SK of the second phase are the same for both entities.

This section describes Diffie-Hellman parameter generation.

A central authority shall select an odd prime p. The central authority shall also select an integer g, the base, that satisfies 0 < g < p. The central authority may optionally select an integer l, the private-value length in bits, that satisfies 2l-1 ≤ p.

The length of the prime p in octets is the integer k satisfying

28(k−1) ≤ p < 28k .

This section describes the first phase of Diffie-Hellman key agreement.

The first phase consists of three steps: private-value generation, exponentiation, and integer-to-octet-string conversion. The input to the first phase shall be the Diffie-Hellman parameters. The output from the first phase shall be an octet string PV, the public value; and an integer x, the private value.

This phase is performed independently by the two parties intending to agree on a secret key.

This section describes the second phase of Diffie-Hellman key agreement.

The second phase consists of three steps: octet-string-to-integer conversion, exponentiation, and integer-to-octet-string conversion. The input to the second phase shall be the Diffie-Hellman parameters; an octet string PV', the other entity's public value; and the private value x. The output from the second phase shall be an octet string SK, the agreed-upon secret key.

This phase is performed independently by the two parties intending to agree on a secret key, after the parties have exchanged public values resulting from the first phase.

This standard defines two object identifiers: pkcs-3 and DHKeyValue.

The object identifier pkcs-3 identifies this standard.

pkcs-3 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 3 }

The object identifier DHKeyValue identifies the Diffie-Hellman key agreement method defined in Sections 7 and 8.

DHKeyValue OBJECT IDENTIFIER ::= { pkcs-3 1 }

The DHKeyValue object identifier is intended to be used in the algorithm field of a value of type AlgorithmIdentifier. The parameters field of that type, which has the algorithm-specific syntax ANY DEFINED BY algorithm, would have ASN.1 type DHParameter for this algorithm.

DHParameter ::= SEQUENCE { prime INTEGER, - p base INTEGER, - g privateValueLength INTEGER OPTIONAL }

The fields of type DHParameter have the following meanings:

• prime is the prime p.
• base is the base g.
• privateValueLength is the optional private-value length l.

RSA Laboratories (415) 595-7703 100 Marine Parkway (415) 595-4126 (fax) Redwood City, CA 94065 USA pkcs-editor@rsa.com

IKE implementations MAY support a MODP group with the following prime and generator. This group is assigned id 1 (one).

The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } Its hexadecimal value is:

The generator is: 2.

IKE implementations SHOULD support a MODP group with the following prime and generator. This group is assigned id 2 (two).

The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. Its hexadecimal value is:

The generator is 2 (decimal)

IKE implementations MUST support a MODP group with the following prime and generator. This group is assigned id 5 (five). The 1536 bit MODP group has been used for the implementations for quite a long time, but it has not been documented in the current RFCs or drafts.

The prime is 2^1536 - 2^1472 - 1 + 2^64 * {[2^1406 pi] + 741804}. Its hexadecimal value is

The generator is 2.

This prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 } Its hexadecimal value is

The generator is: 2.

This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] + 1690314 }

Its hexadecimal value is:

The generator is: 2.

This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] + 240904 }

Its hexadecimal value is :

The generator is: 2.

This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] + 929484 }

Its hexadecimal value is :

The generator is: 2.

This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] + 4743158 }

Its hexadecimal value is :

The generator is: 2.