doc: Add RFC documents

1 files changed, 3083 insertions, 0 deletions

diff --git a/doc/rfc/rfc2412.txt b/doc/rfc/rfc2412.txt
new file mode 100644
index 0000000..9169d78
--- /dev/null
+++ b/doc/rfc/rfc2412.txt
@@ -0,0 +1,3083 @@
+
+
+
+
+
+
+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.
+
+   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:
+
+
+
+
+
+
+
+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
+
+      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.
+
+
+
+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 encryption boundary using the key
+   indicated.  The hash value is placed in the "digital signature" field
+   (see Appendix B).
+
+      New GRP identifier = trunc16(Na) | trunc16(Nb)
+
+      (trunc16 indicates truncation to 16 bits; the initiator and
+      responder must use nonces that have distinct upper bits from any
+      used for current GRPID's)
+
+      Desc(G) is the encoding of the descriptor for the group descriptor
+      (see Appendix A for the format of a group descriptor)
+
+   The two parties must store the mapping between the new group
+   identifier GRP and the group descriptor Desc(New Group).  They must
+   also note the identities used for the KEYID and copy these to the
+   state for the new group.
+
+   Note that one could have the same group descriptor associated with
+   several KEYID's.   Pre-calculation of g^x values may be done based
+   only on the group descriptor, not the private group name.
+
+2.8.2 Deriving a Key Using a Private Group
+
+   Once a private group has been established, its group id can be used
+   in the key exchange messages in the GRP position.  No changes to the
+   protocol are required.
+
+
+
+Orman                        Informational                     [Page 28]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+2.9 Quick Mode: New Keys From Old,
+
+   When an authenticated KEYID and associated keying material sKEYID
+   already exist, it is easy to derive additional KEYID's and keys
+   sharing similar attributes (GRP, EHA, etc.)  using only hashing
+   functions.  The KEYID might be one that was derived in Main Mode, for
+   example.
+
+   On the other hand, the authenticated key may be a manually
+   distributed key, one that is shared by the initiator and responder
+   via some means external to OAKLEY.  If the distribution method has
+   formed the KEYID using appropriately unique values for the two halves
+   (CKY-I and CKY-R), then this method is applicable.
+
+   In the following, the Key Exchange Identifier is OAKLEY Quick Mode.
+   The nonces are carried in the Authentication Payload, and the prf
+   value is carried in the Authentication Payload; the Authentication
+   Authority is "None" and the type is "Pre-Shared".
+
+   The protocol is:
+
+     Initiator                                           Responder
+     ---------                                           ---------
+     -> KEYID, INEWKRQ, Ni, prf(sKEYID, Ni)                ->
+    <-  KEYID, INEWKRS, Nr, prf(sKEYID, 1 | Nr | Ni)      <-
+     -> KEYID, INEWKRP, 0, prf(sKEYID,  0 | Ni | Nr)       ->
+
+   The New KEYID, NKEYID, is Ni | Nr
+
+   sNKEYID = prf(sKEYID, Ni | Nr )
+
+   The identities and EHA values associated with NKEYID are the same as
+   those associated with KEYID.
+
+   Each party must validate the hash values before using the new key for
+   any purpose.
+
+2.10 Defining and Using Pre-Distributed Keys
+
+   If a key and an associated key identifier and state information have
+   been distributed manually, then the key can be used for any OAKLEY
+   purpose.  The key must be associated with the usual state
+   information:  ID's and EHA algorithms.
+
+   Local policy dictates when a manual key can be included in the OAKLEY
+   database.  For example, only privileged users would be permitted to
+   introduce keys associated with privileged ID's, an unprivileged user
+   could only introduce keys associated with her own ID.
+
+
+
+Orman                        Informational                     [Page 29]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+2.11 Distribution of an External Key
+
+   Once an OAKLEY session key and ancillary algorithms are established,
+   the keying material and the "H" algorithm can be used to distribute
+   an externally generated key and to assign a KEYID to it.
+
+   In the following, KEYID represents an existing, authenticated OAKLEY
+   session key, and sNEWKEYID represents the externally generated keying
+   material.
+
+   In the following, the Key Exchange Identifier is OAKLEY External
+   Mode.  The Key Exchange Payload contains the new key, which is
+   protected
+
+  Initiator                                                     Responder
+  ---------                                                     ---------
+  -> KEYID, IEXTKEY, Ni, prf(sKEYID, Ni)                               ->
+ <-  KEYID, IEXTKEY, Nr, prf(sKEYID, 1 | Nr | Ni)                     <-
+  -> KEYID, IEXTKEY, Kir xor sNEWKEYID*, prf(Kir, sNEWKEYID | Ni | Nr) ->
+
+   Kir = prf(sKEYID, Ni | Nr)
+
+   * this field is carried in the Key Exchange Payload.
+
+   Each party must validate the hash values using the "H" function in
+   the KEYID state before changing any key state information.
+
+   The new key is recovered by the Responder by calculating the xor of
+   the field in the Authentication Payload with the Kir value.
+
+   The new key identifier, naming the keying material sNEWKEYID, is
+   prf(sKEYID, 1 | Ni | Nr).
+
+   Note that this exchange does not require encryption.  Hugo Krawcyzk
+   suggested the method and noted its advantage.
+
+2.11.1 Cryptographic Strength Considerations
+
+   The strength of the key used to distribute the external key must be
+   at least equal to the strength of the external key.  Generally, this
+   means that the length of the sKEYID material must be greater than or
+   equal to the length of the sNEWKEYID material.
+
+   The derivation of the external key, its strength or intended use are
+   not addressed by this protocol; the parties using the key must have
+   some other method for determining these properties.
+
+
+
+
+
+Orman                        Informational                     [Page 30]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+   As of early 1996, it appears that for 90 bits of cryptographic
+   strength, one should use a modular exponentiation group modulus of
+   2000 bits.  For 128 bits of strength, a 3000 bit modulus is required.
+
+3. Specifying and Deriving Security Associations
+
+   When a security association is defined, only the KEYID need be given.
+   The responder should be able to look up the state associated with the
+   KEYID value and find the appropriate keying material, sKEYID.
+
+   Deriving keys for use with IPSEC protocols such as ESP or AH is a
+   subject covered in the ISAKMP/Oakley Resolution document.  That
+   document also describes how to negotiate acceptable parameter sets
+   and identifiers for ESP and AH, and how to exactly calculate the
+   keying material for each instance of the protocols.  Because the
+   basic keying material defined here (g^xy) may be used to derive keys
+   for several instances of ESP and AH, the exact mechanics of using
+   one-way functions to turn g^xy into several unique keys is essential
+   to correct usage.
+
+4. ISAKMP Compatibility
+
+   OAKLEY uses ISAKMP header and payload formats, as described in the
+   text and in Appendix B.  There are particular noteworthy extensions
+   beyond the version 4 draft.
+
+4.1 Authentication with Existing Keys
+
+   In the case that two parties do not have suitable public key
+   mechanisms in place for authenticating each other, they can use keys
+   that were distributed manually.  After establishment of these keys
+   and their associated state in OAKLEY, they can be used for
+   authentication modes that depend on signatures, e.g. Aggressive Mode.
+
+   When an existing key is to appear in an offer list, it should be
+   indicated with an Authentication Algorithm of ISAKMP_EXISTING.  This
+   value will be assigned in the ISAKMP RFC.
+
+   When the authentication method is ISAKMP_EXISTING, the authentication
+   authority will have the value ISAKMP_AUTH_EXISTING; the value for
+   this field must not conflict with any authentication authority
+   registered with IANA and is defined in the ISAKMP RFC.
+
+
+
+
+
+
+
+
+
+Orman                        Informational                     [Page 31]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+   The authentication payload will have two parts:
+
+       the KEYID for the pre-existing key
+
+       the identifier for the party to be authenticated by the pre-
+       existing key.
+
+   The pseudo-random function "H" in the state information for that
+   KEYID will be the signature algorithm, and it will use the keying
+   material for that key (sKEYID) when generating or checking the
+   validity of message data.
+
+   E.g. if the existing key has an KEYID denoted by KID and 128 bits of
+   keying material denoted by sKID and "H" algorithm a transform named
+   HMAC, then to generate a "signature" for a data block, the output of
+   HMAC(sKID, data) will be the corresponding signature payload.
+
+   The KEYID state will have the identities of the local and remote
+   parties for which the KEYID was assigned; it is up to the local
+   policy implementation to decide when it is appropriate to use such a
+   key for authenticating other parties.  For example, a key distributed
+   for use between two Internet hosts A and B may be suitable for
+   authenticating all identities of the form "alice@A" and "bob@B".
+
+4.2 Third Party Authentication
+
+   A local security policy might restrict key negotiation to trusted
+   parties.  For example, two OAKLEY daemons running with equal
+   sensitivity labels on two machines might wish to be the sole arbiters
+   of key exchanges between users with that same sensitivity label.  In
+   this case, some way of authenticating the provenance of key exchange
+   requests is needed.  I.e., the identities of the two daemons should
+   be bound to a key, and that key will be used to form a "signature"
+   for the key exchange messages.
+
+   The Signature Payload, in Appendix B, is for this purpose.  This
+   payload names a KEYID that is in existence before the start of the
+   current exchange.  The "H" transform for that KEYID is used to
+   calculate an integrity/authentication value for all payloads
+   preceding the signature.
+
+   Local policy can dictate which KEYID's are appropriate for signing
+   further exchanges.
+
+
+
+
+
+
+
+
+Orman                        Informational                     [Page 32]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+4.3 New Group Mode
+
+   OAKLEY uses a new KEI for the exchange that defines a new group.
+
+5. Security Implementation Notes
+
+   Timing attacks that are capable of recovering the exponent value used
+   in Diffie-Hellman calculations have been described by Paul Kocher
+   [Kocher].  In order to nullify the attack, implementors must take
+   pains to obscure the sequence of operations involved in carrying out
+   modular exponentiations.
+
+   A "blinding factor" can accomplish this goal.  A group element, r, is
+   chosen at random.  When an exponent x is chosen, the value r^(-x) is
+   also calculated.  Then, when calculating (g^y)^x, the implementation
+   will calculate this sequence:
+
+           A = (rg^y)
+           B = A^x = (rg^y)^x = (r^x)(g^(xy))
+           C = B*r^(-x) = (r^x)(r^-(x))(g^(xy)) = g^(xy)
+
+   The blinding factor is only necessary if the exponent x is used more
+   than 100 times (estimate by Richard Schroeppel).
+
+6. OAKLEY Parsing and State Machine
+
+   There are many pathways through OAKLEY, but they follow a left-to-
+   right parsing pattern of the message fields.
+
+   The initiator decides on an initial message in the following order:
+
+      1. Offer a cookie.  This is not necessary but it helps with
+      aggressive exchanges.
+
+      2. Pick a group.  The choices are the well-known groups or any
+      private groups that may have been negotiated.  The very first
+      exchange between two Oakley daemons with no common state must
+      involve a well-known group (0, meaning no group, is a well-known
+      group).  Note that the group identifier, not the group descriptor,
+      is used in the message.
+
+      If a non-null group will be used, it must be included with the
+      first message specifying EHAO.  It need not be specified until
+      then.
+
+      3. If PFS will be used, pick an exponent x and present g^x.
+
+      4. Offer Encryption, Hash, and Authentication lists.
+
+
+
+Orman                        Informational                     [Page 33]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+      5. Use PFS for hiding the identities
+
+      If identity hiding is not used, then the initiator has this
+      option:
+
+      6. Name the identities and include authentication information
+
+   The information in the authentication section depends on the first
+   authentication offer.  In this aggressive exchange, the Initiator
+   hopes that the Responder will accept all the offered information and
+   the first authentication method.  The authentication method
+   determines the authentication payload as follows:
+
+      1. Signing method.  The signature will be applied to all the
+      offered information.
+
+      2. A public key encryption method.  The algorithm will be used to
+      encrypt a nonce in the public key of the requested Responder
+      identity.  There are two cases possible, depending on whether or
+      not identity hiding is used:
+
+         a. No identity hiding.  The ID's will appear as plaintext.
+         b. Identity hiding.  A well-known ID, call it R', will appear
+         as plaintext in the authentication payload.  It will be
+         followed by two ID's and a nonce; these will be encrypted using
+         the public key for R'.
+
+      3. A pre-existing key method.  The pre-existing key will be used
+      to encrypt a nonce.  If identity hiding is used, the ID's will be
+      encrypted in place in the payload, using the "E" algorithm
+      associated with the pre-existing key.
+
+   The Responder can accept all, part or none of the initial message.
+
+   The Responder accepts as many of the fields as he wishes, using the
+   same decision order as the initiator.  At any step he can stop,
+   implicitly rejecting further fields (which will have null values in
+   his response message).  The minimum response is a cookie and the GRP.
+
+      1. Accept cookie.  The Responder may elect to record no state
+      information until the Initiator successfully replies with a cookie
+      chosen by the responder.  If so, the Responder replies with a
+      cookie, the GRP, and no other information.
+
+      2. Accept GRP.  If the group is not acceptable, the Responder will
+      not reply.  The Responder may send an error message indicating the
+      the group is not acceptable (modulus too small, unknown
+      identifier, etc.)  Note that "no group" has two meanings during
+
+
+
+Orman                        Informational                     [Page 34]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+      the protocol: it may mean the group is not yet specified, or it
+      may mean that no group will be used (and thus PFS is not
+      possible).
+
+      3. Accept the g^x value.  The Responder indicates his acceptance
+      of the g^x value by including his own g^y value in his reply.  He
+      can postpone this by ignoring g^x and putting a zero length g^y
+      value in his reply.  He can also reject the g^x value with an
+      error message.
+
+      4. Accept one element from each of the EHA lists.  The acceptance
+      is indicated by a non-zero proposal.
+
+      5. If PFS for identity hiding is requested, then no further data
+      will follow.
+
+      6. If the authentication payload is present, and if the first item
+      in the offered authentication class is acceptable, then the
+      Responder must validate/decrypt the information in the
+      authentication payload and signature payload, if present. The
+      Responder should choose a nonce and reply using the same
+      authentication/hash algorithm as the Initiator used.
+
+   The Initiator notes which information the Responder has accepted,
+   validates/decrypts any signed, hashed, or encrypted fields, and if
+   the data is acceptable, replies in accordance to the EHA methods
+   selected by the Responder.  The Initiator replies are distinguished
+   from his initial message by the presence of the non-zero value for
+   the Responder cookie.
+
+   The output of the signature or prf function will be encoded as a
+   variable precision integer as described in Appendix C.  The KEYID
+   will indicate KEYID that names keying material and the Hash or
+   Signature function.
+
+7. The Credential Payload
+
+   Useful certificates with public key information can be attached to
+   OAKLEY messages using Credential Payloads as defined in the ISAKMP
+   document.  It should be noted that the identity protection option
+   applies to the credentials as well as the identities.
+
+Security Considerations
+
+   The focus of this document is security; hence security considerations
+   permeate this memo.
+
+
+
+
+
+Orman                        Informational                     [Page 35]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+Author's Address
+
+   Hilarie K. Orman
+   Department of Computer Science
+   University of Arizona
+
+   EMail: ho@darpa.mil
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Orman                        Informational                     [Page 36]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+APPENDIX A Group Descriptors
+
+   Three distinct group representations can be used with OAKLEY.  Each
+   group is defined by its group operation and the kind of underlying
+   field used to represent group elements.  The three types are modular
+   exponentiation groups (named MODP herein), elliptic curve groups over
+   the field GF[2^N] (named EC2N herein), and elliptic curve groups over
+   GF[P] (named ECP herein) For each representation, many distinct
+   realizations are possible, depending on parameter selection.
+
+   With a few exceptions, all the parameters are transmitted as if they
+   were non-negative multi-precision integers, using the format defined
+   in this appendix (note, this is distinct from the encoding in
+   Appendix C).  Every multi-precision integer has a prefixed length
+   field, even where this information is redundant.
+
+   For the group type EC2N, the parameters are more properly thought of
+   as very long bit fields, but they are represented as multi-precision
+   integers, (with length fields, and right-justified).  This is the
+   natural encoding.
+
+   MODP means the classical modular exponentiation group, where the
+   operation is to calculate G^X (mod P).  The group is defined by the
+   numeric parameters P and G.  P must be a prime.  G is often 2, but
+   may be a larger number.  2 <= G <= P-2.
+
+   ECP is an elliptic curve group, modulo a prime number P.  The
+   defining equation for this kind of group is
+    Y^2 = X^3 + AX + B The group operation is taking a multiple of an
+   elliptic-curve point.  The group is defined by 5 numeric parameters:
+   The prime P, two curve parameters A and B, and a generator (X,Y).
+   A,B,X,Y are all interpreted mod P, and must be (non-negative)
+   integers less than P.  They must satisfy the defining equation,
+   modulo P.
+
+   EC2N is an elliptic curve group, over the finite field F[2^N].  The
+   defining equation for this kind of group is
+    Y^2 + XY = X^3 + AX^2 + B (This equation differs slightly from the
+   mod P case:  it has an XY term, and an AX^2 term instead of an AX
+   term.)
+
+   We must specify the field representation, and then the elliptic
+   curve.  The field is specified by giving an irreducible polynomial
+   (mod 2) of degree N.  This polynomial is represented as an integer of
+   size between 2^N and 2^(N+1), as if the defining polynomial were
+   evaluated at the value U=2.
+
+
+
+
+
+Orman                        Informational                     [Page 37]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+   For example, the field defined by the polynomial U^155 + U^62 + 1 is
+   represented by the integer 2^155 + 2^62 + 1.  The group is defined by
+   4 more parameters, A,B,X,Y.  These parameters are elements of the
+   field GF[2^N], and can be thought of as polynomials of degree < N,
+   with (mod 2) coefficients.  They fit in N-bit fields, and are
+   represented as integers < 2^N, as if the polynomial were evaluated at
+   U=2.  For example, the field element U^2 + 1 would be represented by
+   the integer 2^2+1, which is 5.  The two parameters A and B define the
+   curve.  A is frequently 0.  B must not be 0.  The parameters X and Y
+   select a point on the curve.  The parameters A,B,X,Y must satisfy the
+   defining equation, modulo the defining polynomial, and mod 2.
+
+   Group descriptor formats:
+
+   Type of group: A two-byte field,
+           assigned values for the types "MODP", "ECP", "EC2N"
+           will be defined (see ISAKMP-04).
+   Size of a field element, in bits.  This is either Ceiling(log2 P)
+      or the degree of the irreducible polynomial: a 32-bit integer.
+   The prime P or the irreducible field polynomial: a multi-precision
+      integer.
+   The generator: 1 or 2 values, multi-precision integers.
+   EC only:  The parameters of the curve:  2 values, multi-precision
+      integers.
+
+   The following parameters are Optional (each of these may appear
+   independently):
+     a value of 0 may be used as a place-holder to represent an unspecified
+     parameter; any number of the parameters may be sent, from 0 to 3.
+
+   The largest prime factor: the encoded value that is the LPF of the
+     group size, a multi-precision integer.
+
+   EC only:  The order of the group: multi-precision integer.
+     (The group size for MODP is always P-1.)
+
+   Strength of group: 32-bit integer.
+     The strength of the group is approximately the number of key-bits
+     protected.
+        It is determined by the log2 of the effort to attack the group.
+        It may change as we learn more about cryptography.
+
+   This is a generic example for a "classic" modular exponentiation group:
+     Group type: "MODP"
+     Size of a field element in bits:  Log2 (P) rounded *up*.  A 32bit
+        integer.
+     Defining prime P: a multi-precision integer.
+     Generator G: a multi-precision integer.  2 <= G <= P-2.
+
+
+
+Orman                        Informational                     [Page 38]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+     <optional>
+     Largest prime factor of P-1: the multi-precision integer Q
+     Strength of group: a 32-bit integer.  We will specify a formula
+       for calculating this number (TBD).
+
+   This is a generic example for an elliptic curve group, mod P:
+      Group type: "ECP"
+      Size of a field element in bits:  Log2 (P) rounded *up*,
+          a 32 bit integer.
+      Defining prime P: a multi-precision integer.
+      Generator (X,Y): 2 multi-precision integers, each < P.
+      Parameters of the curve A,B: 2 multi-precision integers, each < P.
+      <optional>
+      Largest prime factor of the group order: a multi-precision integer.
+      Order of the group: a multi-precision integer.
+      Strength of group:  a 32-bit integer.  Formula TBD.
+
+   This is a specific example for an elliptic curve group:
+      Group type: "EC2N"
+      Degree of the irreducible polynomial: 155
+      Irreducible polynomial:  U^155 + U^62 + 1, represented as the
+        multi-precision integer 2^155 + 2^62 + 1.
+      Generator (X,Y) : represented as 2 multi-precision integers, each
+        < 2^155.
+      For our present curve, these are (decimal) 123 and 456.  Each is
+        represented as a multi-precision integer.
+      Parameters of the curve A,B: represented as 2 multi-precision
+        integers,  each < 2^155.
+      For our present curve these are 0 and (decimal) 471951, represented
+        as two multi-precision integers.
+
+      <optional>
+      Largest prime factor of the group order:
+
+       3805993847215893016155463826195386266397436443,
+
+      represented as a multi-precision integer.
+      The order of the group:
+
+        45671926166590716193865565914344635196769237316
+
+      represented as a multi-precision integer.
+
+      Strength of group: 76, represented as a 32-bit integer.
+
+   The variable precision integer encoding for group descriptor fields
+   is the following.  This is a slight variation on the format defined
+   in Appendix C in that a fixed 16-bit value is used first, and the
+
+
+
+Orman                        Informational                     [Page 39]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+   length is limited to 16 bits.  However, the interpretation is
+   otherwise identical.
+
+                             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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    !   Fixed value (TBD)           !             Length            !
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    .                                                               .
+    .                  Integer                                      .
+    .                                                               .
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   The format of a group descriptor is:
+                             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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !1!1!     Group Description     !             MODP              !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !1!0!        Field Size         !            Length             !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !                              MPI                              !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !1!0!          Prime            !            Length             !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !                              MPI                              !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !1!0!       Generator1          !            Length             !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !                              MPI                              !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !1!0!       Generator2          !            Length             !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !                              MPI                              !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !1!0!         Curve-p1          !            Length             !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !                              MPI                              !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !1!0!         Curve-p2          !            Length             !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !                              MPI                              !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !1!0!   Largest Prime Factor    !            Length             !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !                              MPI                              !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Orman                        Informational                     [Page 40]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+   !1!0!      Order of Group       !            Length             !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !                              MPI                              !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !0!0!    Strength of Group      !            Length             !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   !                              MPI                              !
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Orman                        Informational                     [Page 41]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+APPENDIX B  Message formats
+
+   The encodings of Oakley messages into ISAKMP payloads is deferred to
+   the ISAKMP/Oakley Resolution document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Orman                        Informational                     [Page 42]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+APPENDIX C Encoding a variable precision integer.
+
+   Variable precision integers will be encoded as a 32-bit length field
+   followed by one or more 32-bit quantities containing the
+   representation of the integer, aligned with the most significant bit
+   in the first 32-bit item.
+
+                           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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !    length                                                     !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !    first value word (most significant bits)                   !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !                                                               !
+      ~     additional value words                                    ~
+      !                                                               !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   An example of such an encoding is given below, for a number with 51
+   bits of significance.  The length field indicates that 2 32-bit
+   quantities follow.  The most significant non-zero bit of the number
+   is in bit 13 of the first 32-bit quantity, the low order bits are in
+   the second 32-bit quantity.
+
+                            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
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       !                                                            1 0!
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       !0 0 0 0 0 0 0 0 0 0 0 0 0 1 x x x x x x x x x x x x x x x x x x!
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       !x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x!
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Orman                        Informational                     [Page 43]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+APPENDIX D Cryptographic strengths
+
+   The Diffie-Hellman algorithm is used to compute keys that will be
+   used with symmetric algorithms.  It should be no easier to break the
+   Diffie-Hellman computation than it is to do an exhaustive search over
+   the symmetric key space.  A recent recommendation by an group of
+   cryptographers [Blaze] has recommended a symmetric key size of 75
+   bits for a practical level of security.  For 20 year security, they
+   recommend 90 bits.
+
+   Based on that report, a conservative strategy for OAKLEY users would
+   be to ensure that their Diffie-Hellman computations were as secure as
+   at least a 90-bit key space.  In order to accomplish this for modular
+   exponentiation groups, the size of the largest prime factor of the
+   modulus should be at least 180 bits, and the size of the modulus
+   should be at least 1400 bits.  For elliptic curve groups, the LPF
+   should be at least 180 bits.
+
+   If long-term secrecy of the encryption key is not an issue, then the
+   following parameters may be used for the modular exponentiation
+   group: 150 bits for the LPF, 980 bits for the modulus size.
+
+   The modulus size alone does not determine the strength of the
+   Diffie-Hellman calculation; the size of the exponent used in
+   computing powers within the group is also important.  The size of the
+   exponent in bits should be at least twice the size of any symmetric
+   key that will be derived from it.  We recommend that ISAKMP
+   implementors use at least 180 bits of exponent (twice the size of a
+   20-year symmetric key).
+
+   The mathematical justification for these estimates can be found in
+   texts that estimate the effort for solving the discrete log problem,
+   a task that is strongly related to the efficiency of using the Number
+   Field Sieve for factoring large integers.  Readers are referred to
+   [Stinson] and [Schneier].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Orman                        Informational                     [Page 44]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+APPENDIX E The Well-Known Groups
+
+   The group identifiers:
+
+      0   No group (used as a placeholder and for non-DH exchanges)
+      1   A modular exponentiation group with a 768 bit modulus
+      2   A modular exponentiation group with a 1024 bit modulus
+      3   A modular exponentiation group with a 1536 bit modulus (TBD)
+      4   An elliptic curve group over GF[2^155]
+      5   An elliptic curve group over GF[2^185]
+
+      values 2^31 and higher are used for private group identifiers
+
+   Richard Schroeppel performed all the mathematical and computational
+   work for this appendix.
+
+   Classical Diffie-Hellman Modular Exponentiation Groups
+
+   The primes for groups 1 and 2 were selected to have certain
+   properties.  The high order 64 bits are forced to 1.  This helps the
+   classical remainder algorithm, because the trial quotient digit can
+   always be taken as the high order word of the dividend, possibly +1.
+   The low order 64 bits are forced to 1.  This helps the Montgomery-
+   style remainder algorithms, because the multiplier digit can always
+   be taken to be the low order word of the dividend.  The middle bits
+   are taken from the binary expansion of pi.  This guarantees that they
+   are effectively random, while avoiding any suspicion that the primes
+   have secretly been selected to be weak.
+
+   Because both primes are based on pi, there is a large section of
+   overlap in the hexadecimal representations of the two primes.  The
+   primes are chosen to be Sophie Germain primes (i.e., (P-1)/2 is also
+   prime), to have the maximum strength against the square-root attack
+   on the discrete logarithm problem.
+
+   The starting trial numbers were repeatedly incremented by 2^64 until
+   suitable primes were located.
+
+   Because these two primes are congruent to 7 (mod 8), 2 is a quadratic
+   residue of each prime.  All powers of 2 will also be quadratic
+   residues.  This prevents an opponent from learning the low order bit
+   of the Diffie-Hellman exponent (AKA the subgroup confinement
+   problem).  Using 2 as a generator is efficient for some modular
+   exponentiation algorithms.  [Note that 2 is technically not a
+   generator in the number theory sense, because it omits half of the
+   possible residues mod P.  From a cryptographic viewpoint, this is a
+   virtue.]
+
+
+
+
+Orman                        Informational                     [Page 45]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+E.1. Well-Known Group 1:  A 768 bit prime
+
+   The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }.  Its
+   decimal value is
+          155251809230070893513091813125848175563133404943451431320235
+          119490296623994910210725866945387659164244291000768028886422
+          915080371891804634263272761303128298374438082089019628850917
+          0691316593175367469551763119843371637221007210577919
+
+   This has been rigorously verified as a prime.
+
+   The representation of the group in OAKLEY is
+
+      Type of group:                    "MODP"
+      Size of field element (bits):      768
+      Prime modulus:                     21 (decimal)
+         Length (32 bit words):          24
+         Data (hex):
+            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+            E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
+      Generator:                         22 (decimal)
+         Length (32 bit words):          1
+         Data (hex):                     2
+
+      Optional Parameters:
+      Group order largest prime factor:  24 (decimal)
+         Length (32 bit words):          24
+         Data (hex):
+            7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68
+            94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E
+            F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122
+            F242DABB 312F3F63 7A262174 D31D1B10 7FFFFFFF FFFFFFFF
+      Strength of group:                 26 (decimal)
+         Length (32 bit words)            1
+         Data (hex):
+            00000042
+
+E.2. Well-Known Group 2:  A 1024 bit prime
+
+   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
+   Its decimal value is
+         179769313486231590770839156793787453197860296048756011706444
+         423684197180216158519368947833795864925541502180565485980503
+         646440548199239100050792877003355816639229553136239076508735
+         759914822574862575007425302077447712589550957937778424442426
+         617334727629299387668709205606050270810842907692932019128194
+
+
+
+Orman                        Informational                     [Page 46]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+         467627007
+
+   The primality of the number has been rigorously proven.
+
+   The representation of the group in OAKLEY is
+      Type of group:                    "MODP"
+      Size of field element (bits):      1024
+      Prime modulus:                     21 (decimal)
+         Length (32 bit words):          32
+         Data (hex):
+            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
+            FFFFFFFF FFFFFFFF
+      Generator:                         22 (decimal)
+         Length (32 bit words):          1
+         Data (hex):                     2
+
+      Optional Parameters:
+      Group order largest prime factor:  24 (decimal)
+         Length (32 bit words):          32
+         Data (hex):
+            7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68
+            94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E
+            F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122
+            F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6
+            F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F67329C0
+            FFFFFFFF FFFFFFFF
+      Strength of group:                 26 (decimal)
+         Length (32 bit words)            1
+         Data (hex):
+            0000004D
+
+E.3. Well-Known Group 3:  An Elliptic Curve Group Definition
+
+   The curve is based on the Galois field GF[2^155] with 2^155 field
+   elements.  The irreducible polynomial for the field is u^155 + u^62 +
+   1.  The equation for the elliptic curve is
+
+   Y^2 + X Y = X^3 + A X + B
+
+   X, Y, A, B are elements of the field.
+
+   For the curve specified, A = 0 and
+
+    B = u^18 + u^17 + u^16 + u^13 + u^12 + u^9 + u^8 + u^7 + u^3 + u^2 +
+
+
+
+Orman                        Informational                     [Page 47]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+   u + 1.
+
+   B is represented in binary as the bit string 1110011001110001111; in
+   decimal this is 471951, and in hex 7338F.
+
+   The generator is a point (X,Y) on the curve (satisfying the curve
+   equation, mod 2 and modulo the field polynomial).
+
+   X = u^6 + u^5 + u^4 + u^3 + u + 1
+
+   and
+
+   Y = u^8 + u^7 + u^6 + u^3.
+
+   The binary bit strings for X and Y are 1111011 and 111001000; in
+   decimal they are 123 and 456.
+
+   The group order (the number of curve points) is
+        45671926166590716193865565914344635196769237316
+   which is 12 times the prime
+
+         3805993847215893016155463826195386266397436443.
+   (This prime has been rigorously proven.)  The generating point (X,Y)
+   has order 4 times the prime; the generator is the triple of some
+   curve point.
+
+   OAKLEY representation of this group:
+      Type of group:                    "EC2N"
+      Size of field element (bits):      155
+      Irreducible field polynomial:      21 (decimal)
+         Length (32 bit words):          5
+         Data (hex):
+            08000000 00000000 00000000 40000000 00000001
+      Generator:
+         X coordinate:                   22 (decimal)
+             Length (32 bit words):      1
+             Data (hex):                 7B
+         Y coordinate:                   22 (decimal)
+             Length (32 bit words):      1
+             Data (hex):                 1C8
+      Elliptic curve parameters:
+         A parameter:                    23 (decimal)
+             Length (32 bit words):      1
+             Data (hex):                 0
+         B parameter:                    23 (decimal)
+             Length (32 bit words):      1
+             Data (hex):                 7338F
+
+
+
+
+Orman                        Informational                     [Page 48]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+      Optional Parameters:
+      Group order largest prime factor:  24 (decimal)
+         Length (32 bit words):          5
+         Data (hex):
+            00AAAAAA AAAAAAAA AAAAB1FC F1E206F4 21A3EA1B
+      Group order:                       25 (decimal)
+         Length (32 bit words):          5
+         Data (hex):
+            08000000 00000000 000057DB 56985371 93AEF944
+      Strength of group:                 26 (decimal)
+         Length (32 bit words)            1
+         Data (hex):
+            0000004C
+
+E.4. Well-Known Group 4:  A Large Elliptic Curve Group Definition
+
+   This curve is based on the Galois field GF[2^185] with 2^185 field
+   elements.  The irreducible polynomial for the field is
+
+   u^185 + u^69 + 1.
+
+   The equation for the elliptic curve is
+
+   Y^2 + X Y = X^3 + A X + B.
+
+   X, Y, A, B are elements of the field.  For the curve specified, A = 0
+   and
+
+   B = u^12 + u^11 + u^10 + u^9 + u^7 + u^6 + u^5 + u^3 + 1.
+
+   B is represented in binary as the bit string 1111011101001; in
+   decimal this is 7913, and in hex 1EE9.
+
+   The generator is a point (X,Y) on the curve (satisfying the curve
+   equation, mod 2 and modulo the field polynomial);
+
+   X = u^4 + u^3 and Y = u^3 + u^2 + 1.
+
+   The binary bit strings for X and Y are 11000 and 1101; in decimal
+   they are 24 and 13.  The group order (the number of curve points) is
+
+        49039857307708443467467104857652682248052385001045053116,
+
+   which is 4 times the prime
+
+        12259964326927110866866776214413170562013096250261263279.
+
+   (This prime has been rigorously proven.)
+
+
+
+Orman                        Informational                     [Page 49]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+   The generating point (X,Y) has order 2 times the prime; the generator
+   is the double of some curve point.
+
+   OAKLEY representation of this group:
+
+      Type of group:                    "EC2N"
+      Size of field element (bits):      185
+      Irreducible field polynomial:      21 (decimal)
+         Length (32 bit words):          6
+         Data (hex):
+            02000000 00000000 00000000 00000020 00000000 00000001
+      Generator:
+         X coordinate:                   22 (decimal)
+             Length (32 bit words):      1
+             Data (hex):                 18
+         Y coordinate:                   22 (decimal)
+             Length (32 bit words):      1
+             Data (hex):                 D
+      Elliptic curve parameters:
+         A parameter:                    23 (decimal)
+             Length (32 bit words):      1
+             Data (hex):                 0
+         B parameter:                    23 (decimal)
+             Length (32 bit words):      1
+             Data (hex):                 1EE9
+
+      Optional parameters:
+      Group order largest prime factor:  24 (decimal)
+         Length (32 bit words):          6
+         Data (hex):
+            007FFFFF FFFFFFFF FFFFFFFF F6FCBE22 6DCF9210 5D7E53AF
+      Group order:                       25 (decimal)
+         Length (32 bit words):          6
+         Data (hex):
+            01FFFFFF FFFFFFFF FFFFFFFF DBF2F889 B73E4841 75F94EBC
+      Strength of group:                 26 (decimal)
+         Length (32 bit words)            1
+         Data (hex):
+            0000005B
+
+E.5. Well-Known Group 5:  A 1536 bit prime
+
+      The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] +  741804
+   }.
+      Its decimal value is
+            241031242692103258855207602219756607485695054850245994265411
+            694195810883168261222889009385826134161467322714147790401219
+            650364895705058263194273070680500922306273474534107340669624
+
+
+
+Orman                        Informational                     [Page 50]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+            601458936165977404102716924945320037872943417032584377865919
+            814376319377685986952408894019557734611984354530154704374720
+            774996976375008430892633929555996888245787241299381012913029
+            459299994792636526405928464720973038494721168143446471443848
+            8520940127459844288859336526896320919633919
+
+      The primality of the number has been rigorously proven.
+
+      The representation of the group in OAKLEY is
+         Type of group:                    "MODP"
+         Size of field element (bits):      1536
+         Prime modulus:                     21 (decimal)
+            Length (32 bit words):          48
+            Data (hex):
+               FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+               29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+               EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+               E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+               EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
+               C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
+               83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+               670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
+         Generator:                         22 (decimal)
+            Length (32 bit words):          1
+            Data (hex):                     2
+
+         Optional Parameters:
+         Group order largest prime factor:  24 (decimal)
+            Length (32 bit words):          48
+            Data (hex):
+               7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68
+               94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E
+               F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122
+               F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6
+               F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E
+               E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF
+               C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36
+               B3861AA7 255E4C02 78BA3604 6511B993 FFFFFFFF FFFFFFFF
+         Strength of group:                 26 (decimal)
+            Length (32 bit words)            1
+            Data (hex):
+               0000005B
+
+
+
+
+
+
+
+
+
+Orman                        Informational                     [Page 51]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+Appendix F  Implementing Group Operations
+
+   The group operation must be implemented as a sequence of arithmetic
+   operations; the exact operations depend on the type of group.  For
+   modular exponentiation groups, the operation is multi-precision
+   integer multiplication and remainders by the group modulus.  See
+   Knuth Vol. 2 [Knuth] for a discussion of how to implement these for
+   large integers.  Implementation recommendations for elliptic curve
+   group operations over GF[2^N] are described in [Schroeppel].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Orman                        Informational                     [Page 52]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+BIBLIOGRAPHY
+
+   [RFC2401]    Atkinson, R., "Security Architecture for the
+                Internet Protocol", RFC 2401, November 1998.
+
+   [RFC2406]    Atkinson, R., "IP Encapsulating Security Payload (ESP)",
+                RFC 2406, November 1998.
+
+   [RFC2402]    Atkinson, R., "IP Authentication Header", RFC 2402,
+                November 1998.
+
+   [Blaze]      Blaze, Matt et al., MINIMAL KEY LENGTHS FOR SYMMETRIC
+                CIPHERS TO PROVIDE ADEQUATE COMMERCIAL SECURITY. A
+                REPORT BY AN AD HOC GROUP OF CRYPTOGRAPHERS AND COMPUTER
+                SCIENTISTS...  --
+                http://www.bsa.org/policy/encryption/cryptographers.html
+
+   [STS]        W. Diffie, P.C. Van Oorschot, and M.J. Wiener,
+                "Authentication and Authenticated Key Exchanges," in
+                Designs, Codes and Cryptography, Kluwer Academic
+                Publishers, 1992, pp. 107
+
+   [SECDNS]     Eastlake, D. and C. Kaufman, "Domain Name System
+                Security Extensions", RFC 2065, January 1997.
+
+   [Random]     Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+                Recommendations for Security", RFC 1750, December 1994.
+
+   [Kocher]     Kocher, Paul, Timing Attack,
+                http://www.cryptography.com/timingattack.old/timingattack.html
+
+   [Knuth]      Knuth, Donald E., The Art of Computer Programming, Vol.
+                2, Seminumerical Algorithms, Addison Wesley, 1969.
+
+   [Krawcyzk]   Krawcyzk, Hugo, SKEME: A Versatile Secure Key Exchange
+                Mechanism for Internet, ISOC Secure Networks and
+                Distributed Systems Symposium, San Diego, 1996
+
+   [Schneier]   Schneier, Bruce, Applied cryptography: protocols,
+                algorithms, and source code in C, Second edition, John
+                Wiley & Sons, Inc. 1995, ISBN 0-471-12845-7, hardcover.
+                ISBN 0-471-11709-9, softcover.
+
+   [Schroeppel] Schroeppel, Richard, et al.; Fast Key Exchange with
+                Elliptic Curve Systems, Crypto '95, Santa Barbara, 1995.
+                Available on-line as
+                ftp://ftp.cs.arizona.edu/reports/1995/TR95-03.ps (and
+                .Z).
+
+
+
+Orman                        Informational                     [Page 53]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+   [Stinson]    Stinson, Douglas, Cryptography Theory and Practice. CRC
+                Press, Inc., 2000, Corporate Blvd., Boca Raton, FL,
+                33431-9868, ISBN 0-8493-8521-0, 1995
+
+   [Zimmerman]  Philip Zimmermann, The Official Pgp User's Guide,
+                Published by MIT Press Trade, Publication date: June
+                1995, ISBN: 0262740176
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Orman                        Informational                     [Page 54]
+
+RFC 2412         The OAKLEY Key Determination Protocol     November 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Orman                        Informational                     [Page 55]
+