doc: Add RFC documents

1 files changed, 2299 insertions, 0 deletions

diff --git a/doc/rfc/rfc2409.txt b/doc/rfc/rfc2409.txt
new file mode 100644
index 0000000..9d3e6f8
--- /dev/null
+++ b/doc/rfc/rfc2409.txt
@@ -0,0 +1,2299 @@
+
+
+
+
+
+
+Network Working Group                                         D. Harkins
+Request for Comments: 2409                                     D. Carrel
+Category: Standards Track                                  cisco Systems
+                                                           November 1998
+
+
+                    The Internet Key Exchange (IKE)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Table Of Contents
+
+   1 Abstract........................................................  2
+   2 Discussion......................................................  2
+   3 Terms and Definitions...........................................  3
+   3.1 Requirements Terminology......................................  3
+   3.2 Notation......................................................  3
+   3.3 Perfect Forward Secrecty......................................  5
+   3.4 Security Association..........................................  5
+   4 Introduction....................................................  5
+   5 Exchanges.......................................................  8
+   5.1 Authentication with Digital Signatures........................ 10
+   5.2 Authentication with Public Key Encryption..................... 12
+   5.3 A Revised method of Authentication with Public Key Encryption. 13
+   5.4 Authentication with a Pre-Shared Key.......................... 16
+   5.5 Quick Mode.................................................... 16
+   5.6 New Group Mode................................................ 20
+   5.7 ISAKMP Informational Exchanges................................ 20
+   6 Oakley Groups................................................... 21
+   6.1 First Oakley Group............................................ 21
+   6.2 Second Oakley Group........................................... 22
+   6.3 Third Oakley Group............................................ 22
+   6.4 Fourth Oakley Group........................................... 23
+   7 Payload Explosion of Complete Exchange.......................... 23
+   7.1 Phase 1 with Main Mode........................................ 23
+   7.2 Phase 2 with Quick Mode....................................... 25
+   8 Perfect Forward Secrecy Example................................. 27
+   9 Implementation Hints............................................ 27
+
+
+
+Harkins & Carrel            Standards Track                     [Page 1]
+
+RFC 2409                          IKE                      November 1998
+
+
+   10 Security Considerations........................................ 28
+   11 IANA Considerations............................................ 30
+   12 Acknowledgments................................................ 31
+   13 References..................................................... 31
+   Appendix A........................................................ 33
+   Appendix B........................................................ 37
+   Authors' Addresses................................................ 40
+   Authors' Note..................................................... 40
+   Full Copyright Statement.......................................... 41
+
+1. Abstract
+
+   ISAKMP ([MSST98]) provides a framework for authentication and key
+   exchange but does not define them.  ISAKMP is designed to be key
+   exchange independant; that is, it is designed to support many
+   different key exchanges.
+
+   Oakley ([Orm96]) describes a series of key exchanges-- called
+   "modes"-- and details the services provided by each (e.g. perfect
+   forward secrecy for keys, identity protection, and authentication).
+
+   SKEME ([SKEME]) describes a versatile key exchange technique which
+   provides anonymity, repudiability, and quick key refreshment.
+
+   This document describes a protocol using part of Oakley and part of
+   SKEME in conjunction with ISAKMP to obtain authenticated keying
+   material for use with ISAKMP, and for other security associations
+   such as AH and ESP for the IETF IPsec DOI.
+
+2. Discussion
+
+   This memo describes a hybrid protocol. The purpose is to negotiate,
+   and provide authenticated keying material for, security associations
+   in a protected manner.
+
+   Processes which implement this memo can be used for negotiating
+   virtual private networks (VPNs) and also for providing a remote user
+   from a remote site (whose IP address need not be known beforehand)
+   access to a secure host or network.
+
+   Client negotiation is supported.  Client mode is where the
+   negotiating parties are not the endpoints for which security
+   association negotiation is taking place.  When used in client mode,
+   the identities of the end parties remain hidden.
+
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                     [Page 2]
+
+RFC 2409                          IKE                      November 1998
+
+
+   This does not implement the entire Oakley protocol, but only a subset
+   necessary to satisfy its goals. It does not claim conformance or
+   compliance with the entire Oakley protocol nor is it dependant in any
+   way on the Oakley protocol.
+
+   Likewise, this does not implement the entire SKEME protocol, but only
+   the method of public key encryption for authentication and its
+   concept of fast re-keying using an exchange of nonces. This protocol
+   is not dependant in any way on the SKEME protocol.
+
+3. Terms and Definitions
+
+3.1 Requirements Terminology
+
+   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
+   "MAY" that appear in this document are to be interpreted as described
+   in [Bra97].
+
+3.2 Notation
+
+   The following notation is used throughout this memo.
+
+     HDR is an ISAKMP header whose exchange type is the mode.  When
+     writen as HDR* it indicates payload encryption.
+
+     SA is an SA negotiation payload with one or more proposals. An
+     initiator MAY provide multiple proposals for negotiation; a
+     responder MUST reply with only one.
+
+     <P>_b indicates the body of payload <P>-- the ISAKMP generic
+     vpayload is not included.
+
+     SAi_b is the entire body of the SA payload (minus the ISAKMP
+     generic header)-- i.e. the DOI, situation, all proposals and all
+     transforms offered by the Initiator.
+
+     CKY-I and CKY-R are the Initiator's cookie and the Responder's
+     cookie, respectively, from the ISAKMP header.
+
+     g^xi and g^xr are the Diffie-Hellman ([DH]) public values of the
+     initiator and responder respectively.
+
+     g^xy is the Diffie-Hellman shared secret.
+
+     KE is the key exchange payload which contains the public
+     information exchanged in a Diffie-Hellman exchange. There is no
+     particular encoding (e.g. a TLV) used for the data of a KE payload.
+
+
+
+
+Harkins & Carrel            Standards Track                     [Page 3]
+
+RFC 2409                          IKE                      November 1998
+
+
+     Nx is the nonce payload; x can be: i or r for the ISAKMP initiator
+     and responder respectively.
+
+     IDx is the identification payload for "x".  x can be: "ii" or "ir"
+     for the ISAKMP initiator and responder respectively during phase
+     one negotiation; or "ui" or "ur" for the user initiator and
+     responder respectively during phase two.  The ID payload format for
+     the Internet DOI is defined in [Pip97].
+
+     SIG is the signature payload. The data to sign is exchange-
+     specific.
+
+     CERT is the certificate payload.
+
+     HASH (and any derivitive such as HASH(2) or HASH_I) is the hash
+     payload. The contents of the hash are specific to the
+     authentication method.
+
+     prf(key, msg) is the keyed pseudo-random function-- often a keyed
+     hash function-- used to generate a deterministic output that
+     appears pseudo-random.  prf's are used both for key derivations and
+     for authentication (i.e. as a keyed MAC). (See [KBC96]).
+
+     SKEYID is a string derived from secret material known only to the
+     active players in the exchange.
+
+     SKEYID_e is the keying material used by the ISAKMP SA to protect
+     the confidentiality of its messages.
+
+     SKEYID_a is the keying material used by the ISAKMP SA to
+     authenticate its messages.
+
+     SKEYID_d is the keying material used to derive keys for non-ISAKMP
+     security associations.
+
+     <x>y indicates that "x" is encrypted with the key "y".
+
+     --> signifies "initiator to responder" communication (requests).
+
+     <-- signifies "responder to initiator" communication (replies).
+
+      |  signifies concatenation of information-- e.g. X | Y is the
+     concatentation of X with Y.
+
+     [x] indicates that x is optional.
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                     [Page 4]
+
+RFC 2409                          IKE                      November 1998
+
+
+   Message encryption (when noted by a '*' after the ISAKMP header) MUST
+   begin immediately after the ISAKMP header. When communication is
+   protected, all payloads following the ISAKMP header MUST be
+   encrypted.  Encryption keys are generated from SKEYID_e in a manner
+   that is defined for each algorithm.
+
+3.3 Perfect Forward Secrecy
+
+   When used in the memo Perfect Forward Secrecy (PFS) refers to the
+   notion that compromise of a single key will permit access to only
+   data protected by a single key. For PFS to exist the key used to
+   protect transmission of data MUST NOT be used to derive any
+   additional keys, and if the key used to protect transmission of data
+   was derived from some other keying material, that material MUST NOT
+   be used to derive any more keys.
+
+   Perfect Forward Secrecy for both keys and identities is provided in
+   this protocol. (Sections 5.5 and 8).
+
+3.4 Security Association
+
+   A security association (SA) is a set of policy and key(s) used to
+   protect information. The ISAKMP SA is the shared policy and key(s)
+   used by the negotiating peers in this protocol to protect their
+   communication.
+
+4. Introduction
+
+   Oakley and SKEME each define a method to establish an authenticated
+   key exchange. This includes payloads construction, the information
+   payloads carry, the order in which they are processed and how they
+   are used.
+
+   While Oakley defines "modes", ISAKMP defines "phases".  The
+   relationship between the two is very straightforward and IKE presents
+   different exchanges as modes which operate in one of two phases.
+
+   Phase 1 is where the two ISAKMP peers establish a secure,
+   authenticated channel with which to communicate.  This is called the
+   ISAKMP Security Association (SA). "Main Mode" and "Aggressive Mode"
+   each accomplish a phase 1 exchange. "Main Mode" and "Aggressive Mode"
+   MUST ONLY be used in phase 1.
+
+   Phase 2 is where Security Associations are negotiated on behalf of
+   services such as IPsec or any other service which needs key material
+   and/or parameter negotiation. "Quick Mode" accomplishes a phase 2
+   exchange. "Quick Mode" MUST ONLY be used in phase 2.
+
+
+
+
+Harkins & Carrel            Standards Track                     [Page 5]
+
+RFC 2409                          IKE                      November 1998
+
+
+   "New Group Mode" is not really a phase 1 or phase 2.  It follows
+   phase 1, but serves to establish a new group which can be used in
+   future negotiations. "New Group Mode" MUST ONLY be used after phase
+   1.
+
+   The ISAKMP SA is bi-directional. That is, once established, either
+   party may initiate Quick Mode, Informational, and New Group Mode
+   Exchanges.  Per the base ISAKMP document, the ISAKMP SA is identified
+   by the Initiator's cookie followed by the Responder's cookie-- the
+   role of each party in the phase 1 exchange dictates which cookie is
+   the Initiator's. The cookie order established by the phase 1 exchange
+   continues to identify the ISAKMP SA regardless of the direction the
+   Quick Mode, Informational, or New Group exchange. In other words, the
+   cookies MUST NOT swap places when the direction of the ISAKMP SA
+   changes.
+
+   With the use of ISAKMP phases, an implementation can accomplish very
+   fast keying when necessary.  A single phase 1 negotiation may be used
+   for more than one phase 2 negotiation.  Additionally a single phase 2
+   negotiation can request multiple Security Associations.  With these
+   optimizations, an implementation can see less than one round trip per
+   SA as well as less than one DH exponentiation per SA.  "Main Mode"
+   for phase 1 provides identity protection.  When identity protection
+   is not needed, "Aggressive Mode" can be used to reduce round trips
+   even further.  Developer hints for doing these optimizations are
+   included below. It should also be noted that using public key
+   encryption to authenticate an Aggressive Mode exchange will still
+   provide identity protection.
+
+   This protocol does not define its own DOI per se. The ISAKMP SA,
+   established in phase 1, MAY use the DOI and situation from a non-
+   ISAKMP service (such as the IETF IPSec DOI [Pip97]). In this case an
+   implementation MAY choose to restrict use of the ISAKMP SA for
+   establishment of SAs for services of the same DOI. Alternately, an
+   ISAKMP SA MAY be established with the value zero in both the DOI and
+   situation (see [MSST98] for a description of these fields) and in
+   this case implementations will be free to establish security services
+   for any defined DOI using this ISAKMP SA. If a DOI of zero is used
+   for establishment of a phase 1 SA, the syntax of the identity
+   payloads used in phase 1 is that defined in [MSST98] and not from any
+   DOI-- e.g. [Pip97]-- which may further expand the syntax and
+   semantics of identities.
+
+   The following attributes are used by IKE and are negotiated as part
+   of the ISAKMP Security Association.  (These attributes pertain only
+   to the ISAKMP Security Association and not to any Security
+   Associations that ISAKMP may be negotiating on behalf of other
+   services.)
+
+
+
+Harkins & Carrel            Standards Track                     [Page 6]
+
+RFC 2409                          IKE                      November 1998
+
+
+      - encryption algorithm
+
+      - hash algorithm
+
+      - authentication method
+
+      - information about a group over which to do Diffie-Hellman.
+
+   All of these attributes are mandatory and MUST be negotiated. In
+   addition, it is possible to optionally negotiate a psuedo-random
+   function ("prf").  (There are currently no negotiable pseudo-random
+   functions defined in this document. Private use attribute values can
+   be used for prf negotiation between consenting parties). If a "prf"
+   is not negotiation, the HMAC (see [KBC96]) version of the negotiated
+   hash algorithm is used as a pseudo-random function. Other non-
+   mandatory attributes are described in Appendix A. The selected hash
+   algorithm MUST support both native and HMAC modes.
+
+   The Diffie-Hellman group MUST be either specified using a defined
+   group description (section 6) or by defining all attributes of a
+   group (section 5.6). Group attributes (such as group type or prime--
+   see Appendix A) MUST NOT be offered in conjunction with a previously
+   defined group (either a reserved group description or a private use
+   description that is established after conclusion of a New Group Mode
+   exchange).
+
+   IKE implementations MUST support the following attribute values:
+
+      - DES [DES] in CBC mode with a weak, and semi-weak, key check
+      (weak and semi-weak keys are referenced in [Sch96] and listed in
+      Appendix A). The key is derived according to Appendix B.
+
+      - MD5 [MD5] and SHA [SHA}.
+
+      - Authentication via pre-shared keys.
+
+      - MODP over default group number one (see below).
+
+   In addition, IKE implementations SHOULD support: 3DES for encryption;
+   Tiger ([TIGER]) for hash; the Digital Signature Standard, RSA [RSA]
+   signatures and authentication with RSA public key encryption; and
+   MODP group number 2.  IKE implementations MAY support any additional
+   encryption algorithms defined in Appendix A and MAY support ECP and
+   EC2N groups.
+
+   The IKE modes described here MUST be implemented whenever the IETF
+   IPsec DOI [Pip97] is implemented. Other DOIs MAY use the modes
+   described here.
+
+
+
+Harkins & Carrel            Standards Track                     [Page 7]
+
+RFC 2409                          IKE                      November 1998
+
+
+5. Exchanges
+
+   There are two basic methods used to establish an authenticated key
+   exchange: Main Mode and Aggressive Mode. Each generates authenticated
+   keying material from an ephemeral Diffie-Hellman exchange. Main Mode
+   MUST be implemented; Aggressive Mode SHOULD be implemented. In
+   addition, Quick Mode MUST be implemented as a mechanism to generate
+   fresh keying material and negotiate non-ISAKMP security services. In
+   addition, New Group Mode SHOULD be implemented as a mechanism to
+   define private groups for Diffie-Hellman exchanges. Implementations
+   MUST NOT switch exchange types in the middle of an exchange.
+
+   Exchanges conform to standard ISAKMP payload syntax, attribute
+   encoding, timeouts and retransmits of messages, and informational
+   messages-- e.g a notify response is sent when, for example, a
+   proposal is unacceptable, or a signature verification or decryption
+   was unsuccessful, etc.
+
+   The SA payload MUST precede all other payloads in a phase 1 exchange.
+   Except where otherwise noted, there are no requirements for ISAKMP
+   payloads in any message to be in any particular order.
+
+   The Diffie-Hellman public value passed in a KE payload, in either a
+   phase 1 or phase 2 exchange, MUST be the length of the negotiated
+   Diffie-Hellman group enforced, if necessary, by pre-pending the value
+   with zeros.
+
+   The length of nonce payload MUST be between 8 and 256 bytes
+   inclusive.
+
+   Main Mode is an instantiation of the ISAKMP Identity Protect
+   Exchange: The first two messages negotiate policy; the next two
+   exchange Diffie-Hellman public values and ancillary data (e.g.
+   nonces) necessary for the exchange; and the last two messages
+   authenticate the Diffie-Hellman Exchange. The authentication method
+   negotiated as part of the initial ISAKMP exchange influences the
+   composition of the payloads but not their purpose. The XCHG for Main
+   Mode is ISAKMP Identity Protect.
+
+   Similarly, Aggressive Mode is an instantiation of the ISAKMP
+   Aggressive Exchange. The first two messages negotiate policy,
+   exchange Diffie-Hellman public values and ancillary data necessary
+   for the exchange, and identities.  In addition the second message
+   authenticates the responder. The third message authenticates the
+   initiator and provides a proof of participation in the exchange. The
+   XCHG for Aggressive Mode is ISAKMP Aggressive.  The final message MAY
+   NOT be sent under protection of the ISAKMP SA allowing each party to
+
+
+
+
+Harkins & Carrel            Standards Track                     [Page 8]
+
+RFC 2409                          IKE                      November 1998
+
+
+   postpone exponentiation, if desired, until negotiation of this
+   exchange is complete. The graphic depictions of Aggressive Mode show
+   the final payload in the clear; it need not be.
+
+   Exchanges in IKE are not open ended and have a fixed number of
+   messages.  Receipt of a Certificate Request payload MUST NOT extend
+   the number of messages transmitted or expected.
+
+   Security Association negotiation is limited with Aggressive Mode. Due
+   to message construction requirements the group in which the Diffie-
+   Hellman exchange is performed cannot be negotiated. In addition,
+   different authentication methods may further constrain attribute
+   negotiation. For example, authentication with public key encryption
+   cannot be negotiated and when using the revised method of public key
+   encryption for authentication the cipher and hash cannot be
+   negotiated. For situations where the rich attribute negotiation
+   capabilities of IKE are required Main Mode may be required.
+
+   Quick Mode and New Group Mode have no analog in ISAKMP. The XCHG
+   values for Quick Mode and New Group Mode are defined in Appendix A.
+
+   Main Mode, Aggressive Mode, and Quick Mode do security association
+   negotiation. Security Association offers take the form of Tranform
+   Payload(s) encapsulated in Proposal Payload(s) encapsulated in
+   Security Association (SA) payload(s). If multiple offers are being
+   made for phase 1 exchanges (Main Mode and Aggressive Mode) they MUST
+   take the form of multiple Transform Payloads for a single Proposal
+   Payload in a single SA payload. To put it another way, for phase 1
+   exchanges there MUST NOT be multiple Proposal Payloads for a single
+   SA payload and there MUST NOT be multiple SA payloads. This document
+   does not proscribe such behavior on offers in phase 2 exchanges.
+
+   There is no limit on the number of offers the initiator may send to
+   the responder but conformant implementations MAY choose to limit the
+   number of offers it will inspect for performance reasons.
+
+   During security association negotiation, initiators present offers
+   for potential security associations to responders. Responders MUST
+   NOT modify attributes of any offer, attribute encoding excepted (see
+   Appendix A).  If the initiator of an exchange notices that attribute
+   values have changed or attributes have been added or deleted from an
+   offer made, that response MUST be rejected.
+
+   Four different authentication methods are allowed with either Main
+   Mode or Aggressive Mode-- digital signature, two forms of
+   authentication with public key encryption, or pre-shared key. The
+   value SKEYID is computed seperately for each authentication method.
+
+
+
+
+Harkins & Carrel            Standards Track                     [Page 9]
+
+RFC 2409                          IKE                      November 1998
+
+
+     For signatures:            SKEYID = prf(Ni_b | Nr_b, g^xy)
+     For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I |
+   CKY-R)
+     For pre-shared keys:       SKEYID = prf(pre-shared-key, Ni_b |
+   Nr_b)
+
+   The result of either Main Mode or Aggressive Mode is three groups of
+   authenticated keying material:
+
+      SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
+      SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
+      SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
+
+   and agreed upon policy to protect further communications. The values
+   of 0, 1, and 2 above are represented by a single octet. The key used
+   for encryption is derived from SKEYID_e in an algorithm-specific
+   manner (see appendix B).
+
+   To authenticate either exchange the initiator of the protocol
+   generates HASH_I and the responder generates HASH_R where:
+
+    HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
+    HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
+
+   For authentication with digital signatures, HASH_I and HASH_R are
+   signed and verified; for authentication with either public key
+   encryption or pre-shared keys, HASH_I and HASH_R directly
+   authenticate the exchange.  The entire ID payload (including ID type,
+   port, and protocol but excluding the generic header) is hashed into
+   both HASH_I and HASH_R.
+
+   As mentioned above, the negotiated authentication method influences
+   the content and use of messages for Phase 1 Modes, but not their
+   intent.  When using public keys for authentication, the Phase 1
+   exchange can be accomplished either by using signatures or by using
+   public key encryption (if the algorithm supports it). Following are
+   Phase 1 exchanges with different authentication options.
+
+5.1 IKE Phase 1 Authenticated With Signatures
+
+   Using signatures, the ancillary information exchanged during the
+   second roundtrip are nonces; the exchange is authenticated by signing
+   a mutually obtainable hash. Main Mode with signature authentication
+   is described as follows:
+
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 10]
+
+RFC 2409                          IKE                      November 1998
+
+
+        Initiator                          Responder
+       -----------                        -----------
+        HDR, SA                     -->
+                                    <--    HDR, SA
+        HDR, KE, Ni                 -->
+                                    <--    HDR, KE, Nr
+        HDR*, IDii, [ CERT, ] SIG_I -->
+                                    <--    HDR*, IDir, [ CERT, ] SIG_R
+
+   Aggressive mode with signatures in conjunction with ISAKMP is
+   described as follows:
+
+        Initiator                          Responder
+       -----------                        -----------
+        HDR, SA, KE, Ni, IDii       -->
+                                    <--    HDR, SA, KE, Nr, IDir,
+                                                [ CERT, ] SIG_R
+        HDR, [ CERT, ] SIG_I        -->
+
+   In both modes, the signed data, SIG_I or SIG_R, is the result of the
+   negotiated digital signature algorithm applied to HASH_I or HASH_R
+   respectively.
+
+   In general the signature will be over HASH_I and HASH_R as above
+   using the negotiated prf, or the HMAC version of the negotiated hash
+   function (if no prf is negotiated). However, this can be overridden
+   for construction of the signature if the signature algorithm is tied
+   to a particular hash algorithm (e.g. DSS is only defined with SHA's
+   160 bit output). In this case, the signature will be over HASH_I and
+   HASH_R as above, except using the HMAC version of the hash algorithm
+   associated with the signature method.  The negotiated prf and hash
+   function would continue to be used for all other prescribed pseudo-
+   random functions.
+
+   Since the hash algorithm used is already known there is no need to
+   encode its OID into the signature. In addition, there is no binding
+   between the OIDs used for RSA signatures in PKCS #1 and those used in
+   this document. Therefore, RSA signatures MUST be encoded as a private
+   key encryption in PKCS #1 format and not as a signature in PKCS #1
+   format (which includes the OID of the hash algorithm). DSS signatures
+   MUST be encoded as r followed by s.
+
+   One or more certificate payloads MAY be optionally passed.
+
+
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 11]
+
+RFC 2409                          IKE                      November 1998
+
+
+5.2 Phase 1 Authenticated With Public Key Encryption
+
+   Using public key encryption to authenticate the exchange, the
+   ancillary information exchanged is encrypted nonces. Each party's
+   ability to reconstruct a hash (proving that the other party decrypted
+   the nonce) authenticates the exchange.
+
+   In order to perform the public key encryption, the initiator must
+   already have the responder's public key. In the case where the
+   responder has multiple public keys, a hash of the certificate the
+   initiator is using to encrypt the ancillary information is passed as
+   part of the third message. In this way the responder can determine
+   which corresponding private key to use to decrypt the encrypted
+   payloads and identity protection is retained.
+
+   In addition to the nonce, the identities of the parties (IDii and
+   IDir) are also encrypted with the other party's public key. If the
+   authentication method is public key encryption, the nonce and
+   identity payloads MUST be encrypted with the public key of the other
+   party. Only the body of the payloads are encrypted, the payload
+   headers are left in the clear.
+
+   When using encryption for authentication, Main Mode is defined as
+   follows.
+
+        Initiator                        Responder
+       -----------                      -----------
+        HDR, SA                   -->
+                                  <--    HDR, SA
+        HDR, KE, [ HASH(1), ]
+          <IDii_b>PubKey_r,
+            <Ni_b>PubKey_r        -->
+                                         HDR, KE, <IDir_b>PubKey_i,
+                                  <--            <Nr_b>PubKey_i
+        HDR*, HASH_I              -->
+                                  <--    HDR*, HASH_R
+
+   Aggressive Mode authenticated with encryption is described as
+   follows:
+
+        Initiator                        Responder
+       -----------                      -----------
+        HDR, SA, [ HASH(1),] KE,
+          <IDii_b>Pubkey_r,
+           <Ni_b>Pubkey_r         -->
+                                         HDR, SA, KE, <IDir_b>PubKey_i,
+                                  <--         <Nr_b>PubKey_i, HASH_R
+        HDR, HASH_I               -->
+
+
+
+Harkins & Carrel            Standards Track                    [Page 12]
+
+RFC 2409                          IKE                      November 1998
+
+
+   Where HASH(1) is a hash (using the negotiated hash function) of the
+   certificate which the initiator is using to encrypt the nonce and
+   identity.
+
+   RSA encryption MUST be encoded in PKCS #1 format. While only the body
+   of the ID and nonce payloads is encrypted, the encrypted data must be
+   preceded by a valid ISAKMP generic header. The payload length is the
+   length of the entire encrypted payload plus header. The PKCS #1
+   encoding allows for determination of the actual length of the
+   cleartext payload upon decryption.
+
+   Using encryption for authentication provides for a plausably deniable
+   exchange. There is no proof (as with a digital signature) that the
+   conversation ever took place since each party can completely
+   reconstruct both sides of the exchange. In addition, security is
+   added to secret generation since an attacker would have to
+   successfully break not only the Diffie-Hellman exchange but also both
+   RSA encryptions. This exchange was motivated by [SKEME].
+
+   Note that, unlike other authentication methods, authentication with
+   public key encryption allows for identity protection with Aggressive
+   Mode.
+
+5.3 Phase 1 Authenticated With a Revised Mode of Public Key Encryption
+
+   Authentication with Public Key Encryption has significant advantages
+   over authentication with signatures (see section 5.2 above).
+   Unfortunately, this is at the cost of 4 public key operations-- two
+   public key encryptions and two private key decryptions. This
+   authentication mode retains the advantages of authentication using
+   public key encryption but does so with half the public key
+   operations.
+
+   In this mode, the nonce is still encrypted using the public key of
+   the peer, however the peer's identity (and the certificate if it is
+   sent) is encrypted using the negotiated symmetric encryption
+   algorithm (from the SA payload) with a key derived from the nonce.
+   This solution adds minimal complexity and state yet saves two costly
+   public key operations on each side. In addition, the Key Exchange
+   payload is also encrypted using the same derived key. This provides
+   additional protection against cryptanalysis of the Diffie-Hellman
+   exchange.
+
+   As with the public key encryption method of authentication (section
+   5.2), a HASH payload may be sent to identify a certificate if the
+   responder has multiple certificates which contain useable public keys
+   (e.g. if the certificate is not for signatures only, either due to
+   certificate restrictions or algorithmic restrictions). If the HASH
+
+
+
+Harkins & Carrel            Standards Track                    [Page 13]
+
+RFC 2409                          IKE                      November 1998
+
+
+   payload is sent it MUST be the first payload of the second message
+   exchange and MUST be followed by the encrypted nonce. If the HASH
+   payload is not sent, the first payload of the second message exchange
+   MUST be the encrypted nonce. In addition, the initiator my optionally
+   send a certificate payload to provide the responder with a public key
+   with which to respond.
+
+   When using the revised encryption mode for authentication, Main Mode
+   is defined as follows.
+
+        Initiator                        Responder
+       -----------                      -----------
+        HDR, SA                   -->
+                                  <--    HDR, SA
+        HDR, [ HASH(1), ]
+          <Ni_b>Pubkey_r,
+          <KE_b>Ke_i,
+          <IDii_b>Ke_i,
+          [<<Cert-I_b>Ke_i]       -->
+                                         HDR, <Nr_b>PubKey_i,
+                                              <KE_b>Ke_r,
+                                  <--         <IDir_b>Ke_r,
+        HDR*, HASH_I              -->
+                                  <--    HDR*, HASH_R
+
+   Aggressive Mode authenticated with the revised encryption method is
+   described as follows:
+
+        Initiator                        Responder
+       -----------                      -----------
+        HDR, SA, [ HASH(1),]
+          <Ni_b>Pubkey_r,
+          <KE_b>Ke_i, <IDii_b>Ke_i
+          [, <Cert-I_b>Ke_i ]     -->
+                                         HDR, SA, <Nr_b>PubKey_i,
+                                              <KE_b>Ke_r, <IDir_b>Ke_r,
+                                  <--         HASH_R
+        HDR, HASH_I               -->
+
+   where HASH(1) is identical to section 5.2. Ke_i and Ke_r are keys to
+   the symmetric encryption algorithm negotiated in the SA payload
+   exchange. Only the body of the payloads are encrypted (in both public
+   key and symmetric operations), the generic payload headers are left
+   in the clear. The payload length includes that added to perform
+   encryption.
+
+   The symmetric cipher keys are derived from the decrypted nonces as
+   follows.  First the values Ne_i and Ne_r are computed:
+
+
+
+Harkins & Carrel            Standards Track                    [Page 14]
+
+RFC 2409                          IKE                      November 1998
+
+
+      Ne_i = prf(Ni_b, CKY-I)
+      Ne_r = prf(Nr_b, CKY-R)
+
+   The keys Ke_i and Ke_r are then taken from Ne_i and Ne_r respectively
+   in the manner described in Appendix B used to derive symmetric keys
+   for use with the negotiated encryption algorithm. If the length of
+   the output of the negotiated prf is greater than or equal to the key
+   length requirements of the cipher, Ke_i and Ke_r are derived from the
+   most significant bits of Ne_i and Ne_r respectively. If the desired
+   length of Ke_i and Ke_r exceed the length of the output of the prf
+   the necessary number of bits is obtained by repeatedly feeding the
+   results of the prf back into itself and concatenating the result
+   until the necessary number has been achieved. For example, if the
+   negotiated encryption algorithm requires 320 bits of key and the
+   output of the prf is only 128 bits, Ke_i is the most significant 320
+   bits of K, where
+
+      K = K1 | K2 | K3 and
+      K1 = prf(Ne_i, 0)
+      K2 = prf(Ne_i, K1)
+      K3 = prf(Ne_i, K2)
+
+   For brevity, only derivation of Ke_i is shown; Ke_r is identical. The
+   length of the value 0 in the computation of K1 is a single octet.
+   Note that Ne_i, Ne_r, Ke_i, and Ke_r are all ephemeral and MUST be
+   discarded after use.
+
+   Save the requirements on the location of the optional HASH payload
+   and the mandatory nonce payload there are no further payload
+   requirements. All payloads-- in whatever order-- following the
+   encrypted nonce MUST be encrypted with Ke_i or Ke_r depending on the
+   direction.
+
+   If CBC mode is used for the symmetric encryption then the
+   initialization vectors (IVs) are set as follows. The IV for
+   encrypting the first payload following the nonce is set to 0 (zero).
+   The IV for subsequent payloads encrypted with the ephemeral symmetric
+   cipher key, Ke_i, is the last ciphertext block of the previous
+   payload. Encrypted payloads are padded up to the nearest block size.
+   All padding bytes, except for the last one, contain 0x00. The last
+   byte of the padding contains the number of the padding bytes used,
+   excluding the last one. Note that this means there will always be
+   padding.
+
+
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 15]
+
+RFC 2409                          IKE                      November 1998
+
+
+5.4 Phase 1 Authenticated With a Pre-Shared Key
+
+   A key derived by some out-of-band mechanism may also be used to
+   authenticate the exchange. The actual establishment of this key is
+   out of the scope of this document.
+
+   When doing a pre-shared key authentication, Main Mode is defined as
+   follows:
+
+              Initiator                        Responder
+             ----------                       -----------
+              HDR, SA             -->
+                                  <--    HDR, SA
+              HDR, KE, Ni         -->
+                                  <--    HDR, KE, Nr
+              HDR*, IDii, HASH_I  -->
+                                  <--    HDR*, IDir, HASH_R
+
+   Aggressive mode with a pre-shared key is described as follows:
+
+            Initiator                        Responder
+           -----------                      -----------
+            HDR, SA, KE, Ni, IDii -->
+                                  <--    HDR, SA, KE, Nr, IDir, HASH_R
+            HDR, HASH_I           -->
+
+   When using pre-shared key authentication with Main Mode the key can
+   only be identified by the IP address of the peers since HASH_I must
+   be computed before the initiator has processed IDir. Aggressive Mode
+   allows for a wider range of identifiers of the pre-shared secret to
+   be used. In addition, Aggressive Mode allows two parties to maintain
+   multiple, different pre-shared keys and identify the correct one for
+   a particular exchange.
+
+5.5 Phase 2 - Quick Mode
+
+   Quick Mode is not a complete exchange itself (in that it is bound to
+   a phase 1 exchange), but is used as part of the SA negotiation
+   process (phase 2) to derive keying material and negotiate shared
+   policy for non-ISAKMP SAs. The information exchanged along with Quick
+   Mode MUST be protected by the ISAKMP SA-- i.e. all payloads except
+   the ISAKMP header are encrypted. In Quick Mode, a HASH payload MUST
+   immediately follow the ISAKMP header and a SA payload MUST
+   immediately follow the HASH. This HASH authenticates the message and
+   also provides liveliness proofs.
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 16]
+
+RFC 2409                          IKE                      November 1998
+
+
+   The message ID in the ISAKMP header identifies a Quick Mode in
+   progress for a particular ISAKMP SA which itself is identified by the
+   cookies in the ISAKMP header. Since each instance of a Quick Mode
+   uses a unique initialization vector (see Appendix B) it is possible
+   to have multiple simultaneous Quick Modes, based off a single ISAKMP
+   SA, in progress at any one time.
+
+   Quick Mode is essentially a SA negotiation and an exchange of nonces
+   that provides replay protection. The nonces are used to generate
+   fresh key material and prevent replay attacks from generating bogus
+   security associations.  An optional Key Exchange payload can be
+   exchanged to allow for an additional Diffie-Hellman exchange and
+   exponentiation per Quick Mode. While use of the key exchange payload
+   with Quick Mode is optional it MUST be supported.
+
+   Base Quick Mode (without the KE payload) refreshes the keying
+   material derived from the exponentiation in phase 1. This does not
+   provide PFS.  Using the optional KE payload, an additional
+   exponentiation is performed and PFS is provided for the keying
+   material.
+
+   The identities of the SAs negotiated in Quick Mode are implicitly
+   assumed to be the IP addresses of the ISAKMP peers, without any
+   implied constraints on the protocol or port numbers allowed, unless
+   client identifiers are specified in Quick Mode.  If ISAKMP is acting
+   as a client negotiator on behalf of another party, the identities of
+   the parties MUST be passed as IDci and then IDcr.  Local policy will
+   dictate whether the proposals are acceptable for the identities
+   specified.  If the client identities are not acceptable to the Quick
+   Mode responder (due to policy or other reasons), a Notify payload
+   with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent.
+
+   The client identities are used to identify and direct traffic to the
+   appropriate tunnel in cases where multiple tunnels exist between two
+   peers and also to allow for unique and shared SAs with different
+   granularities.
+
+   All offers made during a Quick Mode are logically related and must be
+   consistant. For example, if a KE payload is sent, the attribute
+   describing the Diffie-Hellman group (see section 6.1 and [Pip97])
+   MUST be included in every transform of every proposal of every SA
+   being negotiated. Similarly, if client identities are used, they MUST
+   apply to every SA in the negotiation.
+
+   Quick Mode is defined as follows:
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 17]
+
+RFC 2409                          IKE                      November 1998
+
+
+        Initiator                        Responder
+       -----------                      -----------
+        HDR*, HASH(1), SA, Ni
+          [, KE ] [, IDci, IDcr ] -->
+                                  <--    HDR*, HASH(2), SA, Nr
+                                               [, KE ] [, IDci, IDcr ]
+        HDR*, HASH(3)             -->
+
+   Where:
+   HASH(1) is the prf over the message id (M-ID) from the ISAKMP header
+   concatenated with the entire message that follows the hash including
+   all payload headers, but excluding any padding added for encryption.
+   HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni,
+   minus the payload header-- is added after M-ID but before the
+   complete message.  The addition of the nonce to HASH(2) is for a
+   liveliness proof. HASH(3)-- for liveliness-- is the prf over the
+   value zero represented as a single octet, followed by a concatenation
+   of the message id and the two nonces-- the initiator's followed by
+   the responder's-- minus the payload header. In other words, the
+   hashes for the above exchange are:
+
+   HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
+   HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci |
+   IDcr )
+   HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)
+
+   With the exception of the HASH, SA, and the optional ID payloads,
+   there are no payload ordering restrictions on Quick Mode. HASH(1) and
+   HASH(2) may differ from the illustration above if the order of
+   payloads in the message differs from the illustrative example or if
+   any optional payloads, for example a notify payload, have been
+   chained to the message.
+
+   If PFS is not needed, and KE payloads are not exchanged, the new
+   keying material is defined as
+
+       KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b).
+
+   If PFS is desired and KE payloads were exchanged, the new keying
+   material is defined as
+
+       KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)
+
+   where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman
+   exchange of this Quick Mode.
+
+   In either case, "protocol" and "SPI" are from the ISAKMP Proposal
+   Payload that contained the negotiated Transform.
+
+
+
+Harkins & Carrel            Standards Track                    [Page 18]
+
+RFC 2409                          IKE                      November 1998
+
+
+   A single SA negotiation results in two security assocations-- one
+   inbound and one outbound. Different SPIs for each SA (one chosen by
+   the initiator, the other by the responder) guarantee a different key
+   for each direction.  The SPI chosen by the destination of the SA is
+   used to derive KEYMAT for that SA.
+
+   For situations where the amount of keying material desired is greater
+   than that supplied by the prf, KEYMAT is expanded by feeding the
+   results of the prf back into itself and concatenating results until
+   the required keying material has been reached. In other words,
+
+      KEYMAT = K1 | K2 | K3 | ...
+      where
+        K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b)
+        K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b |
+        Nr_b)
+        K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b |
+        Nr_b)
+        etc.
+
+   This keying material (whether with PFS or without, and whether
+   derived directly or through concatenation) MUST be used with the
+   negotiated SA. It is up to the service to define how keys are derived
+   from the keying material.
+
+   In the case of an ephemeral Diffie-Hellman exchange in Quick Mode,
+   the exponential (g(qm)^xy) is irretreivably removed from the current
+   state and SKEYID_e and SKEYID_a (derived from phase 1 negotiation)
+   continue to protect and authenticate the ISAKMP SA and SKEYID_d
+   continues to be used to derive keys.
+
+   Using Quick Mode, multiple SA's and keys can be negotiated with one
+   exchange as follows:
+
+        Initiator                        Responder
+       -----------                      -----------
+        HDR*, HASH(1), SA0, SA1, Ni,
+          [, KE ] [, IDci, IDcr ] -->
+                                  <--    HDR*, HASH(2), SA0, SA1, Nr,
+                                            [, KE ] [, IDci, IDcr ]
+        HDR*, HASH(3)             -->
+
+   The keying material is derived identically as in the case of a single
+   SA. In this case (negotiation of two SA payloads) the result would be
+   four security associations-- two each way for both SAs.
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 19]
+
+RFC 2409                          IKE                      November 1998
+
+
+5.6 New Group Mode
+
+   New Group Mode MUST NOT be used prior to establishment of an ISAKMP
+   SA. The description of a new group MUST only follow phase 1
+   negotiation.  (It is not a phase 2 exchange, though).
+
+        Initiator                        Responder
+       -----------                      -----------
+        HDR*, HASH(1), SA        -->
+                                 <--     HDR*, HASH(2), SA
+
+   where HASH(1) is the prf output, using SKEYID_a as the key, and the
+   message-ID from the ISAKMP header concatenated with the entire SA
+   proposal, body and header, as the data; HASH(2) is the prf output,
+   using SKEYID_a as the key, and the message-ID from the ISAKMP header
+   concatenated with the reply as the data. In other words the hashes
+   for the above exchange are:
+
+      HASH(1) = prf(SKEYID_a, M-ID | SA)
+      HASH(2) = prf(SKEYID_a, M-ID | SA)
+
+   The proposal will specify the characteristics of the group (see
+   appendix A, "Attribute Assigned Numbers"). Group descriptions for
+   private Groups MUST be greater than or equal to 2^15.  If the group
+   is not acceptable, the responder MUST reply with a Notify payload
+   with the message type set to ATTRIBUTES-NOT-SUPPORTED (13).
+
+   ISAKMP implementations MAY require private groups to expire with the
+   SA under which they were established.
+
+   Groups may be directly negotiated in the SA proposal with Main Mode.
+   To do this the component parts-- for a MODP group, the type, prime
+   and generator; for a EC2N group the type, the Irreducible Polynomial,
+   Group Generator One, Group Generator Two, Group Curve A, Group Curve
+   B and Group Order-- are passed as SA attributes (see Appendix A).
+   Alternately, the nature of the group can be hidden using New Group
+   Mode and only the group identifier is passed in the clear during
+   phase 1 negotiation.
+
+5.7 ISAKMP Informational Exchanges
+
+   This protocol protects ISAKMP Informational Exchanges when possible.
+   Once the ISAKMP security association has been established (and
+   SKEYID_e and SKEYID_a have been generated) ISAKMP Information
+   Exchanges, when used with this protocol, are as follows:
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 20]
+
+RFC 2409                          IKE                      November 1998
+
+
+        Initiator                        Responder
+       -----------                      -----------
+        HDR*, HASH(1), N/D      -->
+
+   where N/D is either an ISAKMP Notify Payload or an ISAKMP Delete
+   Payload and HASH(1) is the prf output, using SKEYID_a as the key, and
+   a M-ID unique to this exchange concatenated with the entire
+   informational payload (either a Notify or Delete) as the data. In
+   other words, the hash for the above exchange is:
+
+      HASH(1) = prf(SKEYID_a, M-ID | N/D)
+
+   As noted the message ID in the ISAKMP header-- and used in the prf
+   computation-- is unique to this exchange and MUST NOT be the same as
+   the message ID of another phase 2 exchange which generated this
+   informational exchange. The derivation of the initialization vector,
+   used with SKEYID_e to encrypt this message, is described in Appendix
+   B.
+
+   If the ISAKMP security association has not yet been established at
+   the time of the Informational Exchange, the exchange is done in the
+   clear without an accompanying HASH payload.
+
+6 Oakley Groups
+
+   With IKE, the group in which to do the Diffie-Hellman exchange is
+   negotiated. Four groups-- values 1 through 4-- are defined below.
+   These groups originated with the Oakley protocol and are therefore
+   called "Oakley Groups". The attribute class for "Group" is defined in
+   Appendix A. All values 2^15 and higher are used for private group
+   identifiers. For a discussion on the strength of the default Oakley
+   groups please see the Security Considerations section below.
+
+   These groups were all generated by Richard Schroeppel at the
+   University of Arizona. Properties of these groups are described in
+   [Orm96].
+
+6.1 First Oakley Default Group
+
+   Oakley implementations MUST support a MODP group with the following
+   prime and generator. This group is assigned id 1 (one).
+
+      The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }
+      Its hexadecimal value is
+
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 21]
+
+RFC 2409                          IKE                      November 1998
+
+
+         FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+         29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+         EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+         E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
+
+      The generator is: 2.
+
+6.2 Second Oakley Group
+
+   IKE implementations SHOULD support a MODP group with the following
+   prime and generator. This group is assigned id 2 (two).
+
+   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
+   Its hexadecimal value is
+
+         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
+
+   The generator is 2 (decimal)
+
+6.3 Third Oakley Group
+
+   IKE implementations SHOULD support a EC2N group with the following
+   characteristics. This group is assigned id 3 (three). The curve is
+   based on the Galois Field GF[2^155]. The field size is 155. The
+   irreducible polynomial for the field is:
+          u^155 + u^62 + 1.
+   The equation for the elliptic curve is:
+           y^2 + xy = x^3 + ax^2 + b.
+
+   Field Size:                         155
+   Group Prime/Irreducible Polynomial:
+                    0x0800000000000000000000004000000000000001
+   Group Generator One:                0x7b
+   Group Curve A:                      0x0
+   Group Curve B:                      0x07338f
+
+   Group Order: 0X0800000000000000000057db5698537193aef944
+
+   The data in the KE payload when using this group is the value x from
+   the solution (x,y), the point on the curve chosen by taking the
+   randomly chosen secret Ka and computing Ka*P, where * is the
+   repetition of the group addition and double operations, P is the
+   curve point with x coordinate equal to generator 1 and the y
+
+
+
+Harkins & Carrel            Standards Track                    [Page 22]
+
+RFC 2409                          IKE                      November 1998
+
+
+   coordinate determined from the defining equation. The equation of
+   curve is implicitly known by the Group Type and the A and B
+   coefficients. There are two possible values for the y coordinate;
+   either one can be used successfully (the two parties need not agree
+   on the selection).
+
+6.4 Fourth Oakley Group
+
+   IKE implementations SHOULD support a EC2N group with the following
+   characteristics. This group is assigned id 4 (four). The curve is
+   based on the Galois Field GF[2^185]. The field size is 185. The
+   irreducible polynomial for the field is:
+           u^185 + u^69 + 1. The
+   equation for the elliptic curve is:
+           y^2 + xy = x^3 + ax^2 + b.
+
+   Field Size:                         185
+   Group Prime/Irreducible Polynomial:
+                    0x020000000000000000000000000000200000000000000001
+   Group Generator One:                0x18
+   Group Curve A:                      0x0
+   Group Curve B:                      0x1ee9
+
+   Group Order: 0X01ffffffffffffffffffffffdbf2f889b73e484175f94ebc
+
+   The data in the KE payload when using this group will be identical to
+   that as when using Oakley Group 3 (three).
+
+   Other groups can be defined using New Group Mode. These default
+   groups were generated by Richard Schroeppel at the University of
+   Arizona.  Properties of these primes are described in [Orm96].
+
+7. Payload Explosion for a Complete IKE Exchange
+
+   This section illustrates how the IKE protocol is used to:
+
+      - establish a secure and authenticated channel between ISAKMP
+      processes (phase 1); and
+
+      - generate key material for, and negotiate, an IPsec SA (phase 2).
+
+7.1 Phase 1 using Main Mode
+
+   The following diagram illustrates the payloads exchanged between the
+   two parties in the first round trip exchange. The initiator MAY
+   propose several proposals; the responder MUST reply with one.
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 23]
+
+RFC 2409                          IKE                      November 1998
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~             ISAKMP Header with XCHG of Main Mode,             ~
+      ~                  and Next Payload of ISA_SA                   ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !       0       !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !                  Domain of Interpretation                     !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !                          Situation                            !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !       0       !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !  Proposal #1  ! PROTO_ISAKMP  ! SPI size = 0  | # Transforms  !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !    ISA_TRANS  !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !  Transform #1 !  KEY_OAKLEY   |          RESERVED2            !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                   prefered SA attributes                      ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !       0       !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !  Transform #2 !  KEY_OAKLEY   |          RESERVED2            !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                   alternate SA attributes                     ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The responder replies in kind but selects, and returns, one transform
+   proposal (the ISAKMP SA attributes).
+
+   The second exchange consists of the following payloads:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~             ISAKMP Header with XCHG of Main Mode,             ~
+      ~                  and Next Payload of ISA_KE                   ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !    ISA_NONCE  !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~   D-H Public Value  (g^xi from initiator g^xr from responder) ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !       0       !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~         Ni (from initiator) or  Nr (from responder)           ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 24]
+
+RFC 2409                          IKE                      November 1998
+
+
+   The shared keys, SKEYID_e and SKEYID_a, are now used to protect and
+   authenticate all further communication. Note that both SKEYID_e and
+   SKEYID_a are unauthenticated.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~            ISAKMP Header with XCHG of Main Mode,              ~
+      ~     and Next Payload of ISA_ID and the encryption bit set     ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !    ISA_SIG    !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~        Identification Data of the ISAKMP negotiator           ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !       0       !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~       signature verified by the public key of the ID above    ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The key exchange is authenticated over a signed hash as described in
+   section 5.1. Once the signature has been verified using the
+   authentication algorithm negotiated as part of the ISAKMP SA, the
+   shared keys, SKEYID_e and SKEYID_a can be marked as authenticated.
+   (For brevity, certificate payloads were not exchanged).
+
+7.2 Phase 2 using Quick Mode
+
+   The following payloads are exchanged in the first round of Quick Mode
+   with ISAKMP SA negotiation. In this hypothetical exchange, the ISAKMP
+   negotiators are proxies for other parties which have requested
+   authentication.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~            ISAKMP Header with XCHG of Quick Mode,             ~
+      ~   Next Payload of ISA_HASH and the encryption bit set         ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !     ISA_SA    !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                 keyed hash of message                         ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !   ISA_NONCE   !    RESERVED   !         Payload Length        !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !                 Domain Of Interpretation                      !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !                          Situation                            !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !       0       !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 25]
+
+RFC 2409                          IKE                      November 1998
+
+
+      !  Proposal #1  ! PROTO_IPSEC_AH! SPI size = 4  | # Transforms  !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                        SPI (4 octets)                         ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !    ISA_TRANS  !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !  Transform #1 !     AH_SHA    |          RESERVED2            !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !                       other SA attributes                     !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !       0       !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !  Transform #2 !     AH_MD5    |          RESERVED2            !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !                       other SA attributes                     !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !    ISA_ID     !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                            nonce                              ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !    ISA_ID     !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~              ID of source for which ISAKMP is a client        ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !      0        !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~           ID of destination for which ISAKMP is a client      ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   where the contents of the hash are described in 5.5 above. The
+   responder replies with a similar message which only contains one
+   transform-- the selected AH transform. Upon receipt, the initiator
+   can provide the key engine with the negotiated security association
+   and the keying material.  As a check against replay attacks, the
+   responder waits until receipt of the next message.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~          ISAKMP Header with XCHG of Quick Mode,               ~
+      ~   Next Payload of ISA_HASH and the encryption bit set         ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !       0       !    RESERVED   !        Payload Length         !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                         hash data                             ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   where the contents of the hash are described in 5.5 above.
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 26]
+
+RFC 2409                          IKE                      November 1998
+
+
+8. Perfect Forward Secrecy Example
+
+   This protocol can provide PFS of both keys and identities. The
+   identies of both the ISAKMP negotiating peer and, if applicable, the
+   identities for whom the peers are negotiating can be protected with
+   PFS.
+
+   To provide Perfect Forward Secrecy of both keys and all identities,
+   two parties would perform the following:
+
+      o A Main Mode Exchange to protect the identities of the ISAKMP
+        peers.
+        This establishes an ISAKMP SA.
+      o A Quick Mode Exchange to negotiate other security protocol
+        protection.
+        This establishes a SA on each end for this protocol.
+      o Delete the ISAKMP SA and its associated state.
+
+   Since the key for use in the non-ISAKMP SA was derived from the
+   single ephemeral Diffie-Hellman exchange PFS is preserved.
+
+   To provide Perfect Forward Secrecy of merely the keys of a non-ISAKMP
+   security association, it in not necessary to do a phase 1 exchange if
+   an ISAKMP SA exists between the two peers. A single Quick Mode in
+   which the optional KE payload is passed, and an additional Diffie-
+   Hellman exchange is performed, is all that is required. At this point
+   the state derived from this Quick Mode must be deleted from the
+   ISAKMP SA as described in section 5.5.
+
+9. Implementation Hints
+
+   Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2
+   negotiations extremely quick.  As long as the Phase 1 state remains
+   cached, and PFS is not needed, Phase 2 can proceed without any
+   exponentiation. How many Phase 2 negotiations can be performed for a
+   single Phase 1 is a local policy issue. The decision will depend on
+   the strength of the algorithms being used and level of trust in the
+   peer system.
+
+   An implementation may wish to negotiate a range of SAs when
+   performing Quick Mode.  By doing this they can speed up the "re-
+   keying". Quick Mode defines how KEYMAT is defined for a range of SAs.
+   When one peer feels it is time to change SAs they simply use the next
+   one within the stated range. A range of SAs can be established by
+   negotiating multiple SAs (identical attributes, different SPIs) with
+   one Quick Mode.
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 27]
+
+RFC 2409                          IKE                      November 1998
+
+
+   An optimization that is often useful is to establish Security
+   Associations with peers before they are needed so that when they
+   become needed they are already in place. This ensures there would be
+   no delays due to key management before initial data transmission.
+   This optimization is easily implemented by setting up more than one
+   Security Association with a peer for each requested Security
+   Association and caching those not immediately used.
+
+   Also, if an ISAKMP implementation is alerted that a SA will soon be
+   needed (e.g. to replace an existing SA that will expire in the near
+   future), then it can establish the new SA before that new SA is
+   needed.
+
+   The base ISAKMP specification describes conditions in which one party
+   of the protocol may inform the other party of some activity-- either
+   deletion of a security association or in response to some error in
+   the protocol such as a signature verification failed or a payload
+   failed to decrypt. It is strongly suggested that these Informational
+   exchanges not be responded to under any circumstances. Such a
+   condition may result in a "notify war" in which failure to understand
+   a message results in a notify to the peer who cannot understand it
+   and sends his own notify back which is also not understood.
+
+10. Security Considerations
+
+   This entire memo discusses a hybrid protocol, combining parts of
+   Oakley and parts of SKEME with ISAKMP, to negotiate, and derive
+   keying material for, security associations in a secure and
+   authenticated manner.
+
+   Confidentiality is assured by the use of a negotiated encryption
+   algorithm.  Authentication is assured by the use of a negotiated
+   method: a digital signature algorithm; a public key algorithm which
+   supports encryption; or, a pre-shared key. The confidentiality and
+   authentication of this exchange is only as good as the attributes
+   negotiated as part of the ISAKMP security association.
+
+   Repeated re-keying using Quick Mode can consume the entropy of the
+   Diffie-Hellman shared secret. Implementors should take note of this
+   fact and set a limit on Quick Mode Exchanges between exponentiations.
+   This memo does not prescribe such a limit.
+
+   Perfect Forward Secrecy (PFS) of both keying material and identities
+   is possible with this protocol. By specifying a Diffie-Hellman group,
+   and passing public values in KE payloads, ISAKMP peers can establish
+   PFS of keys-- the identities would be protected by SKEYID_e from the
+   ISAKMP SA and would therefore not be protected by PFS. If PFS of both
+   keying material and identities is desired, an ISAKMP peer MUST
+
+
+
+Harkins & Carrel            Standards Track                    [Page 28]
+
+RFC 2409                          IKE                      November 1998
+
+
+   establish only one non-ISAKMP security association (e.g. IPsec
+   Security Association) per ISAKMP SA. PFS for keys and identities is
+   accomplished by deleting the ISAKMP SA (and optionally issuing a
+   DELETE message) upon establishment of the single non-ISAKMP SA. In
+   this way a phase one negotiation is uniquely tied to a single phase
+   two negotiation, and the ISAKMP SA established during phase one
+   negotiation is never used again.
+
+   The strength of a key derived from a Diffie-Hellman exchange using
+   any of the groups defined here depends on the inherent strength of
+   the group, the size of the exponent used, and the entropy provided by
+   the random number generator used. Due to these inputs it is difficult
+   to determine the strength of a key for any of the defined groups. The
+   default Diffie-Hellman group (number one) when used with a strong
+   random number generator and an exponent no less than 160 bits is
+   sufficient to use for DES.  Groups two through four provide greater
+   security. Implementations should make note of these conservative
+   estimates when establishing policy and negotiating security
+   parameters.
+
+   Note that these limitations are on the Diffie-Hellman groups
+   themselves.  There is nothing in IKE which prohibits using stronger
+   groups nor is there anything which will dilute the strength obtained
+   from stronger groups. In fact, the extensible framework of IKE
+   encourages the definition of more groups; use of elliptical curve
+   groups will greatly increase strength using much smaller numbers.
+
+   For situations where defined groups provide insufficient strength New
+   Group Mode can be used to exchange a Diffie-Hellman group which
+   provides the necessary strength. In is incumbent upon implementations
+   to check the primality in groups being offered and independently
+   arrive at strength estimates.
+
+   It is assumed that the Diffie-Hellman exponents in this exchange are
+   erased from memory after use. In particular, these exponents must not
+   be derived from long-lived secrets like the seed to a pseudo-random
+   generator.
+
+   IKE exchanges maintain running initialization vectors (IV) where the
+   last ciphertext block of the last message is the IV for the next
+   message. To prevent retransmissions (or forged messages with valid
+   cookies) from causing exchanges to get out of sync IKE
+   implementations SHOULD NOT update their running IV until the
+   decrypted message has passed a basic sanity check and has been
+   determined to actually advance the IKE state machine-- i.e. it is not
+   a retransmission.
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 29]
+
+RFC 2409                          IKE                      November 1998
+
+
+   While the last roundtrip of Main Mode (and optionally the last
+   message of Aggressive Mode) is encrypted it is not, strictly
+   speaking, authenticated.  An active substitution attack on the
+   ciphertext could result in payload corruption. If such an attack
+   corrupts mandatory payloads it would be detected by an authentication
+   failure, but if it corrupts any optional payloads (e.g. notify
+   payloads chained onto the last message of a Main Mode exchange) it
+   might not be detectable.
+
+11. IANA Considerations
+
+   This document contains many "magic numbers" to be maintained by the
+   IANA.  This section explains the criteria to be used by the IANA to
+   assign additional numbers in each of these lists.
+
+11.1 Attribute Classes
+
+   Attributes negotiated in this protocol are identified by their class.
+   Requests for assignment of new classes must be accompanied by a
+   standards-track RFC which describes the use of this attribute.
+
+11.2 Encryption Algorithm Class
+
+   Values of the Encryption Algorithm Class define an encryption
+   algorithm to use when called for in this document. Requests for
+   assignment of new encryption algorithm values must be accompanied by
+   a reference to a standards-track or Informational RFC or a reference
+   to published cryptographic literature which describes this algorithm.
+
+11.3 Hash Algorithm
+
+   Values of the Hash Algorithm Class define a hash algorithm to use
+   when called for in this document. Requests for assignment of new hash
+   algorithm values must be accompanied by a reference to a standards-
+   track or Informational RFC or a reference to published cryptographic
+   literature which describes this algorithm. Due to the key derivation
+   and key expansion uses of HMAC forms of hash algorithms in IKE,
+   requests for assignment of new hash algorithm values must take into
+   account the cryptographic properties-- e.g it's resistance to
+   collision-- of the hash algorithm itself.
+
+11.4 Group Description and Group Type
+
+   Values of the Group Description Class identify a group to use in a
+   Diffie-Hellman exchange. Values of the Group Type Class define the
+   type of group. Requests for assignment of new groups must be
+   accompanied by a reference to a standards-track or Informational RFC
+   which describes this group. Requests for assignment of new group
+
+
+
+Harkins & Carrel            Standards Track                    [Page 30]
+
+RFC 2409                          IKE                      November 1998
+
+
+   types must be accompanied by a reference to a standards-track or
+   Informational RFC or by a reference to published cryptographic or
+   mathmatical literature which describes the new type.
+
+11.5 Life Type
+
+   Values of the Life Type Class define a type of lifetime to which the
+   ISAKMP Security Association applies. Requests for assignment of new
+   life types must be accompanied by a detailed description of the units
+   of this type and its expiry.
+
+12. Acknowledgements
+
+   This document is the result of close consultation with Hugo Krawczyk,
+   Douglas Maughan, Hilarie Orman, Mark Schertler, Mark Schneider, and
+   Jeff Turner. It relies on protocols which were written by them.
+   Without their interest and dedication, this would not have been
+   written.
+
+   Special thanks Rob Adams, Cheryl Madson, Derrell Piper, Harry Varnis,
+   and Elfed Weaver for technical input, encouragement, and various
+   sanity checks along the way.
+
+   We would also like to thank the many members of the IPSec working
+   group that contributed to the development of this protocol over the
+   past year.
+
+13. References
+
+   [CAST]   Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
+            May 1997.
+
+   [BLOW]   Schneier, B., "The Blowfish Encryption Algorithm", Dr.
+            Dobb's Journal, v. 19, n. 4, April 1994.
+
+   [Bra97]  Bradner, S., "Key Words for use in RFCs to indicate
+            Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [DES]    ANSI X3.106, "American National Standard for Information
+            Systems-Data Link Encryption", American National Standards
+            Institute, 1983.
+
+   [DH]     Diffie, W., and Hellman M., "New Directions in
+            Cryptography", IEEE Transactions on Information Theory, V.
+            IT-22, n. 6, June 1977.
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 31]
+
+RFC 2409                          IKE                      November 1998
+
+
+   [DSS]    NIST, "Digital Signature Standard", FIPS 186, National
+            Institute of Standards and Technology, U.S. Department of
+            Commerce, May, 1994.
+
+   [IDEA]   Lai, X., "On the Design and Security of Block Ciphers," ETH
+            Series in Information Processing, v. 1, Konstanz: Hartung-
+            Gorre Verlag, 1992
+
+   [KBC96]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+            Hashing for Message Authentication", RFC 2104, February
+            1997.
+
+   [SKEME]  Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
+            Mechanism for Internet", from IEEE Proceedings of the 1996
+            Symposium on Network and Distributed Systems Security.
+
+   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
+            April 1992.
+
+   [MSST98] Maughhan, D., Schertler, M., Schneider, M., and J. Turner,
+            "Internet Security Association and Key Management Protocol
+            (ISAKMP)", RFC 2408, November 1998.
+
+   [Orm96]  Orman, H., "The Oakley Key Determination Protocol", RFC
+            2412, November 1998.
+
+   [PKCS1]  RSA Laboratories, "PKCS #1: RSA Encryption Standard",
+            November 1993.
+
+   [Pip98]  Piper, D., "The Internet IP Security Domain Of
+            Interpretation for ISAKMP", RFC 2407, November 1998.
+
+   [RC5]    Rivest, R., "The RC5 Encryption Algorithm", Dr. Dobb's
+            Journal, v. 20, n. 1, January 1995.
+
+   [RSA]    Rivest, R., Shamir, A., and Adleman, L., "A Method for
+            Obtaining Digital Signatures and Public-Key Cryptosystems",
+            Communications of the ACM, v. 21, n. 2, February 1978.
+
+   [Sch96]  Schneier, B., "Applied Cryptography, Protocols, Algorithms,
+            and Source Code in C", 2nd edition.
+
+   [SHA]    NIST, "Secure Hash Standard", FIPS 180-1, National Institue
+            of Standards and Technology, U.S. Department of Commerce,
+            May 1994.
+
+   [TIGER]  Anderson, R., and Biham, E., "Fast Software Encryption",
+            Springer LNCS v. 1039, 1996.
+
+
+
+Harkins & Carrel            Standards Track                    [Page 32]
+
+RFC 2409                          IKE                      November 1998
+
+
+Appendix A
+
+   This is a list of DES Weak and Semi-Weak keys.  The keys come from
+   [Sch96].  All keys are listed in hexidecimal.
+
+       DES Weak Keys
+       0101 0101 0101 0101
+       1F1F 1F1F E0E0 E0E0
+       E0E0 E0E0 1F1F 1F1F
+       FEFE FEFE FEFE FEFE
+
+       DES Semi-Weak Keys
+       01FE 01FE 01FE 01FE
+       1FE0 1FE0 0EF1 0EF1
+       01E0 01E0 01F1 01F1
+       1FFE 1FFE 0EFE 0EFE
+       011F 011F 010E 010E
+       E0FE E0FE F1FE F1FE
+
+       FE01 FE01 FE01 FE01
+       E01F E01F F10E F10E
+       E001 E001 F101 F101
+       FE1F FE1F FE0E FE0E
+       1F01 1F01 0E01 0E01
+       FEE0 FEE0 FEF1 FEF1
+
+   Attribute Assigned Numbers
+
+   Attributes negotiated during phase one use the following definitions.
+   Phase two attributes are defined in the applicable DOI specification
+   (for example, IPsec attributes are defined in the IPsec DOI), with
+   the exception of a group description when Quick Mode includes an
+   ephemeral Diffie-Hellman exchange.  Attribute types can be either
+   Basic (B) or Variable-length (V). Encoding of these attributes is
+   defined in the base ISAKMP specification as Type/Value (Basic) and
+   Type/Length/Value (Variable).
+
+   Attributes described as basic MUST NOT be encoded as variable.
+   Variable length  attributes MAY be encoded as basic attributes if
+   their value can fit into two octets. If this is the case, an
+   attribute offered as variable (or basic) by the initiator of this
+   protocol MAY be returned to the initiator as a basic (or variable).
+
+
+
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 33]
+
+RFC 2409                          IKE                      November 1998
+
+
+   Attribute Classes
+
+          class                         value              type
+     -------------------------------------------------------------------
+      Encryption Algorithm                1                 B
+      Hash Algorithm                      2                 B
+      Authentication Method               3                 B
+      Group Description                   4                 B
+      Group Type                          5                 B
+      Group Prime/Irreducible Polynomial  6                 V
+      Group Generator One                 7                 V
+      Group Generator Two                 8                 V
+      Group Curve A                       9                 V
+      Group Curve B                      10                 V
+      Life Type                          11                 B
+      Life Duration                      12                 V
+      PRF                                13                 B
+      Key Length                         14                 B
+      Field Size                         15                 B
+      Group Order                        16                 V
+
+   values 17-16383 are reserved to IANA. Values 16384-32767 are for
+   private use among mutually consenting parties.
+
+   Class Values
+
+   - Encryption Algorithm                       Defined In
+      DES-CBC                             1     RFC 2405
+      IDEA-CBC                            2
+      Blowfish-CBC                        3
+      RC5-R16-B64-CBC                     4
+      3DES-CBC                            5
+      CAST-CBC                            6
+
+     values 7-65000 are reserved to IANA. Values 65001-65535 are for
+     private use among mutually consenting parties.
+
+   - Hash Algorithm                             Defined In
+      MD5                                 1     RFC 1321
+      SHA                                 2     FIPS 180-1
+      Tiger                               3     See Reference [TIGER]
+
+     values 4-65000 are reserved to IANA. Values 65001-65535 are for
+     private use among mutually consenting parties.
+
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 34]
+
+RFC 2409                          IKE                      November 1998
+
+
+   - Authentication Method
+      pre-shared key                      1
+      DSS signatures                      2
+      RSA signatures                      3
+      Encryption with RSA                 4
+      Revised encryption with RSA         5
+
+     values 6-65000 are reserved to IANA. Values 65001-65535 are for
+     private use among mutually consenting parties.
+
+   - Group Description
+      default 768-bit MODP group (section 6.1)      1
+
+      alternate 1024-bit MODP group (section 6.2)   2
+
+      EC2N group on GP[2^155] (section 6.3)         3
+
+      EC2N group on GP[2^185] (section 6.4)         4
+
+     values 5-32767 are reserved to IANA. Values 32768-65535 are for
+     private use among mutually consenting parties.
+
+   - Group Type
+      MODP (modular exponentiation group)            1
+      ECP  (elliptic curve group over GF[P])         2
+      EC2N (elliptic curve group over GF[2^N])       3
+
+     values 4-65000 are reserved to IANA. Values 65001-65535 are for
+     private use among mutually consenting parties.
+
+   - Life Type
+      seconds                             1
+      kilobytes                           2
+
+     values 3-65000 are reserved to IANA. Values 65001-65535 are for
+     private use among mutually consenting parties. For a given "Life
+     Type" the value of the "Life Duration" attribute defines the actual
+     length of the SA life-- either a number of seconds, or a number of
+     kbytes protected.
+
+   - PRF
+     There are currently no pseudo-random functions defined.
+
+     values 1-65000 are reserved to IANA. Values 65001-65535 are for
+     private use among mutually consenting parties.
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 35]
+
+RFC 2409                          IKE                      November 1998
+
+
+   - Key Length
+
+     When using an Encryption Algorithm that has a variable length key,
+     this attribute specifies the key length in bits. (MUST use network
+     byte order). This attribute MUST NOT be used when the specified
+     Encryption Algorithm uses a fixed length key.
+
+   - Field Size
+
+     The field size, in bits, of a Diffie-Hellman group.
+
+   - Group Order
+
+     The group order of an elliptical curve group. Note the length of
+     this attribute depends on the field size.
+
+   Additional Exchanges Defined-- XCHG values
+     Quick Mode                         32
+     New Group Mode                     33
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 36]
+
+RFC 2409                          IKE                      November 1998
+
+
+Appendix B
+
+   This appendix describes encryption details to be used ONLY when
+   encrypting ISAKMP messages.  When a service (such as an IPSEC
+   transform) utilizes ISAKMP to generate keying material, all
+   encryption algorithm specific details (such as key and IV generation,
+   padding, etc...) MUST be defined by that service.  ISAKMP does not
+   purport to ever produce keys that are suitable for any encryption
+   algorithm.  ISAKMP produces the requested amount of keying material
+   from which the service MUST generate a suitable key.  Details, such
+   as weak key checks, are the responsibility of the service.
+
+   Use of negotiated PRFs may require the PRF output to be expanded due
+   to the PRF feedback mechanism employed by this document. For example,
+   if the (ficticious) DOORAK-MAC requires 24 bytes of key but produces
+   only 8 bytes of output, the output must be expanded three times
+   before being used as the key for another instance of itself. The
+   output of a PRF is expanded by feeding back the results of the PRF
+   into itself to generate successive blocks. These blocks are
+   concatenated until the requisite number of bytes has been acheived.
+   For example, for pre-shared key authentication with DOORAK-MAC as the
+   negotiated PRF:
+
+     BLOCK1-8 = prf(pre-shared-key, Ni_b | Nr_b)
+     BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni_b | Nr_b)
+     BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni_b | Nr_b)
+   and
+     SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24
+
+   so therefore to derive SKEYID_d:
+
+     BLOCK1-8 = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
+     BLOCK9-16 = prf(SKEYID, BLOCK1-8 | g^xy | CKY-I | CKY-R | 0)
+     BLOCK17-24 = prf(SKEYID, BLOCK9-16 | g^xy | CKY-I | CKY-R | 0)
+   and
+     SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24
+
+   Subsequent PRF derivations are done similarly.
+
+   Encryption keys used to protect the ISAKMP SA are derived from
+   SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long
+   enough to supply all the necessary keying material an algorithm
+   requires, the key is derived from feeding the results of a pseudo-
+   random function into itself, concatenating the results, and taking
+   the highest necessary bits.
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 37]
+
+RFC 2409                          IKE                      November 1998
+
+
+   For example, if (ficticious) algorithm AKULA requires 320-bits of key
+   (and has no weak key check) and the prf used to generate SKEYID_e
+   only generates 120 bits of material, the key for AKULA, would be the
+   first 320-bits of Ka, where:
+
+       Ka = K1 | K2 | K3
+   and
+       K1 = prf(SKEYID_e, 0)
+       K2 = prf(SKEYID_e, K1)
+       K3 = prf(SKEYID_e, K2)
+
+   where prf is the negotiated prf or the HMAC version of the negotiated
+   hash function (if no prf was negotiated) and 0 is represented by a
+   single octet. Each result of the prf provides 120 bits of material
+   for a total of 360 bits. AKULA would use the first 320 bits of that
+   360 bit string.
+
+   In phase 1, material for the initialization vector (IV material) for
+   CBC mode encryption algorithms is derived from a hash of a
+   concatenation of the initiator's public Diffie-Hellman value and the
+   responder's public Diffie-Hellman value using the negotiated hash
+   algorithm. This is used for the first message only. Each message
+   should be padded up to the nearest block size using bytes containing
+   0x00. The message length in the header MUST include the length of the
+   pad since this reflects the size of the ciphertext. Subsequent
+   messages MUST use the last CBC encryption block from the previous
+   message as their initialization vector.
+
+   In phase 2, material for the initialization vector for CBC mode
+   encryption of the first message of a Quick Mode exchange is derived
+   from a hash of a concatenation of the last phase 1 CBC output block
+   and the phase 2 message id using the negotiated hash algorithm. The
+   IV for subsequent messages within a Quick Mode exchange is the CBC
+   output block from the previous message. Padding and IVs for
+   subsequent messages are done as in phase 1.
+
+   After the ISAKMP SA has been authenticated all Informational
+   Exchanges are encrypted using SKEYID_e. The initiaization vector for
+   these exchanges is derived in exactly the same fashion as that for a
+   Quick Mode-- i.e. it is derived from a hash of a concatenation of the
+   last phase 1 CBC output block and the message id from the ISAKMP
+   header of the Informational Exchange (not the message id from the
+   message that may have prompted the Informational Exchange).
+
+   Note that the final phase 1 CBC output block, the result of
+   encryption/decryption of the last phase 1 message, must be retained
+   in the ISAKMP SA state to allow for generation of unique IVs for each
+   Quick Mode. Each post- phase 1 exchange (Quick Modes and
+
+
+
+Harkins & Carrel            Standards Track                    [Page 38]
+
+RFC 2409                          IKE                      November 1998
+
+
+   Informational Exchanges) generates IVs independantly to prevent IVs
+   from getting out of sync when two different exchanges are started
+   simultaneously.
+
+   In all cases, there is a single bidirectional cipher/IV context.
+   Having each Quick Mode and Informational Exchange maintain a unique
+   context prevents IVs from getting out of sync.
+
+   The key for DES-CBC is derived from the first eight (8) non-weak and
+   non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first
+   8 bytes of the IV material derived above.
+
+   The key for IDEA-CBC is derived from the first sixteen (16) bytes of
+   SKEYID_e.  The IV is the first eight (8) bytes of the IV material
+   derived above.
+
+   The key for Blowfish-CBC is either the negotiated key size, or the
+   first fifty-six (56) bytes of a key (if no key size is negotiated)
+   derived in the aforementioned pseudo-random function feedback method.
+   The IV is the first eight (8) bytes of the IV material derived above.
+
+   The key for RC5-R16-B64-CBC is the negotiated key size, or the first
+   sixteen (16) bytes of a key (if no key size is negotiated) derived
+   from the aforementioned pseudo-random function feedback method if
+   necessary. The IV is the first eight (8) bytes of the IV material
+   derived above. The number of rounds MUST be 16 and the block size
+   MUST be 64.
+
+   The key for 3DES-CBC is the first twenty-four (24) bytes of a key
+   derived in the aforementioned pseudo-random function feedback method.
+   3DES-CBC is an encrypt-decrypt-encrypt operation using the first,
+   middle, and last eight (8) bytes of the entire 3DES-CBC key.  The IV
+   is the first eight (8) bytes of the IV material derived above.
+
+   The key for CAST-CBC is either the negotiated key size, or the first
+   sixteen (16) bytes of a key derived in the aforementioned pseudo-
+   random function feedback method.  The IV is the first eight (8) bytes
+   of the IV material derived above.
+
+   Support for algorithms other than DES-CBC is purely optional. Some
+   optional algorithms may be subject to intellectual property claims.
+
+
+
+
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 39]
+
+RFC 2409                          IKE                      November 1998
+
+
+Authors' Addresses
+
+   Dan Harkins
+   cisco Systems
+   170 W. Tasman Dr.
+   San Jose, California, 95134-1706
+   United States of America
+
+   Phone: +1 408 526 4000
+   EMail: dharkins@cisco.com
+
+
+   Dave Carrel
+   76 Lippard Ave.
+   San Francisco, CA 94131-2947
+   United States of America
+
+   Phone: +1 415 337 8469
+   EMail: carrel@ipsec.org
+
+Authors' Note
+
+   The authors encourage independent implementation, and
+   interoperability testing, of this hybrid protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 40]
+
+RFC 2409                          IKE                      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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harkins & Carrel            Standards Track                    [Page 41]
+