rfc2412.txt

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

      sends the reply message, encrypted with the public key of ID(R),

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

   When the Responder receives this message, it marks the key as being
   in the authenticated state.  If it has not already done so, it should
   compute g^xy and associate it with the KEYID.

   The secret keying material sKEYID = prf(Ni | Nr,  g^xy | CKY-I |
   CKY-R)

   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.

2.4.3 An Aggressive Example With Private Identities and Without Diffie-
      Hellman

   Considerable computational expense can be avoided if perfect forward
   secrecy is not a requirement for the session key derivation.  The two
   parties can exchange nonces and secret key parts to achieve the
   authentication and derive keying material.  The long-term privacy of
   data protected with derived keying material is dependent on the
   private keys of each of the parties.





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


   In this exchange, the GRP has the value 0 and the field for the group
   exponential is used to hold a nonce value instead.

   As in the previous section, the first proposed algorithm must be a
   public key encryption system; by responding with a cookie and a non-
   zero exponential field, the Responder implicitly accepts the first
   proposal and the lack of perfect forward secrecy for the identities
   and derived keying material.

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

   Kir = prf(0, sKi | sKr)

   NB  The sKi and sKr values go into the nonce fields.  The change in
   notation is meant to emphasize that their entropy is critical to
   setting the keying material.

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

   The result of this exchange is a key with KEYID = CKY-I|CKY-R and
   value sKEYID = prf(Kir, CKY-I | CKY-R).

2.4.3 A Conservative Example

   In this example the two parties are minimally aggressive; they use
   the cookie exchange to delay creation of state, and they use perfect
   forward secrecy to protect the identities.  For this example, they
   use public key encryption for authentication; digital signatures or
   pre-shared keys can also be used, as illustrated previously.  The
   conservative example here does not change the use of nonces, prf's,
   etc., but it does change how much information is transmitted in each
   message.

   The responder considers the ability of the initiator to repeat CKY-R
   as weak evidence that the message originates from a "live"
   correspondent on the network and the correspondent is associated with
   the initiator's network address.  The initiator makes similar
   assumptions when CKY-I is repeated to the initiator.




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


   All messages must have either valid cookies or at least one zero
   cookie. If both cookies are zero, this indicates a request for a
   cookie; if only the initiator cookie is zero, it is a response to a
   cookie request.

   Information in messages violating the cookie rules cannot be used for
   any OAKLEY operations.

   Note that the Initiator and Responder must agree on one set of EHA
   algorithms; there is not one set for the Responder and one for the
   Initiator.  The Initiator must include at least MD5 and DES in the
   initial offer.

   Fields not indicated have null values.

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

   Kir = prf(0, Ni | Nr)

   * when IDP is in effect, authentication payloads are encrypted with
     the selected encryption algorithm using the keying material prf(0,
     g^xy).  (The transform defining the encryption algorithm will
     define how to select key bits from the keying material.) This
     encryption is in addition to and after any  public key encryption.
     See Appendix B.

     Note that in the first messages, several fields are omitted from
     the description.  These fields are present as null values.

   The first exchange allows the Responder to use stateless cookies; if
   the responder generates cookies in a manner that allows him to
   validate them without saving them, as in Photuris, then this is
   possible.  Even if the Initiator includes a cookie in his initial
   request, the responder can still use stateless cookies by merely
   omitting the CKY-I from his reply and by declining to record the
   Initiator cookie until it appears in a later message.



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


   After the exchange is complete, both parties compute the shared key
   material sKEYID as prf(Ni | Nr, g^xy | CKY-I | CKY-R) where "prf" is
   the pseudo-random function in class "hash" selected in the EHA list.

   As with the cookies, each party considers the ability of the remote
   side to repeat the Ni or Nr value as a proof that Ka, the public key
   of party a, speaks for the remote party and establishes its identity.

   In analyzing this exchange, it is important to note that although the
   IDP option ensures that the identities are protected with an
   ephemeral key g^xy, the authentication itself does not depend on
   g^xy.  It is essential that the authentication steps validate the g^x
   and g^y values, and it is thus imperative that the authentication not
   involve a circular dependency on them.  A third party could intervene
   with a "man-in-middle" scheme to convince the initiator and responder
   to use different g^xy values; although such an attack might result in
   revealing the identities to the eavesdropper, the authentication
   would fail.

2.4.4 Extra Strength for Protection of Encryption Keys

   The nonces Ni and Nr are used to provide an extra dimension of
   secrecy in deriving session keys.  This makes the secrecy of the key
   depend on two different problems: the discrete logarithm problem in
   the group G, and the problem of breaking the nonce encryption scheme.
   If RSA encryption is used, then this second problem is roughly
   equivalent to factoring the RSA public keys of both the initiator and
   responder.

   For authentication, the key type, the validation method, and the
   certification requirement must be indicated.

