From c8dd27322ebf4c7a7807ae917b12ba6ef3d06960 Mon Sep 17 00:00:00 2001 From: Ian Paterson Date: Mon, 27 Nov 2006 16:02:36 +0000 Subject: [PATCH] 0.13 RC2 removed signature and public key specs in favor of W3C XMLdsig git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@219 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0116.xml | 242 ++++++++++++++++++++------------------------------- 1 file changed, 95 insertions(+), 147 deletions(-) diff --git a/xep-0116.xml b/xep-0116.xml index f3762108..9559ee23 100644 --- a/xep-0116.xml +++ b/xep-0116.xml @@ -78,7 +78,7 @@ 0.13 2006-11-27 ip -

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

 0.12 @@ -228,7 +228,7 @@

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

    • -

  • 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) If the entity already possesses one of the other entity's public keys then it is RECOMMENDED that only the fingerprint is requested from the other entity - since this saves bandwidth., or 'none' (no identification). 'none' MUST NOT be specified with 3-message negotiation.

    • +

  • 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") If the entity already possesses one of the other entity's public keys then it is RECOMMENDED that only the fingerprint is requested from the other entity - since this saves bandwidth., or 'none' (no authentication via public keys). Note: 'none' MUST NOT be specified with 3-message negotiation.

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

      @@ -279,8 +279,8 @@ - - + + @@ -445,7 +445,7 @@ 5 aes256-ctr sha256 - rsa + http://www.w3.org/2000/09/xmldsig#rsa-sha256 none message hash @@ -492,14 +492,14 @@

      Bob MUST perform the following steps before he can prove his identity to Alice while protecting it from third parties.

        -

      1. 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").

        2. +

      2. 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").

      3. 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.

      4. 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;})
        5. -

      5. 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;

        +

      6. 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;)
        7. -

      7. 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;)
        8. +

      8. 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>'

      9. 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;)
        10. -

      10. 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.

        +

      11. 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'.

      12. Set the value of &formB; to be the Normalized content of the form she received from Bob without any 'identity' or 'mac' fields.

      13. 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;})

      14. 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;)
       @@ -750,63 +750,20 @@

      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:

      -
        -
      • Set attribute value delimiters to single quotation marks (i.e. simply replace all single quotes in the serialized XML with double quotes)
        • -
      • Impose lexicographic order on the attributes of "field" elements (i.e. ensure "type" is before "var")
        • -
      -

      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.

      -
        -
      • Ensure there are no character references
        • -
      • Convert empty elements to start-end tag pairs
        • -
      • Ensure there is no whitespace except for single spaces before attributes
        • -
      -       - -

      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:

      -
        -
      • number of bytes in sig_dsa_r (2-byte integer)
        • -
      • sig_dsa_r
        • -
      • number of bytes in sig_dsa_s (2-byte integer)
        • -
      • sig_dsa_s
        • -
      -       -       - -

      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:

      +
        +
      • Set attribute value delimiters to single quotation marks (i.e. simply replace all single quotes in the serialized XML with double quotes)
        • +
      • Impose lexicographic order on the attributes of "field" elements (i.e. ensure "type" is before "var")
        • +
      +

      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.

      +
        +
      • Ensure there are no character references
        • +
      • Convert empty elements to start-end tag pairs
        • +
      • Ensure there is no whitespace except for single spaces before attributes
        • +
      +       @@ -816,7 +773,7 @@

      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.

       @@ -839,82 +796,75 @@

      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:

      -
        -
      • aes128-ctr (see &nistfips197;)
        • -
      -

      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:

      -
        -
      • aes256-ctr
        • -
      • aes192-ctr
        • -
      • twofish256-ctr (see &twofish;)
        • -
      • twofish192-ctr
        • -
      • twofish128-ctr
        • -
      • serpent256-ctr (see &serpent;)
        • -
      • serpent192-ctr
        • -
      • serpent128-ctr
        • -
      • none (no encryption, only signing)
        • -
      -       - -

      An implementation of ESession MUST support at least the following signing algorithm:

      -
        -
      • rsa (see RFC 3447)
        • -
      -

      An implementation of ESession SHOULD also support at least the following signing algorithm:

      -
        -
      • dsa (see Digital Signature Standard)
        • -
      -       - -

      An implementation of ESession MUST support the following public key formats:

      -
        -
      • ssh-rsa
        • -
      -

      An implementation of ESession SHOULD also support at least the following public key formats:

      -
        -
      • ssh-dss
        • -
      • x509v3-sign-rsa (see &sshx509;)
        • -
      • x509v3-sign-dss
        • -
      • pgp-sign-rsa
        • -
      • pgp-sign-dss
        • -
      -

      An implementation of ESession MAY also support the following public key formats:

      -
        -
      • spki-sign-rsa
        • -
      • spki-sign-dss
        • -
      -       - -

      An implementation of ESession MUST support the following hash algorithm:

      -
        -
      • sha256 (see Secure Hash Standard)
        • -
      -

      An implementation of ESession SHOULD also support at least the following hash algorithm (sha1 and md5 are broken and therefore NOT RECOMMENDED):

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

      -
        -
      • none (no compression, the output MUST be the same as the input)
        • -
      -

      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:

      -
        -
      • lzw (see &ecma151;)
        • -
      • zlib (see &rfc1950;)
        • -
      -       +       + +

      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:

      +
        +
      • aes128-ctr (see &nistfips197;)
        • +
      +

      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:

      +
        +
      • aes256-ctr
        • +
      • aes192-ctr
        • +
      • twofish256-ctr (see &twofish;)
        • +
      • twofish192-ctr
        • +
      • twofish128-ctr
        • +
      • serpent256-ctr (see &serpent;)
        • +
      • serpent192-ctr
        • +
      • serpent128-ctr
        • +
      • none (no encryption, only signing)
        • +
      +       + +

      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:

      +
        +
      • <RSAKeyValue/>
        • +
      +

      An implementation of ESession SHOULD also support the following public key format:

      +
        +
      • <DSAKeyValue/>
        • +
      +       + +

      An implementation of ESession MUST support the following hash algorithm:

      +
        +
      • sha256 (see Secure Hash Standard)
        • +
      +

      An implementation of ESession SHOULD also support at least the following hash algorithm (sha1 and md5 are broken and therefore NOT RECOMMENDED):

      +
        +
      • 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:

      +
        +
      • none (no compression, the output MUST be the same as the input)
        • +
      +

      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:

      +
        +
      • lzw (see &ecma151;)
        • +
      • zlib (see &rfc1950;)
        • +
      @@ -1065,7 +1015,6 @@
        -
      1. Standardise on the X.509 public key and signature formats?
      2. What challenges exist to make the OTR Gaim Plugin use this protocol natively when talking to XMPP entities? Can these be mitigated by 'non-critical' protocol changes?
      3. Would anything in this protocol (e.g., its dependency on in-order stanza delivery) prevent an XMPP entity using it to exchange encrypted messages and presence with a user of a non-XMPP messaging system, assuming that the gateway both supports this protocol and is compatible with a purpose-built security plugin on the other user's client (e.g. a Gaim plugin connects to the gateway via a non-XMPP network)?
      4. Could use &xep0013; (FOMR) instead of AMP to prevent any offline ESessions Bob can't decrypt being delivered to him. (Each <item/> that corresponds to an ESession message would have to contain a <ESessionID/> child, to allow Bob to discover which of his stored values of y was used to encrypt the message.)
        5. @@ -1074,7 +1023,6 @@
        1. Ask the authors of AMP to explain how to achieve the match_resource functionality specified in XEP-0187.
          2. -
        2. Define names for X.509 SubjectPublicKeyInfo public key formats (different to X.509 certificates). This format must be used when keys are distributed within session negotiation.
        3. Add non-repudiable signing option
        4. Perhaps the document needs to specify more carefully how block counters are handled between messages, especially in the event of partial blocks?
        5. Give examples of specific errors and discuss error scenarios throughout document (e.g., what should Bob do if he is not offline and he receives an offline key exchange stanza?).