rfc2523.txt

<VC++网络游戏建摸与实现>源代码


RFC 2523                 Schemes and Attributes               March 1999


   by the UDP Length.


3.2.  DES-EDE3-CBC over Mask

   This is "Triple DES" outer-CBC EDE encryption (and DED decryption)
   with three 56-bit keys [KR96].

   As described in [RFC-2522] "Privacy-Key Computation", sufficient
   privacy-key material is generated to match the message length,
   beginning with the next field after the SPI, and including the
   Padding.  The message is masked by XOR with the privacy-key.

   Then, the Key-Generation-Function is iterated (at least) three times
   to generate the three DES keys.  The most significant 64-bits (8
   bytes) of each generated hash are used for each successive privacy-
   key, and the remainder are discarded.  Each key is examined
   sequentially, in the order used for encryption.  A key that is
   identical to a previous key MUST be discarded.  Although extremely
   rare, the 64 weak, semi-weak, and possibly weak keys [Schneier95,
   pages 280-282] MUST be discarded.  The Key-Generation-Function is
   iterated until a valid key is obtained before generating the next
   key.

   In all three keys, the least significant bit of each key byte is
   ignored (or set to parity when the implementation requires).

   The 64-bit CBC IV is zero.  Message encryption begins with the next
   field after the SPI, and continues to the end of the data indicated
   by the UDP Length.


4.  Additional Validity-Method
4.1.  SHA1-IPMAC Check

   As described in [RFC-2522] "Validity Verification", the Verification
   field value is the SHA1 [FIPS-180-1] hash over the concatenation of

      SHA1( key, keyfill, data, datafill, key, mdfill )

   where the key is the computed verification-key.

   The keyfill and datafill use the same pad-with-length technique
   defined for mdfill.  This padding and length is implicit, and does
   not appear in the datagram.

   The resulting Verification field is a 160-bit Variable Precision
   Integer (22 bytes including Size).  When used in calculations, the



Karn & Simpson                Experimental                      [Page 6]

RFC 2523                 Schemes and Attributes               March 1999


   Verification data includes both the Size and Value fields.


5.  Additional Attributes

   The attribute format and basic facilities are already defined for
   Photuris [RFC-2522].

   These optional attributes are specified separately, and no single
   implementation is expected to support all of them.

   This document defines the following values:

     Use    Type
     AEI      6  SHA1-IPMAC
     AEI      7  RIPEMD-160-IPMAC
      E       8  DES-CBC
      E       9  Invert (Decryption/Encryption)
      E      10  XOR

     A      AH Attribute-Choice
      E     ESP Attribute-Choice
       I    Identity-Choice
        X   dependent on list location



5.1.  SHA1-IPMAC

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Attribute   |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Attribute        6

   Length           0














Karn & Simpson                Experimental                      [Page 7]

RFC 2523                 Schemes and Attributes               March 1999


5.1.1.  Symmetric Identification

   When selected as an Identity-Choice, the immediately following
   Identification field contains an unstructured Variable Precision
   Integer.  Valid Identifications and symmetric secret-keys are
   preconfigured by the parties.

   There is no required format or content for the Identification value.
   The value may be a number or string of any kind.  See [RFC-2522] "Use
   of Identification and Secrets" for details.

   The symmetric secret-key (as specified) is selected based on the
   contents of the Identification field.  All implementations MUST
   support at least 62 bytes.  The selected symmetric secret-key SHOULD
   provide at least 80-bits of cryptographic strength.

   As described in [RFC-2522] "Identity Verification", the Verification
   field value is the SHA1 [FIPS-180-1] hash over the concatenation of:

      SHA1( key, keyfill, data, datafill, key, mdfill )

   where the key is the computed verification-key.

   The keyfill and datafill use the same pad-with-length technique
   defined for mdfill.  This padding and length is implicit, and does
   not appear in the datagram.

   The resulting Verification field is a 160-bit Variable Precision
   Integer (22 bytes including Size).  When used in calculations, the
   Verification data includes both the Size and Value fields.

   For both [RFC-2522] "Identity Verification" and "Validity
   Verification", the verification-key is the SHA1 [FIPS-180-1] hash of
   the following concatenated values:

    + the symmetric secret-key,
    + the computed shared-secret.

   For [RFC-2522] "Session-Key Computation", the symmetric secret-key is
   used directly as the generation-key.

   The symmetric secret-key is used in calculations in the same fashion
   as [RFC-2522] "MD5-IPMAC Symmetric Identification".








Karn & Simpson                Experimental                      [Page 8]

RFC 2523                 Schemes and Attributes               March 1999


5.1.2.  Authentication

   May be selected as an AH or ESP Attribute-Choice, pursuant to [RFC-
   1852] et sequitur.  The selected Exchange-Scheme SHOULD provide at
   least 80-bits of cryptographic strength.

   As described in [RFC-2522] "Session-Key Computation", the most
   significant 384-bits (48 bytes) of the Key-Generation-Function
   iterations are used for the key.

   Profile:

      When negotiated with Photuris, the transform differs slightly from
      [RFC-1852].

      The form of the authenticated message is:

         SHA1( key, keyfill, datagram, datafill, key, mdfill )

      where the key is the SPI session-key.

      The additional datafill protects against the attack described in
      [PO96].  The keyfill and datafill use the same pad-with-length
      technique defined for mdfill.  This padding and length is
      implicit, and does not appear in the datagram.


