rfc2412.txt

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

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


   Initiation

      The Initiator generates a unique cookie and associates it with the
      expected IP address of the responder, and its chosen state
      information: GRP (the group identifier), a pseudo-randomly
      selected exponent x, g^x, EHAO list, nonce, identities.  The first
      authentication choice in the EHAO list is an algorithm that
      supports digital signatures, and this is used to sign the ID's and
      the nonce and group id.  The Initiator further

      notes that the key is in the initial state of "unauthenticated",
      and

      sets a timer for possible retransmission and/or termination of the
      request.

   When the Responder receives the message, he may choose to ignore all
   the information and treat it as merely a request for a cookie,
   creating no state.  If CKY-I is not already in use by the source
   address in the IP header, the responder generates a unique cookie,
   CKY-R.  The next steps depend on the Responder's preferences.  The
   minimal required response is to reply with the first cookie field set
   to zero and CKY-R in the second field.  For this example we will
   assume that the responder is more aggressive (for the alternatives,
   see section 6) and accepts the following:

      group with identifier GRP,
      first authentication choice (which must be the digital signature
      method used to sign the Initiator message),
      lack of perfect forward secrecy for protecting the identities,
      identity ID(I) and identity ID(R)

   In this example the Responder decides to accept all the information
   offered by the initiator.  It validates the signature over the signed
   portion of the message, and associate the pair (CKY-I, CKY-R) with
   the following state information:

      the source and destination network addresses of the message

      key state of "unauthenticated"

      the first algorithm from the authentication offer

      group GRP, a "y" exponent value in group GRP, and g^x from the
      message

      the nonce Ni and a pseudorandomly selected value Nr




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


      a timer for possible destruction of the state.

   The Responder computes g^y, forms the reply message, and then signs
   the ID and nonce information with the private key of ID(R) and sends
   it to the Initiator.  In all exchanges, each party should make sure
   that he neither offers nor accepts 1 or g^(p-1) as an exponential.

   In this example, to expedite the protocol, the Responder implicitly
   accepts the first algorithm in the Authentication class of the EHAO
   list.  This because he cannot validate the Initiator signature
   without accepting the algorithm for doing the signature.  The
   Responder's EHAS list will also reflect his acceptance.

   The Initiator receives the reply message and
      validates that CKY-I is a valid association for the network
      address of the incoming message,

      adds the CKY-R value to the state for the pair (CKY-I, network
      address), and associates all state information with the pair
      (CKY-I, CKY-R),

      validates the signature of the responder over the state
      information (should validation fail, the message is discarded)

      adds g^y to its state information,

      saves the EHA selections in the state,

      optionally computes (g^y)^x (= g^xy) (this can be deferred until
      after sending the reply message),

      sends the reply message, signed with the public key of ID(I),

      marks the KEYID (CKY-I|CKY-R) as authenticated,

      and composes the reply message and signature.

   When the Responder receives the Initiator message, and if the
   signature is valid, it marks the key as being in the authenticated
   state.  It should compute g^xy and associate it with the KEYID.

   Note that although PFS for identity protection is not used, PFS for
   the derived keying material is still present because the Diffie-
   Hellman half-keys g^x and g^y are exchanged.

   Even if the Responder only accepts some of the Initiator information,
   the Initiator will consider the protocol to be progressing.  The
   Initiator should assume that fields that were not accepted by the



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


   Responder were not recorded by the Responder.

   If the Responder does not accept the aggressive exchange and selects
   another algorithm for the A function, then the protocol will not
   continue using the signature algorithm or the signature value from
   the first message.

2.4.1.1 Fields Not Present

   If the Responder does not accept all the fields offered by the
   Initiator, he should include null values for those fields in his
   response.  Section 6 has guidelines on how to select fields in a
   "left-to-right" manner.  If a field is not accepted, then it and all
   following fields must have null values.

   The Responder should not record any information that it does not
   accept.  If the ID's and nonces have null values, there will not be a
   signature over these null values.

