idnits 2.17.1 draft-ietf-ipsec-isakmp-oakley-07.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-03-29) 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([MSST98], [Kra96], [Orm96]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1488 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). == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Similarly, Aggressive Mode is an instantiation of the ISAKMP Aggressive Exchange. The first two messages negotiate policy, exchange Diffie-Hellman public values and ancillary data necessary for the exchange, and identities. In addition the second message authenticates the responder. The third message authenticates the initiator and provides a proof of participation in the exchange. The XCHG for Aggressive Mode is ISAKMP Aggressive. The final message MAY NOT be sent under protection of the ISAKMP SA allowing each party to postpone exponentiation, if desired, until negotiation of this exchange is complete. The graphic depictions of Aggressive Mode show the final payload in the clear; it need not be. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9511 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: 'Pip97' is mentioned on line 794, but not defined == Missing Reference: 'P' is mentioned on line 1562, but not defined == Unused Reference: 'Acm97' is defined on line 1424, but no explicit reference was found in the text == Unused Reference: 'Pip98' is defined on line 1444, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2144 (ref. 'Acm97') ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'KBC96') -- Possible downref: Non-RFC (?) normative reference: ref. 'Kra96' ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. 'MSST98') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-oakley is -01, but you're referring to -02. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-oakley (ref. 'Orm96') == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-ipsec-doi-08 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-ipsec-doi (ref. 'Pip98') -- Possible downref: Non-RFC (?) normative reference: ref. 'Sch96' Summary: 17 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSEC Working Group D. Harkins, D. Carrel 3 INTERNET-DRAFT cisco Systems 4 draft-ietf-ipsec-isakmp-oakley-07.txt March 1998 6 The Internet Key Exchange (IKE) 7 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 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 To learn the current status of any Internet Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Australia), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Table Of Contents 29 1 Abstract 30 2 Discussion 31 3 Terms and Definitions 32 3.1 Requirements Terminology 33 3.2 Notation 34 3.3 Perfect Forward Secrecty 35 3.4 Security Association 36 4 Introduction 37 5 Exchanges 38 5.1 Authentication with Digital Signatures 39 5.2 Authentication with Public Key Encryption 40 5.3 A Revised method of Authentication with Public Key Encryption 41 5.4 Authentication with a Pre-Shared Key 42 5.5 Quick Mode 43 5.6 New Group Mode 44 5.7 ISAKMP Informational Exchanges 45 6 Oakley Groups 46 6.1 First Oakley Group 47 6.2 Second Oakley Group 48 6.3 Third Oakley Group 49 6.4 Fourth Oakley Group 50 7 Payload Explosion of Complete Exchange 51 7.1 Phase 1 with Main Mode 52 7.2 Phase 2 with Quick Mode 53 8 Perfect Forward Secrecy Example 54 9 Implementation Hints 55 10 Security Considerations 56 11 IANA Considerations 57 12 Acknowledgments 58 13 References 59 Appendix A 60 Appendix B 62 1. Abstract 64 [MSST98] (ISAKMP) provides a framework for authentication and key 65 exchange but does not define them. ISAKMP is designed to be key 66 exchange independant; that is, it is designed to support many 67 different key exchanges. 69 [Orm96] (Oakley) describes a series of key exchanges-- called 70 "modes"-- and details the services provided by each (e.g. perfect 71 forward secrecy for keys, identity protection, and authentication). 73 [Kra96] (SKEME) describes a versatile key exchange technique which 74 provides anonymity, repudiability, and quick key refreshment. 76 This document describes a protocol using part of Oakley and part of 77 SKEME in conjunction with ISAKMP to obtain authenticated keying 78 material for use with ISAKMP, and for other security associations 79 such as AH and ESP for the IETF IPsec DOI. 81 2. Discussion 83 This draft describes a hybrid protocol. The purpose is to negotiate, 84 and provide authenticated keying material for, security associations 85 in a protected manner. 87 Processes which implement this draft can be used for negotiating 88 virtual private networks (VPNs) and also for providing a remote user 89 from a remote site (whose IP address need not be known beforehand) 90 access to a secure host or network. 92 Client negotiation is supported. Client mode is where the 93 negotiating parties are not the endpoints for which security 94 association negotiation is taking place. When used in client mode, 95 the identities of the end parties remain hidden. 97 This does not implement the entire Oakley protocol, but only a subset 98 necessary to satisfy its goals. It does not claim conformance or 99 compliance with the entire Oakley protocol nor is it dependant in any 100 way on the Oakley protocol. 102 Likewise, this does not implement the entire SKEME protocol, but only 103 the method of public key encryption for authentication and its 104 concept of fast re-keying using an exchange of nonces. This protocol 105 is not dependant in any way on the SKEME protocol. 107 3. Terms and Definitions 109 3.1 Requirements Terminology 111 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 112 "MAY" that appear in this document are to be interpreted as described 113 in [Bra97]. 115 3.2 Notation 117 The following notation is used throughout this draft. 119 HDR is an ISAKMP header whose exchange type is the mode. When 120 writen as HDR* it indicates payload encryption. 122 SA is an SA negotiation payload with one or more proposals. An 123 initiator MAY provide multiple proposals for negotiation; a 124 responder MUST reply with only one. 126

_b indicates the body of payload