5.2.  RIPEMD-160-IPMAC

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Attribute   |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Attribute        7

   Length           0














Karn & Simpson                Experimental                      [Page 9]

RFC 2523                 Schemes and Attributes               March 1999


5.2.1.  Symmetric Identification

   When selected as an Identity-Choice, the immediately following
   Identification field contains an unstructured Variable Precision
   Integer.  Valid Identifications and symmetric secret-keys are
   preconfigured by the parties.

   There is no required format or content for the Identification value.
   The value may be a number or string of any kind.  See [RFC-2522] "Use
   of Identification and Secrets" for details.

   The symmetric secret-key (as specified) is selected based on the
   contents of the Identification field.  All implementations MUST
   support at least 62 bytes.  The selected symmetric secret-key SHOULD
   provide at least 80-bits of cryptographic strength.

   As described in [RFC-2522] "Identity Verification", the Verification
   field value is the RIPEMD-160 [DBP96] hash over the concatenation of:

      RIPEMD160( key, keyfill, data, datafill, key, mdfill )

   where the key is the computed verification-key.

   The keyfill and datafill use the same pad-with-length technique
   defined for mdfill.  This padding and length is implicit, and does
   not appear in the datagram.

   The resulting Verification field is a 160-bit Variable Precision
   Integer (22 bytes including Size).  When used in calculations, the
   Verification data includes both the Size and Value fields.

   For both [RFC-2522] "Identity Verification" and "Validity
   Verification", the verification-key is the RIPEMD-160 [DBP96] hash of
   the following concatenated values:

    + the symmetric secret-key,
    + the computed shared-secret.

   For [RFC-2522] "Session-Key Computation", the symmetric secret-key is
   used directly as the generation-key.

   The symmetric secret-key is used in calculations in the same fashion
   as [RFC-2522] "MD5-IPMAC Symmetric Identification".








Karn & Simpson                Experimental                     [Page 10]

RFC 2523                 Schemes and Attributes               March 1999


5.2.2.  Authentication

   May be selected as an AH or ESP Attribute-Choice.  The selected
   Exchange-Scheme SHOULD provide at least 80-bits of cryptographic
   strength.

   As described in [RFC-2522] "Session-Key Computation", the most
   significant 384-bits (48 bytes) of the Key-Generation-Function
   iterations are used for the key.

   Profile:

      When negotiated with Photuris, the form of the authenticated
      message is:

         RIPEMD160( key, keyfill, datagram, datafill, key, mdfill )

      where the key is the SPI session-key.

      The additional datafill protects against the attack described in
      [PO96].  The keyfill and datafill use the same pad-with-length
      technique defined for mdfill.  This padding and length is
      implicit, and does not appear in the datagram.


5.3.  DES-CBC

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Attribute   |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Attribute        8

   Length           0

   May be selected as an ESP Attribute-Choice, pursuant to [RFC-1829] et
   sequitur.  The selected Exchange-Scheme SHOULD provide at least 56-
   bits of cryptographic strength.

   As described in [RFC-2522] "Session-Key Computation", the most
   significant 64-bits (8 bytes) of the Key-Generation iteration are
   used for the key, and the remainder are discarded.  Although
   extremely rare, the 64 weak, semi-weak, and possibly weak keys
   [Schneier95, pages 280-282] MUST be discarded.  The Key-Generation-
   Function is iterated until a valid key is obtained.

   The least significant bit of each key byte is ignored (or set to



Karn & Simpson                Experimental                     [Page 11]

RFC 2523                 Schemes and Attributes               March 1999


   parity when the implementation requires).

   Profile:

      When negotiated with Photuris, the transform differs slightly from
      [RFC-1829].

      The 32-bit Security Parameters Index (SPI) field is followed by a
      32-bit Sequence Number (SN).

      The 64-bit CBC IV is generated from the 32-bit Security Parameters
      Index (SPI) field followed by (concatenated with) the 32-bit
      Sequence Number (SN) field.  Then, the bit-wise complement of the
      32-bit Sequence Number (SN) value is XOR'd with the first 32-bits
      (SPI):

         (SPI ^ -SN) || SN

      The Padding values begin with the value 1, and count up to the
      number of padding bytes.  For example, if the plaintext length is
      41, the padding values are 1, 2, 3, 4, 5, 6 and 7, plus any
      additional obscuring padding.

      The PadLength and PayloadType are not appended.  Instead, the
      PayloadType is indicated by the SPI, as specified by the ESP-
      Attributes attribute (#2).

      After decryption, if the padding bytes are not the correct
      sequential values, then the payload is discarded, and a
      "Decryption Failed" error is indicated, as described in [RFC-
      2521].


5.4.  Invert (Decryption/Encryption)

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Attribute   |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Attribute        9

   Length           0

   May be selected as an ESP Attribute-Choice, immediately preceding an
   encryption choice.  This indicates that the following attribute is
   inverted from encryption to decryption (or decryption to encryption)
   as the attributes are processed.



Karn & Simpson                Experimental                     [Page 12]

RFC 2523                 Schemes and Attributes               March 1999