IPSEC Working Group Dan Harkins, Network Alchemy INTERNET-DRAFT Dave Carrel, Redback Networks draft-ieft-ipsec-ike-00.txt May 1999 The Internet Key Exchange (IKE) <draft-ietf-ipsec-ike-00.txt> Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026 [Bra96]. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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). Table of Contents 1 Abstract.......................................................2 2 Terms and Definitions..........................................3 2.1 Requirements Terminology.....................................3 2.2 Perfect Forward Secrecy......................................3 2.3 Modes and Phases.............................................3 2.4 Security Association.........................................4 2.5 Authentication Options.......................................4 2.6 Notation.....................................................4 3 Introduction...................................................6 3.1 Mandatory Options............................................7 3.2 Attribute Negotiation........................................8 4 IKE Internal State.............................................9 4.1 Phase 1 state................................................9 4.2 Phase 2 state................................................10 5 Oakley Groups..................................................11 5.1 Group One....................................................11 Harkins Carrel [Page 1]
INTERNET DRAFT May 1999 5.2 Group Two....................................................12 5.3 Group Three..................................................12 5.4 Group Four...................................................12 5.5 Group Five...................................................13 6 IKE Phases.....................................................13 6.1 Phase 1......................................................14 6.1.1 Main Mode..................................................14 6.1.1.1 Authentication with Pre-shared keys......................15 6.1.1.2 Authentication with Digital Signatures...................15 6.1.1.3 Authentication with Public Key Encryption................16 6.1.1.4 Authentication with Revised Public Key Encryption........17 6.1.2 Aggressive Mode............................................19 6.1.2.1 Authentication with Pre-shared keys......................20 6.1.2.2 Authentication with Digital Signatures...................21 6.1.2.3 Authentication with Public Key Encryption................21 6.1.2.4 Authentication with Revised Public Key Encryption........22 6.2 Quick Mode...................................................23 6.3 New Group Mode...............................................27 6.4 Notification Exchanges.......................................28 6.4.1 Unacknowledged Informational...............................29 6.4.2 Acknowledged Informational.................................29 7 Payload Explosion of Sample Exchange...........................31 7.1 Phase 1 Using Main Mode......................................31 7.2 Phase 2 Using Quick Mode.....................................32 8 Security Considerations........................................34 9 IANA Considerations............................................36 10 Acknowledgements..............................................37 11 References....................................................37 Appendix A.......................................................40 Appendix B.......................................................43 Author's Address.................................................45 1. Abstract This memo describes a key exchange and security negotiation protocol which is intended to depricate [HC98]. As such it will not change the "bits on the wire" for an implementation which is compiant with [HC98] but will clarify contentious issues with [HC98] and attempt to explain the protocol in a less haphazard manner. Due to advances in computer processing some mandatory-to-implement attributes have changed between this [HC98] and this document. In addition a new and optional exchange is introduced. Like [HC98] this memo uses [MSST98] for a framework and as a language to express exchanges which are derived from [Kra96] and [Orm98]. In places where the requirements between this document and [MSST98] or [Kra96] or [Orm98] conflict, this document will be supreme. Harkins Carrel [Page 2]
INTERNET DRAFT May 1999 This is a request/response type protocol in which roles of an Initiator and Responder are played by the parties to the protocol. The Initiator initiates the protocol to the Responder who responds back. 2. Terms and Definitions 2.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]. 2.2 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. 2.3 Modes and Phases This protocol uses ISAKMP as a means of communication and all rules regarding transport, construction, and retransmission of messages are as specified in [MSST98]. All messages in IKE are constructed by chaining ISAKMP payloads to an ISAKMP header. This is a dual phase protocol where the parties to the protocol, also called the peers, authenticate each other and establish a protected communications channel in the first phase and then negotiate security services in the second phase (using the protected communications channel from the first for security). There are different exchanges, also called "modes", which can be used in the different phases. Phase 1 exchanges are Main Mode and Aggressive Mode. The only phase 2 exchange is Quick Mode. In addition, three additional modes are defined which are neither strictly phase 1 nor phase 2. Section 6 discusses IKE phases in detail. Unless otherwise noted there are no ordering requirements on payloads Harkins Carrel [Page 3]
INTERNET DRAFT May 1999 in various IKE messages. 2.4 Security Association A security association (SA) is a set of policy and key(s) used to protect information. The Phase 1 SA is the shared policy and key(s) used by the negotiating peers in this protocol to protect their communication. The Phase 1 SA is bi-directional. That is, once established, the peers may use it to securely initiate communication with each other regardless of who initiated the Phase 1 exchange. The roles played by the peers are strictly adhered to during Phase 1 (the Initiator remains the Initiator and the Responder remains the Responder for the entire mode) but once the Phase 1 SA is established the roles can reverse for Phase 2. The peer who was the Responder during Phase 1 can become the Initiator of Phase 2. Phase 1 SAs are identified by the cookies contained in the ISAKMP header. There are two cookies in the ISAKMP header, one for the Initiator and one for the Responder. The roles during Phase 1 dictate who generates which cookie and once established the cookie order does not swap even if the direction of the Phase 1 SA switches. That is, if Alice initiates a Phase 1 exchange to Bob which results in a Phase 1 SA, the SA will be identified by an Initiator cookie generated by Alice and a Responder cookie generated by Bob even if Bob susequently assumes the role of Initiator during a Phase 2 exchange. Security Associations are negotiated for other security services during Phase 2. The nature of these SAs is dependant on the Domain of Interpretation (DOI) in the SA payload. ([Pip98] defines the DOI for IPSec). 2.5 Authentication Options During Phase 1 the peers authenticate each other. There are four distinct methods of authentication in IKE: authentication with pre- shared keys, authentication with digital signatures, and two methods of authentication using public key encryption. These options impact the Phase 1 exchange in a different manner. In fact, the exchange can morph depending on the method chosen. 2.6 Notation The following notation is used throughout this memo. All "payloads" are from [MSST98]. HDR is an ISAKMP header. When written as HDR* it indicates message Harkins Carrel [Page 4]
INTERNET DRAFT May 1999 encryption: all payloads following the header are encrypted with a symmetric session key. SA is an SA negotiation payload with one or more proposal payloads enclosed, which themselves may contain one or more transform payloads. SAi_b is the entire body of the SA payload (minus the ISAKMP generic header)-- i.e. the DOI, situation, and all proposals and transforms enclosed-- proposed by the Initiator. CKY-I and CKY-R are the Initiator's cookie and the Responder's cookie, respectively, from the ISAKMP header. g^i and g^r are the Diffie-Hellman ([DH]) public values of the Initiator and the Responder respectively. The length of these values MUST be the minimum number of octets required to hold a bitstream whose length is equal to the size of the group-- the size of the prime modulus for MODP groups, or the field size for ECP and EC2N groups (see section 5). This requirement is ensured by pre-pending the value with zero bits up to the next 8-bit boundary if necessary. g^ir is the Diffie-Hellman secret. When used in IKE as input to functions the length of this value MUST be identical to that of g^i and g^r. KE is the key exchange payload which contains the public value (g^i or g^r) exchanged in a Diffie-Hellman exchange. Ni and Nr are the nonce payloads from the Initiator or the Responder, respectively. Nonce lengths MUST be between 8 and 256 bytes inclusive. ID_x is the identification payload for "x". x can be: "i1" or "r1" for the phase one identities of the Initiator or the Responder, respectively; or, "i2" or "r2" for the optional identities exchanged in phase 2. <P>_b indicates the body of payload <P>-- the ISAKMP generic payload is not included. For instance, Ni_b would signify the body of the nonce payload-- everything except the generic header-- supplied by the Initiator. SIG is the signature payload. CERT is the certificate payload. Harkins Carrel [Page 5]
INTERNET DRAFT May 1999 CERT_REQ is the certificate request payload. HASH (and any derivitive such as HASH(2) or HASH_I) is the hash payload. H(x) is the hash of "x" whose result is a digest. prf(key, msg) is a keyed pseudo-random function-- often a keyed hash function-- used to generate a deterministic output that appears pseudo-random. 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 parties of the exchange to protect the confidentiality of messages. SKEYID_a is the keying material used by the parties of the exchange for message integrity. SKEYID_d is the keying material used to derive keys for security services during phase 2. <x>y indicates that "x" is encrypted with the key "y". --> signifies a message from the Initiator to the Responder. <-- signifies a message from the Responder to the Initiator. | signifies concatenation of information. For example, X | Y is the concatenation of X with Y. [x] indicates that x is optional. 3. Introduction A Domain Of Interpretation defines the attributes (and their meanings) negotiated by IKE. It may overload payloads that are defined in [MSST98]. This protocol does not define its own DOI per se. It does not define DOI nor Situation values for the SA payload during Phase 1 negotiation. The Phase 1 SA MAY use the DOI and situation from a non-ISAKMP service (such as [Pip97]). In this case an implementation MAY choose to restrict use of the Phase 1 SA for establishment of SAs for services of the same DOI. Alternatively, a Phase 1 SA MAY be established with the value zero in both the DOI and Situation fields and in this case implementations will be free to establish security Harkins Carrel [Page 6]
INTERNET DRAFT May 1999 services for any defined DOI using this Phase 1 SA. If a DOI of zero is used for establishment of a Phase 1 SA, the syntax of the identity payloads used in the Phase 1 exchange MUST be as defined in [MSST98] and not from any DOI. 3.1 Mandatory Options Main Mode (section 6.1.1) MUST be implemented for Phase 1; Aggressive Mode (section 6.1.2) SHOULD be implemented. Quick Mode (section 6.2) MUST be implemented for Phase 2. Both acknowledged and unacknowledged notification exchanges (section 6.4) MUST be implemented. New Group mode (section 6.3) SHOULD be implemented. [MSST98] defines the concept of a "protection suite". To IKE this is the attributes negotiated in SA payloads during Phase 1 whose agreement results in the Phase 1 SA. Attributes that MUST comprise a "protection suite" are: - encryption algorithm - hash algorithm - authentication method - information about a group over which to do a Diffie-Hellman. In addition, optional attributes may be negotiated. These include a lifetime and a pseudo-random function ("prf"). (There are currently no negotiable pseudo-random functions defined in this document but the ability to negotiate them exists). In the absense of a negotiated "prf" the HMAC version of the negotiated hash function (see [KCB96]) is used as a pseudo-random function. Negotiable Phase 1 attributes are described in Appendix A. IKE implementations MUST support the following attribute values: - Triple DES in CBC mode for encryption algorithm. - MD5 [MD5] and SHA [SHA]) for hash function. - Authentication via pre-shared keys. - MODP over group number two (see section 5). In addtion IKE implementations SHOULD support the following values: - CAST in CBC mode and Blowfish in CBC mode for encryption Harkins Carrel [Page 7]
INTERNET DRAFT May 1999 algorithm. - Tiger ([Tiger]) for hash algorithm. - Authentication using RSA and DSA signatures, and using RSA and El-Gamal public key encryption. - Groups 3 through 5 for Diffie-Hellman group. In addition IKE implementations MAY support the following values: - DES in CBC mode for encryption algorithm. - Group 1 for Diffie-Hellman group. 3.2 Attribute Negotiation During security association negotiation Initiators present offers, in the form of protection suites, to Responders. Responders MUST NOT modify any attributes of any offer (with the possible exception of attribute encoding, see Appendix A). If the Initiator of an exchange notices that attribute values have been changed or attributes have been added or deleted from an offer made that response MUST be rejected. The SA payload from [MSST98] is used to negotiate security associations in both Phase 1 and Phase 2 exchanges. This payload contains a field for a Security Parameter Index (SPI) and a field for the length of the SPI. During Phase 1 the SPI field MUST be empty and the length of the SPI MUST be zero. During Phase 2 the SPI values and their lengths depends on the particular DOI being negotiated. Diffie-Hellman groups are specified either using a defined group description (section 5) or by defining all attributes of a group (Appendix A) in a protection suite. Group attributes, such as group type or prime number MUST NOT be offered in conjunction with a previously defined group, defined either in section 5 or via a previous New Group Mode exchange (section 6.3). Certain negotiable attributes have ranges or multiple acceptable values. For instance, if the policy specification on a peer mandates group 2 but is offered group 5, as part of an otherwise acceptable protection suite, the peer SHOULD accept that value as it provides more security than demanded. SA lifetimes pose similar issues. If a peer has a local policy which requires SAs live for no more than 2 hours and is offered a protection suite which contains a lifetime value of 1 hour, the peer SHOULD accept that value as it provides less opportunity for key exposure. Harkins Carrel [Page 8]
INTERNET DRAFT May 1999 The converse, though, does not hold. If a peer mandates group 5 (or a lifetime of 1 hour) and is offered group 2 (or a lifetime of 1 hour) that offer SHOULD be refused as it violates the local policy. It is therefore possible to be in a situation where Alice can successfully initiate an IKE exchange with Bob but not the other way around. A simple way around this situation is to not enforce local policy and accept any lifetime offered or any group offered. This behavior is strongly discouraged; implementations SHOULD NOT ignore local policy. If an implementation accepts a protection suite all values of that protection suite MUST be honored-- in other words, implementations MUST NOT ignore lifetime or Diffie-Hellman group offers and just "do their own thing". A DOI may dictate other actions to take in these circumstances when negotiating its service. 4. IKE Internal State During an IKE exchange the peers generate state associated with the exchange. This state is generated as soon as all components are available. 4.1 Phase 1 state Information exchanged during Phase 1 allows for the construction of a Phase 1 SA. This information is protection suite offer(s), cookies (CKY-I and CKY-R), nonces (Ni and Nr), and Diffie-Hellman values (g^i and g^r). In addition to (and out of) this information transmitted in messages some Phase 1 state is generated by each peer. These are the keys the peers use to protect their communications (SKEYID and its derivitives) and the digests they use to authenticate each other. When the Diffie-Hellman shared secret is used in Phase 1 state generation its length MUST be the minimum number of octets required to hold a bitstream whose length is equal to the size of the group-- the size of the prime modulus for MODP groups, or the field element size for ECP and EC2N groups (section 5). This can be ensured by pre- pending the value with zero bits up to the next 8-bit boundary if necessary. SKEYID takes different values depending on the authentication method negotiated. The methods of generation are: digital signatures: SKEYID = prf(Ni_b | Nr_b, g^ir) public key encryption: SKEYID = prf(H(Ni_b | Nr_b), CKY-I | CKY-R) Harkins Carrel [Page 9]
INTERNET DRAFT May 1999 pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b) Upon generation of SKEYID, the remaining internal state can be derived. SKEYID_d is used to derive additional keys for security services other than IKE during a Phase 2 exchange; SKEYID_a is used to provide authentication and data integrity to IKE messages; and, SKEYID_e is used to provide confidentiality to IKE messages. SKEYID_d = prf(SKEYID, g^ir | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^ir | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^ir | CKY-I | CKY-R | 2) where 0, 1, and 2 are represented by a single octet. As part of the authentication step each side generates two digests, one for the Initiator, I, and one for the Responder, R. These digests either presented as is or digitally signed depending on the authentication method negotiated. These digests are: I-digest = prf(SKEYID, g^i | g^r | CKY-I | CKY-R | SAi_b | ID_i1) R-digest = prf(SKEYID, g^r | g^i | CKY-R | CKY-I | SAi_b | ID_r1) For authentication with digital signatures, I and R are digitally signed and the resulting signature is passed as a SIG payload during the exchange. For authentication with pre-shared keys and both types of public key encryption I and R are passed as a HASH payload during the exchange. Symmetric encryption algorithms used by IKE to protect its messages MUST be in CBC mode. This mode requires an Initialization Vector (IV) for each encrytion operation. The initial IV is derived from a hash of the concatenation of the Initiator's Diffie-Hellman public value and the Responder's Diffie-Hellman public value using the negotiated hash algorithm. The public values are those taken directly out of the KE payload including any pre-pended zero bits. This is used for the first message only. Subsequent messages MUST use the last CBC encryption block from the previous message as their initialization vector. 4.2 Phase 2 state During a Quick Mode exchange new SAs for a security service other than ISAKMP are generated (e.g. IPSec). The exact nature of those SAs is defined in the approprate DOI document, but as part of the key generation aspect of Quick Mode negotiation IKE does require some new Harkins Carrel [Page 10]
INTERNET DRAFT May 1999 state be maintained. Quick Mode exchanges are done under the protection of an existing Phase 1 exchange and the message ID from the ISAKMP header is used to multiplex multiple exchanges through the single SA. While the Phase 1 SA is identified by the cookies during a Phase 1 exchange, it is the message ID and the cookies that identifies a state specific to a Phase 2 exchange. Unlike a Phase 1 exchange there are no variables that need to be calculated and retained after the exchange has finished. Only information exchanged during a Quick Mode-- protection suite offers, nonces and, if PFS is desired, additional Diffie-Hellman public values-- need be maintained and once the exchange has terminated it can be thrown away (after, of course, the key(s) for the SA(s) have been supplied to the appropriate service). The actual method for generating keying material is discussed in section 6.2. All Quick Mode messages are encrypted using the negotiated symmetric cipher with SKEYID_e as the key. Therefore a seperate IV is needed to "jump start" the encryption. This IV is derived from a hash of the concatenation of the last Phase 1 CBC output block (or the Phase 1 IV derived in section 4.1 if no Phase 1 messages were encrypted), and the Phase 2 message ID using the negotiated hash algorithm. 5 Oakley Groups There are 5 groups different Diffie-Hellman groups defined for use in IKE. These groups were generated by Richard Schroeppel at the University of Arizona. Properties of these primes are described in [Orm96]. The strength supplied by group one may not be sufficient for the mandatory-to-implement encryption algorithm and is here for historic reasons. 5.1 First Oakley Group IKE implementations MAY 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 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF Harkins Carrel [Page 11]
INTERNET DRAFT May 1999 The generator is: 2. Harkins Carrel [Page 12]
INTERNET DRAFT May 1999 5.2 Second Oakley Group IKE implementations MUST 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 C90FDAA2 2168C234 C4C6628B 80DC1CD1 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF The generator is 2 (decimal) 5.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 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). 5.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 Harkins Carrel [Page 13]
INTERNET DRAFT May 1999 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). 5.5 Fifth Oakley Group IKE implementations SHOULD support a MODP group with the following prime and generator. This group is assigned id 5 (five). The prime is 2^1536 - 2^1472 - 1 + 2^64 * {[2^1406 pi] + 741804}. Its hexadecimal value is FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF The generator is 2. Other groups can be defined using New Group Mode. 6. Modes for IKE Phases IKE exchanges are called modes and these modes accomplish the phased negotiation for IKE. There are two phases. Phase 1 exchanges are intended to establish shared policy and keys in the form of a Phase 1 Security Association (SA). Phase 2 exchanges are intented to establish Security Associations for security services other than IKE. A DOI defines the nature of those services. [Pip98] is the DOI for IPSec. Exchanges in IKE are not open-ended and a certificate request payload MUST NOT extend the number of messages in a given exchange. Harkins Carrel [Page 14]
INTERNET DRAFT May 1999 6.1 Phase 1 There are three steps to Phase 1: negotiation of protection suites, a Diffie-Hellman exchange, authentication. There are two modes to accomplish Phase 1: Main Mode, and Aggressive Mode. Their most obvious difference is in the number of message necessary to accomplish the work. Main Mode requires 6 messages while Aggressive Mode requires 3. There are other subtle differences. For instance, the parameters to negotiate in an Aggressive Mode exchange are constrained compared to a Main Mode exchange. Because the Diffie-Hellman exchange begins with the first message (which also contains the protection suite offers) it is not possible to negotiate offers with differing Diffie-Hellman group attributes. Other parameters are constrained depending on the authentication method chosen. All initial Phase 1 messages from the Initiator to the Responder MUST have an SA payload as the first payload following the ISAKMP header. The SA payload MUST contain only one proposal payload. Multiple protection suites are offered by offering multiple transform payloads and encapsulating them in the single SA payload. There is no limit on the number of offers an Initiator can make but compliant implementations MAY, for performance reasons, choose to limit the number of offers it will inspect. Phase 1 authentication using Public Key Encryption requires the Initiator to possess the Responder's public key prior to initiation of the exchange. The method of acquisition of the Responder's public key is outside the scope of this memo. It can be any out-of-band mechanism or it can be from a previous IKE exchange in which certificates were requested, exchanged, and retained. If a previous exchange requests a peer's certificate for subsequent use during an exchange using public key encryption as the authentication method the certificate encoding requested MUST be for key exchange (5). Use of the commit bit from [MSST98] during Phase 1 is forbidden. Implementations SHOULD respond with an notify message whose type is set to INVALID-FLAGS (8). 6.1.1 Main Mode A goal of Main Mode is identity protection. The ID payloads are never passed on the wire in the clear, thereby masking the true identity of the parties performing the IKE exchange. Main Mode is an instantiation of the ISAKMP Identity Protect exchange from [MSST98]. Harkins Carrel [Page 15]
INTERNET DRAFT May 1999 6.1.1.1 Main Mode Authentication With Pre-Shared Keys A key derived from some out-of-band mechanism (which is beyond the scope of this memo) can be used to authenticate an IKE exchange. When using pre-shared key authentication, Main Mode is defined as: Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDi1, HASH_I --> <-- HDR*, IDr1, HASH_R Where HASH_I and HASH_R are the I-digest and R-digest (section 4.1), respectively, presented in a hash payload. When using pre-shared key authentication with Main Mode the key can only be identified by the IP address of the peers since computation of the I-digest is dependant on the pre-shared key and I-digest must be computed prior to the Responder receiving IDi1. 6.1.1.2 Main Mode Authentication with Digital Signatures Digital signatures may be used to authenticate a Main Mode exchange. Signature checking requires trusting a public key and, in lieu of a Public Key Infrastructure, certificates can be passed in-line to faccilitate this. Main Mode authenticated with digital signatures is defined as: Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDi1, [ CERT, ] SIG_I --> <-- HDR*, IDr1, [ CERT, ] SIG_R Where SIG_I and SIG_R are digital signatures of I-digest and R-digest (section 4.1), respectively, and presented in a signature payload. Since the algorithm used in generation of I-digest and R-digest is known (it is the prf which is, most likely, the HMAC version of the negotiated hash algorithm) 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 [PKCS1] and those used in this document. Harkins Carrel [Page 16]
INTERNET DRAFT May 1999 Therefore, RSA signatures MUST be encoded as a private key encryption in [PKCS1] format (without the hash OID) and not as a PKCS #1 signature (which encodes the digest with an OID). DSA signatures MUST be encoded as the value "r" followed by "s". In general the signature will be directly over I-digest and R-digest which are generated by the pseudo-random function. However, this can be overridden for construction of a signature if the signature algorithm is tied to a particular hash algorithm by changing the digest construction from: digest = prf(key, msg) to digest = hash(key | msg) For example, DSS is only defined with SHA's 160 bit output and in this case the digests would be: I-digest = SHA(SKEYID | g^i | g^r | CKY-I | CKY-R | SAi_b | ID_i1) R-digest = SHA(SKEYID | g^r | g^i | CKY-R | CKY-I | SAi_b | ID_r1) The contents of the signature payload would then be the resulting 320-bit DSA signature of the digest ("r" followed by "s"). 6.1.1.3 Main Mode Authentication with Public Key Encryption Main Mode can be authenticated by using public key encryption by encrypting each nonce in the peer's public key. The ability of the peer to decrypt the nonce and properly construct the authenticating digest from section 4.1 is authenticated proof of identity. This authentication method is attractive in that it is a deniable exchange. The peers authenticate each other but they lack the kind of non-repudiable proof of conversation that one gets with a digital signature. In addition, security is added to secret generation since an attack would have to successfully break not only the Diffie- Hellman exchange but also both public key encryptions. This exchange was adapted from [SKEME]. In order to perform public key encryption authentication 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 which contains the pubic key the Initiator is using to encrypt the nonce is passed as part of the third message. When passed, the hash payload MUST precede any payloads encrypted with the Responder's public key. The Responder identifies the Initiator's Harkins Carrel [Page 17]
INTERNET DRAFT May 1999 public key using the Inititator's identity passed as IDi1. The Nonce and ID payloads MUST be encrypted in the public key of the peer. Main Mode authenticated with public key encryption is defined as: Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, [ HASH(1), ] <IDi1_b>PubKey_r, <Ni_b>PubKey_r --> HDR, KE, <IDr1_b>PubKey_i, <-- <Nr_b>PubKey_i HDR*, HASH_I --> <-- HDR*, HASH_R Where HASH(1) is the optional hash of the certificate which contained Pubkey_r. Where HASH_I and HASH_R are the I-digest and R-digest, respectively, from section 4.1 presented in a hash payload. The format of the encrypted data depends on the algorithm being used. For RSA encryption the format is specified in [PKCS1]. For El-Gamal encryption the [PKCS1] convention for encryption block encoding is used for each component of the ciphertext, and the ciphertext of message M consists of the value A followed by the value B: A = g^k mod p B = y^k * M mod p where the peer's public key is y, g, p and k is a random value per the El-Gamal cryptosystem. 6.1.1.4 Main Mode Authentication with Revised Public Key Encryption Authentication with public key encryption has significant advantages over authentication with digital signatures (see 6.1.1.3 above). Unfortunatly, this is at the cost of 4 public key operations-- two public key encryptions and two private key decryptions. The revised mode of public key authentication retains the advantages to 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 all subsequent payloads are encrypted using the negotiated symmetric encryption algorithm (from the SA payload) with a key derived from the nonce. This solution adds minimal complexity Harkins Carrel [Page 18]
INTERNET DRAFT May 1999 and state yet saves two costly public key operations on each side. In addition the KE payload is also encrypted using this same derived key to provide additional protection against cryptanalysis of the Diffie-Hellman exchange. As with the authentication method from 6.1.1.3 a hash payload may be sent to identify a certificate if the Responder has multiple certificates which contain useable public keys. If the hash payload is sent is MUST be the first payload of the third message and MUST be followed by the encrypted nonce. If the hash payload is not sent the first payload MUST be the encrypted nonce. All payloads, including any optional payloads, following the nonce MUST be encrypted in the appropriate symmetric key derived from the encrypted nonce. Main Mode authenticated with the revised method of public key encryption is defined as: Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, [ HASH(1), ] <Ni_b>Pubkey_r, <KE_b>Ke_i, <IDi1_b>Ke_i, [<<Cert-I_b>Ke_i] --> HDR, <Nr_b>PubKey_i, <KE_b>Ke_r, <-- <IDr1_b>Ke_r, HDR*, HASH_I --> <-- HDR*, HASH_R Where HASH(1) is the optional hash of the certificate which contained Pubkey_r, HASH_I and HASH_R are the I-digest and R-digest, respectively, from section 4.1 presented in a hash payload, and Ke_i and Ke_r are the keys to the symmetric encryption algorithm negotiated in the SA payload. Note that only the bodies of the payloads are encrypted (in both asymmetric and symmetric operations), the generic headers are left in the clear to enable proper payload parsing. The payload length includes that added to perform encryption. The format of the ciphertext depends on the algorithm used and is identical to that of section 6.1.1.3. The symmetric cipher keys are derived from the decrypted nonces as follows. First the values Ne_i and Ne_r are computed: Harkins Carrel [Page 19]
INTERNET DRAFT May 1999 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 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. CBC mode is used with symmetric encryption in IKE and this requires an IV. 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. 6.1.2 Aggressive Mode An Aggressive Mode exchange completes Phase 1 with half the messages as Main Mode. It does this at some expense of negotiation. Because more payloads are sent with the first two messages more committment Harkins Carrel [Page 20]
INTERNET DRAFT May 1999 to the nature of the exchange must be made. For instance, the KE payload, which contains the Diffie-Hellman public value, is sent in the same message as the SA payload which contains attributes for negotiation of the Diffie-Hellman group. Obviously, it is not possible to negotiate this attribute. Different authentication methods can further constrain the negotiable options of Aggressive Mode. Unlike Main Mode, Aggressive Mode was not designed for Identity Protection. The ID payloads are passed in the clear allowing a potential adversary to observe the identities of the parties to the IKE exchange. An advantage of Aggressive Mode over Main Mode (aside from the fewer rounds) is that computation of SKEYID state can be delayed until transmission (and receipt) of the final authenticating message from the Initiator to the Responder. All diagrams show this final Aggressive Mode message as unencrypted (it lacks the asterisk with the HDR). Implementations MAY choose to send this message encrypted though. 6.1.2.1 Aggressive Mode Authentication with Pre-Shared Keys Because the ID payload is passed in Aggressive Mode prior to computation of SKEYID state it is possible to use pre-shared keys which are bound to identities other than the peer's IP address. For situations where the Initiator is using a dynamically assigned IP address this is especially important. In spite of the fact that the ID payload is passed in the clear an identity can be "hidden" by using the KEY_ID identity type from [MSST98]. This enables a pre- shared key to be associated with an opaque sequence of characters which conveys no meaning to anyone except the two parties to the exchange. Aggressive Mode authenticated with pre-shared keys is defined as: Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDi1 --> <-- HDR, SA, KE, Nr, IDr1, HASH_R HDR, HASH_I --> Where the payload contents are identical to Main Mode. Harkins Carrel [Page 21]
INTERNET DRAFT May 1999 6.1.2.2 Aggressive Mode Authenticated with Digital Signatures Digital signatures can authenticate Aggressive Mode in the same manner in which they authenticate Main Mode. Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDi1 --> <-- HDR, SA, KE, Nr, IDr1, [ CERT, ] SIG_R HDR, [ CERT, ] SIG_I --> The optional CERT payload sent by the Initiator is shown as part of the last Aggressive Mode message but since [MSST98] allows for a freeform construction of messages this payload MAY be sent as part of the first message. 6.1.2.3 Aggressive Mode Authenticate with Public Key Encryption This authentication method further constrains Aggressive Mode authentication in that if this method is desired than all protection suites offered in the SA payload must offer it. Note that Aggressive Mode authenticated with both pre-shared keys and digital signatures may offer multiple protection suites, some with pre-shared key offers, some with digital signature offers because the Initiator has not yet committed himself to an authentication method. This is not the case with authentiction using public key encryption. The nonce payload, which is part of the first message, must be encrypted in the Responder's public key so the Initiator is bound to this method if it is desired. Like Main Mode authentication with public key encryption, a hash payload may be sent by the Initiator prior to the use of the Responder's public key to identify which public key is being used in the event the Responder has multiple certificates. The Nonce payloads and ID payloads MUST be encrypted in the peer's public key. Also, like Main Mode this is a completely deniable exchange. An advantage of using this method of authentication in Aggressive Mode is that identity protection can be realized because the ID payloads are similarly encrypted in the peer's public key along with the nonce payload. Harkins Carrel [Page 22]
INTERNET DRAFT May 1999 Aggressive Mode authenticated with public key encryption is defined as: Initiator Responder ----------- ----------- HDR, SA, [ HASH(1),] KE, <IDi1_b>Pubkey_r, <Ni_b>Pubkey_r --> HDR, SA, KE, <IDr1_b>PubKey_i, <-- <Nr_b>PubKey_i, HASH_R HDR, HASH_I --> Where the notation, formatting, and payload contents are identitical to section 6.1.1.3. 6.1.2.4 Aggressive Mode Authentication with Revised Public Key Encryption The revised method of public key encryption affords the same benefits to Aggressive Mode as it did to Main Mode: the exchange is still completely deniable, an adversary must attack not only the Diffie- Hellman exchange but both public key encryptions, and it requires only two public key operations, a public key encryption and a private key decryption. As with the Revised Public Key Encryption method in Main Mode, a hash of the Responder's public key may be sent prior to the use of the key in the event that the Responder has multiple public keys. Also, all payloads following the encrypted nonce, including any optional payloads, MUST be encrypted with the negotiated symmetric cipher (from the SA payload) using a key derived from the nonce. The revised method of public key encryption further constrains the negotiable options that the Initiator can offer to the Responder. This is due to the fact that a hash algorithm and a symmetric encryption algorithm must be used to construct the first message. In fact, all mandatory attributes that must accompany all protection suite offers must be identical. The only way to construct multiple protection suite offers using Aggressive Mode with the revised method of public key encryption is to vary the lifetime. Harkins Carrel [Page 23]
INTERNET DRAFT May 1999 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 notation, formatting, payload contents and all state generation is identical to section 6.1.1.4. 6.2 Quick Mode A Quick Mode exchange is strictly a Phase 2 exchange and MUST be done under the protection of an existing Phase 1 SA. SKEYID_a is used, in conjunction with the appropriate prf, to authenticate Phase 2 messages and SKEYID_e is used, in conjunction with the negotiated symmetric cipher, to encrypt Phase 2 messages. As mentioned in section 4.2 the message ID and cookies from the ISAKMP SA identifies the Phase 1 SA and transient Phase 2 state for a Quick Mode. The first payload, following the ISAKMP header, of a Quick Mode exchange MUST be a hash payload and following it MUST be an SA payload. Quick Mode is essentially SA negotiation and an exchange of nonces that provides replay protection. The nonces are used to generate fresh keying material and to prevent replay attacks from generating bogus security associations. If PFS is desired optional KE payloads 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. The security service for which the Quick Mode exchange is being performed may require identities to be supplied along with the SA and key(s). Those identities are implicitly assumed to be the IP address of the IKE peers, without any implied constraints on the protocol or port numbers allowed, unless additional ID payloads (called "client IDs") are passed. Client IDs come in pairs, an Initiator ID, IDi2, and a Responder ID, IDr2, to denote to the service where the information being secured will come from and to where it is going-- e.g. if IKE is negotiating SAs for IPSec on a security gateway the client IDs could specify that the SAs are for traffic from a Harkins Carrel [Page 24]
INTERNET DRAFT May 1999 particular IP address (IDi2) to a particular IP address (IDr2). The order is crucial and the first ID in any Quick Mode MUST be the IDi2 and the second MUST be IDr2. For parsing sanity's sake, IDr2 MUST immediately follow IDi2. In the case of a Quick Mode Initiator, these client IDs are be supplied by the service requesting SAs. In the case of a Quick Mode Responder, those IDs are extracted from the Quick Mode message and supplied to the service identified by the DOI value in the SA payload (also in the Quick Mode message). If the identities are not acceptable to the service (due to policy or other reasons), an Informational message containing a notify payload, with a type of INVALID-ID-INFORMATION (18), SHOULD be sent back to the Initiator. The Responder MUST NOT modify the client IDs in any way and they MUST be delivered back to the Initiator in exactly the order supplied, that is, IDi2 does not become IDr2 in the message the Responder sends back to the Initiator. Client IDs are used to constrain the use of security associations. For example, SAs negotiated under [Pip98] can be have varying granularities by specifying (or not) particular port and protocol combinations along with the ID type. In this fashion, a single pair of SAs can protect all traffic between two subnets, and a separate pair can protect only telnet traffic between two particular hosts. The DOI of the service being negotiated defines the exact format that client IDs may take. All offers made during a Quick Mode are logically related and MUST be consistant. For example, if a KE payload is send the attribute describing the Diffie-Hellman group (see section 5 and [Pip98]) MUST be included in every transform of every proposal of every SA being negotiated. Similarly, if client IDs are used they MUST apply to every SA negotiated. Quick Mode is defined as: Initiator Responder ----------- ----------- HDR*, HASH(1), SA, Ni [, KE ] [, IDi2, IDr2 ] --> <-- HDR*, HASH(2), SA, Nr [, KE ] [, IDi2, IDr2 ] HDR*, HASH(3) --> where: HASH(1) is the results of a prf over the message ID (M-ID) of the Harkins Carrel [Page 25]
INTERNET DRAFT May 1999 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 that the Initiator's nonce-- Ni, minus the payload header-- is added after M-ID and prior to the rest of the message. The addition of the nonce to HASH(2) is for a liveliness proof. HASH(3) is the results of a 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. This is for a liveliness proof. Graphically, the hashes 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 client 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. The commit bit in the ISAKMP header ([MSST98]) can be used to extend a Quick Mode by a single message from the Responder to the Initiator to delay use of the SAs created by the Quick Mode. This message will consist of an authenticated hash, using SKEYID_a as the key, of the message ID from the Quick Mode concatinated with a notify payload whose type is set to CONNECTED (16384). This final message is sent as part of the Quick Mode exchange and not as a seperate Informational exchange. Either side can set the commit during the exchange and the other party SHOULD reflect back, or acknowledgement, the commit bit in a subsequent message. Using the '#' symbol to denote the message with the commit bit, a Quick Mode exchange would become: Harkins Carrel [Page 26]
INTERNET DRAFT May 1999 Initiator Responder ----------- ----------- HDR*, HASH(1), SA, Ni [, KE ] [, IDi2, IDr2 ] --> <-- HDR*#, HASH(2), SA, Nr [, KE ] [, IDi2, IDr2 ] HDR*#, HASH(3) --> <-- HDR#*, HASH(4), notify where HASH(4) = prf(SKEYID_a, M-ID | notify). If PFS is not desired and KE payloads were not exchanged the keying material generated by IKE to accompany the SA is defined as: KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b ) If PFS is desired and KE payloads were exchanged the keying material generated by IKE to accompany the SA 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 (and accepted) transform payload. A single SA negotiation results in two security associations-- 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. Harkins Carrel [Page 27]
INTERNET DRAFT May 1999 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) MUST be irretrievably removed from the current state and SKEYID_e and SKEYID_a (derived from the Phase 1 negotiation) continue to protect and authenticate the Phase 1 SA and SKEYID_d continues to be used to derive keys for subsequent Quick Modes. 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 ] [, IDi2, IDr2 ] --> <-- HDR*, HASH(2), SA0, SA1, Nr, [, KE ] [, IDi2, IDr2 ] 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. 6.3 New Group Mode IKE uses 5 groups from [Orm96] to choose from when doing Diffie- Hellman exchanges. Sometimes those groups may not be desirable for one reason or another. In this case, New Group Mode can be used to establish a new shared group between cooperating peers. New Group mode uses an SA payload from [MSST98] to convey the attributes of the group being established. This payload contains a field for the Security Parameter Index (SPI) and a field for the SPI length. During a New Group mode exchange the SPI field MUST be empty and its length set to zero. New Group Mode MUST NOT be used prior to establishment of an IKE 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 Harkins Carrel [Page 28]
INTERNET DRAFT May 1999 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). IKE 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. 6.4 Notification Exchanges At various point during an IKE exchange peers may desire to convey some information to each other regarding errors or notifications of certain state transitions. To accomplish this IKE defines two Informational exchanges, an unreliable uni-directional message and an acknowledged, reliable bi-directional exchange. Informational exchanges described in this memo are secured by a previously established Phase 1 SA. Any Information message sent prior the the establishment of a Phase 1 SA MUST be sent unsecured to prevent a loss of cryptographic syncronization. Any action taken upon receipt of an unprotected Informational message should be taken with great care as they can easily be forged by any evesdropper. Therefore, IKE implementations are discouraged from sending unprotected Informational messages. Exceptions to this are for Informational messages which will not effect continuation of the exchange. For example, sending an INVALID-FLAGS message for improper use of the commit bit would not necessarily cause termination of an exchange in the way a NO-PROPOSAL-CHOSEN message would. Harkins Carrel [Page 29]
INTERNET DRAFT May 1999 Like a Quick Mode exchange, Informational messages are given a pseudo-random message ID to allow for multiplexing exchanges through a single Phase 1 SA. Likewise, they are secured by a Phase 1 SA: confidentiality is provided by SKEYID_e and message integrity is provided by a keyed hash using SKEYID_a. 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 (or the Phase 1 IV if no Phase 1 messages were encrypted) 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). Due to the freeform nature of ISAKMP message construction more than one single notify payload may be sent in a single Informational exchange. 6.4.1 Unacknowledged Informational An unacknowledged, FYI-style, Informational message is defined as: Initiator Responder ----------- ----------- HDR*, HASH, N/D --> where N/D is either an ISAKMP notify payhload or an ISAKMP delete payload, and HASH is the prf output, using SKEYID_a as the key and the message ID from the ISAKMP header concatenated with the entire Informational payload (the Notify or Delete payload and any additional chained payloads) as the data. In other words, the hash for the above exchange is: HASH = prf(SKEYID_a, M-ID | N/D) 6.4.2 Acknowledged Informational IKE exchanges are sent as ISAKMP messages whose delivery is unreliable. This fact has been taken into account in the design of Phase 1 and Phase 2 exchanges since retransmission timers are set to allow for packet loss. Due to the unreliable nature of the exchange described in 6.4.1 certain messages should not be sent that way. For instance, if a notification that an SA has been deleted is lost the sender may delete it but the intended recipient will have not way of knowing this fact. The first payload of the acknowledged Informational exchange MUST be a hash payload and the second payload MUST be the nonce of the Harkins Carrel [Page 30]
INTERNET DRAFT May 1999 sender. The Responder MUST NOT change the notification payloads which follow the Initiator's nonce. The acknowledged Informational exchange is defined as: Initiator Responder ----------- ----------- HDR*, HASH(1), Ni, N/D --> <-- HDR*, HASH(2), Nr, N/D where HASH(1) is prf output using SKEYID_a from the Phase 1 SA identified by the cookies in the ISAKMP header as the key, and the unique, pseudo-random message ID for this exchange concatenated with the remaining payloads (in this case, a delete or notify and a nonce payload, but more payloads could be chained to this message) as the data, and HASH(2) is the prf output using SKEYID_a, from the Phase 1 SA identified by the cookies in the ISKAMP header, as the key and the nonce payload sent by the Initiator concatenated with the pseudo- random message ID for this exchange and the remaining payloads as the message to hash. The hashes for the above exchange would be: HASH(1) = prf(SKEYID_a, M-ID | Ni | N/D) HASH(2) = prf(SKEYID_a, Ni | M-ID | Nr | N/D) This memo does not proscribe which messages should be sent with the Acknowledged or Unacknowledged Informational. Harkins Carrel [Page 31]
INTERNET DRAFT May 1999 7 Payload Explosion of Sample Exchange 7.1 Phase 1 Using Main Mode 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). Harkins Carrel [Page 32]
INTERNET DRAFT May 1999 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^ii from initiator g^ir from responder) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Ni (from initiator) or Nr (from responder) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. Harkins Carrel [Page 33]
INTERNET DRAFT May 1999 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 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 Harkins Carrel [Page 34]
INTERNET DRAFT May 1999 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. 8 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 without PFS 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 using the PFS option during a Quick Mode, specifying a Diffie-Hellman group and passing public values in KE payloads, IKE peers can establish PFS of keys. The identities would be protected by SKEYID_e from the Phase 1 SA and would therefore not be protected by PFS. If PFS of both keying material and identities is desired, an IKE peer MUST establish only one non-ISAKMP security association (e.g. IPsec Security Association) per Phase 1 SA. PFS for keys and identities is accomplished by deleting the Phase 1 SA (and optionally issuing a DELETE message) upon establishment of the single Phase 2 SA. In this way the Phase one negotiation is uniquely tied to a single Phase two Harkins Carrel [Page 35]
INTERNET DRAFT May 1999 negotiation, and 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 two) when used with a strong random number generator and an exponent no less than 160 bits is sufficient to use for 3DES. Groups three through five provide greater security. Group one is for historic purposes only and does not provide sufficient strength to the required cipher (although it is sufficient for use with DES, which is also for historic use only). 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. 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 Harkins Carrel [Page 36]
INTERNET DRAFT May 1999 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. The message ID used for all non-Phase 1 exchanges MUST be pseudo- randomly generated using a strong random number generator. Optimal Asymmetric Encryption Padding [BR94] MUST be used with PKCS#1 to avoid the adaptive chosen ciphertext attack against RSA that is described in [Ble98]. See [PKCS1]. The acknowledged Informational exchange is open to replay attacks. 9 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. 9.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. 9.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. 9.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. 9.4 Group Description and Group Type Values of the Group Description Class identify a group to use in a Harkins Carrel [Page 37]
INTERNET DRAFT May 1999 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 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. 9.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. 10 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 Ben Rogers and D. Hugh Redelmeier for helping close up various holes in the text which were open to interpretation. 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 two years, especially those of you who've implemented IKE. Thanks! 11 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. [Bra96] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [Bra97] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Harkins Carrel [Page 38]
INTERNET DRAFT May 1999 [Ble98] Bleichenbacher, D., "Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS#1", Advances in Cryptology Eurocrypt '98, Springer-Verlag, 1998. [BR94] Bellare, M., and Rogaway P., "Optimal Asymmetric Encryption." Advances in Cryptology Eurocrypt '94, Springer-Verlag, 1994. [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. [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] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2", September 1998. [Pip98] Piper, D., "The Internet IP Security Domain Of Interpretation for ISAKMP", RFC 2407, November 1998. Harkins Carrel [Page 39]
INTERNET DRAFT May 1999 [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 [Page 40]
INTERNET DRAFT May 1999 Appendix A 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 [MSST98] 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). 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 Block Size 17 B values 18-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 Harkins Carrel [Page 41]
INTERNET DRAFT May 1999 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. - Authentication Method pre-shared key 1 DSS signatures 2 RSA signatures 3 Encryption with RSA 4 Revised encryption with RSA 5 Encryption with El-Gamal 6 Revised encryption with El-Gamal 7 values 8-65000 are reserved to IANA. Values 65001-65535 are for private use among mutually consenting parties. - Group Description 768-bit MODP group (section 5.1) 1 1024-bit MODP group (section 5.2) 2 EC2N group on GP[2^155] (section 5.3) 3 EC2N group on GP[2^185] (section 5.4) 4 1536-bit MODP group (section 5.5) 5 values 6-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. Harkins Carrel [Page 42]
INTERNET DRAFT May 1999 - 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. - 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. - Block Size The number of bits per block of a cipher with a variable block length. Additional Exchanges Defined-- XCHG values Quick Mode 32 New Group Mode 33 Acknowledged Informational 34 Harkins Carrel [Page 43]
INTERNET DRAFT May 1999 Appendix B This appendix describes encryption details to be used ONLY when encrypting IKE messages. When a service (such as IPSec) utilizes IKE to generate keying material, all encryption algorithm specific details (such as key and IV generation, padding, etc...) MUST be defined by that service. IKE does not purport to produce keys that are suitable for every encryption algorithm. IKE 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^ir | CKY-I | CKY-R | 0) BLOCK9-16 = prf(SKEYID, BLOCK1-8 | g^ir | CKY-I | CKY-R | 0) BLOCK17-24 = prf(SKEYID, BLOCK9-16 | g^ir | 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 Phase 1 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 [Page 44]
INTERNET DRAFT May 1999 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. The input to a CBC mode operation must be equivalent to the block size of the underlying cipher. To satisfy this requirment, IKE messages are padded up to the nearest block size using bytes containing 0x00. The message length in the ISAKMP header MUST include the length of this pad. 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 in section 4.1 above. 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 in section 4.1 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 in section 4.1 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 in section 4.1 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 Harkins Carrel [Page 45]
INTERNET DRAFT May 1999 from the aforementioned pseudo-random function feedback method if necessary. The IV is the first eight (8) bytes of the IV material derived in section 4.1 above. The number of rounds MUST be 16 and the block size MUST be 64. 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 in section 4.1 above. Support for algorithms other than 3DES-CBC is purely optional. Some optional algorithms may be subject to intellectual property claims. Authors' Addresses Dan Harkins Network Alchemy 1615 Pacific ave Santa Cruz, California, 95060 United States of America Phone: +1 831 460 3800 EMail: dharkins@network-alchemy.com Dave Carrel Redback Networks San Francisco, CA 94131-2947 United States of America Phone: +1 415 337 8469 EMail: carrel@rback.net Authors' Note The authors encourage independent implementation, and interoperability testing, of this hybrid protocol. Harkins Carrel [Page 46]
