rfc2412.txt

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

Network Working Group                                           H. Orman
Request for Comments: 2412                Department of Computer Science
Category: Informational                            University of Arizona
                                                           November 1998


                 The OAKLEY Key Determination Protocol

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   This document describes a protocol, named OAKLEY, by which two
   authenticated parties can agree on secure and secret keying material.
   The basic mechanism is the Diffie-Hellman key exchange algorithm.

   The OAKLEY protocol supports Perfect Forward Secrecy, compatibility
   with the ISAKMP protocol for managing security associations, user-
   defined abstract group structures for use with the Diffie-Hellman
   algorithm, key updates, and incorporation of keys distributed via
   out-of-band mechanisms.

1. INTRODUCTION

   Key establishment is the heart of data protection that relies on
   cryptography, and it is an essential component of the packet
   protection mechanisms described in [RFC2401], for example.  A
   scalable and secure key distribution mechanism for the Internet is a
   necessity.  The goal of this protocol is to provide that mechanism,
   coupled with a great deal of cryptographic strength.

   The Diffie-Hellman key exchange algorithm provides such a mechanism.
   It allows two parties to agree on a shared value without requiring
   encryption.  The shared value is immediately available for use in
   encrypting subsequent conversation, e.g. data transmission and/or
   authentication.  The STS protocol [STS] provides a demonstration of
   how to embed the algorithm in a secure protocol, one that ensures
   that in addition to securely sharing a secret, the two parties can be
   sure of each other's identities, even when an active attacker exists.




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


   Because OAKLEY is a generic key exchange protocol, and because the
   keys that it generates might be used for encrypting data with a long
   privacy lifetime, 20 years or more, it is important that the
   algorithms underlying the protocol be able to ensure the security of
   the keys for that period of time, based on the best prediction
   capabilities available for seeing into the mathematical future.  The
   protocol therefore has two options for adding to the difficulties
   faced by an attacker who has a large amount of recorded key exchange
   traffic at his disposal (a passive attacker).  These options are
   useful for deriving keys which will be used for encryption.

   The OAKLEY protocol is related to STS, sharing the similarity of
   authenticating the Diffie-Hellman exponentials and using them for
   determining a shared key, and also of achieving Perfect Forward
   Secrecy for the shared key, but it differs from the STS protocol in
   several ways.

      The first is the addition of a weak address validation mechanism
      ("cookies", described by Phil Karn in the Photuris key exchange
      protocol work in progress) to help avoid denial of service
      attacks.

      The second extension is to allow the two parties to select
      mutually agreeable supporting algorithms for the protocol: the
      encryption method, the key derivation method, and the
      authentication method.

      Thirdly, the authentication does not depend on encryption using
      the Diffie-Hellman exponentials; instead, the authentication
      validates the binding of the exponentials to the identities of the
      parties.

      The protocol does not require the two parties compute the shared
      exponentials prior to authentication.

      This protocol adds additional security to the derivation of keys
      meant for use with encryption (as opposed to authentication) by
      including a dependence on an additional algorithm.  The derivation
      of keys for encryption is made to depend not only on the Diffie-
      Hellman algorithm, but also on the cryptographic method used to
      securely authenticate the communicating parties to each other.

      Finally, this protocol explicitly defines how the two parties can
      select the mathematical structures (group representation and
      operation) for performing the Diffie-Hellman algorithm; they can
      use standard groups or define their own.  User-defined groups
      provide an additional degree of long-term security.




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


   OAKLEY has several options for distributing keys.  In addition to the
   classic Diffie-Hellman exchange, this protocol can be used to derive
   a new key from an existing key and to distribute an externally
   derived key by encrypting it.

   The protocol allows two parties to use all or some of the anti-
   clogging and perfect forward secrecy features.  It also permits the
   use of authentication based on symmetric encryption or non-encryption
   algorithms.  This flexibility is included in order to allow the
   parties to use the features that are best suited to their security
   and performance requirements.

   This document draws extensively in spirit and approach from the
   Photuris work in progress by Karn and Simpson (and from discussions
   with the authors), specifics of the ISAKMP document by Schertler et
   al. the ISAKMP protocol document, and it was also influenced by
   papers by Paul van Oorschot and Hugo Krawcyzk.

2. The Protocol Outline

