The process for establishing a secure session over an insecure transport is essentially a negotiation of various ESession algorithms and other parameters, combined with a translation into XMPP syntax of the σ approach to key exchange (see Cryptographic Design of Encrypted Sessions).
-If Alice believes Bob may be online then she SHOULD use the protocol specified in &xep0155; and in this section to negotiate the ESession options and the keys.
-Note: If Alice believes Bob is offline then she SHOULD NOT use this negotiation protocol. However, she MAY use the protocol specified in Offline Encrypted Sessions to establish the ESession options and keys. Alternatively, she MAY send stanzas without encryption - in which case her client MUST make absolutely clear to her that the stanzas will not be protected and give her the option not to send the stanzas.
-Each entity (or each user of a client installation) MUST be assigned a large random Anonymous ID (AID) upon first use.
-This protocol supports both 3- and 4-message key negotiations. The 3-message SIGMA-I-based key exchange protects the identity of the initiator against active attacks. This SHOULD NOT be used to establish client-to-client sessions since the responder's identity is not protected against active attacks. However, it SHOULD be used to establish client-to-service (server) sessions, especially where the identity of the service is well known to third parties.
-The 4-message SIGMA-R-based key exchange with hash commitment defends the responder's identity against active attacks and facilitates detection of a Man in the Middle attack. It SHOULD be used to establish client-to-client sessions. The 4-message key exchange also features optional Short-Authentication-String protection against Man-in-the-Middle attacks without the need to generate, distribute or authenticate any public keys. As long as a hash commitment is used at the start of the key exchange then only a short human-friendly string needs to be verified out-of-band (e.g. by recognizable voice communication).
-The 4-message key exchange also features optional secret retention. If retained secrets are employed consistently during key exchanges, then the Man in the Middle would need to be present for every session, including the first, and the out-of-band verification would only need to be performed once to verify the absence of a Man in the Middle for all sessions between the parties (past, present and future).
Public keys are optional in the diagram below. It describes the same SIGMA-R with SAS key exchange protocol as the SIGMA-R Overview. It provides much more detail including the use of retained secrets and other secrets. Note: These optional security enhancements are especially important when the protocol is being used without public keys.
-Alternatively Alice and Bob could agree a shared secret via secure out-of-band communication, Bob could then use it to create an HMAC of his public key that only Alice could verify.
+The process for establishing a secure session over an insecure transport is essentially a negotiation of various ESession algorithms and other parameters, combined with a translation into XMPP syntax of the σ approach to key exchange (see Cryptographic Design of Encrypted Sessions).
+If Alice believes Bob may be online then she SHOULD use the protocol specified in &xep0155; and in this section to negotiate the ESession options and the keys.
+Note: If Alice believes Bob is offline then she SHOULD NOT use this negotiation protocol. However, she MAY use the protocol specified in Offline Encrypted Sessions to establish the ESession options and keys. Alternatively, she MAY send stanzas without encryption - in which case her client MUST make absolutely clear to her that the stanzas will not be protected and give her the option not to send the stanzas.
+This protocol supports both 3- and 4-message key negotiations.
+The 3-message SIGMA-I-based key exchange protects the identity of the initiator against active attacks. This SHOULD NOT be used to establish client-to-client sessions since the responder's identity is not protected against active attacks. However, it SHOULD be used to establish client-to-service (server) sessions, especially where the identity of the service is well known to third parties.
+The 4-message SIGMA-R-based key exchange with hash commitment defends the responder's identity against active attacks and facilitates detection of a Man in the Middle attack. It SHOULD be used to establish client-to-client sessions. The 4-message key exchange also includes the following optional security enhancements:
+"Secret Retention": If retained secrets are employed consistently during key exchanges, then the Man in the Middle would need to be present for every session, including the first. Sessions remain secure even if a long-lived private signing key is compromised at some time after the first session.
"Short-Authentication-String": Alice and Bob can use SAS once to quickly authenticate each other's public keys. Only a very short human-friendly string needs to be verified out-of-band (e.g. by recognizable voice communication).
+Alternatively, thanks to its protection against Man-in-the-Middle attacks, SAS can be used to eliminate the need to generate, distribute or authenticate any public keys. Note: When this protocol is being used without public keys Alice and Bob SHOULD employ Secret Retention, then the out-of-band verification only needs to be performed once to verify the absence of a Man in the Middle for all sessions (past, present and future).
"Other Secret": Alice and Bob agree a password out-of-band and their clients use it to authenticate each other every time a session is negotiated.
Signature algorithm names
Compression algorithm names
The list of stanza types that MAY be encrypted and decrypted
Whether or not the other entity MUST send the fingerprint of its public signature-verification key instead of the full key
The different versions of this protocol that are supported
The minimum number of stanzas that MUST be exchanged before an entity MAY initiate a key re-exchange (1 - every stanza, 100 - every hundred stanzas). Note: This value MUST be less than &twosup32; (see Re-Keying Limits)
What sort of identification is required from the other entity. This MUST be either 'key' (its public signature-verification key), or 'hash' (a fingerprint of its public key)
Each MODP group has at least two well known constants: a large prime number p, and a generator g for a subgroup of GF(p). For each MODP group that Alice specifies she MUST perform the following computations to calculate her Diffie-Hellman keys (where n is the number of bits per cipher block for the block cipher algorithm with the largest block size out of those she specified):
Generate a secret random number x (where &twosup2n; < x < p - 1)
Calculate e = &gsupx; mod p
Generate: a secret random number x (where &twosup2n; < x < p - 1)
Calculate: e = &gsupx; mod p
Calculate: He = SHA256(e) (see &nistfips180-2;)
Alice MUST send all her calculated values of e to Bob (in the same order as the associated MODP groups are being sent). She MUST also specify randomly generated Base64 encoded (in accordance with Section 3 of &rfc3548;) value of &NsubA; (her ESession ID).
-Alice MUST send all her calculated values of 'He' (for 4-message negotiations) or 'e' (for 3-message negotiations) to Bob (in the same order as the associated MODP groups are being sent). She MUST also specify randomly generated Base64 encoded (in accordance with Section 3 of &rfc3548;) value of &NsubA; (her ESession ID).
+The first message of a 3-message negotiation is identical except the a 'dhkeys' field is included instead of the 'dhhashes' field:
+If Bob supports one or more of each of Alice's ESession options and is willing to start an ESession with Alice, then he MUST select one of the options from each of the ESession fields he received from Alice including one hash algorithm ("HASH"), and one of the MODP groups and Alice's corresponding value of e (see &rfc3766; or RFC 3526 for recommendations regarding balancing the sizes of symmetric cipher blocks and Diffie-Hellman moduli).
-Each MODP group has at least two well known constants: a large prime number p, and a generator g for a subgroup of GF(p). Bob SHOULD return a &feature; error unless: 1 < e < p - 1
+If Bob supports one or more of each of Alice's ESession options and is willing to start an ESession with Alice, then he MUST select one of the options from each of the ESession fields he received from Alice including one hash algorithm ("HASH"), and one of the MODP groups (see &rfc3766; or RFC 3526 for recommendations regarding balancing the sizes of symmetric cipher blocks and Diffie-Hellman moduli) and Alice's corresponding value of 'He' (for 4-message negotiations) or 'e' (for 3-message negotiations).
+Note: Each MODP group has at least two well known constants: a large prime number p, and a generator g for a subgroup of GF(p).
+For 3-message negotiations, Bob SHOULD return a &feature; error unless: 1 < e < p - 1
Bob MUST then perform the following computations (where n is the number of bits per cipher block for the selected block cipher algorithm):
Generate a random number &NsubB; (his ESession ID)
Calculate d = &gsupy; mod p
Calculate K = HASH(&esupy; mod p) (the shared secret)
If this is a 4-message negotiation Bob MUST skip the last step above and all the steps described in the next two sections. He can skip straight to the ESession Response section.
Bob MUST perform the following steps before he can prove his identity to Alice while protecting it from third parties.
Select &pubKeyB;, the public key Alice should use to authenticate his signature with the signature algorithm he selected ("SIGN").
Set &formB; to the Normalized content of the reponse data form he will send back to Alice (including his responses for all the fields he received from Alice).
-Bob MUST encapsulate the Base64 encoded values of &CsubA; and Alice's &NsubA; in two new 'counter' and 'nonce' fields and add them to &formB;. He MUST set the 'pk_hash' field to specify whether or not Alice MUST send the fingerprint of her public signature-verification key instead of her full key. He MUST set the value of the 'rekey_freq' field to be less than &twosup32; and greater than or equal to the value specified by Alice. Bob MUST place his Base64 encoded values of &NsubB; and d in the 'my_nonce' and 'keys' fields. Note: Bob MUST NOT return Alice's values of &NsubA; and e in these fields.
If the value of the 'pubkey' field that Alice sent Bob was not 'none' then Bob MUST set &pubKeyB; to a zero length string of characters. Otherwise Bob SHOULD select &pubKeyB;, the public key Alice will use to authenticate his signature with the signature algorithm he selected ("SIGN").
Set &formB; to the Normalized content of the reponse data form he will send back to Alice (including his responses for all the fields he received from Alice) - see ESession Response.
+Bob MUST encapsulate the Base64 encoded values of &CsubA; and Alice's &NsubA; in two new 'counter' and 'nonce' fields and add them to &formB;. He MUST set the 'pubkey' field to specify what sort of identification he requires from Alice (see ESession Request). He MUST set the value of the 'rekey_freq' field to be less than &twosup32; and greater than or equal to the value specified by Alice. Bob MUST place his Base64 encoded values of &NsubB; and d in the 'my_nonce' and 'dhkeys' fields. Note: Bob MUST NOT return Alice's values of &NsubA; and e in these fields.
Concatenate Alice's ESession ID, Bob's ESession ID, d, &pubKeyB; and &formB;, and calculate the HMAC (as defined in Section 2 of &rfc2104;) of the resulting byte string using the selected hash algorithm ("HASH") and the key &KSsubB;.
&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})Calculate &signB;, the signature of the HMAC result using his private signature key that corresponds to &pubKeyB;
+If the value of the 'pubkey' field that Alice sent Bob was not 'none' then Bob MUST calculate &signB;, the signature of the HMAC result using his private signature key that corresponds to &pubKeyB;
&signB; = SIGN(&signKeyB;, &macB;)If the value of the 'pk_hash' field that Alice sent Bob was true then Bob SHOULD set &pubKeyB; to the key's fingerprint
-if (pk_hash) &pubKeyB; = HASH(&pubKeyB;)Concatenate &pubKeyB; and &signB; and encrypt the resulting byte string with the agreed algorithm ("CIPHER") in counter mode (see &nistfips800-38a;), using the encryption key &KCsubB; and block counter &CsubB;. Note: &CsubB; MUST be incremented by 1 for each encrypted block or partial block (i.e. &CsubB; = (&CsubB; + 1) mod 2n, where n is the number of bits per cipher block for the agreed block cipher algorithm).
-&IDB; = CIPHER(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})If the value of the 'pubkey' field that Alice sent Bob was 'hash' then Bob SHOULD set &pubKeyB; to the key's fingerprint
+if (pubkey == 'hash') &pubKeyB; = HASH(&pubKeyB;)Encrypt the byte string resulting from the concatenation of &pubKeyB; and &signB; (or, if the value of the 'pubkey' field that Alice sent Bob was 'none', encrypt just the HMAC result) with the agreed algorithm ("CIPHER") in counter mode (see &nistfips800-38a;), using the encryption key &KCsubB; and block counter &CsubB;. Note: &CsubB; MUST be incremented by 1 for each encrypted block or partial block (i.e. &CsubB; = (&CsubB; + 1) mod 2n, where n is the number of bits per cipher block for the agreed block cipher algorithm).
+&IDB; = CIPHER(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
+ or
+&IDB; = CIPHER(&KCsubB;, &CsubB;, &macB;)Calculate the HMAC of the encrypted identity (&IDB;) and the value of Bob's block cipher counter &CsubB; before the encryption above using the selected hash algorithm ("HASH") and the integrity key &KMsubB;.
&MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)Return a &feature; error to Bob unless the value of &MsubB; she calculated matches the one she received in the 'mac' field
Obtain &pubKeyB; and &signB; by decrypting &IDB; with the agreed symmetric block cipher algorithm ("DECIPHER") in counter mode, using the encryption key &KCsubB; and block counter &CsubB;. Note: &CsubB; MUST be incremented by 1 for each encrypted block or partial block (i.e. &CsubB; = (&CsubB; + 1) mod 2n, where n is the number of bits per cipher block for the agreed block cipher algorithm).
{&pubKeyB;, &signB;} = DECIPHER(&KCsubB;, &CsubB;, &IDB;)If the value of the 'pk_hash' field she sent to Bob in her ESession Request was true, then Alice SHOULD change the value of &pubKeyB; to be her copy of the public key whose HASH matches the value of &pubKeyB; that she received from Bob. Note: If she cannot find a copy of the public key then Alice MUST terminate the ESession. She MAY then request a new ESession with the 'pk_hash' field set to false.
If the value of the 'pubkey' field she sent to Bob in her ESession Request was 'hash', then Alice SHOULD change the value of &pubKeyB; to be her copy of the public key whose HASH matches the value of &pubKeyB; that she received from Bob. Note: If she cannot find a copy of the public key then Alice MUST terminate the ESession. She MAY then request a new ESession with the 'pubkey' field set to 'key' or 'none'.
Return a &feature; error to Bob unless she can confirm (or has previously confirmed) that &pubKeyB; really is Bob's public key, for examples, via secure out-of-band communication, or through a third-party authority (see Verifying Keys).
Set the value of &formB; to be the Normalized content of the form she received from Bob without any 'identity' or 'mac' fields.
Concatenate Alice's ESession ID, Bob's ESession ID, d, &pubKeyB; and &formB;, and calculate the HMAC of the resulting byte string using HASH and the key &KSsubB;.
@@ -504,7 +551,7 @@Alice MUST then prove her identity to Bob while protecting it from third parties. She MUST perform the steps equivalent to those Bob performed above (see Hiding Identity for a more detailed description). Alice's calculations are summarised below (pay attention to the order of &NsubB; and &NsubA; when calculating &macA;). Note: &formA; is the Normalized content of the ESession Request data form that she sent to Bob previously.
&macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;})
&signA; = SIGN(&signKeyA;, &macA;)
- if (pk_hash) &pubKeyA; = HASH(&pubKeyA;)
+ if (pubkey == 'hash') &pubKeyA; = HASH(&pubKeyA;)
&IDA; = CIPHER(&KCsubA;, &CsubA;, {&pubKeyA;, &signA;})
&MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;)
@@ -659,7 +706,6 @@
Entities MUST associate one or more JIDs with each public key fingerprint that they store, and alert their users immediately if another JID presents the same public key. This is necessary since if Bob already has fingerprints from Alice and Mallory, and Bob's client presents only the JID (or a name associated with the JID) to Bob, then Mallory could use his own public key (that is trusted by Bob) and pretend to be Alice simply by exchanging stanzas with Bob using Alice's JID.
If a JID for which a key has previously been stored attempts to establish an ESession using a public key with a different fingerprint (or no key at all) then the entity MUST alert its user.
Since Alice MAY use many different JIDs to talk to Bob, but always identify herself to him with the same public key, Entities SHOULD associate a "petname" with each public key fingerprint they store. Entities MUST present any public key petnames clearly to their users, and more prominently than any petname or nickname associated with the JID or the JID itself.
-Entities MUST take the precautions described above also when storing retained secrets and other secrets (passwords) associated with Anonimous IDs.
Organisations with full disclosure policies may require entities to disable encryption (see Back Doors) to enable the logging of all messages on their server. Unencrypted ESessions meet all the Security Requirements (see Cryptographic Design of Encrypted Sessions) except for Confidentiality. Unencrypted ESessions enable Alice to to confirm securely with Bob that both client-server connections are secure. i.e. that the value of the 'security' option (as specified in Chat Session Negotiation) has not been tampered with.
@@ -726,7 +772,7 @@An implementation of ESession MUST support the following hash algorithm:
An implementation of ESession SHOULD also support at least the following hash algorithm (sha1 and md5 are broken and therefore NOT RECOMMENDED):