idnits 2.17.1 draft-ietf-ipsec-ike-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == Mismatching filename: the document gives the document name as 'draft-ieft-ipsec-ike-00', but the file name used is 'draft-ietf-ipsec-ike-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 46 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MSST98], [Kra96], [Orm98], [HC98]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 582 has weird spacing: '... The equati...' == Line 1802 has weird spacing: '... length attri...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 1999) is 9113 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'HC98' is mentioned on line 92, but not defined == Missing Reference: 'Kra96' is mentioned on line 97, but not defined == Missing Reference: 'Orm98' is mentioned on line 97, but not defined == Missing Reference: 'Pip97' is mentioned on line 285, but not defined == Missing Reference: 'KCB96' is mentioned on line 320, but not defined == Missing Reference: 'Tiger' is mentioned on line 340, but not defined == Missing Reference: 'P' is mentioned on line 1878, but not defined == Unused Reference: 'CAST' is defined on line 1711, but no explicit reference was found in the text == Unused Reference: 'BLOW' is defined on line 1714, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 1731, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 1739, but no explicit reference was found in the text == Unused Reference: 'IDEA' is defined on line 1743, but no explicit reference was found in the text == Unused Reference: 'KBC96' is defined on line 1747, but no explicit reference was found in the text == Unused Reference: 'RC5' is defined on line 1771, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 1774, but no explicit reference was found in the text == Unused Reference: 'Sch96' is defined on line 1778, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2144 (ref. 'CAST') -- Possible downref: Non-RFC (?) normative reference: ref. 'BLOW' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ble98' -- Possible downref: Non-RFC (?) normative reference: ref. 'BR94' -- Possible downref: Non-RFC (?) normative reference: ref. 'DES' -- Possible downref: Non-RFC (?) normative reference: ref. 'DH' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDEA' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'KBC96') -- Possible downref: Non-RFC (?) normative reference: ref. 'SKEME' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') ** Obsolete normative reference: RFC 2408 (ref. 'MSST98') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 (ref. 'Orm96') -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' ** Obsolete normative reference: RFC 2407 (ref. 'Pip98') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'RC5' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sch96' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' -- Possible downref: Non-RFC (?) normative reference: ref. 'TIGER' Summary: 13 errors (**), 0 flaws (~~), 23 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSEC Working Group Dan Harkins, Network Alchemy 2 INTERNET-DRAFT Dave Carrel, Redback Networks 3 draft-ieft-ipsec-ike-00.txt May 1999 5 The Internet Key Exchange (IKE) 6 8 Status of this Memo 10 This document is an Internet Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are 12 working documents of the Internet Engineering Task Force (IETF), its 13 areas, and working groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inapproporiate to use Internet Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 To learn the current status of any Internet Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Australia), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Table of Contents 35 1 Abstract.......................................................2 36 2 Terms and Definitions..........................................3 37 2.1 Requirements Terminology.....................................3 38 2.2 Perfect Forward Secrecy......................................3 39 2.3 Modes and Phases.............................................3 40 2.4 Security Association.........................................4 41 2.5 Authentication Options.......................................4 42 2.6 Notation.....................................................4 43 3 Introduction...................................................6 44 3.1 Mandatory Options............................................7 45 3.2 Attribute Negotiation........................................8 46 4 IKE Internal State.............................................9 47 4.1 Phase 1 state................................................9 48 4.2 Phase 2 state................................................10 49 5 Oakley Groups..................................................11 50 5.1 Group One....................................................11 51 5.2 Group Two....................................................12 52 5.3 Group Three..................................................12 53 5.4 Group Four...................................................12 54 5.5 Group Five...................................................13 55 6 IKE Phases.....................................................13 56 6.1 Phase 1......................................................14 57 6.1.1 Main Mode..................................................14 58 6.1.1.1 Authentication with Pre-shared keys......................15 59 6.1.1.2 Authentication with Digital Signatures...................15 60 6.1.1.3 Authentication with Public Key Encryption................16 61 6.1.1.4 Authentication with Revised Public Key Encryption........17 62 6.1.2 Aggressive Mode............................................19 63 6.1.2.1 Authentication with Pre-shared keys......................20 64 6.1.2.2 Authentication with Digital Signatures...................21 65 6.1.2.3 Authentication with Public Key Encryption................21 66 6.1.2.4 Authentication with Revised Public Key Encryption........22 67 6.2 Quick Mode...................................................23 68 6.3 New Group Mode...............................................27 69 6.4 Notification Exchanges.......................................28 70 6.4.1 Unacknowledged Informational...............................29 71 6.4.2 Acknowledged Informational.................................29 72 7 Payload Explosion of Sample Exchange...........................31 73 7.1 Phase 1 Using Main Mode......................................31 74 7.2 Phase 2 Using Quick Mode.....................................32 75 8 Security Considerations........................................34 76 9 IANA Considerations............................................36 77 10 Acknowledgements..............................................37 78 11 References....................................................37 79 Appendix A.......................................................40 80 Appendix B.......................................................43 81 Author's Address.................................................45 83 1. Abstract 85 This memo describes a key exchange and security negotiation protocol 86 which is intended to depricate [HC98]. As such it will not change the 87 "bits on the wire" for an implementation which is compiant with 88 [HC98] but will clarify contentious issues with [HC98] and attempt to 89 explain the protocol in a less haphazard manner. Due to advances in 90 computer processing some mandatory-to-implement attributes have 91 changed between this [HC98] and this document. In addition a new and 92 optional exchange is introduced. Like [HC98] this memo uses [MSST98] 93 for a framework and as a language to express exchanges which are 94 derived from [Kra96] and [Orm98]. 96 In places where the requirements between this document and [MSST98] 97 or [Kra96] or [Orm98] conflict, this document will be supreme. 99 This is a request/response type protocol in which roles of an 100 Initiator and Responder are played by the parties to the protocol. 101 The Initiator initiates the protocol to the Responder who responds 102 back. 104 2. Terms and Definitions 106 2.1 Requirements Terminology 108 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 109 "MAY" that appear in this document are to be interpreted as described 110 in [Bra97]. 112 2.2 Perfect Forward Secrecy 114 When used in the memo Perfect Forward Secrecy (PFS) refers to the 115 notion that compromise of a single key will permit access to only 116 data protected by a single key. For PFS to exist the key used to 117 protect transmission of data MUST NOT be used to derive any 118 additional keys, and if the key used to protect transmission of data 119 was derived from some other keying material, that material MUST NOT 120 be used to derive any more keys. 122 Perfect Forward Secrecy for both keys and identities is provided in 123 this protocol. 125 2.3 Modes and Phases 127 This protocol uses ISAKMP as a means of communication and all rules 128 regarding transport, construction, and retransmission of messages are 129 as specified in [MSST98]. All messages in IKE are constructed by 130 chaining ISAKMP payloads to an ISAKMP header. 132 This is a dual phase protocol where the parties to the protocol, also 133 called the peers, authenticate each other and establish a protected 134 communications channel in the first phase and then negotiate security 135 services in the second phase (using the protected communications 136 channel from the first for security). 138 There are different exchanges, also called "modes", which can be used 139 in the different phases. Phase 1 exchanges are Main Mode and 140 Aggressive Mode. The only phase 2 exchange is Quick Mode. In 141 addition, three additional modes are defined which are neither 142 strictly phase 1 nor phase 2. Section 6 discusses IKE phases in 143 detail. 145 Unless otherwise noted there are no ordering requirements on payloads 146 in various IKE messages. 148 2.4 Security Association 150 A security association (SA) is a set of policy and key(s) used to 151 protect information. The Phase 1 SA is the shared policy and key(s) 152 used by the negotiating peers in this protocol to protect their 153 communication. 155 The Phase 1 SA is bi-directional. That is, once established, the 156 peers may use it to securely initiate communication with each other 157 regardless of who initiated the Phase 1 exchange. The roles played by 158 the peers are strictly adhered to during Phase 1 (the Initiator 159 remains the Initiator and the Responder remains the Responder for the 160 entire mode) but once the Phase 1 SA is established the roles can 161 reverse for Phase 2. The peer who was the Responder during Phase 1 162 can become the Initiator of Phase 2. 164 Phase 1 SAs are identified by the cookies contained in the ISAKMP 165 header. There are two cookies in the ISAKMP header, one for the 166 Initiator and one for the Responder. The roles during Phase 1 dictate 167 who generates which cookie and once established the cookie order does 168 not swap even if the direction of the Phase 1 SA switches. That is, 169 if Alice initiates a Phase 1 exchange to Bob which results in a Phase 170 1 SA, the SA will be identified by an Initiator cookie generated by 171 Alice and a Responder cookie generated by Bob even if Bob susequently 172 assumes the role of Initiator during a Phase 2 exchange. 174 Security Associations are negotiated for other security services 175 during Phase 2. The nature of these SAs is dependant on the Domain of 176 Interpretation (DOI) in the SA payload. ([Pip98] defines the DOI for 177 IPSec). 179 2.5 Authentication Options 181 During Phase 1 the peers authenticate each other. There are four 182 distinct methods of authentication in IKE: authentication with pre- 183 shared keys, authentication with digital signatures, and two methods 184 of authentication using public key encryption. These options impact 185 the Phase 1 exchange in a different manner. In fact, the exchange can 186 morph depending on the method chosen. 188 2.6 Notation 190 The following notation is used throughout this memo. All "payloads" 191 are from [MSST98]. 193 HDR is an ISAKMP header. When written as HDR* it indicates message 194 encryption: all payloads following the header are encrypted with a 195 symmetric session key. 197 SA is an SA negotiation payload with one or more proposal payloads 198 enclosed, which themselves may contain one or more transform 199 payloads. 201 SAi_b is the entire body of the SA payload (minus the ISAKMP 202 generic header)-- i.e. the DOI, situation, and all proposals and 203 transforms enclosed-- proposed by the Initiator. 205 CKY-I and CKY-R are the Initiator's cookie and the Responder's 206 cookie, respectively, from the ISAKMP header. 208 g^i and g^r are the Diffie-Hellman ([DH]) public values of the 209 Initiator and the Responder respectively. The length of these 210 values MUST be the minimum number of octets required to hold a 211 bitstream whose length is equal to the size of the group-- the 212 size of the prime modulus for MODP groups, or the field size for 213 ECP and EC2N groups (see section 5). This requirement is ensured 214 by pre-pending the value with zero bits up to the next 8-bit 215 boundary if necessary. 217 g^ir is the Diffie-Hellman secret. When used in IKE as input to 218 functions the length of this value MUST be identical to that of 219 g^i and g^r. 221 KE is the key exchange payload which contains the public value 222 (g^i or g^r) exchanged in a Diffie-Hellman exchange. 224 Ni and Nr are the nonce payloads from the Initiator or the 225 Responder, respectively. Nonce lengths MUST be between 8 and 256 226 bytes inclusive. 228 ID_x is the identification payload for "x". x can be: "i1" or "r1" 229 for the phase one identities of the Initiator or the Responder, 230 respectively; or, "i2" or "r2" for the optional identities 231 exchanged in phase 2. 233