2.4.1.2 Signature via Pseudo-Random Functions

   The aggressive example is written to suggest that public key
   technology is used for the signatures.  However, a pseudorandom
   function can be used, if the parties have previously agreed to such a
   scheme and have a shared key.

   If the first proposal in the EHAO list is an "existing key" method,
   then the KEYID named in that proposal will supply the keying material
   for the "signature" which is computed using the "H" algorithm
   associated with the KEYID.

   Suppose the first proposal in EHAO is
      EXISTING-KEY, 32
   and the "H" algorithm for KEYID 32 is MD5-HMAC, by prior negotiation.
   The keying material is some string of bits, call it sK32.  Then in
   the first message in the aggressive exchange, where the signature

           S{ID(I), ID(R), Ni, 0, GRP, g^x, EHAO}Ki

   is indicated, the signature computation would be performed by
       MD5-HMAC_func(KEY=sK32, DATA = ID(I) | ID(R) | Ni | 0 | GRP | g^x
      | g^y | EHAO) (The exact definition of the algorithm corresponding
   to "MD5-HMAC- func" will appear in the RFC defining that transform).

   The result of this computation appears in the Authentication payload.






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


2.4.2 An Aggressive Example With Hidden Identities

   The following example indicates how two parties can complete a key
   exchange without using digital signatures.  Public key cryptography
   hides the identities during authentication.  The group exponentials
   are exchanged and authenticated, but the implied keying material
   (g^xy) is not needed during the exchange.

   This exchange has an important difference from the previous signature
   scheme --- in the first message, an identity for the responder is
   indicated as cleartext: ID(R').  However, the identity hidden with
   the public key cryptography is different: ID(R).  This happens
   because the Initiator must somehow tell the Responder which
   public/private key pair to use for the decryption, but at the same
   time, the identity is hidden by encryption with that public key.

   The Initiator might elect to forgo secrecy of the Responder identity,
   but this is undesirable.  Instead, if there is a well-known identity
   for the Responder node, the public key for that identity can be used
   to encrypt the actual Responder identity.

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

   Kir = prf(0, Ni | Nr)

   NB "NIDP" means that the PFS option for hiding identities is not used.

   NB  The ID(R') value is included in the Authentication payload as
       described in Appendix B.

   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:

   Initiation
      The Initiator generates a unique cookie and associates it with the
      expected IP address of the responder, and its chosen state
      information: GRP, g^x, EHAO list.  The first authentication choice
      in the EHAO list is an algorithm that supports public key



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


      encryption.  The Initiator also names the two identities to be
      used for the connection and enters these into the state.  A well-
      known identity for the responder machine is also chosen, and the
      public key for this identity is used to encrypt the nonce Ni and
      the two connection identities.  The Initiator further

      notes that the key is in the initial state of "unauthenticated",
      and

      sets a timer for possible retransmission and/or termination of the
      request.

   When the Responder receives the message, he may choose to ignore all
   the information and treat it as merely a request for a cookie,
   creating no state.

   If CKY-I is not already in use by the source address in the IP
   header, the Responder generates a unique cookie, CKY-R.  As before,
   the next steps depend on the responder's preferences.  The minimal
   required response is a message with the first cookie field set to
   zero and CKY-R in the second field.  For this example we will assume
   that responder is more aggressive and accepts the following:

      group GRP, first authentication choice (which must be the public
      key encryption algorithm used to encrypt the payload), lack of
      perfect forward secrecy for protecting the identities, identity
      ID(I), identity ID(R)

   The Responder must decrypt the ID and nonce information, using the
   private key for the R' ID.  After this, the private key for the R ID
   will be used to decrypt the nonce field.

   The Responder now associates the pair (CKY-I, CKY-R) with the
   following state information:

      the source and destination network addresses of the message

      key state of "unauthenticated"

      the first algorithm from each class in the EHAO (encryption-hash-
      authentication algorithm offers) list

      group GRP and a y and g^y value in group GRP

      the nonce Ni and a pseudorandomly selected value Nr

      a timer for possible destruction of the state.




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


   The Responder then encrypts the state information with the public key
   of ID(I), forms the prf value, and sends it to the Initiator.

   The Initiator receives the reply message and
      validates that CKY-I is a valid association for the network
      address of the incoming message,

      adds the CKY-R value to the state for the pair (CKY-I, network
      address), and associates all state information with the pair
      (CKY-I, CKY-R),

      decrypts the ID and nonce information

      checks the prf calculation (should this fail, the message is
      discarded)

      adds g^y to its state information,

      saves the EHA selections in the state,

      optionally computes (g^x)^y (= g^xy) (this may be deferred), and