From f1aa5b6c5107a39bea04ef3fa462dd6087715007 Mon Sep 17 00:00:00 2001 From: Ian Paterson Date: Mon, 27 Nov 2006 01:58:01 +0000 Subject: [PATCH] 0.13 RC1 synchronised with XEP-0188 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@213 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0116.xml | 128 ++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 106 insertions(+), 22 deletions(-) diff --git a/xep-0116.xml b/xep-0116.xml index e4cc23f3..f3762108 100644 --- a/xep-0116.xml +++ b/xep-0116.xml @@ -76,9 +76,9 @@ &dizzyd; 0.13 - 2006-11-23 + 2006-11-27 ip -

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; moved exchanging stanzas and rekeying sections to XEP-0200; changed namespace

 0.12 @@ -206,8 +206,8 @@

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:

+

The 3-message SIGMA-I-based key exchange (see useful summary of 3-message negotiation) 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 (see useful summary of 4-message negotiation) 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).

    @@ -224,6 +224,7 @@

  • Hash algorithm names

  • Signature algorithm names

  • Compression algorithm names

    • +

  • Short Authentication String generation algorithm names

  • The list of stanza types that MAY be encrypted and decrypted

  • The different versions of this protocol that are supported This version of this document describes version 1.0 of this protocol.

  • 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)

    • @@ -305,6 +306,9 @@ ** Alice's Base64 encoded ESession ID ** + + + ** Base64 encoded value of He5 ** ** Base64 encoded value of He14 ** @@ -317,7 +321,7 @@ ]]> -

    The first message of a 3-message negotiation is identical except the a 'dhkeys' field is included instead of the 'dhhashes' field:

    +

    The first message of a 3-message negotiation is identical except there MUST be no 'sas_algs' field and a 'dhkeys' field MUST be included instead of the 'dhhashes' field:

    ffd7076498744578d10edabfe7f4a866 @@ -416,7 +420,7 @@

  • Set &CBeCAx2n1; (where &CsubB; is the block counter for stanzas sent from Bob to Alice)

  • Generate a secret random number y (where &twosup2n; < y < p - 1)

  • Calculate d = &gsupy; mod p

    • -

  • Calculate K = HASH(&esupy; mod p) (the shared secret)

    • +

  • Calculate K = HASH(&esupy; mod p) (the Diffie-Hellman shared secret)

    • If this is a 4-message negotiation Bob MUST skip the last step above.

    @@ -450,6 +454,7 @@ ** Bob's Base64 encoded ESession ID ** + sas28x5 ** Base64 encoded value of d ** @@ -480,7 +485,7 @@

  • Integrity key &KMsubB; = HMAC(HASH, K, "Responder MAC Key")

  • SIGMA key &KSsubB; = HMAC(HASH, K, "Responder SIGMA Key")

    • -

    Once the sets of keys have been calculated the value of K MUST be securely destroyed.

    +

    Once the sets of keys have been calculated the value of K MUST be securely destroyed, unless it will be used later to generate the final shared secret (see Generating Bob's Final Session Keys or Generating Alice's Final Session Keys).

    Note: As many bits of key data as are needed for each key MUST be taken from the least significant bits of the HMAC output. When negotiating a hash, entities MUST ensure that the hash output is no shorter than the required key data. For algorithms with variable-length keys the maximum length (up to the hash output length) SHOULD be used.

    @@ -517,6 +522,15 @@ ... ... ... + + ** Bob's Base64 encoded ESession ID ** + + + ** Base64 encoded value of d ** + + + ** Alice's Base64 encoded ESession ID ** + ** Base64 encoded block counter ** @@ -549,7 +563,7 @@

    If this is a 4-message negotiation then Alice MUST skip the next section and proceed by executing the steps in the Hiding Alice's Identity section.

    -

    If Bob included 'identity' and 'mac' fields in his response then Alice MUST also perform the following steps:

    +

    If this is a 3-message negotiation then Alice MUST also perform the following steps:

    1. Calculate the HMAC of the encrypted identity (&IDB;) and the value of Bob's block cipher counter using HASH and the integrity key &KMsubB;.

      &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
      2. @@ -571,7 +585,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 Bob's Identity for a more detailed description). Alice's calculations are summarised below. Note: When calculating &macA; pay attention to the order of &NsubB; and &NsubA; and to the inclusion of &formA2;.

      -

      Note: &formA; is the full Normalized content of the ESession Request data form that Alice sent to Bob at the start of the negotiation, while &formA2; is the full Normalized content of Alice's session negotiation completion form excluding the 'identity' or 'mac' fields (see Sending Alice's Identity below).

      +

      Note: &formA; is the full Normalized content of the ESession Request data form that Alice sent to Bob at the start of the negotiation, while &formA2; is the full Normalized content of Alice's session negotiation completion form excluding the 'identity' and 'mac' fields (see Sending Alice's Identity below).

      &macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;, &formA2;}) &signA; = SIGN(&signKeyA;, &macA;) if (pubkey == 'hash') &pubKeyA; = HASH(&pubKeyA;) @@ -601,7 +615,7 @@ ]]>

      Note: If Alice also includes a 'terminate' field with its value set to "1" or "true" (see ESession Termination) within the form then the ESession is terminated immediately. Note: This special case, where a single stanza is encrypted and sent in isolation, is equivalent to object encryption (or object signing if no encryption is specified) and offers several significant advantages over non-session approaches - including perfect forward secrecy.

      -

      In the case of a 4-message negotiation Alice MUST also include in the data form her Base64 encoded values of e (wrapped in a 'dhkeys' field) and the Base64 encoded HMAC (using HASH and the key &NsubA; The HMACs of the retained secrets are generated using Alice's unique session nonce to prevent her being identified by her retained secrets (only one secret changes each session, and some might not change very often).) of each secret that Alice has retained from her previous session with each of Bob's clients (wrapped in a 'rshashes' field) - see XXXXXXXXXX. Note: Alice MUST also append a few random numbers to the 'rshashes' field to make it difficult for an active attacker to discover if she has communicated with Bob before or how many clients Bob has used to communicate with her.

      +

      In the case of a 4-message negotiation Alice MUST also include in the data form her Base64 encoded values of e (wrapped in a 'dhkeys' field) and the Base64 encoded HMAC (using HASH and the key &NsubA; The HMACs of the retained secrets are generated using Alice's unique session nonce to prevent her being identified by her retained secrets (only one secret changes each session, and some might not change very often).) of each secret that Alice has retained from her previous session with each of Bob's clients (wrapped in a 'rshashes' field) - see Sending Bob's Identity. Note: Alice MUST also append a few random numbers to the 'rshashes' field to make it difficult for an active attacker to discover if she has communicated with Bob before or how many clients Bob has used to communicate with her.

      ffd7076498744578d10edabfe7f4a866 @@ -632,29 +646,80 @@       - -

      After receiving Alice's identity Bob MUST verify it by performing steps equivalent to those described in the section Verifying Bob's Identity above. Some of Bob'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 (the first form) that Alice sent him. Note: If Bob sends an error to Alice then he SHOULD ignore any encrypted content he received in the stanza.

      - &MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;) - {&pubKeyA;, &signA;} = DECIPHER(&KCsubA;, &CsubA;, &IDA;) - &macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;}) - VERIFY(&signA;, &pubKeyA;, &macA;) -

      If Alice has already confirmed Bob's identity (i.e. if Bob included 'identity' and 'mac' fields in his response above), then the ESession negotiation is complete.

      -

      Otherwise, one more step is necessary. Bob MUST send Alice the Base64 encoded values of &NsubA;, &IDB; and &MsubB; that he calculated previously (see Hiding Bob's Identity). Note: He MAY also send encrypted content (see Stanza Encryption) in the same stanza.

      - + +

      In the case of a 4-message negotiation Bob MUST perform the following four steps:

      +
        +

      1. Return a &feature; error unless SHA256(e) equals 'He', the value he received from Alice in her original session request.

        2. +

      2. Return a &feature; error unless: 1 < e < p - 1

        3. +

      3. Use the value of e he received from Alice, his secret value of y and their agreed value of p to calculate the value of the Diffie-Hellman shared secret: K = HASH(&esupy; mod p)

        4. +

      4. Generate Alice's session keys (&KCsubA;, &KMsubA;, &KSsubA;) in exactly the same way as specified for 3-message negotiations in the Generating Session Keys section.

        5. +
      +

      After receiving Alice's identity Bob MUST verify it by performing steps equivalent to those performed by Alice above (see Verifying Bob's Identity for a more detailed description). Some of Bob's calculations are summarised below. Note: When calculating &macA; pay attention to the order of &NsubB; and &NsubA; and to the inclusion of &formA2;.

      +

      Note: &formA; is the full Normalized content of the ESession Request data form that Alice sent to Bob at the start of the negotiation, while &formA2; is the full Normalized content of Alice's session negotiation completion form excluding the 'identity' and 'mac' fields (see Sending Alice's Identity).

      +

      Note: If Bob sends an error to Alice then he SHOULD ignore any encrypted content he received in the stanza.

      + &MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;) + &macA; = DECIPHER(&KCsubA;, &CsubA;, &IDA;) OR {&pubKeyA;, &signA;} = DECIPHER(&KCsubA;, &CsubA;, &IDA;) + &macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;, &formA2;}) + VERIFY(&signA;, &pubKeyA;, &macA;) +

      In the case of a 3-message negotiation, the ESession negotiation is now complete.

      +       + + +

      Note: The steps in this and all the following Online ESession Negotiation sections are only necessary for 4-message negotiations.

      +

      Bob and Alice MAY confirm out-of-band that the Short Authentication Strings (SAS) their clients generate for them (using the SAS generation algorithm that they agreed on) are the same. This out-of-band step MAY be performed at any time. However, if either Bob or Alice has not provided a public key, or if either of their public keys has never been authenticated by the other party, then they SHOULD confirm out-of-band that their SAS match as soon as they realise that the two clients have no retained secret in common (see Generating Bob's Final Session Keys below, or Generating Alice's Final Session Keys).

      +       + + +

      Bob MUST identify the shared retained secret (SRS) by selecting from his client's list of the secrets it retained from sessions with Alice's clients (the most recent secret for each of the clients she has used to negotiate ESessions with Bob's client).

      +

      Bob does this by calculating the HMAC (using HASH and the key &NsubA;) of each secret in the list in turn and comparing it with each of the values in the 'rshashes' field he received from Alice (see Sending Alice's Identity). Once he finds a match, and has confirmed that the secret has not expired (because it is older than an implementation-defined period of time), then he has found the SRS.

      +

      Bob MUST calculate the final session key by appending to K (the Diffie-Hellman shared secret) the SRS (only if one was found) and then the Other Shared Secret (only if one exists) and then setting K to be the HASH result of the concatenated string of bytes:

      + K = HASH(K | SRS | OSS) +

      Bob MUST now use the new value of K to generate the new session keys (&KCsubA;, &KMsubA;, &KCsubB;, &KMsubB; and &KSsubB;) in exactly the same way as he does for 3-message negotiations (see Generating Session Keys). These keys will be used to exchange encrypted stanzas. Note: Bob will still need the value of K in the next section.

      +       + + +

      Bob MUST now prove his identity to Alice while protecting it from third parties. He does this in the same way as he does for 3-message negotiations (see Hiding Bob's Identity for a more detailed description) except that, when calculating &macA;, he MUST include &formB2;:

      + &macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;, &formB2;}) +

      Note: &formB2; is the full Normalized content of Bob's session negotiation completion form excluding the 'identity' and 'mac' fields (see below).

      +

      Bob MUST send Alice the Base64 encoded value of the HMAC (using HASH and the key SRS) of the string "Shared Retained Secret" (wrapped in an 'srshash' field). If no SRS was found then he MUST use a random number instead. Bob always sends a value in the 'srshash' field to prevent an attacker learning that the session is not protected by a retained secret.

      + HMAC(HASH, SRS, "Shared Retained Secret") +

      Bob MUST also include in the data form the Base64 encoded values of &NsubA;, and &IDB; and &MsubB; (that he just calculated). Note: He MAY also send encrypted content (see Stanza Encryption) in the same stanza.

      + ffd7076498744578d10edabfe7f4a866 urn:xmpp:chatneg ** Alice's Base64 encoded ESession ID ** + ** HMAC with shared retained secret ** ** Encrypted identity ** ** Integrity of identity ** - ]]> -

      After receiving Bob's identity Alice MUST verify it by performing steps described in the section Verifying Bob's Identity above. Note: If Alice sends an error to Bob then she SHOULD ignore any encrypted content she received in the stanza.

      -

      Once ESession negotiation is complete, Alice and Bob MUST exchange only encrypted forms of the one-to-one stanza types they agreed upon (e.g., &MESSAGE; and &IQ; stanzas).

      + ]]>       +

      Finally, Bob MUST destroy all his copies of SRS (the retained secret he was keeping for Alice's client), calculate a new retained secret for this session (see below) and securely store the new value along with the other retained secrets his client shares with Alice's clients:

      + HMAC(HASH, K, "New Retained Secret") +

      Bob's value of K MUST now be securely destroyed.

      + +       + + + +

      Alice MUST identify the shared retained secret (SRS) by selecting from her client's list of the secrets it retained from sessions with Bob's clients (the most recent secret for each of the clients he has used to negotiate ESessions with Alice's client).

      +

      Alice does this by using each secret in the list in turn as the key to calculate the HMAC (with HASH) of the string "Shared Retained Secret", and comparing the calculated value with the value in the 'srshash' field she received from Bob (see Sending Bob's Identity). Once she finds a match, and has confirmed that the secret has not expired (because it is older than an implementation-defined period of time), then she has found the SRS.

      +

      Alice MUST calculate the final session key by appending to K (the Diffie-Hellman shared secret) the SRS (only if one was found) and then the Other Shared Secret (only if one exists) and then setting K to be the HASH result of the concatenated string of bytes:

      + K = HASH(K | SRS | OSS) +

      Alice MUST destroy all her copies of SRS (the retained secret she was keeping for Bob's client), calculate a new retained secret for this session (see below) and securely store the new value along with the other retained secrets her client shares with Bob's clients:

      + HMAC(HASH, K, "New Retained Secret") +

      Alice MUST now use the new value of K to generate the new session keys (&KCsubA;, &KMsubA;, &KCsubB;, &KMsubB; and &KSsubB;) in exactly the same way as Bob did (see Generating Session Keys). These keys will be used to exchange encrypted stanzas.

      +       + + +

      Finally, Alice MUST verify the identity she received from Bob. She does this in the same way as she does for 3-message negotiations Verifying Bob's Identity above. Note: If Alice discovers an error then she SHOULD ignore any encrypted content she received in the stanza.

      +

      Once ESession negotiation is complete, Alice and Bob MUST exchange only encrypted forms of the one-to-one stanza types they agreed upon (e.g., &MESSAGE; and &IQ; stanzas) within the session.

      +       @@ -833,6 +898,12 @@
    2. whirlpool (see &whirlpool;)
+ +

An implementation of ESession MUST support the following SAS generation algorithm:

+
    +
  • sas28x5 (see The sas28x5 SAS Algorithm)
    • +
+

An implementation of ESession MUST support the following compression algorithm:

    @@ -847,6 +918,15 @@ + +

    Given the multi-precision integers e and d (each a big-endian byte array) and the hash function "HASH", the following steps can be used to calculate a 5-character SAS with over 16 million possible values that is easy to read and communicate verbally:

    +
      +

    1. Concatenate e, d and the string "Short Authentication String" into a string of bytes

      2. +

    2. Calculate the least significant 24-bits of the HASH of the string

      3. +

    3. Convert the 24-bit integer into a base-28 Base-28 was used instead of Base-36 because some characters are often confused when communicated verbally (n, s, b, t, z, j), and because zero is often read as the letter 'o', and the letter 'l' is often read as the number '1'. 5-character string using the following digits (values 0-27): acdefghikmopqruvwxy123456789

      4. +
    +     +

    This document requires no interaction with &IANA;.

    @@ -932,6 +1012,10 @@ var='rshashes' type='hidden' label='Hashes of retained secrets'/> +