_b indicates the body of payload

-- the ISAKMP generic 234 payload is not included. For instance, Ni_b would signify the body 235 of the nonce payload-- everything except the generic header-- 236 supplied by the Initiator. 238 SIG is the signature payload. 240 CERT is the certificate payload. 242 CERT_REQ is the certificate request payload. 244 HASH (and any derivitive such as HASH(2) or HASH_I) is the hash 245 payload. 247 H(x) is the hash of "x" whose result is a digest. 249 prf(key, msg) is a keyed pseudo-random function-- often a keyed 250 hash function-- used to generate a deterministic output that 251 appears pseudo-random. 253 SKEYID is a string derived from secret material known only to the 254 active players in the exchange. 256 SKEYID_e is the keying material used by the parties of the 257 exchange to protect the confidentiality of messages. 259 SKEYID_a is the keying material used by the parties of the 260 exchange for message integrity. 262 SKEYID_d is the keying material used to derive keys for security 263 services during phase 2. 265 y indicates that "x" is encrypted with the key "y". 267 --> signifies a message from the Initiator to the Responder. 269 <-- signifies a message from the Responder to the Initiator. 271 | signifies concatenation of information. For example, X | Y is 272 the concatenation of X with Y. 274 [x] indicates that x is optional. 276 3. Introduction 278 A Domain Of Interpretation defines the attributes (and their 279 meanings) negotiated by IKE. It may overload payloads that are 280 defined in [MSST98]. This protocol does not define its own DOI per 281 se. It does not define DOI nor Situation values for the SA payload 282 during Phase 1 negotiation. 284 The Phase 1 SA MAY use the DOI and situation from a non-ISAKMP 285 service (such as [Pip97]). In this case an implementation MAY choose 286 to restrict use of the Phase 1 SA for establishment of SAs for 287 services of the same DOI. Alternatively, a Phase 1 SA MAY be 288 established with the value zero in both the DOI and Situation fields 289 and in this case implementations will be free to establish security 290 services for any defined DOI using this Phase 1 SA. If a DOI of zero 291 is used for establishment of a Phase 1 SA, the syntax of the identity 292 payloads used in the Phase 1 exchange MUST be as defined in [MSST98] 293 and not from any DOI. 295 3.1 Mandatory Options 297 Main Mode (section 6.1.1) MUST be implemented for Phase 1; Aggressive 298 Mode (section 6.1.2) SHOULD be implemented. Quick Mode (section 6.2) 299 MUST be implemented for Phase 2. Both acknowledged and unacknowledged 300 notification exchanges (section 6.4) MUST be implemented. New Group 301 mode (section 6.3) SHOULD be implemented. 303 [MSST98] defines the concept of a "protection suite". To IKE this is 304 the attributes negotiated in SA payloads during Phase 1 whose 305 agreement results in the Phase 1 SA. Attributes that MUST comprise a 306 "protection suite" are: 308 - encryption algorithm 310 - hash algorithm 312 - authentication method 314 - information about a group over which to do a Diffie-Hellman. 316 In addition, optional attributes may be negotiated. These include a 317 lifetime and a pseudo-random function ("prf"). (There are currently 318 no negotiable pseudo-random functions defined in this document but 319 the ability to negotiate them exists). In the absense of a negotiated 320 "prf" the HMAC version of the negotiated hash function (see [KCB96]) 321 is used as a pseudo-random function. 323 Negotiable Phase 1 attributes are described in Appendix A. 325 IKE implementations MUST support the following attribute values: 327 - Triple DES in CBC mode for encryption algorithm. 329 - MD5 [MD5] and SHA [SHA]) for hash function. 331 - Authentication via pre-shared keys. 333 - MODP over group number two (see section 5). 335 In addtion IKE implementations SHOULD support the following values: 337 - CAST in CBC mode and Blowfish in CBC mode for encryption 338 algorithm. 340 - Tiger ([Tiger]) for hash algorithm. 342 - Authentication using RSA and DSA signatures, and using RSA and 343 El-Gamal public key encryption. 345 - Groups 3 through 5 for Diffie-Hellman group. 347 In addition IKE implementations MAY support the following values: 349 - DES in CBC mode for encryption algorithm. 351 - Group 1 for Diffie-Hellman group. 353 3.2 Attribute Negotiation 355 During security association negotiation Initiators present offers, in 356 the form of protection suites, to Responders. Responders MUST NOT 357 modify any attributes of any offer (with the possible exception of 358 attribute encoding, see Appendix A). If the Initiator of an exchange 359 notices that attribute values have been changed or attributes have 360 been added or deleted from an offer made that response MUST be 361 rejected. 363 The SA payload from [MSST98] is used to negotiate security 364 associations in both Phase 1 and Phase 2 exchanges. This payload 365 contains a field for a Security Parameter Index (SPI) and a field for 366 the length of the SPI. During Phase 1 the SPI field MUST be empty and 367 the length of the SPI MUST be zero. During Phase 2 the SPI values and 368 their lengths depends on the particular DOI being negotiated. 370 Diffie-Hellman groups are specified either using a defined group 371 description (section 5) or by defining all attributes of a group 372 (Appendix A) in a protection suite. Group attributes, such as group 373 type or prime number MUST NOT be offered in conjunction with a 374 previously defined group, defined either in section 5 or via a 375 previous New Group Mode exchange (section 6.3). 377 Certain negotiable attributes have ranges or multiple acceptable 378 values. For instance, if the policy specification on a peer mandates 379 group 2 but is offered group 5, as part of an otherwise acceptable 380 protection suite, the peer SHOULD accept that value as it provides 381 more security than demanded. SA lifetimes pose similar issues. If a 382 peer has a local policy which requires SAs live for no more than 2 383 hours and is offered a protection suite which contains a lifetime 384 value of 1 hour, the peer SHOULD accept that value as it provides 385 less opportunity for key exposure. 387 The converse, though, does not hold. If a peer mandates group 5 (or a 388 lifetime of 1 hour) and is offered group 2 (or a lifetime of 1 hour) 389 that offer SHOULD be refused as it violates the local policy. 391 It is therefore possible to be in a situation where Alice can 392 successfully initiate an IKE exchange with Bob but not the other way 393 around. A simple way around this situation is to not enforce local 394 policy and accept any lifetime offered or any group offered. This 395 behavior is strongly discouraged; implementations SHOULD NOT ignore 396 local policy. If an implementation accepts a protection suite all 397 values of that protection suite MUST be honored-- in other words, 398 implementations MUST NOT ignore lifetime or Diffie-Hellman group 399 offers and just "do their own thing". 401 A DOI may dictate other actions to take in these circumstances when 402 negotiating its service. 404 4. IKE Internal State 406 During an IKE exchange the peers generate state associated with the 407 exchange. This state is generated as soon as all components are 408 available. 410 4.1 Phase 1 state 412 Information exchanged during Phase 1 allows for the construction of a 413 Phase 1 SA. This information is protection suite offer(s), cookies 414 (CKY-I and CKY-R), nonces (Ni and Nr), and Diffie-Hellman values (g^i 415 and g^r). In addition to (and out of) this information transmitted in 416 messages some Phase 1 state is generated by each peer. These are the 417 keys the peers use to protect their communications (SKEYID and its 418 derivitives) and the digests they use to authenticate each other. 420 When the Diffie-Hellman shared secret is used in Phase 1 state 421 generation its length MUST be the minimum number of octets required 422 to hold a bitstream whose length is equal to the size of the group-- 423 the size of the prime modulus for MODP groups, or the field element 424 size for ECP and EC2N groups (section 5). This can be ensured by pre- 425 pending the value with zero bits up to the next 8-bit boundary if 426 necessary. 428 SKEYID takes different values depending on the authentication method 429 negotiated. The methods of generation are: 431 digital signatures: SKEYID = prf(Ni_b | Nr_b, g^ir) 433 public key encryption: SKEYID = prf(H(Ni_b | Nr_b), CKY-I | CKY-R) 434 pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b) 436 Upon generation of SKEYID, the remaining internal state can be 437 derived. SKEYID_d is used to derive additional keys for security 438 services other than IKE during a Phase 2 exchange; SKEYID_a is used 439 to provide authentication and data integrity to IKE messages; and, 440 SKEYID_e is used to provide confidentiality to IKE messages. 442 SKEYID_d = prf(SKEYID, g^ir | CKY-I | CKY-R | 0) 444 SKEYID_a = prf(SKEYID, SKEYID_d | g^ir | CKY-I | CKY-R | 1) 446 SKEYID_e = prf(SKEYID, SKEYID_a | g^ir | CKY-I | CKY-R | 2) 448 where 0, 1, and 2 are represented by a single octet. 450 As part of the authentication step each side generates two digests, 451 one for the Initiator, I, and one for the Responder, R. These digests 452 either presented as is or digitally signed depending on the 453 authentication method negotiated. These digests are: 455 I-digest = prf(SKEYID, g^i | g^r | CKY-I | CKY-R | SAi_b | ID_i1) 457 R-digest = prf(SKEYID, g^r | g^i | CKY-R | CKY-I | SAi_b | ID_r1) 459 For authentication with digital signatures, I and R are digitally 460 signed and the resulting signature is passed as a SIG payload during 461 the exchange. For authentication with pre-shared keys and both types 462 of public key encryption I and R are passed as a HASH payload during 463 the exchange. 465 Symmetric encryption algorithms used by IKE to protect its messages 466 MUST be in CBC mode. This mode requires an Initialization Vector (IV) 467 for each encrytion operation. The initial IV is derived from a hash 468 of the concatenation of the Initiator's Diffie-Hellman public value 469 and the Responder's Diffie-Hellman public value using the negotiated 470 hash algorithm. The public values are those taken directly out of the 471 KE payload including any pre-pended zero bits. This is used for the 472 first message only. Subsequent messages MUST use the last CBC 473 encryption block from the previous message as their initialization 474 vector. 476 4.2 Phase 2 state 478 During a Quick Mode exchange new SAs for a security service other 479 than ISAKMP are generated (e.g. IPSec). The exact nature of those SAs 480 is defined in the approprate DOI document, but as part of the key 481 generation aspect of Quick Mode negotiation IKE does require some new 482 state be maintained. 484 Quick Mode exchanges are done under the protection of an existing 485 Phase 1 exchange and the message ID from the ISAKMP header is used to 486 multiplex multiple exchanges through the single SA. While the Phase 487 1 SA is identified by the cookies during a Phase 1 exchange, it is 488 the message ID and the cookies that identifies a state specific to a 489 Phase 2 exchange. 491 Unlike a Phase 1 exchange there are no variables that need to be 492 calculated and retained after the exchange has finished. Only 493 information exchanged during a Quick Mode-- protection suite offers, 494 nonces and, if PFS is desired, additional Diffie-Hellman public 495 values-- need be maintained and once the exchange has terminated it 496 can be thrown away (after, of course, the key(s) for the SA(s) have 497 been supplied to the appropriate service). The actual method for 498 generating keying material is discussed in section 6.2. 500 All Quick Mode messages are encrypted using the negotiated symmetric 501 cipher with SKEYID_e as the key. Therefore a seperate IV is needed to 502 "jump start" the encryption. This IV is derived from a hash of the 503 concatenation of the last Phase 1 CBC output block (or the Phase 1 IV 504 derived in section 4.1 if no Phase 1 messages were encrypted), and 505 the Phase 2 message ID using the negotiated hash algorithm. 507 5 Oakley Groups 509 There are 5 groups different Diffie-Hellman groups defined for use in 510 IKE. These groups were generated by Richard Schroeppel at the 511 University of Arizona. Properties of these primes are described in 512 [Orm96]. 514 The strength supplied by group one may not be sufficient for the 515 mandatory-to-implement encryption algorithm and is here for historic 516 reasons. 518 5.1 First Oakley Group 520 IKE implementations MAY support a MODP group with the following prime 521 and generator. This group is assigned id 1 (one). 523 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 524 Its hexadecimal value is 526 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 8A67CC74 527 020BBEA6 3B139B22 514A0879 8E3404DD CD3A431B 302B0A6D F25F1437 528 4FE1356D 6D51C245 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 529 The generator is: 2. 531 5.2 Second Oakley Group 533 IKE implementations MUST support a MODP group with the following 534 prime and generator. This group is assigned id 2 (two). 536 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 537 Its hexadecimal value is 539 FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 8A67CC74 020BBEA6 540 3B139B22 514A0879 8E3404DD CD3A431B 302B0A6D F25F1437 4FE1356D 541 6D51C245 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 5A899FA5 542 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF 544 The generator is 2 (decimal) 546 5.3 Third Oakley Group 548 IKE implementations SHOULD support a EC2N group with the following 549 characteristics. This group is assigned id 3 (three). The curve is 550 based on the Galois Field GF[2^155]. The field size is 155. The 551 irreducible polynomial for the field is: 552 u^155 + u^62 + 1. 553 The equation for the elliptic curve is: 554 y^2 + xy = x^3 + ax^2 + b. 556 Field Size: 155 557 Group Prime/Irreducible Polynomial: 558 0x0800000000000000000000004000000000000001 559 Group Generator One: 0x7b 560 Group Curve A: 0x0 561 Group Curve B: 0x07338f 562 Group Order: 0x0800000000000000000057db5698537193aef944 564 The data in the KE payload when using this group is the value x from 565 the solution (x,y), the point on the curve chosen by taking the 566 randomly chosen secret Ka and computing Ka*P, where * is the 567 repetition of the group addition and double operations, P is the 568 curve point with x coordinate equal to generator 1 and the y 569 coordinate determined from the defining equation. The equation of 570 curve is implicitly known by the Group Type and the A and B 571 coefficients. There are two possible values for the y coordinate; 572 either one can be used successfully (the two parties need not agree 573 on the selection). 575 5.4 Fourth Oakley Group 577 IKE implementations SHOULD support a EC2N group with the following 578 characteristics. This group is assigned id 4 (four). The curve is 579 based on the Galois Field GF[2^185]. The field size is 185. The 580 irreducible polynomial for the field is: 581 u^185 + u^69 + 1. 582 The equation for the elliptic curve is: 583 y^2 + xy = x^3 + ax^2 + b. 585 Field Size: 185 586 Group Prime/Irreducible Polynomial: 587 0x020000000000000000000000000000200000000000000001 588 Group Generator One: 0x18 589 Group Curve A: 0x0 590 Group Curve B: 0x1ee9 591 Group Order: 0x01ffffffffffffffffffffffdbf2f889b73e484175f94ebc 593 The data in the KE payload when using this group will be identical to 594 that as when using Oakley Group 3 (three). 596 5.5 Fifth Oakley Group 598 IKE implementations SHOULD support a MODP group with the following 599 prime and generator. This group is assigned id 5 (five). 601 The prime is 2^1536 - 2^1472 - 1 + 2^64 * {[2^1406 pi] + 741804}. 602 Its hexadecimal value is 603 FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 8A67CC74 020BBEA6 604 3B139B22 514A0879 8E3404DD CD3A431B 302B0A6D F25F1437 4FE1356D 605 6D51C245 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 5A899FA5 606 AE9F2411 7C4B1FE6 49286651 ECE45B3D A163BF05 98DA4836 1C55D39A 607 69163FA8 FD24CF5F DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 608 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF 610 The generator is 2. 612 Other groups can be defined using New Group Mode. 614 6. Modes for IKE Phases 616 IKE exchanges are called modes and these modes accomplish the phased 617 negotiation for IKE. There are two phases. Phase 1 exchanges are 618 intended to establish shared policy and keys in the form of a Phase 1 619 Security Association (SA). Phase 2 exchanges are intented to 620 establish Security Associations for security services other than IKE. 621 A DOI defines the nature of those services. [Pip98] is the DOI for 622 IPSec. 624 Exchanges in IKE are not open-ended and a certificate request payload 625 MUST NOT extend the number of messages in a given exchange. 627 6.1 Phase 1 629 There are three steps to Phase 1: negotiation of protection suites, a 630 Diffie-Hellman exchange, authentication. There are two modes to 631 accomplish Phase 1: Main Mode, and Aggressive Mode. Their most 632 obvious difference is in the number of message necessary to 633 accomplish the work. Main Mode requires 6 messages while Aggressive 634 Mode requires 3. 636 There are other subtle differences. For instance, the parameters to 637 negotiate in an Aggressive Mode exchange are constrained compared to 638 a Main Mode exchange. Because the Diffie-Hellman exchange begins with 639 the first message (which also contains the protection suite offers) 640 it is not possible to negotiate offers with differing Diffie-Hellman 641 group attributes. Other parameters are constrained depending on the 642 authentication method chosen. 644 All initial Phase 1 messages from the Initiator to the Responder MUST 645 have an SA payload as the first payload following the ISAKMP header. 646 The SA payload MUST contain only one proposal payload. Multiple 647 protection suites are offered by offering multiple transform payloads 648 and encapsulating them in the single SA payload. There is no limit on 649 the number of offers an Initiator can make but compliant 650 implementations MAY, for performance reasons, 651 choose to limit the number of offers it will inspect. 653 Phase 1 authentication using Public Key Encryption requires the 654 Initiator to possess the Responder's public key prior to initiation 655 of the exchange. The method of acquisition of the Responder's public 656 key is outside the scope of this memo. It can be any out-of-band 657 mechanism or it can be from a previous IKE exchange in which 658 certificates were requested, exchanged, and retained. If a previous 659 exchange requests a peer's certificate for subsequent use during an 660 exchange using public key encryption as the authentication method the 661 certificate encoding requested MUST be for key exchange (5). 663 Use of the commit bit from [MSST98] during Phase 1 is forbidden. 664 Implementations SHOULD respond with an notify message whose type is 665 set to INVALID-FLAGS (8). 667 6.1.1 Main Mode 669 A goal of Main Mode is identity protection. The ID payloads are never 670 passed on the wire in the clear, thereby masking the true identity of 671 the parties performing the IKE exchange. Main Mode is an 672 instantiation of the ISAKMP Identity Protect exchange from [MSST98]. 674 6.1.1.1 Main Mode Authentication With Pre-Shared Keys 676 A key derived from some out-of-band mechanism (which is beyond the 677 scope of this memo) can be used to authenticate an IKE exchange. When 678 using pre-shared key authentication, Main Mode is defined as: 680 Initiator Responder 681 ----------- ----------- 682 HDR, SA --> 683 <-- HDR, SA 684 HDR, KE, Ni --> 685 <-- HDR, KE, Nr 686 HDR*, IDi1, HASH_I --> 687 <-- HDR*, IDr1, HASH_R 689 Where HASH_I and HASH_R are the I-digest and R-digest (section 4.1), 690 respectively, presented in a hash payload. 692 When using pre-shared key authentication with Main Mode the key can 693 only be identified by the IP address of the peers since computation 694 of the I-digest is dependant on the pre-shared key and I-digest must 695 be computed prior to the Responder receiving IDi1. 697 6.1.1.2 Main Mode Authentication with Digital Signatures 699 Digital signatures may be used to authenticate a Main Mode exchange. 700 Signature checking requires trusting a public key and, in lieu of a 701 Public Key Infrastructure, certificates can be passed in-line to 702 faccilitate this. Main Mode authenticated with digital signatures is 703 defined as: 705 Initiator Responder 706 ----------- ----------- 707 HDR, SA --> 708 <-- HDR, SA 709 HDR, KE, Ni --> 710 <-- HDR, KE, Nr 711 HDR*, IDi1, [ CERT, ] SIG_I --> 712 <-- HDR*, IDr1, [ CERT, ] SIG_R 714 Where SIG_I and SIG_R are digital signatures of I-digest and R-digest 715 (section 4.1), respectively, and presented in a signature payload. 717 Since the algorithm used in generation of I-digest and R-digest is 718 known (it is the prf which is, most likely, the HMAC version of the 719 negotiated hash algorithm) there is no need to encode its OID into 720 the signature. In addition, there is no binding between the OIDs used 721 for RSA signatures in [PKCS1] and those used in this document. 723 Therefore, RSA signatures MUST be encoded as a private key encryption 724 in [PKCS1] format (without the hash OID) and not as a PKCS #1 725 signature (which encodes the digest with an OID). DSA signatures MUST 726 be encoded as the value "r" followed by "s". 728 In general the signature will be directly over I-digest and R-digest 729 which are generated by the pseudo-random function. However, this can 730 be overridden for construction of a signature if the signature 731 algorithm is tied to a particular hash algorithm by changing the 732 digest construction from: 734 digest = prf(key, msg) 736 to 738 digest = hash(key | msg) 740 For example, DSS is only defined with SHA's 160 bit output and in 741 this case the digests would be: 743 I-digest = SHA(SKEYID | g^i | g^r | CKY-I | CKY-R | SAi_b | ID_i1) 745 R-digest = SHA(SKEYID | g^r | g^i | CKY-R | CKY-I | SAi_b | ID_r1) 747 The contents of the signature payload would then be the resulting 748 320-bit DSA signature of the digest ("r" followed by "s"). 750 6.1.1.3 Main Mode Authentication with Public Key Encryption 752 Main Mode can be authenticated by using public key encryption by 753 encrypting each nonce in the peer's public key. The ability of the 754 peer to decrypt the nonce and properly construct the authenticating 755 digest from section 4.1 is authenticated proof of identity. This 756 authentication method is attractive in that it is a deniable 757 exchange. The peers authenticate each other but they lack the kind of 758 non-repudiable proof of conversation that one gets with a digital 759 signature. In addition, security is added to secret generation since 760 an attack would have to successfully break not only the Diffie- 761 Hellman exchange but also both public key encryptions. This exchange 762 was adapted from [SKEME]. 764 In order to perform public key encryption authentication the 765 Initiator must already have the Responder's public key. In the case 766 where the Responder has multiple public keys, a hash of the 767 certificate which contains the pubic key the Initiator is using to 768 encrypt the nonce is passed as part of the third message. When 769 passed, the hash payload MUST precede any payloads encrypted with the 770 Responder's public key. The Responder identifies the Initiator's 771 public key using the Inititator's identity passed as IDi1. 773 The Nonce and ID payloads MUST be encrypted in the public key of the 774 peer. 776 Main Mode authenticated with public key encryption is defined as: 778 Initiator Responder 779 ----------- ----------- 780 HDR, SA --> 781 <-- HDR, SA 782 HDR, KE, [ HASH(1), ] 783 PubKey_r, 784 PubKey_r --> 785 HDR, KE, PubKey_i, 786 <-- PubKey_i 787 HDR*, HASH_I --> 788 <-- HDR*, HASH_R 790 Where HASH(1) is the optional hash of the certificate which contained 791 Pubkey_r. Where HASH_I and HASH_R are the I-digest and R-digest, 792 respectively, from section 4.1 presented in a hash payload. 794 The format of the encrypted data depends on the algorithm being used. 795 For RSA encryption the format is specified in [PKCS1]. For El-Gamal 796 encryption the [PKCS1] convention for encryption block encoding is 797 used for each component of the ciphertext, and the ciphertext of 798 message M consists of the value A followed by the value B: 800 A = g^k mod p 801 B = y^k * M mod p 803 where the peer's public key is y, g, p and k is a random value per 804 the El-Gamal cryptosystem. 806 6.1.1.4 Main Mode Authentication with Revised Public Key Encryption 808 Authentication with public key encryption has significant advantages 809 over authentication with digital signatures (see 6.1.1.3 above). 810 Unfortunatly, this is at the cost of 4 public key operations-- two 811 public key encryptions and two private key decryptions. The revised 812 mode of public key authentication retains the advantages to public 813 key encryption but does so with half the public key operations. 815 In this mode the nonce is still encrypted using the public key of the 816 peer, however all subsequent payloads are encrypted using the 817 negotiated symmetric encryption algorithm (from the SA payload) with 818 a key derived from the nonce. This solution adds minimal complexity 819 and state yet saves two costly public key operations on each side. 820 In addition the KE payload is also encrypted using this same derived 821 key to provide additional protection against cryptanalysis of the 822 Diffie-Hellman exchange. 824 As with the authentication method from 6.1.1.3 a hash payload may be 825 sent to identify a certificate if the Responder has multiple 826 certificates which contain useable public keys. If the hash payload 827 is sent is MUST be the first payload of the third message and MUST be 828 followed by the encrypted nonce. If the hash payload is not sent the 829 first payload MUST be the encrypted nonce. All payloads, including 830 any optional payloads, following the nonce MUST be encrypted in the 831 appropriate symmetric key derived from the encrypted nonce. 833 Main Mode authenticated with the revised method of public key 834 encryption is defined as: 836 Initiator Responder 837 ----------- ----------- 838 HDR, SA --> 839 <-- HDR, SA 840 HDR, [ HASH(1), ] 841 Pubkey_r, 842 Ke_i, 843 Ke_i, 844 [<Ke_i] --> 845 HDR, PubKey_i, 846 Ke_r, 847 <-- Ke_r, 848 HDR*, HASH_I --> 849 <-- HDR*, HASH_R 851 Where HASH(1) is the optional hash of the certificate which contained 852 Pubkey_r, HASH_I and HASH_R are the I-digest and R-digest, 853 respectively, from section 4.1 presented in a hash payload, and Ke_i 854 and Ke_r are the keys to the symmetric encryption algorithm 855 negotiated in the SA payload. Note that only the bodies of the 856 payloads are encrypted (in both asymmetric and symmetric operations), 857 the generic headers are left in the clear to enable proper payload 858 parsing. The payload length includes that added to perform 859 encryption. 861 The format of the ciphertext depends on the algorithm used and is 862 identical to that of section 6.1.1.3. 864 The symmetric cipher keys are derived from the decrypted nonces as 865 follows. First the values Ne_i and Ne_r are computed: 867 Ne_i = prf(Ni_b, CKY-I) 868 Ne_r = prf(Nr_b, CKY-R) 870 The keys Ke_i and Ke_r are then taken from Ne_i and Ne_r respectively 871 in the manner described in Appendix B used to derive symmetric keys 872 for use with the negotiated encryption algorithm. If the length of 873 the output of the negotiated prf is greater than or equal to the key 874 length requirements of the cipher, Ke_i and Ke_r are derived from the 875 most significant bits of Ne_i and Ne_r respectively. If the desired 876 length of Ke_i and Ke_r exceed the length of the output of the prf 877 the necessary number of bits is obtained by repeatedly feeding the 878 results of the prf back into itself and concatenating the result the 879 necessary number has been achieved. For example, if the negotiated 880 encryption algorithm requires 320 bits of key and the output of the 881 prf is only 128 bits, Ke_i is the most significant 320 bits of K, 882 where 884 K = K1 | K2 | K3 and 885 K1 = prf(Ne_i, 0) 886 K2 = prf(Ne_i, K1) 887 K3 = prf(Ne_i, K2) 889 For brevity, only derivation of Ke_i is shown; Ke_r is identical. The 890 length of the value 0 in the computation of K1 is a single octet. 891 Note that Ne_i, Ne_r, Ke_i, and Ke_r are all ephemeral and MUST be 892 discarded after use. 894 Save the requirements on the location of the optional HASH payload 895 and the mandatory nonce payload there are no further payload 896 requirements. All payloads-- in whatever order-- following the 897 encrypted nonce MUST be encrypted with Ke_i or Ke_r depending on the 898 direction. 900 CBC mode is used with symmetric encryption in IKE and this requires 901 an IV. The IV for encrypting the first payload following the nonce is 902 set to 0 (zero). The IV for subsequent payloads encrypted with the 903 ephemeral symmetric cipher key, Ke_i, is the last ciphertext block of 904 the previous payload. Encrypted payloads are padded up to the nearest 905 block size. All padding bytes, except for the last one, contain 0x00. 906 The last byte of the padding contains the number of the padding bytes 907 used, excluding the last one. Note that this means there will always 908 be padding. 910 6.1.2 Aggressive Mode 912 An Aggressive Mode exchange completes Phase 1 with half the messages 913 as Main Mode. It does this at some expense of negotiation. Because 914 more payloads are sent with the first two messages more committment 915 to the nature of the exchange must be made. For instance, the KE 916 payload, which contains the Diffie-Hellman public value, is sent in 917 the same message as the SA payload which contains attributes for 918 negotiation of the Diffie-Hellman group. Obviously, it is not 919 possible to negotiate this attribute. Different authentication 920 methods can further constrain the negotiable options of Aggressive 921 Mode. 923 Unlike Main Mode, Aggressive Mode was not designed for Identity 924 Protection. The ID payloads are passed in the clear allowing a 925 potential adversary to observe the identities of the parties to the 926 IKE exchange. 928 An advantage of Aggressive Mode over Main Mode (aside from the fewer 929 rounds) is that computation of SKEYID state can be delayed until 930 transmission (and receipt) of the final authenticating message from 931 the Initiator to the Responder. All diagrams show this final 932 Aggressive Mode message as unencrypted (it lacks the asterisk with 933 the HDR). Implementations MAY choose to send this message encrypted 934 though. 936 6.1.2.1 Aggressive Mode Authentication with Pre-Shared Keys 938 Because the ID payload is passed in Aggressive Mode prior to 939 computation of SKEYID state it is possible to use pre-shared keys 940 which are bound to identities other than the peer's IP address. For 941 situations where the Initiator is using a dynamically assigned IP 942 address this is especially important. In spite of the fact that the 943 ID payload is passed in the clear an identity can be "hidden" by 944 using the KEY_ID identity type from [MSST98]. This enables a pre- 945 shared key to be associated with an opaque sequence of characters 946 which conveys no meaning to anyone except the two parties to the 947 exchange. 949 Aggressive Mode authenticated with pre-shared keys is defined as: 951 Initiator Responder 952 ----------- ----------- 953 HDR, SA, KE, Ni, IDi1 --> 954 <-- HDR, SA, KE, Nr, IDr1, HASH_R 955 HDR, HASH_I --> 957 Where the payload contents are identical to Main Mode. 959 6.1.2.2 Aggressive Mode Authenticated with Digital Signatures 961 Digital signatures can authenticate Aggressive Mode in the same 962 manner in which they authenticate Main Mode. 964 Initiator Responder 965 ----------- ----------- 966 HDR, SA, KE, Ni, IDi1 --> 967 <-- HDR, SA, KE, Nr, IDr1, 968 [ CERT, ] SIG_R 969 HDR, [ CERT, ] SIG_I --> 971 The optional CERT payload sent by the Initiator is shown as part of 972 the last Aggressive Mode message but since [MSST98] allows for a 973 freeform construction of messages this payload MAY be sent as part of 974 the first message. 976 6.1.2.3 Aggressive Mode Authenticate with Public Key Encryption 978 This authentication method further constrains Aggressive Mode 979 authentication in that if this method is desired than all protection 980 suites offered in the SA payload must offer it. Note that Aggressive 981 Mode authenticated with both pre-shared keys and digital signatures 982 may offer multiple protection suites, some with pre-shared key 983 offers, some with digital signature offers because the Initiator has 984 not yet committed himself to an authentication method. This is not 985 the case with authentiction using public key encryption. The nonce 986 payload, which is part of the first message, must be encrypted in the 987 Responder's public key so the Initiator is bound to this method if it 988 is desired. 990 Like Main Mode authentication with public key encryption, a hash 991 payload may be sent by the Initiator prior to the use of the 992 Responder's public key to identify which public key is being used in 993 the event the Responder has multiple certificates. The Nonce payloads 994 and ID payloads MUST be encrypted in the peer's public key. Also, 995 like Main Mode this is a completely deniable exchange. 997 An advantage of using this method of authentication in Aggressive 998 Mode is that identity protection can be realized because the ID 999 payloads are similarly encrypted in the peer's public key along with 1000 the nonce payload. 1002 Aggressive Mode authenticated with public key encryption is defined 1003 as: 1005 Initiator Responder 1006 ----------- ----------- 1007 HDR, SA, [ HASH(1),] KE, 1008 Pubkey_r, 1009 Pubkey_r --> 1010 HDR, SA, KE, PubKey_i, 1011 <-- PubKey_i, HASH_R 1012 HDR, HASH_I --> 1014 Where the notation, formatting, and payload contents are identitical 1015 to section 6.1.1.3. 1017 6.1.2.4 Aggressive Mode Authentication with Revised Public Key 1018 Encryption 1020 The revised method of public key encryption affords the same benefits 1021 to Aggressive Mode as it did to Main Mode: the exchange is still 1022 completely deniable, an adversary must attack not only the Diffie- 1023 Hellman exchange but both public key encryptions, and it requires 1024 only two public key operations, a public key encryption and a private 1025 key decryption. 1027 As with the Revised Public Key Encryption method in Main Mode, a hash 1028 of the Responder's public key may be sent prior to the use of the key 1029 in the event that the Responder has multiple public keys. Also, all 1030 payloads following the encrypted nonce, including any optional 1031 payloads, MUST be encrypted with the negotiated symmetric cipher 1032 (from the SA payload) using a key derived from the nonce. 1034 The revised method of public key encryption further constrains the 1035 negotiable options that the Initiator can offer to the Responder. 1036 This is due to the fact that a hash algorithm and a symmetric 1037 encryption algorithm must be used to construct the first message. In 1038 fact, all mandatory attributes that must accompany all protection 1039 suite offers must be identical. The only way to construct multiple 1040 protection suite offers using Aggressive Mode with the revised method 1041 of public key encryption is to vary the lifetime. 1043 Initiator Responder 1044 ----------- ----------- 1045 HDR, SA, [ HASH(1),] 1046 Pubkey_r, 1047 Ke_i, Ke_i 1048 [, Ke_i ] --> 1049 HDR, SA, PubKey_i, 1050 Ke_r, Ke_r, 1051 <-- HASH_R 1052 HDR, HASH_I --> 1054 Where notation, formatting, payload contents and all state generation 1055 is identical to section 6.1.1.4. 1057 6.2 Quick Mode 1059 A Quick Mode exchange is strictly a Phase 2 exchange and MUST be done 1060 under the protection of an existing Phase 1 SA. SKEYID_a is used, in 1061 conjunction with the appropriate prf, to authenticate Phase 2 1062 messages and SKEYID_e is used, in conjunction with the negotiated 1063 symmetric cipher, to encrypt Phase 2 messages. 1065 As mentioned in section 4.2 the message ID and cookies from the 1066 ISAKMP SA identifies the Phase 1 SA and transient Phase 2 state for a 1067 Quick Mode. 1069 The first payload, following the ISAKMP header, of a Quick Mode 1070 exchange MUST be a hash payload and following it MUST be an SA 1071 payload. 1073 Quick Mode is essentially SA negotiation and an exchange of nonces 1074 that provides replay protection. The nonces are used to generate 1075 fresh keying material and to prevent replay attacks from generating 1076 bogus security associations. If PFS is desired optional KE payloads 1077 can be exchanged to allow for an additional Diffie-Hellman exchange 1078 and exponentiation per Quick Mode. While use of the key exchange 1079 payload with Quick Mode is optional it MUST be supported. 1081 The security service for which the Quick Mode exchange is being 1082 performed may require identities to be supplied along with the SA and 1083 key(s). Those identities are implicitly assumed to be the IP address 1084 of the IKE peers, without any implied constraints on the protocol or 1085 port numbers allowed, unless additional ID payloads (called "client 1086 IDs") are passed. Client IDs come in pairs, an Initiator ID, IDi2, 1087 and a Responder ID, IDr2, to denote to the service where the 1088 information being secured will come from and to where it is going-- 1089 e.g. if IKE is negotiating SAs for IPSec on a security gateway the 1090 client IDs could specify that the SAs are for traffic from a 1091 particular IP address (IDi2) to a particular IP address (IDr2). The 1092 order is crucial and the first ID in any Quick Mode MUST be the IDi2 1093 and the second MUST be IDr2. For parsing sanity's sake, IDr2 MUST 1094 immediately follow IDi2. 1096 In the case of a Quick Mode Initiator, these client IDs are be 1097 supplied by the service requesting SAs. In the case of a Quick Mode 1098 Responder, those IDs are extracted from the Quick Mode message and 1099 supplied to the service identified by the DOI value in the SA payload 1100 (also in the Quick Mode message). If the identities are not 1101 acceptable to the service (due to policy or other reasons), an 1102 Informational message containing a notify payload, with a type of 1103 INVALID-ID-INFORMATION (18), SHOULD be sent back to the Initiator. 1104 The Responder MUST NOT modify the client IDs in any way and they MUST 1105 be delivered back to the Initiator in exactly the order supplied, 1106 that is, IDi2 does not become IDr2 in the message the Responder sends 1107 back to the Initiator. 1109 Client IDs are used to constrain the use of security associations. 1110 For example, SAs negotiated under [Pip98] can be have varying 1111 granularities by specifying (or not) particular port and protocol 1112 combinations along with the ID type. In this fashion, a single pair 1113 of SAs can protect all traffic between two subnets, and a separate 1114 pair can protect only telnet traffic between two particular hosts. 1116 The DOI of the service being negotiated defines the exact format that 1117 client IDs may take. 1119 All offers made during a Quick Mode are logically related and MUST be 1120 consistant. For example, if a KE payload is send the attribute 1121 describing the Diffie-Hellman group (see section 5 and [Pip98]) MUST 1122 be included in every transform of every proposal of every SA being 1123 negotiated. Similarly, if client IDs are used they MUST apply to 1124 every SA negotiated. 1126 Quick Mode is defined as: 1128 Initiator Responder 1129 ----------- ----------- 1130 HDR*, HASH(1), SA, Ni 1131 [, KE ] [, IDi2, IDr2 ] --> 1132 <-- HDR*, HASH(2), SA, Nr 1133 [, KE ] [, IDi2, IDr2 ] 1134 HDR*, HASH(3) --> 1136 where: 1138 HASH(1) is the results of a prf over the message ID (M-ID) of the 1139 ISAKMP header concatenated with the entire message that follows 1140 the hash including all payload headers, but excluding any padding 1141 added for encryption. 1143 HASH(2) is identical to HASH(1) except that the Initiator's 1144 nonce-- Ni, minus the payload header-- is added after M-ID and 1145 prior to the rest of the message. The addition of the nonce to 1146 HASH(2) is for a liveliness proof. 1148 HASH(3) is the results of a prf over the value zero represented as 1149 a single octet, followed by a concatenation of the message ID and 1150 the two nonces-- the Initiator's followed by the Responder's. This 1151 is for a liveliness proof. 1153 Graphically, the hashes are: 1155 HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] 1156 [ | IDci | IDcr ] ) 1157 HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] 1158 [ | IDci | IDcr ] ) 1159 HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b) 1161 With the exception of the hash, SA and client ID payloads there are 1162 no payload ordering restrictions on Quick Mode. HASH(1) and HASH(2) 1163 may differ from the illustration above if the order of payloads in 1164 the message differs from the illustrative example or if any optional 1165 payloads, for example a notify payload, have been chained to the 1166 message. 1168 The commit bit in the ISAKMP header ([MSST98]) can be used to extend 1169 a Quick Mode by a single message from the Responder to the Initiator 1170 to delay use of the SAs created by the Quick Mode. This message will 1171 consist of an authenticated hash, using SKEYID_a as the key, of the 1172 message ID from the Quick Mode concatinated with a notify payload 1173 whose type is set to CONNECTED (16384). This final message is sent as 1174 part of the Quick Mode exchange and not as a seperate Informational 1175 exchange. Either side can set the commit during the exchange and the 1176 other party SHOULD reflect back, or acknowledgement, the commit bit 1177 in a subsequent message. Using the '#' symbol to denote the message 1178 with the commit bit, a Quick Mode exchange would become: 1180 Initiator Responder 1181 ----------- ----------- 1182 HDR*, HASH(1), SA, Ni 1183 [, KE ] [, IDi2, IDr2 ] --> 1184 <-- HDR*#, HASH(2), SA, Nr 1185 [, KE ] [, IDi2, IDr2 ] 1186 HDR*#, HASH(3) --> 1187 <-- HDR#*, HASH(4), notify 1189 where HASH(4) = prf(SKEYID_a, M-ID | notify). 1191 If PFS is not desired and KE payloads were not exchanged the keying 1192 material generated by IKE to accompany the SA is defined as: 1194 KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b ) 1196 If PFS is desired and KE payloads were exchanged the keying material 1197 generated by IKE to accompany the SA is defined as: 1199 KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b ) 1201 where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman 1202 exchange of this Quick Mode. 1204 In either case, "protocol", and "SPI", are from the ISAKMP proposal 1205 payload that contained the negotiated (and accepted) transform 1206 payload. 1208 A single SA negotiation results in two security associations-- one 1209 inbound and one outbound. Different SPIs for each SA (one chosen by 1210 the Initiator, the other by the Responder) guarantee a different key 1211 for each direction. The SPI chosen by the destination of the SA is 1212 used to derive KEYMAT for that SA. 1214 For situations where the amount of keying material desired is greater 1215 than that supplied by the prf, KEYMAT is expanded by feeding the 1216 results of the prf back into itself and concatenating results until 1217 the required keying material has been reached. In other words, 1219 KEYMAT = K1 | K2 | K3 | ... 1220 where: 1221 K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b ) 1222 K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | 1223 Nr_b ) 1224 K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | 1225 Nr_b ) 1226 etc. 1228 This keying material (whether with PFS or without, and whether 1229 derived directly or through concatenation) MUST be used with the 1230 negotiated SA. It is up to the service to define how keys are derived 1231 from the keying material. 1233 In the case of an ephemeral Diffie-Hellman exchange in Quick Mode, 1234 the exponential (g(qm)^xy) MUST be irretrievably removed from the 1235 current state and SKEYID_e and SKEYID_a (derived from the Phase 1 1236 negotiation) continue to protect and authenticate the Phase 1 SA and 1237 SKEYID_d continues to be used to derive keys for subsequent Quick 1238 Modes. 1240 Using Quick Mode, multiple SA's and keys can be negotiated with one 1241 exchange as follows: 1243 Initiator Responder 1244 ----------- ----------- 1245 HDR*, HASH(1), SA0, SA1, Ni, 1246 [, KE ] [, IDi2, IDr2 ] --> 1247 <-- HDR*, HASH(2), SA0, SA1, Nr, 1248 [, KE ] [, IDi2, IDr2 ] 1249 HDR*, HASH(3) --> 1251 The keying material is derived identically as in the case of a single 1252 SA. In this case (negotiation of two SA payloads) the result would be 1253 four security associations-- two each way for both SAs. 1255 6.3 New Group Mode 1257 IKE uses 5 groups from [Orm96] to choose from when doing Diffie- 1258 Hellman exchanges. Sometimes those groups may not be desirable for 1259 one reason or another. In this case, New Group Mode can be used to 1260 establish a new shared group between cooperating peers. 1262 New Group mode uses an SA payload from [MSST98] to convey the 1263 attributes of the group being established. This payload contains a 1264 field for the Security Parameter Index (SPI) and a field for the SPI 1265 length. During a New Group mode exchange the SPI field MUST be empty 1266 and its length set to zero. 1268 New Group Mode MUST NOT be used prior to establishment of an IKE SA. 1269 The description of a new group MUST only follow phase 1 negotiation. 1270 (It is not a phase 2 exchange, though). 1272 Initiator Responder 1273 ----------- ----------- 1274 HDR*, HASH(1), SA --> 1275 <-- HDR*, HASH(2), SA 1277 where HASH(1) is the prf output, using SKEYID_a as the key, and the 1278 message-ID from the ISAKMP header concatenated with the entire SA 1279 proposal, body and header, as the data; HASH(2) is the prf output, 1280 using SKEYID_a as the key, and the message-ID from the ISAKMP header 1281 concatenated with the reply as the data. In other words the hashes 1282 for the above exchange are: 1284 HASH(1) = prf(SKEYID_a, M-ID | SA) 1285 HASH(2) = prf(SKEYID_a, M-ID | SA) 1287 The proposal will specify the characteristics of the group (see 1288 appendix A, "Attribute Assigned Numbers"). Group descriptions for 1289 private Groups MUST be greater than or equal to 2^15. If the group 1290 is not acceptable, the responder MUST reply with a Notify payload 1291 with the message type set to ATTRIBUTES-NOT-SUPPORTED (13). 1293 IKE implementations MAY require private groups to expire with the SA 1294 under which they were established. 1296 Groups may be directly negotiated in the SA proposal with Main Mode. 1297 To do this the component parts-- for a MODP group, the type, prime 1298 and generator; for a EC2N group the type, the Irreducible Polynomial, 1299 Group Generator One, Group Generator Two, Group Curve A, Group Curve 1300 B and Group Order-- are passed as SA attributes (see Appendix A). 1301 Alternately, the nature of the group can be hidden using New Group 1302 Mode and only the group identifier is passed in the clear during 1303 phase 1 negotiation. 1305 6.4 Notification Exchanges 1307 At various point during an IKE exchange peers may desire to convey 1308 some information to each other regarding errors or notifications of 1309 certain state transitions. To accomplish this IKE defines two 1310 Informational exchanges, an unreliable uni-directional message and an 1311 acknowledged, reliable bi-directional exchange. 1313 Informational exchanges described in this memo are secured by a 1314 previously established Phase 1 SA. Any Information message sent prior 1315 the the establishment of a Phase 1 SA MUST be sent unsecured to 1316 prevent a loss of cryptographic syncronization. Any action taken 1317 upon receipt of an unprotected Informational message should be taken 1318 with great care as they can easily be forged by any evesdropper. 1319 Therefore, IKE implementations are discouraged from sending 1320 unprotected Informational messages. Exceptions to this are for 1321 Informational messages which will not effect continuation of the 1322 exchange. For example, sending an INVALID-FLAGS message for improper 1323 use of the commit bit would not necessarily cause termination of an 1324 exchange in the way a NO-PROPOSAL-CHOSEN message would. 1326 Like a Quick Mode exchange, Informational messages are given a 1327 pseudo-random message ID to allow for multiplexing exchanges through 1328 a single Phase 1 SA. Likewise, they are secured by a Phase 1 SA: 1329 confidentiality is provided by SKEYID_e and message integrity is 1330 provided by a keyed hash using SKEYID_a. 1332 The initiaization vector for these exchanges is derived in exactly 1333 the same fashion as that for a Quick Mode-- i.e. it is derived from a 1334 hash of a concatenation of the last phase 1 CBC output block (or the 1335 Phase 1 IV if no Phase 1 messages were encrypted) and the message id 1336 from the ISAKMP header of the Informational Exchange (not the message 1337 id from the message that may have prompted the Informational 1338 Exchange). 1340 Due to the freeform nature of ISAKMP message construction more than 1341 one single notify payload may be sent in a single Informational 1342 exchange. 1344 6.4.1 Unacknowledged Informational 1346 An unacknowledged, FYI-style, Informational message is defined as: 1348 Initiator Responder 1349 ----------- ----------- 1350 HDR*, HASH, N/D --> 1352 where N/D is either an ISAKMP notify payhload or an ISAKMP delete 1353 payload, and HASH is the prf output, using SKEYID_a as the key and 1354 the message ID from the ISAKMP header concatenated with the entire 1355 Informational payload (the Notify or Delete payload and any 1356 additional chained payloads) as the data. In other words, the hash 1357 for the above exchange is: 1359 HASH = prf(SKEYID_a, M-ID | N/D) 1361 6.4.2 Acknowledged Informational 1363 IKE exchanges are sent as ISAKMP messages whose delivery is 1364 unreliable. This fact has been taken into account in the design of 1365 Phase 1 and Phase 2 exchanges since retransmission timers are set to 1366 allow for packet loss. Due to the unreliable nature of the exchange 1367 described in 6.4.1 certain messages should not be sent that way. For 1368 instance, if a notification that an SA has been deleted is lost the 1369 sender may delete it but the intended recipient will have not way of 1370 knowing this fact. 1372 The first payload of the acknowledged Informational exchange MUST be 1373 a hash payload and the second payload MUST be the nonce of the 1374 sender. The Responder MUST NOT change the notification payloads 1375 which follow the Initiator's nonce. 1377 The acknowledged Informational exchange is defined as: 1379 Initiator Responder 1380 ----------- ----------- 1381 HDR*, HASH(1), Ni, N/D --> 1382 <-- HDR*, HASH(2), Nr, N/D 1384 where HASH(1) is prf output using SKEYID_a from the Phase 1 SA 1385 identified by the cookies in the ISAKMP header as the key, and the 1386 unique, pseudo-random message ID for this exchange concatenated with 1387 the remaining payloads (in this case, a delete or notify and a nonce 1388 payload, but more payloads could be chained to this message) as the 1389 data, and HASH(2) is the prf output using SKEYID_a, from the Phase 1 1390 SA identified by the cookies in the ISKAMP header, as the key and the 1391 nonce payload sent by the Initiator concatenated with the pseudo- 1392 random message ID for this exchange and the remaining payloads as the 1393 message to hash. The hashes for the above exchange would be: 1395 HASH(1) = prf(SKEYID_a, M-ID | Ni | N/D) 1396 HASH(2) = prf(SKEYID_a, Ni | M-ID | Nr | N/D) 1398 This memo does not proscribe which messages should be sent with the 1399 Acknowledged or Unacknowledged Informational. 1401 7 Payload Explosion of Sample Exchange 1403 7.1 Phase 1 Using Main Mode 1405 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 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 ~ ISAKMP Header with XCHG of Main Mode, ~ 1408 ~ and Next Payload of ISA_SA ~ 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 ! 0 ! RESERVED ! Payload Length ! 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 ! Domain of Interpretation ! 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 ! Situation ! 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 ! 0 ! RESERVED ! Payload Length ! 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 ! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms ! 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 ! ISA_TRANS ! RESERVED ! Payload Length ! 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 ! Transform #1 ! KEY_OAKLEY | RESERVED2 ! 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 ~ prefered SA attributes ~ 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 ! 0 ! RESERVED ! Payload Length ! 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 ! Transform #2 ! KEY_OAKLEY | RESERVED2 ! 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 ~ alternate SA attributes ~ 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 The responder replies in kind but selects, and returns, one transform 1434 proposal (the ISAKMP SA attributes). 1436 The second exchange consists of the following payloads: 1438 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 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 ~ ISAKMP Header with XCHG of Main Mode, ~ 1441 ~ and Next Payload of ISA_KE ~ 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 ! ISA_NONCE ! RESERVED ! Payload Length ! 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 ~ D-H Public Value (g^ii from initiator g^ir from responder) ~ 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 ! 0 ! RESERVED ! Payload Length ! 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 ~ Ni (from initiator) or Nr (from responder) ~ 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 The shared keys, SKEYID_e and SKEYID_a, are now used to protect and 1453 authenticate all further communication. Note that both SKEYID_e and 1454 SKEYID_a are unauthenticated. 1456 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 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 ~ ISAKMP Header with XCHG of Main Mode, ~ 1459 ~ and Next Payload of ISA_ID and the encryption bit set ~ 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 ! ISA_SIG ! RESERVED ! Payload Length ! 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 ~ Identification Data of the ISAKMP negotiator ~ 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 ! 0 ! RESERVED ! Payload Length ! 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 ~ signature verified by the public key of the ID above ~ 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 The key exchange is authenticated over a signed hash as described in 1471 section 5.1. Once the signature has been verified using the 1472 authentication algorithm negotiated as part of the ISAKMP SA, the 1473 shared keys, SKEYID_e and SKEYID_a can be marked as authenticated. 1474 (For brevity, certificate payloads were not exchanged). 1476 7.2 Phase 2 Using Quick Mode 1478 The following payloads are exchanged in the first round of Quick Mode 1479 with ISAKMP SA negotiation. In this hypothetical exchange, the ISAKMP 1480 negotiators are proxies for other parties which have requested 1481 authentication. 1483 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 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 ~ ISAKMP Header with XCHG of Quick Mode, ~ 1486 ~ Next Payload of ISA_HASH and the encryption bit set ~ 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 ! ISA_SA ! RESERVED ! Payload Length ! 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 ~ keyed hash of message ~ 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 ! ISA_NONCE ! RESERVED ! Payload Length ! 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 ! Domain Of Interpretation ! 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 ! Situation ! 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 ! 0 ! RESERVED ! Payload Length ! 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 ! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms ! 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 ~ SPI (4 octets) ~ 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 ! ISA_TRANS ! RESERVED ! Payload Length ! 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 ! Transform #1 ! AH_SHA | RESERVED2 ! 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 ! other SA attributes ! 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 ! 0 ! RESERVED ! Payload Length ! 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 ! Transform #2 ! AH_MD5 | RESERVED2 ! 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 ! other SA attributes ! 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 ! ISA_ID ! RESERVED ! Payload Length ! 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 ~ nonce ~ 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 ! ISA_ID ! RESERVED ! Payload Length ! 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 ~ ID of source for which ISAKMP is a client ~ 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 ! 0 ! RESERVED ! Payload Length ! 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 ~ ID of destination for which ISAKMP is a client ~ 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 where the contents of the hash are described in 5.5 above. The 1530 responder replies with a similar message which only contains one 1531 transform-- the selected AH transform. Upon receipt, the initiator 1532 can provide the key engine with the negotiated security association 1533 and the keying material. As a check against replay attacks, the 1534 responder waits until receipt of the next message. 1536 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 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 ~ ISAKMP Header with XCHG of Quick Mode, ~ 1539 ~ Next Payload of ISA_HASH and the encryption bit set ~ 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 ! 0 ! RESERVED ! Payload Length ! 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 ~ hash data ~ 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 where the contents of the hash are described in 5.5 above. 1548 8 Security Considerations 1550 This entire memo discusses a hybrid protocol, combining parts of 1551 Oakley and parts of SKEME with ISAKMP, to negotiate, and derive 1552 keying material for, security associations in a secure and 1553 authenticated manner. 1555 Confidentiality is assured by the use of a negotiated encryption 1556 algorithm. Authentication is assured by the use of a negotiated 1557 method: a digital signature algorithm; a public key algorithm which 1558 supports encryption; or, a pre-shared key. The confidentiality and 1559 authentication of this exchange is only as good as the attributes 1560 negotiated as part of the ISAKMP security association. 1562 Repeated re-keying using Quick Mode without PFS can consume the 1563 entropy of the Diffie-Hellman shared secret. Implementors should take 1564 note of this fact and set a limit on Quick Mode Exchanges between 1565 exponentiations. This memo does not prescribe such a limit. 1567 Perfect Forward Secrecy (PFS) of both keying material and identities 1568 is possible with this protocol. By using the PFS option during a 1569 Quick Mode, specifying a Diffie-Hellman group and passing public 1570 values in KE payloads, IKE peers can establish PFS of keys. The 1571 identities would be protected by SKEYID_e from the Phase 1 SA and 1572 would therefore not be protected by PFS. If PFS of both keying 1573 material and identities is desired, an IKE peer MUST establish only 1574 one non-ISAKMP security association (e.g. IPsec Security 1575 Association) per Phase 1 SA. PFS for keys and identities is 1576 accomplished by deleting the Phase 1 SA (and optionally issuing a 1577 DELETE message) upon establishment of the single Phase 2 SA. In this 1578 way the Phase one negotiation is uniquely tied to a single Phase two 1579 negotiation, and is never used again. 1581 The strength of a key derived from a Diffie-Hellman exchange using 1582 any of the groups defined here depends on the inherent strength of 1583 the group, the size of the exponent used, and the entropy provided by 1584 the random number generator used. Due to these inputs it is difficult 1585 to determine the strength of a key for any of the defined groups. The 1586 default Diffie-Hellman group (number two) when used with a strong 1587 random number generator and an exponent no less than 160 bits is 1588 sufficient to use for 3DES. Groups three through five provide 1589 greater security. Group one is for historic purposes only and does 1590 not provide sufficient strength to the required cipher (although it 1591 is sufficient for use with DES, which is also for historic use only). 1592 Implementations should make note of these conservative estimates when 1593 establishing policy and negotiating security parameters. 1595 Note that these limitations are on the Diffie-Hellman groups 1596 themselves. There is nothing in IKE which prohibits using stronger 1597 groups nor is there anything which will dilute the strength obtained 1598 from stronger groups. In fact, the extensible framework of IKE 1599 encourages the definition of more groups; use of elliptical curve 1600 groups will greatly increase strength using much smaller numbers. 1602 For situations where defined groups provide insufficient strength New 1603 Group Mode can be used to exchange a Diffie-Hellman group which 1604 provides the necessary strength. In is incumbent upon implementations 1605 to check the primality in groups being offered and independently 1606 arrive at strength estimates. 1608 It is assumed that the Diffie-Hellman exponents in this exchange are 1609 erased from memory after use. In particular, these exponents must not 1610 be derived from long-lived secrets like the seed to a pseudo-random 1611 generator. 1613 IKE exchanges maintain running initialization vectors (IV) where the 1614 last ciphertext block of the last message is the IV for the next 1615 message. To prevent retransmissions (or forged messages with valid 1616 cookies) from causing exchanges to get out of sync IKE 1617 implementations SHOULD NOT update their running IV until the 1618 decrypted message has passed a basic sanity check and has been 1619 determined to actually advance the IKE state machine-- i.e. it is not 1620 a retransmission. 1622 While the last roundtrip of Main Mode (and optionally the last 1623 message of Aggressive Mode) is encrypted it is not, strictly 1624 speaking, authenticated. An active substitution attack on the 1625 ciphertext could result in payload corruption. If such an attack 1626 corrupts mandatory payloads it would be detected by an authentication 1627 failure, but if it corrupts any optional payloads (e.g. notify 1628 payloads chained onto the last message of a Main Mode exchange) it 1629 might not be detectable. 1631 The message ID used for all non-Phase 1 exchanges MUST be pseudo- 1632 randomly generated using a strong random number generator. 1634 Optimal Asymmetric Encryption Padding [BR94] MUST be used with PKCS#1 1635 to avoid the adaptive chosen ciphertext attack against RSA that is 1636 described in [Ble98]. See [PKCS1]. 1638 The acknowledged Informational exchange is open to replay attacks. 1640 9 IANA Considerations 1642 This document contains many "magic numbers" to be maintained by the 1643 IANA. This section explains the criteria to be used by the IANA to 1644 assign additional numbers in each of these lists. 1646 9.1 Attribute Classes 1648 Attributes negotiated in this protocol are identified by their class. 1649 Requests for assignment of new classes must be accompanied by a 1650 standards-track RFC which describes the use of this attribute. 1652 9.2 Encryption Algorithm Class 1654 Values of the Encryption Algorithm Class define an encryption 1655 algorithm to use when called for in this document. Requests for 1656 assignment of new encryption algorithm values must be accompanied by 1657 a reference to a standards-track or Informational RFC or a reference 1658 to published cryptographic literature which describes this algorithm. 1660 9.3 Hash Algorithm 1662 Values of the Hash Algorithm Class define a hash algorithm to use 1663 when called for in this document. Requests for assignment of new hash 1664 algorithm values must be accompanied by a reference to a standards- 1665 track or Informational RFC or a reference to published cryptographic 1666 literature which describes this algorithm. Due to the key derivation 1667 and key expansion uses of HMAC forms of hash algorithms in IKE, 1668 requests for assignment of new hash algorithm values must take into 1669 account the cryptographic properties-- e.g it's resistance to 1670 collision-- of the hash algorithm itself. 1672 9.4 Group Description and Group Type 1674 Values of the Group Description Class identify a group to use in a 1675 Diffie-Hellman exchange. Values of the Group Type Class define the 1676 type of group. Requests for assignment of new groups must be 1677 accompanied by a reference to a standards-track or Informational RFC 1678 which describes this group. Requests for assignment of new group 1679 types must be accompanied by a reference to a standards-track or 1680 Informational RFC or by a reference to published cryptographic or 1681 mathmatical literature which describes the new type. 1683 9.5 Life Type 1685 Values of the Life Type Class define a type of lifetime to which the 1686 ISAKMP Security Association applies. Requests for assignment of new 1687 life types must be accompanied by a detailed description of the units 1688 of this type and its expiry. 1690 10 Acknowledgements 1692 This document is the result of close consultation with Hugo Krawczyk, 1693 Douglas Maughan, Hilarie Orman, Mark Schertler, Mark Schneider, and 1694 Jeff Turner. It relies on protocols which were written by them. 1695 Without their interest and dedication, this would not have been 1696 written. 1698 Special thanks Rob Adams, Cheryl Madson, Derrell Piper, Harry Varnis, 1699 and Elfed Weaver for technical input, encouragement, and various 1700 sanity checks along the way. We would also like to thank Ben Rogers 1701 and D. Hugh Redelmeier for helping close up various holes in the text 1702 which were open to interpretation. 1704 We would also like to thank the many members of the IPSec working 1705 group that contributed to the development of this protocol over the 1706 past two years, especially those of you who've implemented IKE. 1707 Thanks! 1709 11 References 1711 [CAST] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, 1712 May 1997. 1714 [BLOW] Schneier, B., "The Blowfish Encryption Algorithm", Dr. 1715 Dobb's Journal, v. 19, n. 4, April 1994. 1717 [Bra96] Bradner, S., "The Internet Standards Process -- Revision 3", 1718 BCP 9, RFC 2026, October 1996. 1720 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 1721 Requirement Levels", BCP 14, RFC 2119, March 1997. 1723 [Ble98] Bleichenbacher, D., "Chosen Ciphertext Attacks against 1724 Protocols Based on RSA Encryption Standard PKCS#1", Advances 1725 in Cryptology Eurocrypt '98, Springer-Verlag, 1998. 1727 [BR94] Bellare, M., and Rogaway P., "Optimal Asymmetric 1728 Encryption." 1729 Advances in Cryptology Eurocrypt '94, Springer-Verlag, 1994. 1731 [DES] ANSI X3.106, "American National Standard for Information 1732 Systems-Data Link Encryption", American National Standards 1733 Institute, 1983. 1735 [DH] Diffie, W., and Hellman M., "New Directions in 1736 Cryptography", IEEE Transactions on Information Theory, V. 1737 IT-22, n. 6, June 1977. 1739 [DSS] NIST, "Digital Signature Standard", FIPS 186, National 1740 Institute of Standards and Technology, U.S. Department of 1741 Commerce, May, 1994. 1743 [IDEA] Lai, X., "On the Design and Security of Block Ciphers," ETH 1744 Series in Information Processing, v. 1, Konstanz: Hartung- 1745 Gorre Verlag, 1992 1747 [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1748 Hashing for Message Authentication", RFC 2104, February 1749 1997. 1751 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 1752 Mechanism for Internet", from IEEE Proceedings of the 1996 1753 Symposium on Network and Distributed Systems Security. 1755 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 1756 April 1992. 1758 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, 1759 "Internet Security Association and Key Management Protocol 1760 (ISAKMP)", RFC 2408, November 1998. 1762 [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC 1763 2412, November 1998. 1765 [PKCS1] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography 1766 Specifications Version 2", September 1998. 1768 [Pip98] Piper, D., "The Internet IP Security Domain Of 1769 Interpretation for ISAKMP", RFC 2407, November 1998. 1771 [RC5] Rivest, R., "The RC5 Encryption Algorithm", Dr. Dobb's 1772 Journal, v. 20, n. 1, January 1995. 1774 [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for 1775 Obtaining Digital Signatures and Public-Key Cryptosystems", 1776 Communications of the ACM, v. 21, n. 2, February 1978. 1778 [Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms, 1779 and Source Code in C", 2nd edition. 1781 [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institue 1782 of Standards and Technology, U.S. Department of Commerce, 1783 May 1994. 1785 [TIGER] Anderson, R., and Biham, E., "Fast Software Encryption", 1786 Springer LNCS v. 1039, 1996. 1788 Appendix A 1790 Attribute Assigned Numbers 1792 Attributes negotiated during phase one use the following definitions. 1793 Phase two attributes are defined in the applicable DOI specification 1794 (for example, IPsec attributes are defined in the IPsec DOI), with 1795 the exception of a group description when Quick Mode includes an 1796 ephemeral Diffie-Hellman exchange. Attribute types can be either 1797 Basic (B) or Variable-length (V). Encoding of these attributes is 1798 defined in [MSST98] as Type/Value (Basic) and Type/Length/Value 1799 (Variable). 1801 Attributes described as basic MUST NOT be encoded as variable. 1802 Variable length attributes MAY be encoded as basic attributes if 1803 their value can fit into two octets. If this is the case, an 1804 attribute offered as variable (or basic) by the initiator of this 1805 protocol MAY be returned to the initiator as a basic (or variable). 1807 Attribute Classes 1809 class value type 1810 -------------------------------------------------------------- 1811 Encryption Algorithm 1 B 1812 Hash Algorithm 2 B 1813 Authentication Method 3 B 1814 Group Description 4 B 1815 Group Type 5 B 1816 Group Prime/Irreducible Polynomial 6 V 1817 Group Generator One 7 V 1818 Group Generator Two 8 V 1819 Group Curve A 9 V 1820 Group Curve B 10 V 1821 Life Type 11 B 1822 Life Duration 12 V 1823 PRF 13 B 1824 Key Length 14 B 1825 Field Size 15 B 1826 Group Order 16 V 1827 Block Size 17 B 1829 values 18-16383 are reserved to IANA. Values 16384-32767 are for 1830 private use among mutually consenting parties. 1832 Class Values 1834 - Encryption Algorithm Defined In 1835 DES-CBC 1 RFC 2405 1836 IDEA-CBC 2 1837 Blowfish-CBC 3 1838 RC5-R16-B64-CBC 4 1839 3DES-CBC 5 1840 CAST-CBC 6 1842 values 7-65000 are reserved to IANA. Values 65001-65535 are for 1843 private use among mutually consenting parties. 1845 - Hash Algorithm Defined In 1846 MD5 1 RFC 1321 1847 SHA 2 FIPS 180-1 1848 Tiger 3 See Reference [TIGER] 1850 values 4-65000 are reserved to IANA. Values 65001-65535 are for 1851 private use among mutually consenting parties. 1853 - Authentication Method 1854 pre-shared key 1 1855 DSS signatures 2 1856 RSA signatures 3 1857 Encryption with RSA 4 1858 Revised encryption with RSA 5 1859 Encryption with El-Gamal 6 1860 Revised encryption with El-Gamal 7 1862 values 8-65000 are reserved to IANA. Values 65001-65535 are for 1863 private use among mutually consenting parties. 1865 - Group Description 1867 768-bit MODP group (section 5.1) 1 1868 1024-bit MODP group (section 5.2) 2 1869 EC2N group on GP[2^155] (section 5.3) 3 1870 EC2N group on GP[2^185] (section 5.4) 4 1871 1536-bit MODP group (section 5.5) 5 1872 values 6-32767 are reserved to IANA. Values 32768-65535 are for 1873 private use among mutually consenting parties. 1875 - Group Type 1877 MODP (modular exponentiation group) 1 1878 ECP (elliptic curve group over GF[P]) 2 1879 EC2N (elliptic curve group over GF[2^N]) 3 1881 values 4-65000 are reserved to IANA. Values 65001-65535 are for 1882 private use among mutually consenting parties. 1884 - Life Type 1886 seconds 1 1887 kilobytes 2 1889 values 3-65000 are reserved to IANA. Values 65001-65535 are for 1890 private use among mutually consenting parties. For a given "Life 1891 Type" the value of the "Life Duration" attribute defines the 1892 actual length of the SA life-- either a number of seconds, or a 1893 number of kbytes protected. 1895 - PRF 1897 There are currently no pseudo-random functions defined. 1899 values 1-65000 are reserved to IANA. Values 65001-65535 are for 1900 private use among mutually consenting parties. 1902 - Key Length 1904 When using an Encryption Algorithm that has a variable length key, 1905 this attribute specifies the key length in bits. (MUST use network 1906 byte order). This attribute MUST NOT be used when the specified 1907 Encryption Algorithm uses a fixed length key. 1909 - Field Size 1911 The field size, in bits, of a Diffie-Hellman group. 1913 - Group Order 1915 The group order of an elliptical curve group. Note the length of 1916 this attribute depends on the field size. 1918 - Block Size 1920 The number of bits per block of a cipher with a variable block 1921 length. 1923 Additional Exchanges Defined-- XCHG values 1925 Quick Mode 32 1926 New Group Mode 33 1927 Acknowledged Informational 34 1929 Appendix B 1931 This appendix describes encryption details to be used ONLY when 1932 encrypting IKE messages. When a service (such as IPSec) utilizes IKE 1933 to generate keying material, all encryption algorithm specific 1934 details (such as key and IV generation, padding, etc...) MUST be 1935 defined by that service. IKE does not purport to produce keys that 1936 are suitable for every encryption algorithm. IKE produces the 1937 requested amount of keying material from which the service MUST 1938 generate a suitable key. Details, such as weak key checks, are the 1939 responsibility of the service. 1941 Use of negotiated PRFs may require the prf output to be expanded due 1942 to the prf feedback mechanism employed by this document. For example, 1943 if the (ficticious) DOORAK-MAC requires 24 bytes of key but produces 1944 only 8 bytes of output, the output must be expanded three times 1945 before being used as the key for another instance of itself. The 1946 output of a prf is expanded by feeding back the results of the prf 1947 into itself to generate successive blocks. These blocks are 1948 concatenated until the requisite number of bytes has been acheived. 1949 For example, for pre-shared key authentication with DOORAK-MAC as the 1950 negotiated prf: 1952 BLOCK1-8 = prf(pre-shared-key, Ni_b | Nr_b) 1953 BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni_b | Nr_b) 1954 BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni_b | Nr_b) 1955 and 1956 SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 1958 so therefore to derive SKEYID_d: 1960 BLOCK1-8 = prf(SKEYID, g^ir | CKY-I | CKY-R | 0) BLOCK9-16 = 1961 prf(SKEYID, BLOCK1-8 | g^ir | CKY-I | CKY-R | 0) BLOCK17-24 = 1962 prf(SKEYID, BLOCK9-16 | g^ir | CKY-I | CKY-R | 0) 1964 and 1966 SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 1968 Subsequent prf derivations are done similarly. 1970 Encryption keys used to protect the Phase 1 SA are derived from 1971 SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long 1972 enough to supply all the necessary keying material an algorithm 1973 requires, the key is derived from feeding the results of a pseudo- 1974 random function into itself, concatenating the results, and taking 1975 the highest necessary bits. 1977 For example, if (ficticious) algorithm AKULA requires 320-bits of key 1978 (and has no weak key check) and the prf used to generate SKEYID_e 1979 only generates 120 bits of material, the key for AKULA, would be the 1980 first 320-bits of Ka, where: 1982 Ka = K1 | K2 | K3 1984 and 1986 K1 = prf(SKEYID_e, 0) 1987 K2 = prf(SKEYID_e, K1) 1988 K3 = prf(SKEYID_e, K2) 1990 where prf is the negotiated prf or the HMAC version of the negotiated 1991 hash function (if no prf was negotiated) and 0 is represented by a 1992 single octet. Each result of the prf provides 120 bits of material 1993 for a total of 360 bits. AKULA would use the first 320 bits of that 1994 360 bit string. 1996 The input to a CBC mode operation must be equivalent to the block 1997 size of the underlying cipher. To satisfy this requirment, IKE 1998 messages are padded up to the nearest block size using bytes 1999 containing 0x00. The message length in the ISAKMP header MUST include 2000 the length of this pad. 2002 The key for 3DES-CBC is the first twenty-four (24) bytes of a key 2003 derived in the aforementioned pseudo-random function feedback method. 2004 3DES-CBC is an encrypt-decrypt-encrypt operation using the first, 2005 middle, and last eight (8) bytes of the entire 3DES-CBC key. The IV 2006 is the first eight (8) bytes of the IV material derived in section 2007 4.1 above. 2009 The key for DES-CBC is derived from the first eight (8) non-weak and 2010 non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first 2011 8 bytes of the IV material derived in section 4.1 above. 2013 The key for IDEA-CBC is derived from the first sixteen (16) bytes of 2014 SKEYID_e. The IV is the first eight (8) bytes of the IV material 2015 derived in section 4.1 above. 2017 The key for Blowfish-CBC is either the negotiated key size, or the 2018 first fifty-six (56) bytes of a key (if no key size is negotiated) 2019 derived in the aforementioned pseudo-random function feedback method. 2020 The IV is the first eight (8) bytes of the IV material derived in 2021 section 4.1 above. 2023 The key for RC5-R16-B64-CBC is the negotiated key size, or the first 2024 sixteen (16) bytes of a key (if no key size is negotiated) derived 2025 from the aforementioned pseudo-random function feedback method if 2026 necessary. The IV is the first eight (8) bytes of the IV material 2027 derived in section 4.1 above. The number of rounds MUST be 16 and the 2028 block size MUST be 64. 2030 The key for CAST-CBC is either the negotiated key size, or the first 2031 sixteen (16) bytes of a key derived in the aforementioned pseudo- 2032 random function feedback method. The IV is the first eight (8) bytes 2033 of the IV material derived in section 4.1 above. 2035 Support for algorithms other than 3DES-CBC is purely optional. Some 2036 optional algorithms may be subject to intellectual property claims. 2038 Authors' Addresses 2040 Dan Harkins 2041 Network Alchemy 2042 1615 Pacific ave 2043 Santa Cruz, California, 95060 2044 United States of America 2046 Phone: +1 831 460 3800 2047 EMail: dharkins@network-alchemy.com 2049 Dave Carrel 2050 Redback Networks 2051 San Francisco, CA 94131-2947 2052 United States of America 2054 Phone: +1 415 337 8469 2055 EMail: carrel@rback.net 2057 Authors' Note 2059 The authors encourage independent implementation, and 2060 interoperability testing, of this hybrid protocol.