rfc2412.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   The symbol vertical bar "|" is used to denote concatenation of bit
   strings.  Fields are concatenated using their encoded form as they
   appear in their payload.

   Ni and Nr are nonces selected by the initiator and responder,
   respectively.

   ID(I) and ID(R) are the identities to be used in authenticating the
   initiator and responder respectively.

   E{x}Ki indicates the encryption of x using the public key of the
   initiator.  Encryption is done using the algorithm associated with
   the authentication method; usually this will be RSA.

   S{x}Ki indicates the signature over x using the private key (signing
   key) of the initiator.  Signing is done using the algorithm
   associated with the authentication method; usually this will be RSA
   or DSS.

   prf(a, b) denotes the result of applying pseudo-random function "a"
   to data "b".  One may think of "a" as a key or as a value that
   characterizes the function prf; in the latter case it is the index
   into a family of functions.  Each function in the family provides a
   "hash" or one-way mixing of the input.

   prf(0, b) denotes the application of a one-way function to data "b".



Orman                        Informational                      [Page 6]

RFC 2412         The OAKLEY Key Determination Protocol     November 1998


   The similarity with the previous notation is deliberate and indicates
   that a single algorithm, e.g. MD5, might will used for both purposes.
   In the first case a "keyed" MD5 transform would be used with key "a";
   in the second case the transform would have the fixed key value zero,
   resulting in a one-way function.

   The term "transform" is used to refer to functions defined in
   auxiliary RFC's.  The transform RFC's will be drawn from those
   defined for IPSEC AH and ESP (see RFC 2401 for the overall
   architecture encompassing these protocols).

2.3 The Key Exchange Message Overview

   The goal of key exchange processing is the secure establishment of
   common keying information state in the two parties.  This state
   information is a key name, secret keying material, the identification
   of the two parties, and three algorithms for use during
   authentication: encryption (for privacy of the identities of the two
   parties), hashing (a pseudorandom function for protecting the
   integrity of the messages and for authenticating message fields), and
   authentication (the algorithm on which the mutual authentication of
   the two parties is based).  The encodings and meanings for these
   choices are presented in Appendix B.

   The main mode exchange has five optional features: stateless cookie
   exchange, perfect forward secrecy for the keying material, secrecy
   for the identities, perfect forward secrecy for identity secrecy, use
   of signatures (for non-repudiation).  The two parties can use any
   combination of these features.

   The general outline of processing is that the Initiator of the
   exchange begins by specifying as much information as he wishes in his
   first message.  The Responder replies, supplying as much information
   as he wishes.  The two sides exchange messages, supplying more
   information each time, until their requirements are satisfied.

   The choice of how much information to include in each message depends
   on which options are desirable.  For example, if stateless cookies
   are not a requirement, and identity secrecy and perfect forward
   secrecy for the keying material are not requirements, and if non-
   repudiatable signatures are acceptable, then the exchange can be
   completed in three messages.

   Additional features may increase the number of roundtrips needed for
   the keying material determination.

   ISAKMP provides fields for specifying the security association
   parameters for use with the AH and ESP protocols.  These security



Orman                        Informational                      [Page 7]

RFC 2412         The OAKLEY Key Determination Protocol     November 1998


   association payload types are specified in the ISAKMP memo; the
   payload types can be protected with OAKLEY keying material and
   algorithms, but this document does not discuss their use.

