Added optional public key independence, hash commitment, SAS authentication, retained secrets and other secrets to the 4-message key exchange; defined when 3- and 4-message negotiations should be used; added disclosure field; added Back Doors and Key Associations sections; employed HMAC instead of hash; moved exchanging stanzas and rekeying sections to XEP-0200; changed namespace
Added optional public key independence, hash commitment, SAS authentication, retained secrets and other secrets to the 4-message key exchange; defined when 3- and 4-message negotiations should be used; added disclosure field; added Back Doors and Key Associations sections; employed HMAC instead of hash; required public keys to be in W3C xmldsig KeyValue format and signatures to be wrapped in a SignatureValue element; deleted Signature Generation and Verification section in favor of xmldsig; moved exchanging stanzas and rekeying sections to XEP-0200; changed namespace
The list of stanza types that MAY be encrypted and decrypted
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)
What sort of identification is required from the other entity. This MUST be either 'key' (its public signature-verification key wrapped in a <KeyValue/> element as specified in &w3xmlsig;), or 'hash' (a fingerprint of the public key - the result of processing the Normalized <KeyValue/> element with the selected hash algorithm, "HASH")
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):
Bob MUST perform the following steps before he can prove his identity to Alice while protecting it from third parties.
If the value of the 'pubkey' field that Alice sent Bob was '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").
If the value of the 'pubkey' field that Alice sent Bob was 'none' then Bob MUST set &pubKeyB; to a zero length string of characters. Otherwise Bob SHOULD select &pubKeyB;, which MUST be a Normalized <KeyValue/> element (as specified in XML Signature). This is the public key Alice will use to authenticate his signature with the signature algorithm he selected ("SIGN").
Set &formB; to be the full Normalized content of the reponse data form he generated above (see Response Form). Note: this MUST NOT include 'identity' or 'mac' 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;})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;
+If the value of the 'pubkey' field that Alice sent Bob was not 'none' then Bob MUST calculate &signB;, the signature (using his private signature key that corresponds to &pubKeyB;) of the HMAC result wrapped in a <SignatureValue/> element. Note: &signB; MUST be calculated as specified in XML Signature except that it is signature of the HMAC result, not of a <SignedInfo/> element.
&signB; = SIGN(&signKeyB;, &macB;)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;)If the value of the 'pubkey' field that Alice sent Bob was 'hash' then Bob SHOULD set &pubKeyB; to the key's fingerprint wrapped in a <fingerprint/> element
+if (pubkey == 'hash') &pubKeyB; = '<fingerprint>' + HASH(&pubKeyB;) + '</fingerprint>'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
@@ -572,13 +572,13 @@&macB; = DECIPHER(&KCsubB;, &CsubB;, &IDB;)
or
{&pubKeyB;, &signB;} = DECIPHER(&KCsubB;, &CsubB;, &IDB;)If the value of the 'pubkey' field that Alice sent Bob was 'none' then Bob MUST set pubKeyB to a zero length string of characters. Otherwise, if the value 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.
+If the value of the 'pubkey' field that Alice sent Bob was 'none' then Alice MUST set &pubKeyB; to be a zero length string of characters. Otherwise, if the value was 'hash', then Alice SHOULD change the value of &pubKeyB; to be her copy of the public key (a Normalized <KeyValue/> element) whose HASH matches the value wrapped in the &pubKeyB; <fingerprint/> element 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'.
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;.
&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})If the value of the 'pubkey' field that Alice sent Bob was 'none' then return a &feature; error to Bob if the two values of &macB; she calculated above do not match.
-If the value of the 'pubkey' field was not 'none', return a &feature; error unless she can confirm (or has previously confirmed) that &pubKeyB; really is Bob's public key (see Verifying Keys) and she can use &pubKeyB; with the selected signature verification algorithm ("VERIFY") to confirm that &signB; is the signature of the HMAC result (see Signature Verification).
+If the value of the 'pubkey' field was not 'none', return a &feature; error unless she can confirm (or has previously confirmed) that &pubKeyB; really is Bob's public key (see Verifying Keys) and she can use &pubKeyB; with the selected signature verification algorithm ("VERIFY") to confirm that &signB; is the signature of the HMAC result (see XML Signature).
VERIFY(&signB;, &pubKeyB;, &macB;)When Alice receives the stanza she MUST verify the MAC to be sure she received all the stanzas Bob sent her during the ESession. Once an entity has sent a termination or termination acknowledgement stanza it MUST NOT send another stanza within the ESession.
-Before the signature or MAC of a block of XML is generated or verified, all character data between all elements MUST be removed and the XML MUST be converted to canonical form (see &w3canon;).
-All the XML this protocol requires to be signed or MACed is very simple, so in this case, canonicalization SHOULD only require the following changes:
-Implementations MAY conceivably also need to make the following changes. Note: Empty elements and special characters SHOULD NOT appear in the signed or MACed XML specified in this protocol.
-Before the signature or MAC of a block of XML is generated or verified, the agreed hash algorithm MUST be used to generate the hash of the normalized XML.
-m_hash = HASH(m_content)
- The signature generation depends on the type of private key being used.
-signature_rsa = rsa_sign(rsa_private_key, m_hash, hashOID)
- The multiprecision integer signature_rsa is the signature (see &rfc3447;).
-sig_dsa_r, sig_dsa_s = dsa_sign(dsa_private_key, m_hash)
- The multiprecision integers sig_dsa_r and sig_dsa_s are the signature (see &nistfips186-2;).
-The signature formats are the same for all public key formats. All integers are stored in big-endian byte order.
-Base64 encoding of the signature_rsa multiprecision integer (without any header or length prefix).
-Base64 encoding of the following structure:
-The signature verification depends on the type of public key being used.
-The rsa_modulus and rsa_public_exponent multiprecision integers are extracted from the other entity's authenticated public key. The signature_rsa multiprecision integer is the signature received from the other entity.
-boolean = rsa_verify(signature_rsa, m_hash, hashOID, rsa_modulus, rsa_public_exponent)
- The dsa_p, dsa_q, dsa_g and dsa_y multiprecision integers are extracted from the other entity's authenticated public key. The sig_dsa_r and sig_dsa_s multiprecision integers are the signature received from the other entity.
-boolean = dsa_verify(sig_dsa_r, sig_dsa_s, m_hash, dsa_p, dsa_q, dsa_g, dsa_y)
- Before the signature or MAC of a block of XML is generated or verified, all character data between all elements MUST be removed and the XML MUST be converted to canonical form (see &w3canon;).
+All the XML this protocol requires to be signed or MACed is very simple, so in this case, canonicalization SHOULD only require the following changes:
+Implementations MAY conceivably also need to make the following changes. Note: Empty elements and special characters SHOULD NOT appear in the signed or MACed XML specified in this protocol.
+Alice and Bob MUST ensure that the value of e or d they provide when negotiating each online ESession is unique. This prevents complete online ESessions being replayed.
The trust system outlined in this document is based on Alice trusting that the public key presented by Bob is actually Bob's key (and vice versa). Determining this trust may be done in a variety of ways depending on the entities' support for different public key (certificate) formats, signing algorithms and signing authorities. For instance, if Bob publishes a PGP/GPG public key, Alice MAY verify that his key is signed by another key that she knows to be good. Or, if Bob provides an X.509 certificate, she MAY check that his key has been signed by a Certificate Authority that she trusts.
+The trust system outlined in this document is based on Alice trusting that the public key presented by Bob (wrapped in a <KeyValue/> element) is actually Bob's key (and vice versa). Determining this trust may be done in a variety of ways depending on the entities' support for different public key (certificate) formats, signing algorithms and signing authorities. For instance, if Bob publishes a PGP/GPG public key, Alice MAY verify that his key is signed by another key that she knows to be good. Or, if Bob provides an X.509 certificate, she MAY check that his key has been signed by a Certificate Authority that she trusts.
When trust cannot be achieved automatically, methods that are not transparent to the users may be employed. The out-of-band Short Authentication String mechanism described in this document is an easy way for people to do that. Alternatively, Bob could communicate the full SHA-256 fingerprint of his public key to Alice via secure out-of-band communication (e.g. face-to-face). This would enable Alice to confirm that the public key she receives in-band is valid. Note: Since very few people bother to (consistently) verify SAS or fingerprints, entities SHOULD protect against 'man-in-the-middle' attacks using retained secrets and/or other secrets.
Note: If no keys are acceptable to Alice (because Alice has never verified any of the keys, and because either the keys are not signed, or Alice does not support the signature algorithms of the keys, or she cannot parse the certificate formats, or she does not recognise the authorities that signed the keys) then, although the ESession can still be encrypted, she cannot be sure she is communicating with Bob.
Cryptography plays only a small part in an entity's security. Even if it implements this protocol perfectly it may still be vulnerable to other attacks. For examples, an implementation might store ESession keys on swap space or save private keys to a file in cleartext! Implementors MUST take very great care when developing applications with secure technologies.
An implementation of ESession MUST support the Diffie-Hellman Key Agreement and HMAC algorithms. Note: The parameter names mentioned below are related to secure shell; see SSH Transport Layer Encryption Modes for block cipher algorithm details; see the &ianassh; for other names.
-An implementation of ESession MUST support at least the following block cipher algorithm:
-The block length of an block cipher algorithm's cipher SHOULD be at least 128 bits. An implementation of ESession MAY also support the following block cipher algorithms:
-An implementation of ESession MUST support at least the following signing algorithm:
-An implementation of ESession SHOULD also support at least the following signing algorithm:
-An implementation of ESession MUST support the following public key formats:
-An implementation of ESession SHOULD also support at least the following public key formats:
-An implementation of ESession MAY also support the following public key formats:
-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):
-An implementation of ESession MUST support the following SAS generation algorithm:
-An implementation of ESession MUST support the following compression algorithm:
-Support for other algorithms is NOT RECOMMENDED since compression partially defeats the Repudiability requirement of this document by making it more difficult for a third party (with some knowledge of the plaintext) to modify a transcript of an encrypted session in a meaningful way. However, encrypted content is pseudo-random and cannot be compressed, so, in those cases where bandwidth is severely constrained, an implementation of ESession MAY support the following algorithms to compress content before it is encrypted:
-An implementation of ESession MUST support the Diffie-Hellman Key Agreement and HMAC algorithms. Note: Some of the parameter names mentioned below are related to secure shell; see SSH Transport Layer Encryption Modes for block cipher algorithm details; see the &ianassh; for some of the other names.
+An implementation of ESession MUST support the following block cipher algorithm:
+The block length of an block cipher algorithm's cipher SHOULD be at least 128 bits. An implementation of ESession MAY also support the following block cipher algorithms:
+An implementation of ESession MUST support the following signing algorithm:
+http://www.w3.org/2000/09/xmldsig#rsa-sha256
+(the same as http://www.w3.org/2000/09/xmldsig#rsa-sha1 except that it uses SHA256 instead of SHA1, see XML Signature)
An implementation of ESession SHOULD also support at least the following signing algorithm:
+http://www.w3.org/2000/09/xmldsig#dsa-sha256
+(the same as http://www.w3.org/2000/09/xmldsig#dsa-sha1 except that it uses SHA256 instead of SHA1, see XML Signature)
<KeyValue/> elements (as specified in XML Signature) may contain different public key formats. An implementation of ESession MUST support the following format:
+An implementation of ESession SHOULD also support the following public key format:
+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):
+An implementation of ESession MUST support the following SAS generation algorithm:
+An implementation of ESession MUST support the following compression algorithm:
+Support for other algorithms is NOT RECOMMENDED since compression partially defeats the Repudiability requirement of this document by making it more difficult for a third party (with some knowledge of the plaintext) to modify a transcript of an encrypted session in a meaningful way. However, encrypted content is pseudo-random and cannot be compressed, so, in those cases where bandwidth is severely constrained, an implementation of ESession MAY support the following algorithms to compress content before it is encrypted:
+