-- the ISAKMP generic 127 payload is not included. 129 SAi_b is the entire body of the SA payload (minus the ISAKMP 130 generic header)-- i.e. the DOI, situation, all proposals and all 131 transforms offered by the Initiator. 133 CKY-I and CKY-R are the Initiator's cookie and the Responder's 134 cookie, respectively, from the ISAKMP header. 136 g^xi and g^xr are the Diffie-Hellman public values of the 137 initiator and responder respectively. 139 g^xy is the Diffie-Hellman shared secret. 141 KE is the key exchange payload which contains the public 142 information exchanged in a Diffie-Hellman exchange. There is no 143 particular encoding (e.g. a TLV) used for the data of a KE 144 payload. 146 Nx is the nonce payload; x can be: i or r for the ISAKMP initiator 147 and responder respectively. 149 IDx is the identification payload for "x". x can be: "ii" or "ir" 150 for the ISAKMP initiator and responder respectively during phase 151 one negotiation; or "ui" or "ur" for the user initiator and 152 responder respectively during phase two. The ID payload format 153 for the Internet DOI is defined in [Pip97]. 155 SIG is the signature payload. The data to sign is exchange- 156 specific. 158 CERT is the certificate payload. 160 HASH (and any derivitive such as HASH(2) or HASH_I) is the hash 161 payload. The contents of the hash are specific to the 162 authentication method. 164 prf(key, msg) is the keyed pseudo-random function-- often a keyed 165 hash function-- used to generate a deterministic output that 166 appears pseudo-random. prf's are used both for key derivations 167 and for authentication (i.e. as a keyed MAC). (See [KBC96]). 169 SKEYID is a string derived from secret material known only to the 170 active players in the exchange. 172 SKEYID_e is the keying material used by the ISAKMP SA to protect 173 the confidentiality of its messages. 175 SKEYID_a is the keying material used by the ISAKMP SA to 176 authenticate its messages. 178 SKEYID_d is the keying material used to derive keys for non-ISAKMP 179 security associations. 181 y indicates that "x" is encrypted with the key "y". 183 --> signifies "initiator to responder" communication (requests). 185 <-- signifies "responder to initiator" communication (replies). 187 | signifies concatenation of information-- e.g. X | Y is the 188 concatentation of X with Y. 190 [x] indicates that x is optional. 192 Message encryption (when noted by a '*' after the ISAKMP header) MUST 193 begin immediately after the ISAKMP header. When communication is 194 protected, all payloads following the ISAKMP header MUST be 195 encrypted. Encryption keys are generated from SKEYID_e in a manner 196 that is defined for each algorithm. 198 3.3 Perfect Forward Secrecy 200 When used in the draft Perfect Forward Secrecy (PFS) refers to the 201 notion that compromise of a single key will permit access to only 202 data protected by a single key. For PFS to exist the key used to 203 protect transmission of data MUST NOT be used to derive any 204 additional keys, and if the key used to protect transmission of data 205 was derived from some other keying material, that material MUST NOT 206 be used to derive any more keys. 208 Perfect Forward Secrecy for both keys and identities is provided in 209 this protocol. (Sections 5.5 and 8). 211 3.4 Security Association 213 A security association (SA) is a set of policy and key(s) used to 214 protect information. The ISAKMP SA is the shared policy and key(s) 215 used by the negotiating peers in this protocol to protect their 216 communication. 218 4. Introduction 220 Oakley and SKEME each define a method to establish an authenticated 221 key exchange. This includes payloads construction, the information 222 payloads carry, the order in which they are processed and how they 223 are used. 225 While Oakley defines "modes", ISAKMP defines "phases". The 226 relationship between the two is very straightforward and IKE presents 227 different exchanges as modes which operate in one of two phases. 229 Phase 1 is where the two ISAKMP peers establish a secure, 230 authenticated channel with which to communicate. This is called the 231 ISAKMP Security Association (SA). "Main Mode" and "Aggressive Mode" 232 each accomplish a phase 1 exchange. "Main Mode" and "Aggressive Mode" 233 MUST ONLY be used in phase 1. 235 Phase 2 is where Security Associations are negotiated on behalf of 236 services such as IPsec or any other service which needs key material 237 and/or parameter negotiation. "Quick Mode" accomplishes a phase 2 238 exchange. "Quick Mode" MUST ONLY be used in phase 2. 240 "New Group Mode" is not really a phase 1 or phase 2. It follows 241 phase 1, but serves to establish a new group which can be used in 242 future negotiations. "New Group Mode" MUST ONLY be used after phase 243 1. 245 The ISAKMP SA is bi-directional. That is, once established, either 246 party may initiate Quick Mode, Informational, and New Group Mode 247 Exchanges. Per the base ISAKMP document, the ISAKMP SA is identified 248 by the Initiator's cookie followed by the Responder's cookie-- the 249 role of each party in the phase 1 exchange dictates which cookie is 250 the Initiator's. The cookie order established by the phase 1 exchange 251 continues to identify the ISAKMP SA regardless of the direction the 252 Quick Mode, Informational, or New Group exchange. In other words, the 253 cookies MUST NOT swap places when the direction of the ISAKMP SA 254 changes. 256 With the use of ISAKMP phases, an implementation can accomplish very 257 fast keying when necessary. A single phase 1 negotiation may be used 258 for more than one phase 2 negotiation. Additionally a single phase 2 259 negotiation can request multiple Security Associations. With these 260 optimizations, an implementation can see less than one round trip per 261 SA as well as less than one DH exponentiation per SA. "Main Mode" 262 for phase 1 provides identity protection. When identity protection 263 is not needed, "Aggressive Mode" can be used to reduce round trips 264 even further. Developer hints for doing these optimizations are 265 included below. It should also be noted that using public key 266 encryption to authenticate an Aggressive Mode exchange will still 267 provide identity protection. 269 This protocol does not define its own DOI per se. The ISAKMP SA, 270 established in phase 1, MAY use the DOI and situation from a non- 271 ISAKMP service (such as the IETF IPSec DOI [Pip97]). In this case an 272 implementation MAY choose to restrict use of the ISAKMP SA for 273 establishment of SAs for services of the same DOI. Alternately, an 274 ISAKMP SA MAY be established with the value zero in both the DOI and 275 situation (see [MSST98] for a description of these fields) and in 276 this case implementations will be free to establish security services 277 for any defined DOI using this ISAKMP SA. If a DOI of zero is used 278 for establishment of a phase 1 SA, the syntax of the identity 279 payloads used in phase 1 is that defined in [MSST98] and not from any 280 DOI-- e.g. [Pip97]-- which may further expand the syntax and 281 semantics of identities. 283 The following attributes are used by IKE and are negotiated as part 284 of the ISAKMP Security Association. (These attributes pertain only 285 to the ISAKMP Security Association and not to any Security 286 Associations that ISAKMP may be negotiating on behalf of other 287 services.) 289 - encryption algorithm (e.g. DES, IDEA, Blowfish). 291 - hash algorithm (e.g. MD5, SHA) 293 - authentication method (e.g. DSS sig, RSA sig, RSA encryption, 294 pre-shared key) 296 - information about a group over which to do Diffie-Hellman. 298 All of these attributes are mandatory and MUST be negotiated. In 299 addition, it is possible to optionally negotiate a psuedo-random 300 function ("prf"). (There are currently no negotiable pseudo-random 301 functions defined in this document. Private use attribute values can 302 be used for prf negotiation between consenting parties). If a "prf" 303 is not negotiation, the HMAC (see [KBC96]) version of the negotiated 304 hash algorithm is used as a pseudo-random function. Other non- 305 mandatory attributes are described in Appendix A. The selected hash 306 algorithm MUST support both native and HMAC modes. 308 The Diffie-Hellman group MUST be either specified using a defined 309 group description (section 6) or by defining all attributes of a 310 group (section 5.6). Group attributes (such as group type or prime-- 311 see Appendix A) MUST NOT be offered in conjunction with a previously 312 defined group (either a reserved group description or a private use 313 description that is established after conclusion of a New Group Mode 314 exchange). 316 IKE implementations MUST support the following attribute values: 318 - DES-CBC with a weak, and semi-weak, key check (weak and semi- 319 weak keys are referenced in [Sch96] and listed in Appendix A). The 320 key is derived according to Appendix B. 322 - MD5 and SHA. 324 - Authentication via pre-shared keys. The Digital Signature 325 Standard SHOULD be supported; RSA-- both signatures and 326 authentication with public key encryption-- SHOULD be supported. 328 - MODP over the default group (see below). ECP and EC2N groups MAY 329 be supported. 331 The IKE modes described here MUST be implemented whenever the IETF 332 IPsec DOI [Pip97] is implemented. Other DOIs MAY use the modes 333 described here. 335 5. Exchanges 337 There are two basic methods used to establish an authenticated key 338 exchange: Main Mode and Aggressive Mode. Each generates authenticated 339 keying material from an ephemeral Diffie-Hellman exchange. Main Mode 340 MUST be implemented; Aggressive Mode SHOULD be implemented. In 341 addition, Quick Mode MUST be implemented as a mechanism to generate 342 fresh keying material and negotiate non-ISAKMP security services. In 343 addition, New Group Mode SHOULD be implemented as a mechanism to 344 define private groups for Diffie-Hellman exchanges. Implementations 345 MUST NOT switch exchange types in the middle of an exchange. 347 Exchanges conform to standard ISAKMP [MSST98] payload syntax, 348 attribute encoding, timeouts and retransmits of messages, and 349 informational messages-- e.g a notify response is sent when, for 350 example, a proposal is unacceptable, or a signature verification or 351 decryption was unsuccessful, etc. 353 The SA payload MUST precede all other payloads in a phase 1 exchange. 354 Except where otherwise noted, there are no requirements for ISAKMP 355 payloads in any message to be in any particular order. 357 The Diffie-Hellman public value passed in a KE payload, in either a 358 phase 1 or phase 2 exchange, MUST be the length of the negotiated 359 Diffie-Hellman group enforced, if necessary, by pre-pending the value 360 with zeros. 362 The length of nonce payload MUST be between 8 and 256 bytes 363 inclusive. 365 Main Mode is an instantiation of the ISAKMP Identity Protect 366 Exchange: The first two messages negotiate policy; the next two 367 exchange Diffie-Hellman public values and ancillary data (e.g. 368 nonces) necessary for the exchange; and the last two messages 369 authenticate the Diffie-Hellman Exchange. The authentication method 370 negotiated as part of the initial ISAKMP exchange influences the 371 composition of the payloads but not their purpose. The XCHG for Main 372 Mode is ISAKMP Identity Protect. 374 Similarly, Aggressive Mode is an instantiation of the ISAKMP 375 Aggressive Exchange. The first two messages negotiate policy, 376 exchange Diffie-Hellman public values and ancillary data necessary 377 for the exchange, and identities. In addition the second message 378 authenticates the responder. The third message authenticates the 379 initiator and provides a proof of participation in the exchange. The 380 XCHG for Aggressive Mode is ISAKMP Aggressive. The final message MAY 381 NOT be sent under protection of the ISAKMP SA allowing each party to 382 postpone exponentiation, if desired, until negotiation of this 383 exchange is complete. The graphic depictions of Aggressive Mode show 384 the final payload in the clear; it need not be. 386 Exchanges in IKE are not open ended and have a fixed number of 387 messages. Receipt of a Certificate Request payload MUST NOT extend 388 the number of messages transmitted or expected. 390 Security Association negotiation is limited with Aggressive Mode. Due 391 to message construction requirements the group in which the Diffie- 392 Hellman exchange is performed cannot be negotiated. In addition, 393 different authentication methods may further constrain attribute 394 negotiation. For example, authentication with public key encryption 395 cannot be negotiated and when using the revised method of public key 396 encryption for authentication the cipher and hash cannot be 397 negotiated. For situations where the rich attribute negotiation 398 capabilities of IKE are required Main Mode may be required. 400 Quick Mode and New Group Mode have no analog in ISAKMP. The XCHG 401 values for Quick Mode and New Group Mode are defined in Appendix A. 403 Main Mode, Aggressive Mode, and Quick Mode do security association 404 negotiation. Security Association offers take the form of Tranform 405 Payload(s) encapsulated in Proposal Payload(s) encapsulated in 406 Security Association (SA) payload(s). If multiple offers are being 407 made for phase 1 exchanges (Main Mode and Aggressive Mode) they MUST 408 take the form of multiple Transform Payloads for a single Proposal 409 Payload in a single SA payload. To put it another way, for phase 1 410 exchanges there MUST NOT be multiple Proposal Payloads for a single 411 SA payload and there MUST NOT be multiple SA payloads. This document 412 does not proscribe such behavior on offers in phase 2 exchanges. 414 There is no limit on the number of offers the initiator may send to 415 the responder but conformant implementations MAY choose to limit the 416 number of offers it will inspect for performance reasons. 418 During security association negotiation, initiators present offers 419 for potential security associations to responders. Responders MUST 420 NOT modify attributes of any offer, attribute encoding excepted (see 421 Appendix A). If the initiator of an exchange notices that attribute 422 values have changed or attributes have been added or deleted from an 423 offer made, that response MUST be rejected. 425 Four different authentication methods are allowed with either Main 426 Mode or Aggressive Mode-- digital signature, two forms of 427 authentication with public key encryption, or pre-shared key. The 428 value SKEYID is computed seperately for each authentication method. 430 For signatures: SKEYID = prf(Ni_b | Nr_b, g^xy) 431 For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | 432 CKY-R) 433 For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | 434 Nr_b) 436 The result of either Main Mode or Aggressive Mode is three groups of 437 authenticated keying material: 439 SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) 440 SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) 441 SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) 443 and agreed upon policy to protect further communications. The values 444 of 0, 1, and 2 above are represented by a single octet. The key used 445 for encryption is derived from SKEYID_e in an algorithm-specific 446 manner (see appendix B). 448 To authenticate either exchange the initiator of the protocol 449 generates HASH_I and the responder generates HASH_R where: 451 HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) 452 HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) 454 For authentication with digital signatures, HASH_I and HASH_R are 455 signed and verified; for authentication with either public key 456 encryption or pre-shared keys, HASH_I and HASH_R directly 457 authenticate the exchange. The entire ID payload (including ID type, 458 port, and protocol but excluding the generic header) is hashed into 459 both HASH_I and HASH_R. 461 As mentioned above, the negotiated authentication method influences 462 the content and use of messages for Phase 1 Modes, but not their 463 intent. When using public keys for authentication, the Phase 1 464 exchange can be accomplished either by using signatures or by using 465 public key encryption (if the algorithm supports it). Following are 466 Phase 1 exchanges with different authentication options. 468 5.1 IKE Phase 1 Authenticated With Signatures 470 Using signatures, the ancillary information exchanged during the 471 second roundtrip are nonces; the exchange is authenticated by signing 472 a mutually obtainable hash. Main Mode with signature authentication 473 is described as follows: 475 Initiator Responder 476 ---------- ----------- 477 HDR, SA --> 478 <-- HDR, SA 479 HDR, KE, Ni --> 480 <-- HDR, KE, Nr 481 HDR*, IDii, [ CERT, ] SIG_I --> 482 <-- HDR*, IDir, [ CERT, ] SIG_R 484 Aggressive mode with signatures in conjunction with ISAKMP is 485 described as follows: 487 Initiator Responder 488 ----------- ----------- 489 HDR, SA, KE, Ni, IDii --> 490 <-- HDR, SA, KE, Nr, IDir, 491 [ CERT, ] SIG_R 492 HDR, [ CERT, ] SIG_I --> 494 In both modes, the signed data, SIG_I or SIG_R, is the result of the 495 negotiated digital signature algorithm applied to HASH_I or HASH_R 496 respectively. 498 In general the signature will be over HASH_I and HASH_R as above 499 using the negotiated prf, or the HMAC version of the negotiated hash 500 function (if no prf is negotiated). However, this can be overridden 501 for construction of the signature if the signature algorithm is tied 502 to a particular hash algorithm (e.g. DSS is only defined with SHA's 503 160 bit output). In this case, the signature will be over HASH_I and 504 HASH_R as above, except using the HMAC version of the hash algorithm 505 associated with the signature method. The negotiated prf and hash 506 function would continue to be used for all other prescribed pseudo- 507 random functions. 509 Since the hash algorithm used is already known there is no need to 510 encode its OID into the signature. In addition, there is no binding 511 between the OIDs used for RSA signatures in PKCS #1 and those used in 512 this document. Therefore, RSA signatures MUST be encoded as a private 513 key encryption in PKCS #1 format and not as a signature in PKCS #1 514 format (which includes the OID of the hash algorithm). DSS signatures 515 MUST be encoded as r followed by s. 517 One or more certificate payloads MAY be optionally passed. 519 5.2 Phase 1 Authenticated With Public Key Encryption 521 Using public key encryption to authenticate the exchange, the 522 ancillary information exchanged is encrypted nonces. Each party's 523 ability to reconstruct a hash (proving that the other party decrypted 524 the nonce) authenticates the exchange. 526 In order to perform the public key encryption, the initiator must 527 already have the responder's public key. In the case where the 528 responder has multiple public keys, a hash of the certificate the 529 initiator is using to encrypt the ancillary information is passed as 530 part of the third message. In this way the responder can determine 531 which corresponding private key to use to decrypt the encrypted 532 payloads and identity protection is retained. 534 In addition to the nonce, the identities of the parties (IDii and 535 IDir) are also encrypted with the other party's public key. If the 536 authentication method is public key encryption, the nonce and 537 identity payloads MUST be encrypted with the public key of the other 538 party. Only the body of the payloads are encrypted, the payload 539 headers are left in the clear. 541 When using encryption for authentication, Main Mode is defined as 542 follows. 544 Initiator Responder 545 ----------- ----------- 546 HDR, SA --> 547 <-- HDR, SA 548 HDR, KE, [ HASH(1), ] 549 PubKey_r, 550 PubKey_r --> 551 HDR, KE, PubKey_i, 552 <-- PubKey_i 553 HDR*, HASH_I --> 554 <-- HDR*, HASH_R 556 Aggressive Mode authenticated with encryption is described as 557 follows: 559 Initiator Responder 560 ----------- ----------- 561 HDR, SA, [ HASH(1),] KE, 562 Pubkey_r, 563 Pubkey_r --> 564 HDR, SA, KE, PubKey_i, 565 <-- PubKey_i, HASH_R 566 HDR, HASH_I --> 568 Where HASH(1) is a hash (using the negotiated hash function) of the 569 certificate which the initiator is using to encrypt the nonce and 570 identity. 572 RSA encryption MUST be encoded in PKCS #1 format. While only the body 573 of the ID and nonce payloads is encrypted, the encrypted data must be 574 preceded by a valid ISAKMP generic header. The payload length is the 575 length of the entire encrypted payload plus header. The PKCS #1 576 encoding allows for determination of the actual length of the 577 cleartext payload upon decryption. 579 Using encryption for authentication provides for a plausably deniable 580 exchange. There is no proof (as with a digital signature) that the 581 conversation ever took place since each party can completely 582 reconstruct both sides of the exchange. In addition, security is 583 added to secret generation since an attacker would have to 584 successfully break not only the Diffie-Hellman exchange but also both 585 RSA encryptions. This exchange was motivated by [Kra96]. 587 Note that, unlike other authentication methods, authentication with 588 public key encryption allows for identity protection with Aggressive 589 Mode. 591 5.3 Phase 1 Authenticated With a Revised Mode of Public Key Encryption 593 Authentication with Public Key Encryption has significant advantages 594 over authentication with signatures (see section 5.2 above). 595 Unfortunately, this is at the cost of 4 public key operations-- two 596 public key encryptions and two private key decryptions. This 597 authentication mode retains the advantages of authentication using 598 public key encryption but does so with half the public key 599 operations. 601 In this mode, the nonce is still encrypted using the public key of 602 the peer, however the peer's identity (and the certificate if it is 603 sent) is encrypted using the negotiated symmetric encryption 604 algorithm (from the SA payload) with a key derived from the nonce. 605 This solution adds minimal complexity and state yet saves two costly 606 public key operations on each side. In addition, the Key Exchange 607 payload is also encrypted using the same derived key. This provides 608 additional protection against cryptanalysis of the Diffie-Hellman 609 exchange. 611 As with the public key encryption method of authentication (section 612 5.2), a HASH payload may be sent to identify a certificate if the 613 responder has multiple certificates which contain useable public keys 614 (e.g. if the certificate is not for signatures only, either due to 615 certificate restrictions or algorithmic restrictions). If the HASH 616 payload is sent it MUST be the first payload of the second message 617 exchange and MUST be followed by the encrypted nonce. If the HASH 618 payload is not sent, the first payload of the second message exchange 619 MUST be the encrypted nonce. In addition, the initiator my optionally 620 send a certificate payload to provide the responder with a public key 621 with which to respond. 623 When using the revised encryption mode for authentication, Main Mode 624 is defined as follows. 626 Initiator Responder 627 ----------- ----------- 628 HDR, SA --> 629 <-- HDR, SA 630 HDR, [ HASH(1), ] 631 Pubkey_r, 632 Ke_i, 633 Ke_i, 634 [<Ke_i] --> 635 HDR, PubKey_i, 636 Ke_r, 637 <-- Ke_r, 638 HDR*, HASH_I --> 639 <-- HDR*, HASH_R 641 Aggressive Mode authenticated with the revised encryption method is 642 described as follows: 644 Initiator Responder 645 ----------- ----------- 646 HDR, SA, [ HASH(1),] 647 Pubkey_r, 648 Ke_i, Ke_i 649 [, Ke_i ] --> 650 HDR, SA, PubKey_i, 651 Ke_r, Ke_r, 652 <-- HASH_R 653 HDR, HASH_I --> 655 where HASH(1) is identical to section 5.2. Ke_i and Ke_r are keys to 656 the symmetric encryption algorithm negotiated in the SA payload 657 exchange. Only the body of the payloads are encrypted (in both public 658 key and symmetric operations), the generic payload headers are left 659 in the clear. The payload length includes that added to perform 660 encryption. 662 The symmetric cipher keys are derived from the decrypted nonces as 663 follows. First the values Ne_i and Ne_r are computed: 665 Ne_i = prf(Ni_b, CKY-I) 666 Ne_r = prf(Nr_b, CKY-R) 668 The keys Ke_i and Ke_r are then taken from Ne_i and Ne_r respectively 669 in the manner described in Appendix B used to derive symmetric keys 670 for use with the negotiated encryption algorithm. If the length of 671 the output of the negotiated prf is greater than or equal to the key 672 length requirements of the cipher, Ke_i and Ke_r are derived from the 673 most significant bits of Ne_i and Ne_r respectively. If the desired 674 length of Ke_i and Ke_r exceed the length of the output of the prf 675 the necessary number of bits is obtained by repeatedly feeding the 676 results of the prf back into itself and concatenating the result 677 until the necessary number has been achieved. For example, if the 678 negotiated encryption algorithm requires 320 bits of key and the 679 output of the prf is only 128 bits, Ke_i is the most significant 320 680 bits of K, where 682 K = K1 | K2 | K3 and 683 K1 = prf(Ne_i, 0) 684 K2 = prf(Ne_i, K1) 685 K3 = prf(Ne_i, K2) 687 For brevity, only derivation of Ke_i is shown; Ke_r is identical. The 688 length of the value 0 in the computation of K1 is a single octet. 689 Note that Ne_i, Ne_r, Ke_i, and Ke_r are all ephemeral and MUST be 690 discarded after use. 692 Save the requirements on the location of the optional HASH payload 693 and the mandatory nonce payload there are no further payload 694 requirements. All payloads-- in whatever order-- following the 695 encrypted nonce MUST be encrypted with Ke_i or Ke_r depending on the 696 direction. 698 If CBC mode is used for the symmetric encryption then the 699 initialization vectors (IVs) are set as follows. The IV for 700 encrypting the first payload following the nonce is set to 0 (zero). 701 The IV for subsequent payloads encrypted with the ephemeral symmetric 702 cipher key, Ke_i, is the last ciphertext block of the previous 703 payload. Encrypted payloads are padded up to the nearest block size. 704 All padding bytes, except for the last one, contain 0x00. The last 705 byte of the padding contains the number of the padding bytes used, 706 excluding the last one. Note that this means there will always be 707 padding. 709 5.4 Phase 1 Authenticated With a Pre-Shared Key 711 A key derived by some out-of-band mechanism may also be used to 712 authenticate the exchange. The actual establishment of this key is 713 out of the scope of this document. 715 When doing a pre-shared key authentication, Main Mode is defined as 716 follows: 718 Initiator Responder 719 ---------- ----------- 720 HDR, SA --> 721 <-- HDR, SA 722 HDR, KE, Ni --> 723 <-- HDR, KE, Nr 724 HDR*, IDii, HASH_I --> 725 <-- HDR*, IDir, HASH_R 727 Aggressive mode with a pre-shared key is described as follows: 729 Initiator Responder 730 ----------- ----------- 731 HDR, SA, KE, Ni, IDii --> 732 <-- HDR, SA, KE, Nr, IDir, HASH_R 733 HDR, HASH_I --> 735 When using pre-shared key authentication with Main Mode the key can 736 only be identified by the IP address of the peers since HASH_I must 737 be computed before the initiator has processed IDir. Aggressive Mode 738 allows for a wider range of identifiers of the pre-shared secret to 739 be used. In addition, Aggressive Mode allows two parties to maintain 740 multiple, different pre-shared keys and identify the correct one for 741 a particular exchange. 743 5.5 Phase 2 - Quick Mode 745 Quick Mode is not a complete exchange itself (in that it is bound to 746 a phase 1 exchange), but is used as part of the SA negotiation 747 process (phase 2) to derive keying material and negotiate shared 748 policy for non-ISAKMP SAs. The information exchanged along with Quick 749 Mode MUST be protected by the ISAKMP SA-- i.e. all payloads except 750 the ISAKMP header are encrypted. In Quick Mode, a HASH payload MUST 751 immediately follow the ISAKMP header and a SA payload MUST 752 immediately follow the HASH. This HASH authenticates the message and 753 also provides liveliness proofs. 755 The message ID in the ISAKMP header identifies a Quick Mode in 756 progress for a particular ISAKMP SA which itself is identified by the 757 cookies in the ISAKMP header. Since each instance of a Quick Mode 758 uses a unique initialization vector (see Appendix B) it is possible 759 to have multiple simultaneous Quick Modes, based off a single ISAKMP 760 SA, in progress at any one time. 762 Quick Mode is essentially a SA negotiation and an exchange of nonces 763 that provides replay protection. The nonces are used to generate 764 fresh key material and prevent replay attacks from generating bogus 765 security associations. An optional Key Exchange payload can be 766 exchanged to allow for an additional Diffie-Hellman exchange and 767 exponentiation per Quick Mode. While use of the key exchange payload 768 with Quick Mode is optional it MUST be supported. 770 Base Quick Mode (without the KE payload) refreshes the keying 771 material derived from the exponentiation in phase 1. This does not 772 provide PFS. Using the optional KE payload, an additional 773 exponentiation is performed and PFS is provided for the keying 774 material. 776 The identities of the SAs negotiated in Quick Mode are implicitly 777 assumed to be the IP addresses of the ISAKMP peers, without any 778 implied constraints on the protocol or port numbers allowed, unless 779 client identifiers are specified in Quick Mode. If ISAKMP is acting 780 as a client negotiator on behalf of another party, the identities of 781 the parties MUST be passed as IDci and then IDcr. Local policy will 782 dictate whether the proposals are acceptable for the identities 783 specified. If the client identities are not acceptable to the Quick 784 Mode responder (due to policy or other reasons), a Notify payload 785 with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent. 787 The client identities are used to identify and direct traffic to the 788 appropriate tunnel in cases where multiple tunnels exist between two 789 peers and also to allow for unique and shared SAs with different 790 granularities. 792 All offers made during a Quick Mode are logically related and must be 793 consistant. For example, if a KE payload is sent, the attribute 794 describing the Diffie-Hellman group (see section 6.1 and [Pip97]) 795 MUST be included in every transform of every proposal of every SA 796 being negotiated. Similarly, if client identities are used, they MUST 797 apply to every SA in the negotiation. 799 Quick Mode is defined as follows: 801 Initiator Responder 802 ----------- ----------- 803 HDR*, HASH(1), SA, Ni 804 [, KE ] [, IDci, IDcr ] --> 805 <-- HDR*, HASH(2), SA, Nr 806 [, KE ] [, IDci, IDcr ] 807 HDR*, HASH(3) --> 809 Where: 810 HASH(1) is the prf over the message id (M-ID) from the ISAKMP 811 header concatenated with the entire message that follows the hash 812 including all payload headers, but excluding any padding added for 813 encryption. HASH(2) is identical to HASH(1) except the initiator's 814 nonce-- Ni, minus the payload header-- is added after M-ID but before 815 the complete message. The addition of the nonce to HASH(2) is for a 816 liveliness proof. HASH(3)-- for liveliness-- is the prf over the 817 value zero represented as a single octet, followed by a concatenation 818 of the message id and the two nonces-- the initiator's followed by 819 the responder's-- minus the payload header. In other words, the 820 hashes for the above exchange are: 822 HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr ) 823 HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr ) 824 HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b) 826 With the exception of the HASH, SA, and the optional ID payloads, 827 there are no payload ordering restrictions on Quick Mode. HASH(1) and 828 HASH(2) may differ from the illustration above if the order of 829 payloads in the message differs from the illustrative example or if 830 any optional payloads, for example a notify payload, have been 831 chained to the message. 833 If PFS is not needed, and KE payloads are not exchanged, the new 834 keying material is defined as 836 KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b). 838 If PFS is desired and KE payloads were exchanged, the new keying 839 material is defined as 841 KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b) 843 where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman 844 exchange of this Quick Mode. 846 In either case, "protocol" and "SPI" are from the ISAKMP Proposal 847 Payload that contained the negotiated Transform. 849 A single SA negotiation results in two security assocations-- one 850 inbound and one outbound. Different SPIs for each SA (one chosen by 851 the initiator, the other by the responder) guarantee a different key 852 for each direction. The SPI chosen by the destination of the SA is 853 used to derive KEYMAT for that SA. 855 For situations where the amount of keying material desired is greater 856 than that supplied by the prf, KEYMAT is expanded by feeding the 857 results of the prf back into itself and concatenating results until 858 the required keying material has been reached. In other words, 860 KEYMAT = K1 | K2 | K3 | ... 861 where 862 K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) 863 K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) 864 K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) 865 etc. 867 This keying material (whether with PFS or without, and whether 868 derived directly or through concatenation) MUST be used with the 869 negotiated SA. It is up to the service to define how keys are derived 870 from the keying material. 872 In the case of an ephemeral Diffie-Hellman exchange in Quick Mode, 873 the exponential (g(qm)^xy) is irretreivably removed from the current 874 state and SKEYID_e and SKEYID_a (derived from phase 1 negotiation) 875 continue to protect and authenticate the ISAKMP SA and SKEYID_d 876 continues to be used to derive keys. 878 Using Quick Mode, multiple SA's and keys can be negotiated with one 879 exchange as follows: 881 Initiator Responder 882 ----------- ----------- 883 HDR*, HASH(1), SA0, SA1, Ni, 884 [, KE ] [, IDci, IDcr ] --> 885 <-- HDR*, HASH(2), SA0, SA1, Nr, 886 [, KE ] [, IDci, IDcr ] 887 HDR*, HASH(3) --> 889 The keying material is derived identically as in the case of a single 890 SA. In this case (negotiation of two SA payloads) the result would be 891 four security associations-- two each way for both SAs. 893 5.6 New Group Mode 895 New Group Mode MUST NOT be used prior to establishment of an ISAKMP 896 SA. The description of a new group MUST only follow phase 1 897 negotiation. (It is not a phase 2 exchange, though). 899 Initiator Responder 900 ----------- ----------- 901 HDR*, HASH(1), SA --> 902 <-- HDR*, HASH(2), SA 904 where HASH(1) is the prf output, using SKEYID_a as the key, and the 905 message-ID from the ISAKMP header concatenated with the entire SA 906 proposal, body and header, as the data; HASH(2) is the prf output, 907 using SKEYID_a as the key, and the message-ID from the ISAKMP header 908 concatenated with the reply as the data. In other words the hashes 909 for the above exchange are: 911 HASH(1) = prf(SKEYID_a, M-ID | SA) 912 HASH(2) = prf(SKEYID_a, M-ID | SA) 914 The proposal will specify the characteristics of the group (see 915 appendix A, "Attribute Assigned Numbers"). Group descriptions for 916 private Groups MUST be greater than or equal to 2^15. If the group 917 is not acceptable, the responder MUST reply with a Notify payload 918 with the message type set to ATTRIBUTES-NOT-SUPPORTED (13). 920 ISAKMP implementations MAY require private groups to expire with the 921 SA under which they were established. 923 Groups may be directly negotiated in the SA proposal with Main Mode. 924 To do this the component parts-- for a MODP group, the type, prime 925 and generator; for a EC2N group the type, the Irreducible Polynomial, 926 Group Generator One, Group Generator Two, Group Curve A, Group Curve 927 B and Group Order-- are passed as SA attributes (see Appendix A). 928 Alternately, the nature of the group can be hidden using New Group 929 Mode and only the group identifier is passed in the clear during 930 phase 1 negotiation. 932 5.7 ISAKMP Informational Exchanges 934 This protocol protects ISAKMP Informational Exchanges when possible. 935 Once the ISAKMP security association has been established (and 936 SKEYID_e and SKEYID_a have been generated) ISAKMP Information 937 Exchanges, when used with this protocol, are as follows: 939 Initiator Responder 940 ----------- ----------- 941 HDR*, HASH(1), N/D --> 943 where N/D is either an ISAKMP Notify Payload or an ISAKMP Delete 944 Payload and HASH(1) is the prf output, using SKEYID_a as the key, and 945 a M-ID unique to this exchange concatenated with the entire 946 informational payload (either a Notify or Delete) as the data. In 947 other words, the hash for the above exchange is: 949 HASH(1) = prf(SKEYID_a, M-ID | N/D) 951 As noted the message ID in the ISAKMP header-- and used in the prf 952 computation-- is unique to this exchange and MUST NOT be the same as 953 the message ID of another phase 2 exchange which generated this 954 informational exchange. The derivation of the initialization vector, 955 used with SKEYID_e to encrypt this message, is described in Appendix 956 B. 958 If the ISAKMP security association has not yet been established at 959 the time of the Informational Exchange, the exchange is done in the 960 clear without an accompanying HASH payload. 962 6 Oakley Groups 964 With IKE, the group in which to do the Diffie-Hellman exchange is 965 negotiated. Four groups-- values 1 through 4-- are defined below. 966 These groups originated with the Oakley protocol and are therefore 967 called "Oakley Groups". The attribute class for "Group" is defined in 968 Appendix A. All values 2^15 and higher are used for private group 969 identifiers. For a discussion on the strength of the default Oakley 970 groups please see the Security Considerations section below. 972 6.1 First Oakley Default Group 974 Oakley implementations MUST support a MODP group with the following 975 prime and generator. This group is assigned id 1 (one). 977 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 978 Its hexadecimal value is 980 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 981 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 982 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 983 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 985 The generator is: 2. 987 6.2 Second Oakley Group 989 IKE implementations SHOULD support a MODP group with the following 990 prime and generator. This group is assigned id 2 (two). 992 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 993 Its hexadecimal value is 995 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 996 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 997 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 998 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 999 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 1000 FFFFFFFF FFFFFFFF 1002 The generator is 2 (decimal) 1004 6.3 Third Oakley Group 1006 IKE implementations SHOULD support a EC2N group with the following 1007 characteristics. This group is assigned id 3 (three). The curve is 1008 based on the Galois Field GF[2^155]. The field size is 155. The 1009 irreducible polynomial for the field is: 1010 u^155 + u^62 + 1. 1011 The equation for the elliptic curve is: 1012 y^2 + xy = x^3 + ax^2 + b. 1014 Field Size: 155 1015 Group Prime/Irreducible Polynomial: 1016 0x0800000000000000000000004000000000000001 1017 Group Generator One: 0x7b 1018 Group Curve A: 0x0 1019 Group Curve B: 0x07338f 1021 Group Order: 0X0800000000000000000057db5698537193aef944 1023 The data in the KE payload when using this group is the value x from 1024 the solution (x,y), the point on the curve chosen by taking the 1025 randomly chosen secret Ka and computing Ka*P, where * is the 1026 repetition of the group addition and double operations, P is the 1027 curve point with x coordinate equal to generator 1 and the y 1028 coordinate determined from the defining equation. The equation of 1029 curve is implicitly known by the Group Type and the A and B 1030 coefficients. There are two possible values for the y coordinate; 1031 either one can be used successfully (the two parties need not agree 1032 on the selection). 1034 6.4 Fourth Oakley Group 1036 IKE implementations SHOULD support a EC2N group with the following 1037 characteristics. This group is assigned id 4 (four). The curve is 1038 based on the Galois Field GF[2^185]. The field size is 185. The 1039 irreducible polynomial for the field is: 1041 u^185 + u^69 + 1. The 1042 equation for the elliptic curve is: 1043 y^2 + xy = x^3 + ax^2 + b. 1045 Field Size: 185 1046 Group Prime/Irreducible Polynomial: 1047 0x020000000000000000000000000000200000000000000001 1048 Group Generator One: 0x18 1049 Group Curve A: 0x0 1050 Group Curve B: 0x1ee9 1052 Group Order: 0X01ffffffffffffffffffffffdbf2f889b73e484175f94ebc 1054 The data in the KE payload when using this group will be identical to 1055 that as when using Oakley Group 3 (three). 1057 Other groups can be defined using New Group Mode. These default 1058 groups were generated by Richard Schroeppel at the University of 1059 Arizona. Properties of these primes are described in [Orm96]. 1061 7. Payload Explosion for a Complete IKE Exchange 1063 This section illustrates how the IKE protocol is used to: 1065 - establish a secure and authenticated channel between ISAKMP 1066 processes (phase 1); and 1068 - generate key material for, and negotiate, an IPsec SA (phase 2). 1070 7.1 Phase 1 using Main Mode 1072 The following diagram illustrates the payloads exchanged between the 1073 two parties in the first round trip exchange. The initiator MAY 1074 propose several proposals; the responder MUST reply with one. 1076 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 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 ~ ISAKMP Header with XCHG of Main Mode, ~ 1079 ~ and Next Payload of ISA_SA ~ 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 ! 0 ! RESERVED ! Payload Length ! 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 ! Domain of Interpretation ! 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 ! Situation ! 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 ! 0 ! RESERVED ! Payload Length ! 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 ! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms ! 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 ! ISA_TRANS ! RESERVED ! Payload Length ! 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 ! Transform #1 ! KEY_OAKLEY | RESERVED2 ! 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 ~ prefered SA attributes ~ 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 ! 0 ! RESERVED ! Payload Length ! 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 ! Transform #2 ! KEY_OAKLEY | RESERVED2 ! 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 ~ alternate SA attributes ~ 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 The responder replies in kind but selects, and returns, one transform 1105 proposal (the ISAKMP SA attributes). 1107 The second exchange consists of the following payloads: 1109 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 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 ~ ISAKMP Header with XCHG of Main Mode, ~ 1112 ~ and Next Payload of ISA_KE ~ 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 ! ISA_NONCE ! RESERVED ! Payload Length ! 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 ~ D-H Public Value (g^xi from initiator g^xr from responder) ~ 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 ! 0 ! RESERVED ! Payload Length ! 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 ~ Ni (from initiator) or Nr (from responder) ~ 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 The shared keys, SKEYID_e and SKEYID_a, are now used to protect and 1124 authenticate all further communication. Note that both SKEYID_e and 1125 SKEYID_a are unauthenticated. 1127 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 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 ~ ISAKMP Header with XCHG of Main Mode, ~ 1130 ~ and Next Payload of ISA_ID and the encryption bit set ~ 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 ! ISA_SIG ! RESERVED ! Payload Length ! 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 ~ Identification Data of the ISAKMP negotiator ~ 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 ! 0 ! RESERVED ! Payload Length ! 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 ~ signature verified by the public key of the ID above ~ 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 The key exchange is authenticated over a signed hash as described in 1142 section 5.1. Once the signature has been verified using the 1143 authentication algorithm negotiated as part of the ISAKMP SA, the 1144 shared keys, SKEYID_e and SKEYID_a can be marked as authenticated. 1145 (For brevity, certificate payloads were not exchanged). 1147 7.2 Phase 2 using Quick Mode 1149 The following payloads are exchanged in the first round of Quick 1150 Mode with ISAKMP SA negotiation. In this hypothetical exchange, the 1151 ISAKMP negotiators are proxies for other parties which have requested 1152 authentication. 1154 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 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 ~ ISAKMP Header with XCHG of Quick Mode, ~ 1157 ~ Next Payload of ISA_HASH and the encryption bit set ~ 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 ! ISA_SA ! RESERVED ! Payload Length ! 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 ~ keyed hash of message ~ 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 ! ISA_NONCE ! RESERVED ! Payload Length ! 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 ! Domain Of Interpretation ! 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 ! Situation ! 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 ! 0 ! RESERVED ! Payload Length ! 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 ! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms ! 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 ~ SPI (4 octets) ~ 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 ! ISA_TRANS ! RESERVED ! Payload Length ! 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 ! Transform #1 ! AH_SHA | RESERVED2 ! 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 ! other SA attributes ! 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 ! 0 ! RESERVED ! Payload Length ! 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 ! Transform #2 ! AH_MD5 | RESERVED2 ! 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 ! other SA attributes ! 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 ! ISA_ID ! RESERVED ! Payload Length ! 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 ~ nonce ~ 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 ! ISA_ID ! RESERVED ! Payload Length ! 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 ~ ID of source for which ISAKMP is a client ~ 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 ! 0 ! RESERVED ! Payload Length ! 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 ~ ID of destination for which ISAKMP is a client ~ 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 where the contents of the hash are described in 5.5 above. The 1201 responder replies with a similar message which only contains one 1202 transform-- the selected AH transform. Upon receipt, the initiator 1203 can provide the key engine with the negotiated security association 1204 and the keying material. As a check against replay attacks, the 1205 responder waits until receipt of the next message. 1207 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 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 ~ ISAKMP Header with XCHG of Quick Mode, ~ 1210 ~ Next Payload of ISA_HASH and the encryption bit set ~ 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 ! 0 ! RESERVED ! Payload Length ! 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 ~ hash data ~ 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 where the contents of the hash are described in 5.5 above. 1219 8 Perfect Forward Secrecy Example 1220 This protocol can provide PFS of both keys and identities. The 1221 identies of both the ISAKMP negotiating peer and, if applicable, the 1222 identities for whom the peers are negotiating can be protected with 1223 PFS. 1225 To provide Perfect Forward Secrecy of both keys and all identities, 1226 two parties would perform the following: 1227 o A Main Mode Exchange to protect the identities of the ISAKMP 1228 peers. 1229 This establishes an ISAKMP SA. 1230 o A Quick Mode Exchange to negotiate other security protocol 1231 protection. 1232 This establishes a SA on each end for this protocol. 1233 o Delete the ISAKMP SA and its associated state. 1234 Since the key for use in the non-ISAKMP SA was derived from the 1235 single ephemeral Diffie-Hellman exchange PFS is preserved. 1237 To provide Perfect Forward Secrecy of merely the keys of a non-ISAKMP 1238 security association, it in not necessary to do a phase 1 exchange if 1239 an ISAKMP SA exists between the two peers. A single Quick Mode in 1240 which the optional KE payload is passed, and an additional Diffie- 1241 Hellman exchange is performed, is all that is required. At this point 1242 the state derived from this Quick Mode must be deleted from the 1243 ISAKMP SA as described in section 5.5. 1245 9. Implementation Hints 1247 Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2 1248 negotiations extremely quick. As long as the Phase 1 state remains 1249 cached, and PFS is not needed, Phase 2 can proceed without any 1250 exponentiation. How many Phase 2 negotiations can be performed for a 1251 single Phase 1 is a local policy issue. The decision will depend on 1252 the strength of the algorithms being used and level of trust in the 1253 peer system. 1255 An implementation may wish to negotiate a range of SAs when 1256 performing Quick Mode. By doing this they can speed up the "re- 1257 keying". Quick Mode defines how KEYMAT is defined for a range of SAs. 1258 When one peer feels it is time to change SAs they simply use the next 1259 one within the stated range. A range of SAs can be established by 1260 negotiating multiple SAs (identical attributes, different SPIs) with 1261 one Quick Mode. 1263 An optimization that is often useful is to establish Security 1264 Associations with peers before they are needed so that when they 1265 become needed they are already in place. This ensures there would be 1266 no delays due to key management before initial data transmission. 1267 This optimization is easily implemented by setting up more than one 1268 Security Association with a peer for each requested Security 1269 Association and caching those not immediately used. 1271 Also, if an ISAKMP implementation is alerted that a SA will soon be 1272 needed (e.g. to replace an existing SA that will expire in the near 1273 future), then it can establish the new SA before that new SA is 1274 needed. 1276 The base ISAKMP specification describes conditions in which one party 1277 of the protocol may inform the other party of some activity-- either 1278 deletion of a security association or in response to some error in 1279 the protocol such as a signature verification failed or a payload 1280 failed to decrypt. It is strongly suggested that these Informational 1281 exchanges not be responded to under any circumstances. Such a 1282 condition may result in a "notify war" in which failure to understand 1283 a message results in a notify to the peer who cannot understand it 1284 and sends his own notify back which is also not understood. 1286 10. Security Considerations 1288 This entire draft discusses a hybrid protocol, combining parts of 1289 Oakley and parts of SKEME with ISAKMP, to negotiate, and derive 1290 keying material for, security associations in a secure and 1291 authenticated manner. 1293 Confidentiality is assured by the use of a negotiated encryption 1294 algorithm. Authentication is assured by the use of a negotiated 1295 method: a digital signature algorithm; a public key algorithm which 1296 supports encryption; or, a pre-shared key. The confidentiality and 1297 authentication of this exchange is only as good as the attributes 1298 negotiated as part of the ISAKMP security association. 1300 Repeated re-keying using Quick Mode can consume the entropy of the 1301 Diffie- Hellman shared secret. Implementors should take note of this 1302 fact and set a limit on Quick Mode Exchanges between exponentiations. 1303 This draft does not prescribe such a limit. 1305 Perfect Forward Secrecy (PFS) of both keying material and identities 1306 is possible with this protocol. By specifying a Diffie-Hellman group, 1307 and passing public values in KE payloads, ISAKMP peers can establish 1308 PFS of keys-- the identities would be protected by SKEYID_e from the 1309 ISAKMP SA and would therefore not be protected by PFS. If PFS of both 1310 keying material and identities is desired, an ISAKMP peer MUST 1311 establish only one non-ISAKMP security association (e.g. IPsec 1312 Security Association) per ISAKMP SA. PFS for keys and identities is 1313 accomplished by deleting the ISAKMP SA (and optionally issuing a 1314 DELETE message) upon establishment of the single non-ISAKMP SA. In 1315 this way a phase one negotiation is uniquely tied to a single phase 1316 two negotiation, and the ISAKMP SA established during phase one 1317 negotiation is never used again. 1319 The strength of a key derived from a Diffie-Hellman exchange using 1320 any of the groups defined here depends on the inherent strength of 1321 the group, the size of the exponent used, and the entropy provided by 1322 the random number generator used. Due to these inputs it is difficult 1323 to determine the strength of a key for any of the defined groups. The 1324 default Diffie-Hellman group (number one) when used with a strong 1325 random number generator and an exponent no less than 160 bits is 1326 sufficient to use for DES. Groups two through four provide greater 1327 security. Implementations should make note of these conservative 1328 estimates when establishing policy and negotiating security 1329 parameters. 1331 Note that these limitations are on the Diffie-Hellman groups 1332 themselves. There is nothing in IKE which prohibits using stronger 1333 groups nor is there anything which will dilute the strength obtained 1334 from stronger groups. In fact, the extensible framework of IKE 1335 encourages the definition of more groups; use of elliptical curve 1336 groups will greatly increase strength using much smaller numbers. 1338 For situations where defined groups provide insufficient strength New 1339 Group Mode can be used to exchange a Diffie-Hellman group which 1340 provides the necessary strength. In is incumbent upon implementations 1341 to check the primality in groups being offered and independently 1342 arrive at strength estimates. 1344 It is assumed that the Diffie-Hellman exponents in this exchange are 1345 erased from memory after use. In particular, these exponents must not 1346 be derived from long-lived secrets like the seed to a pseudo-random 1347 generator. 1349 IKE exchanges maintain running initialization vectors (IV) where the 1350 last ciphertext block of the last message is the IV for the next 1351 message. To prevent retransmissions (or forged messages with valid 1352 cookies) from causing exchanges to get out of sync IKE 1353 implementations SHOULD NOT update their running IV until the 1354 decrypted message has passed a basic sanity check and has been 1355 determined to actually advance the IKE state machine-- i.e. it is not 1356 a retransmission. 1358 While the last roundtrip of Main Mode (and optionally the last 1359 message of Aggressive Mode) is encrypted it is not, strictly 1360 speaking, authenticated. An active substitution attack on the 1361 ciphertext could result in payload corruption. If such an attack 1362 corrupts mandatory payloads it would be detected by an authentication 1363 failure, but if it corrupts any optional payloads (e.g. notify 1364 payloads chained onto the last message of a Main Mode exchange) it 1365 might not be detectable. 1367 11. IANA Considerations 1369 This document contains many "magic numbers" to be maintained by the 1370 IANA. This section explains the criteria to be used by the IANA to 1371 assign additional numbers in each of these lists. 1372 11.1 Attribute Classes 1373 Attributes negotiated in this protocol are identified by their class. 1374 Requests for assignment of new classes must be accompanied by a 1375 standards- track RFC which describes the use of this attribute. 1376 11.2 Encryption Algorithm Class 1377 Values of the Encryption Algorithm Class define an encryption 1378 algorithm to use when called for in this document. Requests for 1379 assignment of new encryption algorithm values must be accompanied by 1380 a reference to a standards-track or Informational RFC or a reference 1381 to published cryptographic literature which describes this algorithm. 1382 11.3 Hash Algorithm 1383 Values of the Hash Algorithm Class define a hash algorithm to use 1384 when called for in this document. Requests for assignment of new hash 1385 algorithm values must be accompanied by a reference to a standards- 1386 track or Informational RFC or a reference to published cryptographic 1387 literature which describes this algorithm. Due to the key derivation 1388 and key expansion uses of HMAC forms of hash algorithms in IKE, 1389 requests for assignment of new hash algorithm values must take into 1390 account the cryptographic properties-- e.g it's resistance to 1391 collision-- of the hash algorithm itself. 1392 11.4 Group Description and Group Type 1393 Values of the Group Description Class identify a group to use in a 1394 Diffie-Hellman exchange. Values of the Group Type Class define the 1395 type of group. Requests for assignment of new groups must be 1396 accompanied by a reference to a standards-track or Informational RFC 1397 which describes this group. Requests for assignment of new group 1398 types must be accompanied by a reference to a standards-track or 1399 Informational RFC or by a reference to published cryptographic or 1400 mathmatical literature which describes the new type. 1401 11.5 Life Type 1402 Values of the Life Type Class define a type of lifetime to which the 1403 ISAKMP Security Association applies. Requests for assignment of new 1404 life types must be accompanied by a detailed description of the units 1405 of this type and its expiry. 1406 12. Acknowledgements 1408 This document is the result of close consultation with Hugo Krawczyk, 1409 Douglas Maughan, Hilarie Orman, Mark Schertler, Mark Schneider, and 1410 Jeff Turner. It relies on protocols which were written by them. 1411 Without their interest and dedication, this would not have been 1412 written. 1414 Special thanks Rob Adams, Cheryl Madson, Derrell Piper, Harry Varnis, 1415 and Elfed Weaver for technical input, encouragement, and various 1416 sanity checks along the way. 1418 We would also like to thank the many members of the IPSec working 1419 group that contributed to the development of this protocol over the 1420 past year. 1422 13. References 1424 [Acm97] Adams, C.M., "The CAST-128 Encryption Algorithm", RFC 2144, 1425 May 1997. 1427 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 1428 Requirement Levels", RFC2119, March 1997. 1430 [KBC96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing 1431 for Message Authentication", RFC 2104, February 1997. 1433 [Kra96] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 1434 Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium 1435 on Network and Distributed Systems Security. 1437 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., 1438 "Internet Security Association and Key Management Protocol (ISAKMP)", 1439 version 9, draft-ietf-ipsec-isakmp-09.{ps,txt}. 1441 [Orm96] Orman, H., "The Oakley Key Determination Protocol", version 1442 2, draft-ietf-ipsec-oakley-02.txt 1444 [Pip98] Piper, D., "The Internet IP Security Domain Of Interpretation 1445 for ISAKMP", version 8, draft-ietf-ipsec-ipsec-doi-08.txt. 1447 [Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms, 1448 and Source Code in C", 2nd edition. 1450 Appendix A 1452 This is a list of DES Weak and Semi-Weak keys. The keys come from 1453 [Sch96]. All keys are listed in hexidecimal. 1455 DES Weak Keys 1456 0101 0101 0101 0101 1457 1F1F 1F1F E0E0 E0E0 1458 E0E0 E0E0 1F1F 1F1F 1459 FEFE FEFE FEFE FEFE 1461 DES Semi-Weak Keys 1462 01FE 01FE 01FE 01FE 1463 1FE0 1FE0 0EF1 0EF1 1464 01E0 01E0 01F1 01F1 1465 1FFE 1FFE 0EFE 0EFE 1466 011F 011F 010E 010E 1467 E0FE E0FE F1FE F1FE 1469 FE01 FE01 FE01 FE01 1470 E01F E01F F10E F10E 1471 E001 E001 F101 F101 1472 FE1F FE1F FE0E FE0E 1473 1F01 1F01 0E01 0E01 1474 FEE0 FEE0 FEF1 FEF1 1476 Attribute Assigned Numbers 1478 Attributes negotiated during phase one use the following definitions. 1479 Phase two attributes are defined in the applicable DOI specification 1480 (for example, IPsec attributes are defined in the IPsec DOI), with 1481 the exception of a group description when Quick Mode includes an 1482 ephemeral Diffie-Hellman exchange. Attribute types can be either 1483 Basic (B) or Variable-length (V). Encoding of these attributes is 1484 defined in the base ISAKMP specification as Type/Value (Basic) and 1485 Type/Length/Value (Variable). 1487 Attributes described as basic MUST NOT be encoded as variable. 1488 Variable length attributes MAY be encoded as basic attributes if 1489 their value can fit into two octets. If this is the case, an 1490 attribute offered as variable (or basic) by the initiator of this 1491 protocol MAY be returned to the initiator as a basic (or variable). 1493 Attribute Classes 1495 class value type 1496 ------------------------------------------------------------------- 1497 Encryption Algorithm 1 B 1498 Hash Algorithm 2 B 1499 Authentication Method 3 B 1500 Group Description 4 B 1501 Group Type 5 B 1502 Group Prime/Irreducible Polynomial 6 V 1503 Group Generator One 7 V 1504 Group Generator Two 8 V 1505 Group Curve A 9 V 1506 Group Curve B 10 V 1507 Life Type 11 B 1508 Life Duration 12 V 1509 PRF 13 B 1510 Key Length 14 B 1511 Field Size 15 B 1512 Group Order 16 V 1514 values 17-16383 are reserved to IANA. Values 16384-32767 are for 1515 private use among mutually consenting parties. 1517 Class Values 1519 - Encryption Algorithm 1520 DES-CBC 1 1521 IDEA-CBC 2 1522 Blowfish-CBC 3 1523 RC5-R16-B64-CBC 4 1524 3DES-CBC 5 1525 CAST-CBC 6 1527 values 7-65000 are reserved to IANA. Values 65001-65535 are for 1528 private use among mutually consenting parties. 1530 - Hash Algorithm 1531 MD5 1 1532 SHA 2 1533 Tiger 3 1535 values 4-65000 are reserved to IANA. Values 65001-65535 are for 1536 private use among mutually consenting parties. 1538 - Authentication Method 1539 pre-shared key 1 1540 DSS signatures 2 1541 RSA signatures 3 1542 Encryption with RSA 4 1543 Revised encryption with RSA 5 1545 values 6-65000 are reserved to IANA. Values 65001-65535 are for 1546 private use among mutually consenting parties. 1548 - Group Description 1549 default 768-bit MODP group (section 6.1) 1 1551 alternate 1024-bit MODP group (section 6.2) 2 1553 EC2N group on GP[2^155] (section 6.3) 3 1555 EC2N group on GP[2^185] (section 6.4) 4 1557 values 5-32767 are reserved to IANA. Values 32768-65535 are for 1558 private use among mutually consenting parties. 1560 - Group Type 1561 MODP (modular exponentiation group) 1 1562 ECP (elliptic curve group over GF[P]) 2 1563 EC2N (elliptic curve group over GF[2^N]) 3 1565 values 4-65000 are reserved to IANA. Values 65001-65535 are for 1566 private use among mutually consenting parties. 1568 - Life Type 1569 seconds 1 1570 kilobytes 2 1572 values 3-65000 are reserved to IANA. Values 65001-65535 are for 1573 private use among mutually consenting parties. For a given "Life 1574 Type" the value of the "Life Duration" attribute defines the actual 1575 length of the SA life-- either a number of seconds, or a number of 1576 kbytes protected. 1578 - PRF 1579 There are currently no pseudo-random functions defined. 1581 values 1-65000 are reserved to IANA. Values 65001-65535 are for 1582 private use among mutually consenting parties. 1584 - Key Length 1586 When using an Encryption Algorithm that has a variable length key, 1587 this attribute specifies the key length in bits. (MUST use network 1588 byte order). This attribute MUST NOT be used when the specified 1589 Encryption Algorithm uses a fixed length key. 1591 - Field Size 1593 The field size, in bits, of a Diffie-Hellman group. 1595 - Group Order 1597 The group order of an elliptical curve group. Note the length of 1598 this attribute depends on the field size. 1599 Additional Exchanges Defined-- XCHG values 1600 Quick Mode 32 1601 New Group Mode 33 1603 Appendix B 1605 This appendix describes encryption details to be used ONLY when 1606 encrypting ISAKMP messages. When a service (such as an IPSEC 1607 transform) utilizes ISAKMP to generate keying material, all 1608 encryption algorithm specific details (such as key and IV generation, 1609 padding, etc...) MUST be defined by that service. ISAKMP does not 1610 purport to ever produce keys that are suitable for any encryption 1611 algorithm. ISAKMP produces the requested amount of keying material 1612 from which the service MUST generate a suitable key. Details, such 1613 as weak key checks, are the responsibility of the service. 1615 Use of negotiated PRFs may require the PRF output to be expanded due 1616 to the PRF feedback mechanism employed by this document. For example, 1617 if the (ficticious) DOORAK-MAC requires 24 bytes of key but produces 1618 only 8 bytes of output, the output must be expanded three times 1619 before being used as the key for another instance of itself. The 1620 output of a PRF is expanded by feeding back the results of the PRF 1621 into itself to generate successive blocks. These blocks are 1622 concatenated until the requisite number of bytes has been acheived. 1623 For example, for pre-shared key authentication with DOORAK-MAC as the 1624 negotiated PRF: 1626 BLOCK1-8 = prf(pre-shared-key, Ni_b | Nr_b) 1627 BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni_b | Nr_b) 1628 BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni_b | Nr_b) 1629 and 1630 SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 1632 so therefore to derive SKEYID_d: 1634 BLOCK1-8 = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) 1635 BLOCK9-16 = prf(SKEYID, BLOCK1-8 | g^xy | CKY-I | CKY-R | 0) 1636 BLOCK17-24 = prf(SKEYID, BLOCK9-16 | g^xy | CKY-I | CKY-R | 0) 1637 and 1638 SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 1640 Subsequent PRF derivations are done similarly. 1642 Encryption keys used to protect the ISAKMP SA are derived from 1643 SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long 1644 enough to supply all the necessary keying material an algorithm 1645 requires, the key is derived from feeding the results of a pseudo- 1646 random function into itself, concatenating the results, and taking 1647 the highest necessary bits. 1649 For example, if (ficticious) algorithm AKULA requires 320-bits of key 1650 (and has no weak key check) and the prf used to generate SKEYID_e 1651 only generates 120 bits of material, the key for AKULA, would be the 1652 first 320-bits of Ka, where: 1654 Ka = K1 | K2 | K3 1655 and 1656 K1 = prf(SKEYID_e, 0) 1657 K2 = prf(SKEYID_e, K1) 1658 K3 = prf(SKEYID_e, K2) 1660 where prf is the negotiated prf or the HMAC version of the negotiated 1661 hash function (if no prf was negotiated) and 0 is represented by a 1662 single octet. Each result of the prf provides 120 bits of material 1663 for a total of 360 bits. AKULA would use the first 320 bits of that 1664 360 bit string. 1666 In phase 1, material for the initialization vector (IV material) for 1667 CBC mode encryption algorithms is derived from a hash of a 1668 concatenation of the initiator's public Diffie-Hellman value and the 1669 responder's public Diffie-Hellman value using the negotiated hash 1670 algorithm. This is used for the first message only. Each message 1671 should be padded up to the nearest block size using bytes containing 1672 0x00. The message length in the header MUST include the length of the 1673 pad since this reflects the size of the ciphertext. Subsequent 1674 messages MUST use the last CBC encryption block from the previous 1675 message as their initialization vector. 1677 In phase 2, material for the initialization vector for CBC mode 1678 encryption of the first message of a Quick Mode exchange is derived 1679 from a hash of a concatenation of the last phase 1 CBC output block 1680 and the phase 2 message id using the negotiated hash algorithm. The 1681 IV for subsequent messages within a Quick Mode exchange is the CBC 1682 output block from the previous message. Padding and IVs for 1683 subsequent messages are done as in phase 1. 1685 After the ISAKMP SA has been authenticated all Informational 1686 Exchanges are encrypted using SKEYID_e. The initiaization vector for 1687 these exchanges is derived in exactly the same fashion as that for a 1688 Quick Mode-- i.e. it is derived from a hash of a concatenation of the 1689 last phase 1 CBC output block and the message id from the ISAKMP 1690 header of the Informational Exchange (not the message id from the 1691 message that may have prompted the Informational Exchange). 1693 Note that the final phase 1 CBC output block, the result of 1694 encryption/decryption of the last phase 1 message, must be retained 1695 in the ISAKMP SA state to allow for generation of unique IVs for each 1696 Quick Mode. Each post- phase 1 exchange (Quick Modes and 1697 Informational Exchanges) generates IVs independantly to prevent IVs 1698 from getting out of sync when two different exchanges are started 1699 simultaneously. 1701 In all cases, there is a single bidirectional cipher/IV context. 1702 Having each Quick Mode and Informational Exchange maintain a unique 1703 context prevents IVs from getting out of sync. 1705 The key for DES-CBC is derived from the first eight (8) non-weak and 1706 non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first 1707 8 bytes of the IV material derived above. 1709 The key for IDEA-CBC is derived from the first sixteen (16) bytes of 1710 SKEYID_e. The IV is the first eight (8) bytes of the IV material 1711 derived above. 1713 The key for Blowfish-CBC is either the negotiated key size, or the 1714 first fifty-six (56) bytes of a key (if no key size is negotiated) 1715 derived in the aforementioned pseudo-random function feedback method. 1716 The IV is the first eight (8) bytes of the IV material derived above. 1718 The key for RC5-R16-B64-CBC is the negotiated key size, or the first 1719 sixteen (16) bytes of a key (if no key size is negotiated) derived 1720 from the aforementioned pseudo-random function feedback method if 1721 necessary. The IV is the first eight (8) bytes of the IV material 1722 derived above. The number of rounds MUST be 16 and the block size 1723 MUST be 64. 1725 The key for 3DES-CBC is the first twenty-four (24) bytes of a key 1726 derived in the aforementioned pseudo-random function feedback method. 1727 3DES-CBC is an encrypt-decrypt-encrypt operation using the first, 1728 middle, and last eight (8) bytes of the entire 3DES-CBC key. The IV 1729 is the first eight (8) bytes of the IV material derived above. 1731 The key for CAST-CBC is either the negotiated key size, or the first 1732 sixteen (16) bytes of a key derived in the aforementioned pseudo- 1733 random function feedback method. The IV is the first eight (8) bytes 1734 of the IV material derived above. 1736 Support for algorithms other than DES-CBC is purely optional. Some 1737 optional algorithms may be subject to intellectual property claims. 1739 Authors' Addresses: 1741 Dan Harkins 1742 cisco Systems 1743 170 W. Tasman Dr. 1744 San Jose, California, 95134-1706 1745 United States of America 1746 +1 408 526 4000 1748 Dave Carrel 1749 76 Lippard Ave. 1750 San Francisco, CA 94131-2947 1751 United States of America 1752 +1 415 337 8469 1754 Authors' Note: 1756 The authors encourage independent implementation, and 1757 interoperability testing, of this hybrid protocol.