2.5 Identity and Authentication

2.5.1 Identity

   In OAKLEY exchanges the Initiator offers Initiator and Responder ID's
   -- the former is the claimed identity for the Initiator, and the
   latter is the requested ID for the Responder.

   If neither ID is specified, the ID's are taken from the IP header
   source and destination addresses.

   If the Initiator doesn't supply a responder ID, the Responder can
   reply by naming any identity that the local policy allows.  The
   Initiator can refuse acceptance by terminating the exchange.





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


   The Responder can also reply with a different ID than the Initiator
   suggested; the Initiator can accept this implicitly by continuing the
   exchange or refuse it by terminating (not replying).

2.5.2 Authentication

   The authentication of principals to one another is at the heart of
   any key exchange scheme.  The Internet community must decide on a
   scalable standard for solving this problem, and OAKLEY must make use
   of that standard.  At the time of this writing, there is no such
   standard, though several are emerging.  This document attempts to
   describe how a handful of standards could be incorporated into
   OAKLEY, without attempting to pick and choose among them.

   The following methods can appear in OAKLEY offers:

   a. Pre-shared Keys
      When two parties have arranged for a trusted method of
      distributing secret keys for their mutual authentication, they can
      be used for authentication.  This has obvious scaling problems for
      large systems, but it is an acceptable interim solution for some
      situations.  Support for pre-shared keys is REQUIRED.

      The encryption, hash, and authentication algorithm for use with a
      pre-shared key must be part of the state information distributed
      with the key itself.

      The pre-shared keys have a KEYID and keying material sKEYID; the
      KEYID is used in a pre-shared key authentication option offer.
      There can be more than one pre-shared key offer in a list.

      Because the KEYID persists over different invocations of OAKLEY
      (after a crash, etc.), it must occupy a reserved part of the KEYID
      space for the two parties.  A few bits can be set aside in each
      party's "cookie space" to accommodate this.

      There is no certification authority for pre-shared keys.  When a
      pre-shared key is used to generate an authentication payload, the
      certification authority is "None", the Authentication Type is
      "Preshared", and the payload contains

         the KEYID, encoded as two 64-bit quantities, and the result of
         applying the pseudorandom hash function to the message body
         with the sKEYID forming the key for the function







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


   b. DNS public keys
      Security extensions to the DNS protocol [DNSSEC] provide a
      convenient way to access public key information, especially for
      public keys associated with hosts.  RSA keys are a requirement for
      secure DNS implementations; extensions to allow optional DSS keys
      are a near-term possibility.

      DNS KEY records have associated SIG records that are signed by a
      zone authority, and a hierarchy of signatures back to the root
      server establishes a foundation for trust.  The SIG records
      indicate the algorithm used for forming the signature.

      OAKLEY implementations must support the use of DNS KEY and SIG
      records for authenticating with respect to IPv4 and IPv6 addresses
      and fully qualified domain names.  However, implementations are
      not required to support any particular algorithm (RSA, DSS, etc.).

   c. RSA public keys w/o certification authority signature PGP
      [Zimmerman] uses public keys with an informal method for
      establishing trust.  The format of PGP public keys and naming
      methods will be described in a separate RFC.  The RSA algorithm
      can be used with PGP keys for either signing or encryption; the
      authentication option should indicate either RSA-SIG or RSA-ENC,
      respectively.  Support for this is OPTIONAL.

   d.1 RSA public keys w/ certificates There are various formats and
      naming conventions for public keys that are signed by one or more
      certification authorities.  The Public Key Interchange Protocol
      discusses X.509 encodings and validation.  Support for this is
      OPTIONAL.

   d.2 DSS keys w/ certificates Encoding for the Digital Signature
      Standard with X.509 is described in draft-ietf-ipsec-dss-cert-
      00.txt.  Support for this is OPTIONAL; an ISAKMP Authentication
      Type will be assigned.

2.5.3 Validating Authentication Keys

   The combination of the Authentication algorithm, the Authentication
   Authority, the Authentication Type, and a key (usually public) define
   how to validate the messages with respect to the claimed identity.
   The key information will be available either from a pre-shared key,
   or from some kind of certification authority.

   Generally the certification authority produces a certificate binding
   the entity name to a public key.  OAKLEY implementations must be
   prepared to fetch and validate certificates before using the public
   key for OAKLEY authentication purposes.