2.1  General Remarks

   The OAKLEY protocol is used to establish a shared key with an
   assigned identifier and associated authenticated identities for the
   two parties.  The name of the key can be used later to derive
   security associations for the RFC 2402 and RFC 2406 protocols (AH and
   ESP) or to achieve other network security goals.

   Each key is associated with algorithms that are used for
   authentication, privacy, and one-way functions.  These are ancillary
   algorithms for OAKLEY; their appearance in subsequent security
   association definitions derived with other protocols is neither
   required nor prohibited.

   The specification of the details of how to apply an algorithm to data
   is called a transform.  This document does not supply the transform
   definitions; they will be in separate RFC's.

   The anti-clogging tokens, or "cookies", provide a weak form of source
   address identification for both parties; the cookie exchange can be
   completed before they perform the computationally expensive part of
   the protocol (large integer exponentiations).

   It is important to note that OAKLEY uses the cookies for two
   purposes:  anti-clogging and key naming.  The two parties to the
   protocol each contribute one cookie at the initiation of key
   establishment; the pair of cookies becomes the key identifier
   (KEYID), a reusable name for the keying material.  Because of this



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


   dual role, we will use the notation for the concatenation of the
   cookies ("COOKIE-I, COOKIE-R") interchangeably with the symbol
   "KEYID".

   OAKLEY is designed to be a compatible component of the ISAKMP
   protocol [ISAKMP], which runs over the UDP protocol using a well-
   known port (see the RFC on port assignments, STD02-RFC-1700).  The
   only technical requirement for the protocol environment is that the
   underlying protocol stack must be able to supply the Internet address
   of the remote party for each message.  Thus, OAKLEY could, in theory,
   be used directly over the IP protocol or over UDP, if suitable
   protocol or port number assignments were available.

   The machine running OAKLEY must provide a good random number
   generator, as described in [RANDOM], as the source of random numbers
   required in this protocol description.  Any mention of a "nonce"
   implies that the nonce value is generated by such a generator.  The
   same is true for "pseudorandom" values.

2.2  Notation

   The section describes the notation used in this document for message
   sequences and content.

2.2.1  Message descriptions

   The protocol exchanges below are written in an abbreviated notation
   that is intended to convey the essential elements of the exchange in
   a clear manner.  A brief guide to the notation follows.  The detailed
   formats and assigned values are given in the appendices.

   In order to represent message exchanges succinctly, this document
   uses an abbreviated notation that describes each message in terms of
   its source and destination and relevant fields.

   Arrows ("->") indicate whether the message is sent from the initiator
   to the responder, or vice versa ("<-").

   The fields in the message are named and comma separated.  The
   protocol uses the convention that the first several fields constitute
   a fixed header format for all messages.

   For example, consider a HYPOTHETICAL exchange of messages involving a
   fixed format message, the four fixed fields being two "cookies", the
   third field being a message type name, the fourth field being a
   multi-precision integer representing a power of a number:





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


        Initiator                                       Responder
            ->    Cookie-I, 0, OK_KEYX, g^x                    ->
            <-    Cookie-R, Cookie-I, OK_KEYX, g^y            <-

   The notation describes a two message sequence.  The initiator begins
   by sending a message with 4 fields to the responder; the first field
   has the unspecified value "Cookie-I", second field has the numeric
   value 0, the third field indicates the message type is OK_KEYX, the
   fourth value is an abstract group element g to the x'th power.

   The second line indicates that the responder replies with value
   "Cookie-R" in the first field, a copy of the "Cookie-I" value in the
   second field, message type OK_KEYX, and the number g raised to the
   y'th power.

   The value OK_KEYX is in capitals to indicate that it is a unique
   constant (constants are defined in the appendices).

   Variable precision integers with length zero are null values for the
   protocol.

   Sometimes the protocol will indicate that an entire payload (usually
   the Key Exchange Payload) has null values.  The payload is still
   present in the message, for the purpose of simplifying parsing.

2.2.2 Guide to symbols

   Cookie-I and Cookie-R (or CKY-I and CKY-R) are 64-bit pseudo-random
   numbers.  The generation method must ensure with high probability
   that the numbers used for each IP remote address are unique over some
   time period, such as one hour.

   KEYID is the concatenation of the initiator and responder cookies and
   the domain of interpretation; it is the name of keying material.

   sKEYID is used to denote the keying material named by the KEYID.  It
   is never transmitted, but it is used in various calculations
   performed by the two parties.

   OK_KEYX and OK_NEWGRP are distinct message types.

   IDP is a bit indicating whether or not material after the encryption
   boundary (see appendix B), is encrypted.  NIDP means not encrypted.

   g^x and g^y are encodings of group elements, where g is a special
   group element indicated in the group description (see Appendix A) and
   g^x indicates that element raised to the x'th power.  The type of the
   encoding is either a variable precision integer or a pair of such



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


   integers, as indicated in the group operation in the group
   description.  Note that we will write g^xy as a short-hand for
   g^(xy).  See Appendix F for references that describe implementing
   large integer computations and the relationship between various group
   definitions and basic arithmetic operations.

   EHAO is a list of encryption/hash/authentication choices.  Each item
   is a pair of values: a class name and an algorithm name.

   EHAS is a set of three items selected from the EHAO list, one from
   each of the classes for encryption, hash, authentication.

   GRP is a name (32-bit value) for the group and its relevant
   parameters: the size of the integers, the arithmetic operation, and
   the generator element.  There are a few pre-defined GRP's (for 768
   bit modular exponentiation groups, 1024 bit modexp, 2048 bit modexp,
   155-bit and 210-bit elliptic curves, see Appendix E), but
   participants can share other group descriptions in a later protocol
   stage (see the section NEW GROUP).  It is important to separate
   notion of the GRP from the group descriptor (Appendix A); the former
   is a name for the latter.