rfc2412.txt

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

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


   The ISAKMP Authentication Payload defines the Authentication
   Authority field for specifying the authority that must be apparent in
   the trust hierarchy for authentication.

   Once an appropriate certificate is obtained (see 2.4.3), the
   validation method will depend on the Authentication Type; if it is
   PGP then the PGP signature validation routines can be called to
   satisfy the local web-of-trust predicates; if it is RSA with X.509
   certificates, the certificate must be examined to see if the
   certification authority signature can be validated, and if the
   hierarchy is recognized by the local policy.

2.5.4 Fetching Identity Objects

   In addition to interpreting the certificate or other data structure
   that contains an identity, users of OAKLEY must face the task of
   retrieving certificates that bind a public key to an identifier and
   also retrieving auxiliary certificates for certifying authorities or
   co-signers (as in the PGP web of trust).

   The ISAKMP Credentials Payload can be used to attach useful
   certificates to OAKLEY messages.  The Credentials Payload is defined
   in Appendix B.

   Support for accessing and revoking public key certificates via the
   Secure DNS protocol [SECDNS] is MANDATORY for OAKLEY implementations.
   Other retrieval methods can be used when the AUTH class indicates a
   preference.

   The Public Key Interchange Protocol discusses a full protocol that
   might be used with X.509 encoded certificates.

2.6 Interface to Cryptographic Transforms

   The keying material computed by the key exchange should have at least
   90 bits of entropy, which means that it must be at least 90 bits in
   length.  This may be more or less than is required for keying the
   encryption and/or pseudorandom function transforms.

   The transforms used with OAKLEY should have auxiliary algorithms
   which take a variable precision integer and turn it into keying
   material of the appropriate length.  For example, a DES algorithm
   could take the low order 56 bits, a triple DES algorithm might use
   the following:

              K1 = low 56 bits of md5(0|sKEYID)
              K2 = low 56 bits of md5(1|sKEYID)
              K3 = low 56 bits of md5(2|sKEYID)



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


   The transforms will be called with the keying material encoded as a
   variable precision integer, the length of the data, and the block of
   memory with the data.  Conversion of the keying material to a
   transform key is the responsibility of the transform.

2.7 Retransmission, Timeouts, and Error Messages

   If a response from the Responder is not elicited in an appropriate
   amount of time, the message should be retransmitted by the Initiator.
   These retransmissions must be handled gracefully by both parties; the
   Responder must retain information for retransmitting until the
   Initiator moves to the next message in the protocol or completes the
   exchange.

   Informational error messages present a problem because they cannot be
   authenticated using only the information present in an incomplete
   exchange; for this reason, the parties may wish to establish a
   default key for OAKLEY error messages.  A possible method for
   establishing such a key is described in Appendix B, under the use of
   ISA_INIT message types.

   In the following the message type is OAKLEY Error, the KEYID supplies
   the H algorithm and key for authenticating the message contents; this
   value is carried in the Sig/Prf payload.

   The Error payload contains the error code and the contents of the
   rejected message.
























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


                             1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !                                                               !
        ~                       Initiator-Cookie                        ~
     /  !                                                               !
KEYID   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \  !                                                               !
        ~                       Responder-Cookie                        ~
        !                                                               !
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !                  Domain of Interpretation                     !
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ! Message Type  ! Exch  ! Vers  !          Length               !
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !                 SPI (unused)                                  !
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !                 SPI (unused)                                  !
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !                 Error Payload                                 !
        ~                                                               ~
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        !                 Sig/prf Payload
        ~                                                               ~
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The error message will contain the cookies as presented in the
   offending message, the message type OAKLEY_ERROR, and the reason for
   the error, followed by the rejected message.

   Error messages are informational only, and the correctness of the
   protocol does not depend on them.

   Error reasons:

   TIMEOUT                   exchange has taken too long, state destroyed
   AEH_ERROR                 an unknown algorithm appears in an offer
   GROUP_NOT_SUPPORTED       GRP named is not supported
   EXPONENTIAL_UNACCEPTABLE  exponential too large/small or is +-1
   SELECTION_NOT_OFFERED     selection does not occur in offer
   NO_ACCEPTABLE_OFFERS      no offer meets host requirements
   AUTHENTICATION_FAILURE    signature or hash function fails
   RESOURCE_EXCEEDED         too many exchanges or too much state info
   NO_EXCHANGE_IN_PROGRESS   a reply received with no request in progress







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