2.3.1 The Essential Key Exchange Message Fields

   There are 12 fields in an OAKLEY key exchange message.  Not all the
   fields are relevant in every message; if a field is not relevant it
   can have a null value or not be present (no payload).

      CKY-I            originator cookie.
      CKY-R            responder cookie.
      MSGTYPE          for key exchange, will be ISA_KE&AUTH_REQ or
                       ISA_KE&AUTH_REP; for new group definitions,
                       will be ISA_NEW_GROUP_REQ or ISA_NEW_GROUP_REP
      GRP              the name of the Diffie-Hellman group used for
                       the exchange
      g^x (or g^y)     variable length integer representing a power of
                       group generator
      EHAO or EHAS     encryption, hash, authentication functions,
                       offered and selectedj, respectively
      IDP              an indicator as to whether or not encryption with
                       g^xy follows (perfect forward secrecy for ID's)
      ID(I)            the identity for the Initiator
      ID(R)            the identity for the Responder
      Ni               nonce supplied by the Initiator
      Nr               nonce supplied by the Responder

   The construction of the cookies is implementation dependent.  Phil
   Karn has recommended making them the result of a one-way function
   applied to a secret value (changed periodically), the local and
   remote IP address, and the local and remote UDP port.  In this way,
   the cookies remain stateless and expire periodically.  Note that with
   OAKLEY, this would cause the KEYID's derived from the secret value to
   also expire, necessitating the removal of any state information
   associated with it.

   In order to support pre-distributed keys, we recommend that
   implementations reserve some portion of their cookie space to
   permanent keys.  The encoding of these depends only on the local
   implementation.

   The encryption functions used with OAKLEY must be cryptographic
   transforms which guarantee privacy and integrity for the message
   data.  Merely using DES in CBC mode is not permissible.  The
   MANDATORY and OPTIONAL transforms will include any that satisfy this
   criteria and are defined for use with RFC 2406 (ESP).




Orman                        Informational                      [Page 8]

RFC 2412         The OAKLEY Key Determination Protocol     November 1998


   The one-way (hash) functions used with OAKLEY must be cryptographic
   transforms which can be used as either keyed hash (pseudo-random) or
   non-keyed transforms.  The MANDATORY and OPTIONAL transforms will
   include any that are defined for use with RFC 2406 (AH).

   Where nonces are indicated, they will be variable precision integers
   with an entropy value that matches the "strength" attribute of the
   GRP used with the exchange.  If no GRP is indicated, the nonces must
   be at least 90 bits long.  The pseudo-random generator for the nonce
   material should start with initial data that has at least 90 bits of
   entropy; see RFC 1750.

2.3.1.1 Exponent Advice

   Ideally, the exponents will have at least 180 bits of entropy for
   every key exchange.  This ensures complete independence of keying
   material between two exchanges (note that this applies if only one of
   the parties chooses a random exponent).  In practice, implementors
   may wish to base several key exchanges on a single base value with
   180 bits of entropy and use one-way hash functions to guarantee that
   exposure of one key will not compromise others.  In this case, a good
   recommendation is to keep the base values for nonces and cookies
   separate from the base value for exponents, and to replace the base
   value with a full 180 bits of entropy as frequently as possible.

   The values 0 and p-1 should not be used as exponent values;
   implementors should be sure to check for these values, and they
   should also refuse to accept the values 1 and p-1 from remote parties
   (where p is the prime used to define a modular exponentiation group).

2.3.2 Mapping to ISAKMP Message Structures

   All the OAKLEY message fields correspond to ISAKMP message payloads
   or payload components.  The relevant payload fields are the SA
   payload, the AUTH payload, the Certificate Payload, the Key Exchange
   Payload.  The ISAKMP protocol framwork is a work in progress at this
   time, and the exact mapping of Oakley message fields to ISAKMP
   payloads is also in progress (to be known as the Resolution
   document).

   Some of the ISAKMP header and payload fields will have constant
   values when used with OAKLEY.  The exact values to be used will be
   published in a Domain of Interpretation document accompanying the
   Resolution document.

   In the following we indicate where each OAKLEY field appears in the
   ISAKMP message structure.  These are recommended only; the Resolution
   document will be the final authority on this mapping.



Orman                        Informational                      [Page 9]

RFC 2412         The OAKLEY Key Determination Protocol     November 1998


      CKY-I            ISAKMP header
      CKY-R            ISAKMP header
      MSGTYPE          Message Type in ISAKMP header
      GRP              SA payload, Proposal section
      g^x (or g^y)     Key Exchange Payload, encoded as a variable
                       precision integer
      EHAO and EHAS    SA payload, Proposal section
      IDP              A bit in the RESERVED field in the AUTH header
      ID(I)            AUTH payload, Identity field
      ID(R)            AUTH payload, Identity field
      Ni               AUTH payload, Nonce Field
      Nr               AUTH payload, Nonce Field
      S{...}Kx         AUTH payload, Data Field
      prf{K,...}       AUTH payload, Data Field

2.4 The Key Exchange Protocol

   The exact number and content of messages exchanged during an OAKLEY
   key exchange depends on which options the Initiator and Responder
   want to use.  A key exchange can be completed with three or more
   messages, depending on those options.

   The three components of the key determination protocol are the

      1. cookie exchange (optionally stateless)
      2. Diffie-Hellman half-key exchange (optional, but essential for
         perfect forward secrecy)
      3. authentication (options: privacy for ID's, privacy for ID's
         with PFS, non-repudiatable)

   The initiator can supply as little information as a bare exchange
   request, carrying no additional information.  On the other hand the
   initiator can begin by supplying all of the information necessary for
   the responder to authenticate the request and complete the key
   determination quickly, if the responder chooses to accept this
   method.  If not, the responder can reply with a minimal amount of
   information (at the minimum, a cookie).

   The method of authentication can be digital signatures, public key
   encryption, or an out-of-band symmetric key.  The three different
   methods lead to slight variations in the messages, and the variations
   are illustrated by examples in this section.

   The Initiator is responsible for retransmitting messages if the
   protocol does not terminate in a timely fashion.  The Responder must
   therefore avoid discarding reply information until it is acknowledged
   by Initiator in the course of continuing the protocol.




Orman                        Informational                     [Page 10]

RFC 2412         The OAKLEY Key Determination Protocol     November 1998


   The remainder of this section contains examples demonstrating how to
   use OAKLEY options.

2.4.1 An Aggressive Example

   The following example indicates how two parties can complete a key
   exchange in three messages.  The identities are not secret, the
   derived keying material is protected by PFS.

   By using digital signatures, the two parties will have a proof of
   communication that can be recorded and presented later to a third
   party.

   The keying material implied by the group exponentials is not needed
   for completing the exchange.  If it is desirable to defer the
   computation, the implementation can save the "x" and "g^y" values and
   mark the keying material as "uncomputed".  It can be computed from
   this information later.

   Initiator                                                   Responder
   ---------                                                   ---------
     -> CKY-I, 0,     OK_KEYX, GRP, g^x, EHAO, NIDP,               ->
        ID(I), ID(R), Ni, 0,
        S{ID(I) | ID(R) | Ni | 0 | GRP | g^x | 0 | EHAO}Ki
    <-  CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP,
        ID(R), ID(I), Nr, Ni,
        S{ID(R) | ID(I) | Nr | Ni | GRP | g^y | g^x | EHAS}Kr      <-
     -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAS, NIDP,               ->
        ID(I), ID(R), Ni, Nr,
        S{ID(I) | ID(R) | Ni | Nr | GRP | g^x | g^y | EHAS}Ki

   NB "NIDP" means that the PFS option for hiding identities is not used.
      i.e., the identities are not encrypted using a key based on g^xy

   NB Fields are shown separated by commas in this document; they are
   concatenated in the actual protocol messages using their encoded
   forms as specified in the ISAKMP/Oakley Resolution document.

   The result of this exchange is a key with KEYID = CKY-I|CKY-R and
   value

   sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R).

   The processing outline for this exchange is as follows: