IPSEC Working Group D. Harkins, D. Carrel, Editors INTERNET-DRAFT cisco Systems draft-ietf-ipsec-isakmp-oakley-00.txt June 1996 Expire in six months The resolution of ISAKMP with Oakley <draft-ietf-ipsec-isakmp-oakley-00.txt> Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inapproporiate to use Internet Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Australia), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract [MSST96] (ISAKMP) 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. [Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protetion, and authentication). This document describes a proposal for using the Oakley Key Exchange Protocol 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 ISAKMP Internet DOI. 2. Discussion This draft combines ISAKMP and Oakley. The purpose is to negotiate, and provide authenticated keying material for, security associations Harkins, Carrel [Page 1]
INTERNET DRAFT June 1996 in a protected manner. Processes which implement this draft 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 network. Proxy negotiation-- in which the negotiating parties are not the endpoints for which security association negotiation is taking place-- is supported. When used in proxy mode, identities of the end parties, remain hidden. This proposal does not implement the entire Oakley protocol, but only the smallest subset necessary to satisfy its goals. It does not claim conformance or compliance with the entire Oakley protocol. For greater understanding of the Oakley protocol and the mathematics behind it, please refer to [Orm96]. 3. Terms and Definitions 3.1 Requirements Terminology In this document, the words that are used to define the significance of each particular requirement are usually capitalised. These words are: - MUST This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification. - SHOULD This word or the adjective "RECOMMENDED" means that there might exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before taking a different course. - MAY This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor might choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. Harkins, Carrel [Page 2]
INTERNET DRAFT June 1996 3.2 Notation The following notation is used throughout this draft. HDR is an ISAKMP header whose exchange type is the mode 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. KE is the key exchange payload. NONCE is the nonce payload IDx is the identity 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 Appendix A of [MSST96]. SIG is the signature payload. The data to sign is exchange- specific. CERT is the certificate payload. HASH is the hash payload. ENV{} is the envelope payload. The braces are not part of the protocol but are included to illustrate the payloads which are enveloped. These follow the envelope payload. prf() is the keyed hash function negotiated as part of the ISAKMP SA. SKEYID = prf(Ni | Nr, g^xy | cookie-I | Cookie-R). --> signifies "initiator to responder" communication (requests). <-- signifies "responder to initiator" communication (replies). [x] indicates that x is optional. Payload 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. Harkins, Carrel [Page 3]
INTERNET DRAFT June 1996 4. Introductuction Since Oakley defines a method to establish an authenticated key exchange-- how payloads are constructed, the order in which they are processed and how they are used-- its modes MUST be valid ISAKMP exchange types. The following attributes are required by Oakley and MUST be negotiated as part of the ISAKMP Security Association: - encryption algorithm (e.g. DES, IDEA, Blowfish). - hash algorithm (e.g. MD5, SHA) - authentication algorithm (e.g. DSS, RSA) - information about a group over which to do Diffie-Hellman. The selected hash algorithm MUST support both keyed and unkeyed modes. Oakley implementations MUST support the following default attributes: - DES-CBC with a weak, and semi-weak, key check (weak and semi- weak keys are defined in [Sch94]). The first 8 non-weak bytes of keying material are used for the DES key. - MD5 and SHA in native and HMAC mode. - Digital Signature Standard. RSA SHOULD be supported. - MODP over the default Oakley group (see below). ECP and EC2N groups MAY be supported. In the Internet DOI, Oakley MUST be supported as a key exchange protocol. All other DOIs MAY use Oakley provided they implement the mandatory modes described below. 5. Exchanges There are two basic methods used to establish an authenticated key exchange: Oakley Main Mode and Oakley Agressive Mode. Oakley in Main Mode MUST be implemented; Oakley Aggressive Mode SHOULD be implemented. In addition, Oakley Quick Mode MUST be implemented as a mechanism to generate fresh keying material. Oakley Quick Mode will provide keying material for all security associations negotiated with ISAKMP except the ISAKMP SA itself. In additon, Oakley New Group Mode SHOULD be implemented as a mechanism to define private groups for Harkins, Carrel [Page 4]
INTERNET DRAFT June 1996 Diffie-Hellman exchanges. Exchanges are standard ISAKMP-- e.g. timeout and retransmit; notify response is given when a proposal is unacceptable, or a signature verification or decryption was unsuccessful, etc. 5.1 Oakley Main Mode Oakley Main Mode in conjunction with ISAKMP is described as follows: Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, NONCE(Ni) --> <-- HDR, KE, NONCE(Nr) HDR*, IDii, SIG [, CERT] --> <-- HDR*, IDir, SIG [, CERT] where the signature in SIG is a hash of the concatenation of the cookies, g^xy, nonces, and IDs using the negotiated hash function. One or more certificate payloads MAY be optionally passed. 5.2 Oakley Aggressive Mode Oakley Aggressive mode in conjunction with ISAKMP is described as follows: Initiator Responder ----------- ----------- HDR, SA, KE, NONCE, IDii --> <-- HDR, SA, KE, NONCE, IDir, SIG [, CERT] HDR, SIG [, CERT] --> where the signature in SIG is a hash of the concatenation of the cookies, g^xy, nonces, and IDs using the negotiated hash function. One or more certificate payloads MAY be optionally passed. 5.3 Oakley Quick Mode Oakley Quick Mode is not a complete exchange itself, but is used as part of the ISAKMP SA negotiation process (phase 2) to derive keying material for the SA being negotiated. When used with SA negotiation, the information exchanged along with Oakley Quick Mode MUST be protected by the ISAKMP SA-- i.e. all payloads except the ISAKMP header are encrypted. Harkins, Carrel [Page 5]
INTERNET DRAFT June 1996 Quick Mode is essentially an exchange of nonces that provides replay protection. The nonces are used to generate fresh key material. The envelope payload is used to group related payloads-- the negotiation proposal(s), nonce, and hash result-- into entities which MUST be treated as a whole. In ISAKMP for the Internet DOI, Quick Mode appears as follows Initiator Responder ----------- ----------- HDR*, ENV{SA, Ni, HASH(1)} [, IDui, IDur ] --> <-- HDR*, ENV{SA, Nr, HASH(2)} [, IDui, IDur ] HDR*, ENV{HASH(3)} --> Where: HASH(1) = prf( SKEYID, Ni ) HASH(2) = prf( SKEYID, 1 | Nr | Ni ) HASH(3) = prf( SKEYID, 0 | Ni | Nr ) The new keying material is defined as KEYMAT = prf(SKEYID, Ni | Nr) and MAY be used in the negotiated SA. If ISAKMP is acting as a proxy negotiator on behalf of another party the identities of the parties MUST be passed as IDui and IDur. Local policy will dictate whether the proposals are acceptible for the identities specified. If IDs are not exchanged, the negotiation is assumed to be done on behalf of each ISAKMP peer. If an ID range (see Appendix A of [MSST96]) is not acceptable (for example, the specified subnet is too large) an BAD_ID_RANGE notify message followed by an acceptible ID range, in an ID payload, MUST be sent. Multiple SA's and keys can be negotiated with one exchange as follows: Initiator Responder ----------- ----------- HDR*, ENV1{SA1, Ni1, HASH1(1)}, ENV2{SA2, Ni2, HASH2(1)} [, IDui, IDur ] --> <-- HDR*, ENV1{SA1, Nr1, HASH1(2)}, ENV2{SA2, Nr2, HASH2(2)} [, IDui, IDur ] HDR*, ENV1{HASH1(3)}, --> ENV2{HASH2(3)} Harkins, Carrel [Page 6]
INTERNET DRAFT June 1996 Each enveloped entity is evaluated alone, components of entities MUST NOT be swapped. The initiator of the protocol can impose a selection criterion on the responder by using the Collate bit in the ISAKMP header. When this bit is set the responder MUST select the same ordinal proposal for all entities-- e.g. proposal three for ENV1 and proposal three for ENV2. 5.4 Oakley New Group Mode Oakley 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*, SA --> <-- HDR*, SA The proposal will be an Oakley proposal which specifies the characteristics of the group (see A.6 in [MSST96], "Oakley Attribute Classes"). Group descriptions for private Oakley Groups MUST be greater than or equal to 2^31. If the group is not acceptable, the responder MUST reply with a Notify payload with the message type set to GROUP_NOT_ACCEPTABLE (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 Oakley Main Mode. To do this the Prime, Generator, and Group Type are passed as SA attributes (see Appendix A in [MSST96]). Alternately, the nature of the group can be hidden using Oakley New Group Mode and only the group identifier is passed in the clear during Main Mode. 5.5 Oakley Groups [Orm96] defines several groups. The value 0 indicates no group. The value 1 indicates the default group described below. Other values are also defined in [Orm96]. All values 2^31 and higher are used for private group identifiers. 5.5.1 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 [Page 7]
INTERNET DRAFT June 1996 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. other groups can be defined using Oakley New Group Mode. This default group was generated by Richard Schroeppel at the University of Arizona. Properties of this prime are described by the following exerpt from [Orm96]: The prime for this group was selected to have certain properties. The high order 64 bits are forced to 1. This helps the classical remainder algorithm, because the trial quotient digit can always be taken as the high order word of the dividend, possibly +1. The low order 64 bits are forced to 1. This helps the Montgomery-style remainder algorithms, because the multiplier digit can always be taken to be the low order word of the dividend. The middle bits are taken from the binary expansion of pi. This guarantees that they are effectively random, while avoiding any suspicion that the primes have secretly been selected to be weak. The prime is chosen to be a Sophie-Germain prime (i.e., (P-1)/2 is also prime), to have the maximum strength against the square-root attack. The starting trial numbers were repeatedly incremented by 2^64 until suitable primes were located. Because this prime is congruent to 7 (mod 8), 2 is a quadratic residue. All powers of 2 will also be quadratic residues. This prevents an opponent from learning the low order bit of the Diffie-Hellman exponent. Using 2 as a generator is efficient for some modular exponentiation algorithms. [Note that 2 is technically not a generator in the number theory sense, because it omits half of the possible residues mod P. From a cryptographic viewpoint, this is a virtue.] A further discussion of the properties of this group, the motivation behind its creation, as well as the definition of several more groups can be found in [Orm96]. Harkins, Carrel [Page 8]
INTERNET DRAFT June 1996 5.6 Payload Explosion for Complete ISAKMP-Oakley Exchange This section illustrates how ISAKMP payloads are used with Oakley to: - establish a secure and authenticated channel between ISAKMP processes (phase 1); and - generate key material for, and negotiate, an IPsec SA (phase 2). 5.6.1 Phase 1 using Oakley 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. 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 Oakley Main Mode, ~ ~ and Next Payload of ISA_INIT ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (Internet DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Situation ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ ISAKMP SA Proposal(s) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 Oakley Main Mode, ~ ~ and Next Payload of ISA_KE ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_NONCE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ D-H Public Value (g^x from initiator g^y from responder) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Ni (from initiator) or Nr (from responder) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Harkins, Carrel [Page 9]
INTERNET DRAFT June 1996 A shared key, SKEYID = prf(Ni | Nr, g^xy | Cookie-I | Cookie-R) where "prf" is the keyed hash function negotiated as part of the ISAKMP SA, is now used to protect all further communication. Note that SKEYID is 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 Oakley 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 of the cookies, the nonces, the identities, and g^xy. Once the signature has been verified using the authentication algorithm negotiated as part of the ISAKMP SA, the shared key, SKEYID can be marked as authenticated. (For brevity, certificate payloads were not exchanged). 5.6.2 Phase 2 using Oakley Quick Mode The following payloads are exchanged in the first round of Oakley Quick Mode with ISAKMP SA negotiation. In this hypothetical exchange, the ISAKMP negotiators are proxies for other parties which have requested security. Harkins, Carrel [Page 10]
INTERNET DRAFT June 1996 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 Oakley Quick Mode, ~ ~ Next Payload of ISA_ENV and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_INIT ! # of payloads ! Protocol ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SPIs (each party specifies his own) ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_NONCE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (Internet DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Situation ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ IPSec ESP Proposal(s) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_HASH ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Ni (from initiator) or Nr (from responder) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_ID ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ hash data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_ID ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ID of source for which ISAKMP is a proxy ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ID of destination for which ISAKMP is a proxy ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where the contents of the hash are described in 5.3 above. The # of Payloads field of the envelope payload is used to encapsulate the SA, nonce, and hash, and tie all three to the specified SPI. Upon receipt, and validation, of this payload, the initiator can provide the negotiation server (or key engine) with the negotiated security association and the keying material derived from Quick Mode. To prevent replay attacks from creating bogus security associations, the responder does not provide the security association and keying material until receipt and validation of the next payload. Harkins, Carrel [Page 11]
INTERNET DRAFT June 1996 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 Oakley Quick Mode, ~ ~ Next Payload of ISA_ENV and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_HASH ! # of payloads ! Protocol ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ responder SPI ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ hash data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where the contents of the hash are described in 5.3 above. The # of Payloads field of the envelope payload is used to associate the hash payload with the responder's SPI. At this point the responder has verified that the request was not the result of a replay attack and can provide the SA and key material to the negotiation server (or key engine). To provide for secure duplex communication, the ISAKMP negotiators MUST construct two security associations for each accepted proposal. The first, identified by the SPI is from the source to the destination (in the event that there is no proxy negotiation it will be from initiator to responder); the second identified by the AUX-SPI is from the destination to the source (or responder to initiator). 6. Security Considerations This entire draft discusses a hybrid protocol, combining Oakley 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 digital signature algorithm. 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 draft does not proscribe such a limit. Harkins, Carrel [Page 12]
INTERNET DRAFT June 1996 7. Acknowledgements This document is the result of close consultation with Hilarie Orman, Douglas Maughan, Mark Schertler, Mark Schneider, and Jeff Turner. It relies completely on protocols which were written by them. Without their interest and dedication, this would not have been written. We would also like to thank Cherly Madson and Harry Varnis for technical input. 8. References [MSST96] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)", version 5, draft-ietf-ipsec-isakmp-05.{ps,txt}. [Orm96] Orman, H., "The Oakley Key Determination Protocol", version 2, draft-ietf-ipsec-oakley-02.txt. [Sch94] Schneier, B., "Applied Cryptography, Protocols, Algorithms, and Source Code in C", 1st edition. Editors' Addresses: Dan Harkins <dharkins@cisco.com> Dave Carrel <carrel@cisco.com> cisco Systems 170 W. Tasman Dr. San Jose, California, 95134-1706 United States of America +1 408 526 4000 Editors' Note: The editors encourage independent implementation, and interoperability testing, of this hybrid exchange. Harkins, Carrel [Page 13]