2.8 Additional Security for Privacy Keys: Private Groups

   If the two parties have need to use a Diffie-Hellman key
   determination scheme that does not depend on the standard group
   definitions, they have the option of establishing a private group.
   The authentication need not be repeated, because this stage of the
   protocol will be protected by a pre-existing authentication key.  As
   an extra security measure, the two parties will establish a private
   name for the shared keying material, so even if they use exactly the
   same group to communicate with other parties, the re-use will not be
   apparent to passive attackers.

   Private groups have the advantage of making a widespread passive
   attack much harder by increasing the number of groups that would have
   to be exhaustively analyzed in order to recover a large number of
   session keys.  This contrasts with the case when only one or two
   groups are ever used; in that case, one would expect that years and
   years of session keys would be compromised.

   There are two technical challenges to face: how can a particular user
   create a unique and appropriate group, and how can a second party
   assure himself that the proposed group is reasonably secure?

   The security of a modular exponentiation group depends on the largest
   prime factor of the group size.  In order to maximize this, one can
   choose "strong" or Sophie Germaine primes, P = 2Q + 1, where P and Q
   are prime.  However, if P = kQ + 1, where k is small, then the
   strength of the group is still considerable.  These groups are known
   as Schnorr subgroups, and they can be found with much less
   computational effort than Sophie-Germaine primes.

   Schnorr subgroups can also be validated efficiently by using probable
   prime tests.

   It is also fairly easy to find P, k, and Q such that the largest
   prime factor can be easily proven to be Q.

   We estimate that it would take about 10 minutes to find a new group
   of about 2^1024 elements, and this could be done once a day by a
   scheduled process; validating a group proposed by a remote party
   would take perhaps a minute on a 25 MHz RISC machine or a 66 MHz CISC
   machine.

   We note that validation is done only between previously mutually
   authenticated parties, and that a new group definition always follows
   and is protected by a key established using a well-known group.
   There are five points to keep in mind:




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


      a. The description and public identifier for the new group are
      protected by the well-known group.

      b. The responder can reject the attempt to establish the new
      group, either because he is too busy or because he cannot validate
      the largest prime factor as being sufficiently large.

      c. The new modulus and generator can be cached for long periods of
      time; they are not security critical and need not be associated
      with ongoing activity.

      d. Generating a new g^x value periodically will be more expensive
      if there are many groups cached; however, the importance of
      frequently generating new g^x values is reduced, so the time
      period can be lengthened correspondingly.

      e. All modular exponentiation groups have subgroups that are
      weaker than the main group.  For Sophie Germain primes, if the
      generator is a square, then there are only two elements in the
      subgroup: 1 and g^(-1) (same as g^(p-1)) which we have already
      recommended avoiding.  For Schnorr subgroups with k not equal to
      2, the subgroup can be avoided by checking that the exponential is
      not a kth root of 1 (e^k != 1 mod p).

2.8.1 Defining a New Group

   This section describes how to define a new group.  The description of
   the group is hidden from eavesdroppers, and the identifier assigned
   to the group is unique to the two parties.  Use of the new group for
   Diffie-Hellman key exchanges is described in the next section.

   The secrecy of the description and the identifier increases the
   difficulty of a passive attack, because if the group descriptor is
   not known to the attacker, there is no straightforward and efficient
   way to gain information about keys calculated using the group.

   Only the description of the new group need be encrypted in this
   exchange.  The hash algorithm is implied by the OAKLEY session named
   by the group.  The encryption is the encryption function of the
   OAKLEY session.

   The descriptor of the new group is encoded in the new group payload.
   The nonces are encoded in the Authentication Payload.

   Data beyond the encryption boundary is encrypted using the transform
   named by the KEYID.





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


   The following messages use the ISAKMP Key Exchange Identifier OAKLEY
   New Group.

   To define a new modular exponentiation group:

     Initiator                                        Responder
     ---------                                       ----------
      ->   KEYID,                                        ->
           INEWGRP,
           Desc(New Group), Na
           prf(sKEYID, Desc(New Group) | Na)

      <-   KEYID,
           INEWGRPRS,
           Na, Nb
           prf(sKEYID, Na | Nb | Desc(New Group))       <-

       ->  KEYID,
           INEWGRPACK
           prf(sKEYID, Nb | Na | Desc(New Group))        ->

   These messages are encrypted at the encryptio