idnits 2.17.1 draft-ietf-ipsec-isakmp-oakley-02.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-24) 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 26 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The abstract seems to contain references ([Orm96], [MSST96]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 73: '... - MUST...' RFC 2119 keyword, line 78: '... - SHOULD...' RFC 2119 keyword, line 85: '... - MAY...' RFC 2119 keyword, line 101: '... initiator MAY provide multiple p...' RFC 2119 keyword, line 102: '... responder MUST reply with only o...' (36 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 1996) is 10022 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) == Unused Reference: 'Kra96' is defined on line 915, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-ietf-ipsec-hmac-md5 is -00, but you're referring to -01. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-hmac-md5 (ref. 'KBC96') -- Possible downref: Non-RFC (?) normative reference: ref. 'Kra96' == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-isakmp-06 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. 'MSST96') ** 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-00 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-ipsec-doi (ref. 'Pip96') -- Possible downref: Non-RFC (?) normative reference: ref. 'Sch94' Summary: 18 errors (**), 0 flaws (~~), 4 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, Editors 3 INTERNET-DRAFT cisco Systems 4 draft-ietf-ipsec-isakmp-oakley-02.txt November 1996 6 The resolution of ISAKMP with Oakley 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 1. Abstract 29 [MSST96] (ISAKMP) provides a framework for authentication and key 30 exchange but does not define them. ISAKMP is designed to be key 31 exchange independant; that is, it is designed to support many 32 different key exchanges. 34 [Orm96] (Oakley) describes a series of key exchanges-- called 35 "modes"-- and details the services provided by each (e.g. perfect 36 forward secrecy for keys, identity protection, and authentication). 38 This document describes a proposal for using the Oakley Key Exchange 39 Protocol in conjunction with ISAKMP to obtain authenticated keying 40 material for use with ISAKMP, and for other security associations 41 such as AH and ESP for the IETF IPsec DOI. 43 2. Discussion 45 This draft combines ISAKMP and Oakley. The purpose is to negotiate, 46 and provide authenticated keying material for, security associations 47 in a protected manner. 49 Processes which implement this draft can be used for negotiating 50 virtual private networks (VPNs) and also for providing a remote user 51 from a remote site (whose IP address need not be known beforehand) 52 access to a secure host or network. 54 Proxy negotiation is supported. Proxy mode is where the negotiating 55 parties are not the endpoints for which security association 56 negotiation is taking place. When used in proxy mode, the identities 57 of the end parties remain hidden. 59 This proposal does not implement the entire Oakley protocol, but only 60 a subset necessary to satisfy its goals. It does not claim 61 conformance or compliance with the entire Oakley protocol. For 62 greater understanding of the Oakley protocol and the mathematics 63 behind it, please refer to [Orm96]. 65 3. Terms and Definitions 67 3.1 Requirements Terminology 69 In this document, the words that are used to define the significance 70 of each particular requirement are usually capitalised. These words 71 are: 73 - MUST 75 This word or the adjective "REQUIRED" means that the item is an 76 absolute requirement of the specification. 78 - SHOULD 80 This word or the adjective "RECOMMENDED" means that there might 81 exist valid reasons in particular circumstances to ignore this 82 item, but the full implications should be understood and the case 83 carefully weighed before taking a different course. 85 - MAY 87 This word or the adjective "OPTIONAL" means that this item is 88 truly optional. One vendor might choose to include the item 89 because a particular marketplace requires it or because it 90 enhances the product, for example; another vendor may omit the 91 same item. 93 3.2 Notation 95 The following notation is used throughout this draft. 97 HDR is an ISAKMP header whose exchange type is the mode. When 98 writen as HDR* it indicates payload encryption. 100 SA is an SA negotiation payload with one or more proposals. An 101 initiator MAY provide multiple proposals for negotiation; a 102 responder MUST reply with only one. 104 SAp is the entire body of the SA payload (minus the SA header)-- 105 i.e. all proposals and transforms offered by the Initiator. 107 KE is the key exchange payload. 109 Nx is the nonce payload; x can be: i or r for the ISAKMP initiator 110 and responder respectively. 112 IDx is the identity payload for "x". x can be: "ii" or "ir" for 113 the ISAKMP initiator and responder respectively during phase one 114 negotiation; or "ui" or "ur" for the user initiator and responder 115 respectively during phase two. The ID payload format for the 116 Internet DOI is defined in [Pip96]. 118 SIG is the signature payload. The data to sign is exchange- 119 specific. 121 CERT is the certificate payload. 123 HASH is the hash payload. The contents of the hash are exchange 124 specific. 126 prf() is the keyed hash function negotiated as part of the ISAKMP 127 SA. 129 SKEYID_e is the keying material used by the ISAKMP SA to protect 130 it's messages. 132 SKEYID_a is the keying material used by the ISAKMP SA to 133 authenticate it's messages. 135 y indicates that "x" is encrypted with the key "y". 137 --> signifies "initiator to responder" communication (requests). 139 <-- signifies "responder to initiator" communication (replies). 141 | signifies concatenation of information-- e.g. X | Y is the 142 concatentation of X with Y. 144 [x] indicates that x is optional. 146 Payload encryption (when noted by a '*' after the ISAKMP header) MUST 147 begin immediately after the ISAKMP header. When communication is 148 protected, all payloads following the ISAKMP header MUST be 149 encrypted. Encryption keys are generated from SKEYID_e in a manner 150 that is defined for each algorithm. 152 3.3 Perfect Forward Secrecy 154 When used in the draft Perfect Forward Secrecy (PFS) refers to the 155 notion that compromise of a single key will permit access to only 156 data protected by a single key. For PFS to exist the key used to 157 protect transmission of data MUST NOT be used to derive any 158 additional keys, and if the key used to protect transmission of data 159 was derived from some other keying material, that material MUST NOT 160 be used to derive any more keys. 162 Perfect Forward Secrecy for both keys and identities is provided in 163 this protocol. (Sections 5.7 and 7). 165 3.4 Security Association 167 A security association (SA) is a set of policy and key used to 168 protect information. The ISAKMP SA is the shared policy and key used 169 by the negotiating peers in this protocol to protect their 170 communication. 172 4. Introducttion 174 Oakley defines a method to establish an authenticated key exchange. 175 This includes how payloads are constructed, the information they 176 carry, the order in which they are processed and how they are used. 178 While Oakley defines "modes", ISAKMP defines "phases". The 179 relationship between the two is very straightforward. ISAKMP's phase 180 1 is where the two ISAKMP peers establish a secure, authenticated 181 channel with which to communicate. This is called the ISAKMP 182 Security Association (SA). Oakley's "Main Mode" and "Aggressive Mode" 183 each accomplish a phase 1 exchange. "Main Mode" and "Aggressive 184 Mode" MUST ONLY be used in phase 1. 186 Phase 2 is where Security Associations are negotiated on behalf of 187 services such as AH, ESP or any other service which needs key 188 material and/or parameter negotiation. Oakley's "Quick Mode" 189 accomplishes a phase 2 exchange. "Quick Mode" MUST ONLY be used in 190 phase 2. 192 Oakley's "New Group Mode" is not really a phase 1 or phase 2. It 193 follows phase 1, but serves to establish a new group which can be 194 used in future negotiations. "New Group Mode" MUST ONLY be used in 195 phase 2. 197 With the use of ISAKMP phases, an implementation can accomplish very 198 fast keying when necessary. A single phase 1 negotiation may be used 199 for more than one phase 2 negotiation. Additionally a single phase 2 200 negotiation can request multiple Security Associations. With these 201 optimizations, an implementation can see less than one round trip per 202 SA as well as less than one DH exponentiation per SA. "Main Mode" 203 for phase 1 provides identity protection. When identity protection 204 is not needed, "Aggressive Mode" can be used to reduce round trips 205 even further. Developer hints for doing these optimizations are 206 included below. 208 The following attributes are required by Oakley and MUST be 209 negotiated as part of the ISAKMP Security Association. (These 210 attributes pertain only to the ISAKMP Security Association and not to 211 any Security Associations that ISAKMP may be negotiating on behalf of 212 other services.) 214 - encryption algorithm (e.g. DES, IDEA, Blowfish). 216 - hash algorithm (e.g. MD5, SHA) 218 - authentication method (e.g. DSS sig, RSA sig, RSA encryption, 219 pre-shared key) 220 - information about a group over which to do Diffie-Hellman. 222 The selected hash algorithm MUST support both keyed and unkeyed 223 modes. 225 Oakley implementations MUST support the following default attributes: 227 - DES-CBC with a weak, and semi-weak, key check (weak and semi- 228 weak keys are referenced in [Sch94] and listed in Appendix A). The 229 key is derived according to Appendix B. 231 - MD5 and SHA in native and HMAC mode [KBC96]. 233 - Authentication via pre-shared keys. The Digital Signature 234 Standard SHOULD be supported; RSA SHOULD also be supported. 236 - MODP over the default Oakley group (see below). ECP and EC2N 237 groups MAY be supported. 239 The Oakley modes described here MUST be implemented whenever the IETF 240 IPsec DOI [Pip96] is implemented. Other DOIs MAY use the Oakley modes 241 described here. 243 5. Exchanges 245 There are two basic methods used to establish an authenticated key 246 exchange: Oakley Main Mode and Oakley Aggressive Mode. Each generates 247 authenticated keying material from an ephemeral Diffie-Hellman 248 exchange. Oakley in Main Mode MUST be implemented; Oakley Aggressive 249 Mode SHOULD be implemented. In addition, Oakley Quick Mode MUST be 250 implemented as a mechanism to generate fresh keying material and 251 negotiate non-ISAKMP security services. In additon, Oakley New Group 252 Mode SHOULD be implemented as a mechanism to define private groups 253 for Diffie-Hellman exchanges. Implementations MUST NOT switch 254 exchange types in the middle of an exchange. 256 Exchanges conform to standard ISAKMP [MSST96] payload syntax. 257 attribute encoding, timeouts and retransmits of messages, and 258 informational messages-- e.g a notify response is sent when, for 259 example, a proposal is unacceptable, or a signature verification or 260 decryption was unsuccessful, etc. 262 Oakley Main Mode is an instantiation of the ISAKMP Identity Protect 263 Exchange: The first two messages negotiate policy; the next two 264 exchange Diffie-Hellman public values and ancillary data (e.g. 265 nonces) necessary for the exchange; and the last two messages 266 authenticate the Diffie-Hellman Exchange. The authentication method 267 negotiated as part of the initial ISAKMP exchange influences the 268 composition of the payloads but not their purpose. The XCHG for 269 Oakley Main Mode is ISAKMP Identity Protect. 271 Similarly, Oakley Aggressive Mode is an instantiation of the ISAKMP 272 Base Exchange. The first two messages negotiate policy, exchange 273 Diffie-Hellman public values and ancillary data necessary for the 274 exchange, and identities. In addition the second message 275 authenticates the responder. The third message authenticates the 276 initiator and provides a proof of participation in the exchange. The 277 XCHG for Oakley Aggressive Mode is ISAKMP Base Exchange. The final 278 message is not sent under protection of the ISAKMP SA allowing each 279 party to postpone exponentiation, if desired, until negotiation of 280 this exchange is complete. 282 The result of either exchange is two groups of authenticated keying 283 material: 285 SKEYID_e = prf(g^xy, CKY-I | CKY-R | Ni | Nr | 0) 286 SKEYID_a = prf(g^xy, CKY-I | CKY-R | Ni | Nr | 1) 288 and agreed upon policy to protect further communications. The values 289 of 0 and 1 above are represented by a single octet. The key used for 290 encryption is derived from SKEYID_e in an algorithm-specific manner 291 (see appendix B). 293 Quick Mode and New Group Mode have no analog in ISAKMP. The XCHG 294 values for Quick Mode and New Group Mode are defined in Appendix A. 296 As mentioned above, the negotiated authentication method influences 297 the content and use of messages for Phase 1 Oakley Modes, but not 298 their intent. When using public keys for authentication, the Phase 1 299 Oakley can be accomplished either by using signatures or by using 300 public key encryption (if the algorithm supports it). Following are 301 Main Mode Exchanges with different authentication options. 303 5.1 ISAKMP/Oakley Phase 1 Authenticated With Signatures 305 Using signatures, the ancillary information exchanged during the 306 second roundtrip are nonces; the exchange is authenticated by signing 307 a mutually obtainable hash. Oakley Main Mode with signature 308 authentication is described as follows: 310 Initiator Responder 311 ---------- ----------- 312 HDR, SA --> 313 <-- HDR, SA 314 HDR, KE, Ni --> 315 <-- HDR, KE, Nr 316 HDR*, IDii, [ CERT, ] SIG --> 317 <-- HDR*, IDir, [ CERT, ] SIG 319 Oakley Aggressive mode with signatures in conjunction with ISAKMP is 320 described as follows: 322 Initiator Responder 323 ----------- ----------- 324 HDR, SA, KE, Ni, IDii --> 325 <-- HDR, SA, KE, Nr, IDir, 326 [ CERT, ] SIG 327 HDR, [ CERT, ] SIG --> 329 In both modes, the signed data in SIG is a signature of a keyed hash 330 of the concatenation of the nonces, cookies, the entire SA offer-- 331 everything following the SA header-- that was sent from Initiator to 332 Responder, and the sender's ID, with g^xy as the key to the hash 333 function. The order of the nonces, and cookies are specific to the 334 direction. In other words, the sender signs, HASH_I, and the 335 responder signs HASH_R where: 337 HASH_I = prf(g^xy, Ni | Nr | CKY-I | CKY-R | SAp | IDii)) 338 HASH_R = prf(g^xy, Nr | Ni | CKY-R | CKY-I | SAp | IDir)) 340 In general the keyed hash will be the HMAC version of the negotiated 341 hash function. This can be overridden for construction of the 342 signature if the signature algorithm is tied to a particular hash 343 algorithm. In this case, the negotiated hash function would continue 344 to be used for all other proscribed hashing functions. 346 One or more certificate payloads MAY be optionally passed. 348 5.2 Oakley Phase 1 Authenticated With Public Key Encryption 350 Using public key encryption to authenticate the exchange, the 351 ancillary information exchanged is encrypted nonces. Each party's 352 ability to reconstruct a hash (proving that the other party decrypted 353 the nonce) authenticates the exchange. 355 In order to perform the public key encryption, the initiator must 356 already have the responder's public key. In the case where a party 357 has multiple public keys, a hash of the certificate the initiator is 358 using to encrypt the ancillary information is passed as part of the 359 third message. In this way the responder can determine which 360 corresponding private key to use to decrypt the nonce and identity 361 protection is retained. 363 In addition, the identities of the parties (IDii and IDir) are also 364 encrypted with the other parties public key. If the authentication 365 method is public key encryption, the nonce and identity payloads MUST 366 be encrypted with the public key of the other party. 368 When using encrytion for authentication with Oakley, Main Mode is 369 defined as follows. 371 Initiator Responder 372 ----------- ----------- 373 HDR, SA --> 374 <-- HDR, SA 375 HDR, KE, [ HASH(1), ] 376 PubKey_r, 377 PubKey_r --> 378 HDR, KE, PubKey_r, 379 <-- PubKey_i 380 HDR*, HASH_I --> 381 <-- HDR*, HASH_R 383 Oakley Aggressive Mode authenticated with encryption is described as 384 follows: 386 Initiator Responder 387 ----------- ----------- 388 HDR, SA, [ HASH(1),] KE, 389 Pubkey_r, 390 PubKey_r --> 391 HDR, SA, KE, PubKey_i, 392 <-- IDir, HASH_R 393 HDR, HASH_I --> 395 Where HASH(1) is a hash (using the negotiated hash function) of the 396 certificate which the initiator is using to encrypt the nonce and 397 identity. The contents of the other hashes (HASH_I and HASH_R) are 398 the results of the HMAC version of the hash algorithm negotiated in 399 the first roundtrip, with a concatenation of the nonces as the key 400 and a concatenation of the shared secret, the cookies, the entire SA 401 offer-- everything following the SA header-- that was sent from 402 Initiator to Responder, and the sender's ID as the hashed data. The 403 order of the nonces and cookies are specific to the direction. In 404 other words: 406 HASH_I = prf(Ni | Nr, g^xy | CKY-I | CKY-R | SAp | IDii)) 407 HASH_R = prf(Nr | Ni, g^xy | CKY-R | CKY-I | SAp | IDir)) 409 Using encryption for authentication provides for a plausably deniable 410 exchange. There is no proof (as with a digital signature) that the 411 conversation ever took place since each party can completely 412 reconstruct both sides of the exchange. 414 Note that, unlike other authentication methods, authentication with 415 public key encryption allows for identity protection with Aggressive 416 Mode. 418 5.3 Oakley Phase 1 Authenticated With a Pre-Shared Key 420 A key derived by some out-of-band mechanism may also be used to 421 authenticate the exchange. The actual establishment of this key is 422 out of the scope of this document. 424 When doing a pre-shared key authentication with Oakley, Main Mode is 425 defined as follows 427 Initiator Responder 428 ---------- ----------- 429 HDR, SA --> 430 <-- HDR, SA 431 HDR, KE, Ni --> 432 <-- HDR, KE, Nr 433 HDR*, IDii, HASH_I --> 434 <-- HDR*, IDir, HASH_R 436 Oakley Aggressive mode with a pre-shared key is described as follows: 438 Initiator Responder 439 ----------- ----------- 440 HDR, SA, KE, Ni, IDii --> 441 <-- HDR, SA, KE, Nr, IDir, HASH_R 442 HDR, HASH_I --> 444 The hash is the result of the HMAC version of the hash algorithm 445 negotiated in the first roundtrip with the pre-shared key as the key 446 to the HMAC, and a concatenation of the shared secret, the nonces, 447 the cookies, the complete SA offer-- everything following the SA 448 header-- sent from Initiator to Responder, and the sender's ID. The 449 order of the cookies and nonces are specific to the direction. In 450 other words, 452 HASH_I = prf(pre-shared-key, g^xy | Ni | Nr | CKY-I | CKY-R | SAp 453 | IDii) 454 HASH_R = prf(pre-shared-key, g^xy | Nr | Ni | CKY-R | CKY-I | SAp 455 | IDir) 457 5.4 Oakley Phase 2 - Quick Mode 459 Oakley Quick Mode is not a complete exchange itself, but is used as 460 part of the ISAKMP SA negotiation process (phase 2) to derive keying 461 material and negotiate shared policy for non-ISAKMP SAs. The 462 information exchanged along with Oakley Quick Mode MUST be protected 463 by the ISAKMP SA-- i.e. all payloads except the ISAKMP header are 464 encrypted. 466 Quick Mode is essentially an exchange of nonces that provides replay 467 protection. The nonces are used to generate fresh key material and 468 prevent replay attacks from generating bogus security associations. 469 An optional Key Exchange payload can be exchanged to allow for an 470 additional Diffie-Hellman exchange and exponentiation per Quick Mode. 471 While use of the key exchange payload with Quick Mode is optional it 472 MUST be supported. 474 Base Quick Mode (without the KE payload) refreshens the keying 475 material derived from the exponentiation in phase 1. This does not 476 provide PFS. Using the optional KE payload, an additional 477 exponentiation is performed and PFS is provided for the keying 478 material. If a KE payload is sent, a Diffie-Hellman group (see 479 section 5.5.1 and Appendix A) MUST be sent as attributes of the SA 480 being negotiated. 482 Quick Mode is defined as follows: 484 Initiator Responder 485 ----------- ----------- 486 HDR*, HASH(1), SA, Ni 487 [, KE ] [, IDui, IDur ] --> 488 <-- HDR*, HASH(2), SA, Nr 489 [, KE ] [, IDui, IDur ] 490 HDR*, HASH(3) --> 492 Where: 493 HASH(1) and HASH(2) are keyed hashes of the entire message that 494 follows the hash including payload headers, and HASH(3)-- for 495 liveliness-- is a keyed hash of the value zero represented as a 496 single octet, followed by a concatenation of the two nonces. For 497 example, the hashes for the above exchange would be: 499 HASH(1) = prf( SKEYID_a, SA | Ni [ | KE ] [ | IDui | IDur ] ) 500 HASH(2) = prf( SKEYID_a, SA | Nr [ | KE ] [ | IDui | IDur ] ) 501 HASH(3) = prf( SKEYID_a, 0 | Ni | Nr ) 503 If PFS is not needed, and KE payloads are not exchanged, the new 504 keying material is defined as KEYMAT = prf(SKEYID_e, Ni | Nr | 0). 506 If PFS is desired and KE payloads were exchanged, the new keying 507 material is defined as KEYMAT = prf(g(qm)^xy, Ni | Nr | 0), where 508 g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman 509 exchange of this Quick Mode. 511 In either case, 0 is represented by a single octet. 513 For situations where the amount of keying material desired is greater 514 than that supplied by the prf, KEYMAT is expanded by concatenation 515 and rehashing with a monotonically increasing number represented by a 516 single octet, i.e. 518 KEYMAT = prf(SKEYID_e, Ni | Nr | 0) | prf(SKEYID_e, Ni | Nr | 1) 519 ... 521 repeated until the required keying material has been reached. 523 This keying material (whether with PFS or without, and whether 524 derived directly or through concatenation) MUST be used with the 525 negotiated SA. It is up to the service to define how keys are derived 526 from the keying material (see Appendix B). 528 In the case of an ephemeral Diffie-Hellman exchange in Quick Mode, 529 the exponential (g(qm)^xy) is irretreivably removed from the current 530 state and SKEYID_e and SKEYID_a (derived from phase 1 negotiation) 531 continue to protect and authenticate the ISAKMP SA. 533 If ISAKMP is acting as a proxy negotiator on behalf of another party 534 the identities of the parties MUST be passed as IDui and IDur. Local 535 policy will dictate whether the proposals are acceptible for the 536 identities specified. If IDs are not exchanged, the negotiation is 537 assumed to be done on behalf of each ISAKMP peer. If an ID range 538 (see Appendix A of [Pip96]) is not acceptable (for example, the 539 specified subnet is too large) a BAD_ID_RANGE notify message followed 540 by an acceptible ID range, in an ID payload, MUST be sent. 542 Using Quick Mode, multiple SA's and keys can be negotiated with one 543 exchange as follows: 545 Initiator Responder 546 ----------- ----------- 547 HDR*, HASH(1), SA0, SA1, Ni, 548 [, KE ] [, IDui, IDur ] --> 549 <-- HDR*, HASH(2), SA0, SA1, Nr, 550 [, KE ] [, IDui, IDur ] 551 HDR*, HASH(3) --> 553 and the keying material for SAx is prf(SKEYID_e, Ni | Nr | x) where x 554 is the number of the SA negotiated (starting with zero). (In the case 555 where one, or all, of the SAs required keys longer than that supplied 556 by the prf, the number merely monotonically increases for this entire 557 exchange-- e.g. SA0 uses 0 and 1; SA1 uses 2 and 3; etc). For ease of 558 processing the HASH payloads MUST immediately follow the ISAKMP 559 header and precede all other payloads. 561 5.4 Oakley New Group Mode 563 Oakley New Group Mode MUST NOT be used prior to establishment of an 564 ISAKMP SA. The description of a new group MUST only follow phase 1 565 negotiation. (It is not a phase 2 exchange, though). 567 Initiator Responder 568 ----------- ----------- 569 HDR*, HASH(1), SA --> 570 <-- HDR*, HASH(2), SA 572 where HASH(1) is a keyed hash, using SKEYID_a as the key, and the 573 entire SA proposal, body and header, as the data; HASH(2) is a keyed 574 hash, using SKEYID_a as the key, and the reply as the data. 576 The proposal will be an Oakley proposal which specifies the 577 characteristics of the group (see appendix A, "Oakley Attribute 578 Assigned Numbers"). Group descriptions for private Oakley Groups MUST 579 be greater than or equal to 2^15. If the group is not acceptable, 580 the responder MUST reply with a Notify payload with the message type 581 set to GROUP_NOT_ACCEPTABLE (13). 583 ISAKMP implementations MAY require private groups to expire with the 584 SA under which they were established. 586 Groups may be directly negotiated in the SA proposal with Oakley Main 587 Mode. To do this the Prime, Generator, and Group Type are passed as 588 SA attributes (see Appendix A in [MSST96]). Alternately, the nature 589 of the group can be hidden using Oakley New Group Mode and only the 590 group identifier is passed in the clear during Main Mode. 592 5.5 Oakley Groups 594 [Orm96] defines several groups. The value 0 indicates no group. The 595 value 1 indicates the default group described below. The attriute 596 class for "Group" is defined in Appendix A. Other values are also 597 defined in [Orm96]. All values 2^15 and higher are used for private 598 group identifiers. 600 5.5.1 Oakley Default Group 602 Oakley implementations MUST support a MODP group with the following 603 prime and generator. This group is assigned id 1 (one). 605 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 606 Its hexadecimal value is 608 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 609 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 610 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 611 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 613 The generator is: 2. 615 other groups can be defined using Oakley New Group Mode. This default 616 group was generated by Richard Schroeppel at the University of 617 Arizona. Properties of this prime are described by the following 618 exerpt from [Orm96]: 620 The prime for this group was selected to have certain 621 properties. The high order 64 bits are forced to 1. This 622 helps the classical remainder algorithm, because the trial 623 quotient digit can always be taken as the high order word of 624 the dividend, possibly +1. The low order 64 bits are forced to 625 1. This helps the Montgomery-style remainder algorithms, 626 because the multiplier digit can always be taken to be the low 627 order word of the dividend. The middle bits are taken from the 628 binary expansion of pi. This guarantees that they are 629 effectively random, while avoiding any suspicion that the 630 primes have secretly been selected to be weak. 632 The prime is chosen to be a Sophie-Germain prime (i.e., (P-1)/2 633 is also prime), to have the maximum strength against the 634 square-root attack. The starting trial numbers were repeatedly 635 incremented by 2^64 until suitable primes were located. 637 Because this prime is congruent to 7 (mod 8), 2 is a quadratic 638 residue. All powers of 2 will also be quadratic residues. 639 This prevents an opponent from learning the low order bit of 640 the Diffie-Hellman exponent. Using 2 as a generator is 641 efficient for some modular exponentiation algorithms. [Note 642 that 2 is technically not a generator in the number theory 643 sense, because it omits half of the possible residues mod P. 644 From a cryptographic viewpoint, this is a virtue.] 646 A further discussion of the properties of this group, the motivation 647 behind its creation, as well as the definition of several more groups 648 can be found in [Orm96]. 650 5.6 Payload Explosion for Complete ISAKMP-Oakley Exchange 652 This section illustrates how ISAKMP payloads are used with Oakley to: 654 - establish a secure and authenticated channel between ISAKMP 655 processes (phase 1); and 657 - generate key material for, and negotiate, an IPsec SA (phase 2). 659 5.6.1 Phase 1 using Oakley Main Mode 661 The following diagram illustrates the payloads exchanged between the 662 two parties in the first round trip exchange. The initiator MAY 663 propose several proposals; the responder MUST reply with one. 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 ~ ISAKMP Header with XCHG of Oakley Main Mode, ~ 668 ~ and Next Payload of ISA_SA ~ 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 ! ISA_PROP ! RESERVED ! Payload Length ! 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 ! Domain of Interpretation (IPsec DOI) ! 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 ! Situation ! 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 ! ISA_TRANS ! RESERVED ! Payload Length ! 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 ! Proposal #1 ! Proto=ISAKMP ! # of Transforms ! 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 ~ SPI (8 octets) ~ 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 ! ISA_TRANS ! RESERVED ! Payload Length ! 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 ! Transform #1 ! RESERVED | OAKLEY ! 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 ~ preffered SA attributes ~ 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 ! 0 ! RESERVED ! Payload Length ! 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 ! Transform #2 ! RESERVED | OAKLEY ! 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 ~ alternate SA attributes ~ 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 The responder replies in kind but selects, and returns, one transform 696 proposal (the ISAKMP SA attributes). 698 The second exchange consists of the following payloads: 700 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 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 ~ ISAKMP Header with XCHG of Oakley Main Mode, ~ 703 ~ and Next Payload of ISA_KE ~ 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 ! ISA_NONCE ! RESERVED ! Payload Length ! 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 ~ D-H Public Value (g^x from initiator g^y from responder) ~ 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 ! 0 ! RESERVED ! Payload Length ! 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 ~ Ni (from initiator) or Nr (from responder) ~ 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 The shared keys, SKEYID_e and SKEYID_a, are now used to protect and 715 authenticate all further communication. Note that both SKEYID_e and 716 SKEYID_a are unauthenticated. 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 ~ ISAKMP Header with XCHG of Oakley Main Mode, ~ 721 ~ and Next Payload of ISA_ID and the encryption bit set ~ 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 ! ISA_SIG ! RESERVED ! Payload Length ! 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 ~ Identification Data of the ISAKMP negotiator ~ 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 ! 0 ! RESERVED ! Payload Length ! 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 ~ signature verified by the public key of the ID above ~ 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 The key exchange is authenticated over a signed hash as described in 733 section 5.1. Once the signature has been verified using the 734 authentication algorithm negotiated as part of the ISAKMP SA, the 735 shared keys, SKEYID_e and SKEYID_a can be marked as authenticated. 736 (For brevity, certificate payloads were not exchanged). 738 5.6.2 Phase 2 using Oakley Quick Mode 740 The following payloads are exchanged in the first round of Oakley 741 Quick Mode with ISAKMP SA negotiation. In this hypothetical exchange, 742 the ISAKMP negotiators are proxies for other parties which have 743 requested authentication. 745 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 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 ~ ISAKMP Header with XCHG of Oakley Quick Mode, ~ 748 ~ Next Payload of ISA_HASH and the encryption bit set ~ 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 ! ISA_SA ! RESERVED ! Payload Length ! 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 ~ keyed hash of message ~ 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 ! ISA_PROP ! RESERVED ! Payload Length ! 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 ! Domain Of Interpretation (DOI) ! 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 ! Situation ! 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 ! ISA_TRANS ! RESERVED ! Payload Length ! 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 ! Proposal #1 ! Protocol=AH ! # of Transforms ! 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 ~ SPI (8 octets) ~ 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 ! ISA_TRANS ! RESERVED ! Payload Length ! 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 ! Transform #1 ! RESERVED | SHA ! 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 ! other SA attributes ! 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 ! ISA_NONCE ! RESERVED ! Payload Length ! 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 ! Transform #1 ! RESERVED | MD5 ! 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 ! other SA attributes ! 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 ! ISA_ID ! RESERVED ! Payload Length ! 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 ~ nonce ~ 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 ! ISA_ID ! RESERVED ! Payload Length ! 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 ~ ID of source for which ISAKMP is a proxy ~ 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 ! 0 ! RESERVED ! Payload Length ! 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 ~ ID of destination for which ISAKMP is a proxy ~ 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 where the contents of the hash are described in 5.4 above. The 792 responder replies with a similar message which only contains one 793 transform-- the selected AH transform. Upon receipt, the initiator 794 can provide the key engine with the negotiated security association 795 and the keying material. As a check against replay attacks, the 796 responder waits until receipt of the next message. 798 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 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 ~ ISAKMP Header with XCHG of Oakley Quick Mode, ~ 801 ~ Next Payload of ISA_HASH and the encryption bit set ~ 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 ! 0 ! RESERVED ! Payload Length ! 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 ~ hash data ~ 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 where the contents of the hash are described in 5.4 above. 810 5.7 Perfect Forward Secrecy Example 811 This protocol can provide PFS of both keys and identities. The 812 identies of both the ISAKMP negotiating peer and, if applicable, the 813 proxy for whom the peers are negotiating can be protected with PFS. 815 To provide Perfect Forward Secrecy of both keys and all identities, 816 two parties would perform the following: 818 o A Main Mode Exchange to protect the identities of the ISAKMP 819 peers. 820 This establishes an ISAKMP SA. 821 o A Quick Mode Exchange to negotiate other security protocol 822 protection. 823 This establishes a SA on each end for this protocol. 824 o Delete the ISAKMP SA and its associated state. 826 Since the key for use in the non-ISAKMP SA was derived from the 827 single ephemeral Diffie-Hellman exchange PFS is preserved. 829 To provide Perfect Forward Secrecy of merely the keys of a non-ISAKMP 830 security association, it in not necessary to do a phase 1 exchange if 831 an ISAKMP SA exists between the two peers. A single Quick Mode in 832 which the optional KE payload is passed, and an additional Diffie- 833 Hellman exchange is performed, is all that is required. At this point 834 the state derived from this Quick Mode must be deleted from the 835 ISAKMP SA as described in section 5.4. 837 6. Implementation Hints 839 Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2 840 negotiations extremely quick. As long as the Phase 1 state remains 841 cached, and PFS is not needed, Phase 2 can proceed without any 842 exponentiation. How many Phase 2 negotiations can be performed for a 843 single Phase 1 is a local policy issue. The decision will depend on 844 the strength of the algorithms being used and level of trust in the 845 peer system. 847 An implementation may wish to negotiate a range of SAs when 848 performing Quick Mode. By doing this they can speed up the "re- 849 keying". Quick Mode defines how KEYMAT is defined for a range of SAs. 850 When one peer feels it is time to change SAs they simple use the next 851 one within the stated range. A range of SAs can be established by 852 negotiating multiple SAs (identical attributes, different SPIs) with 853 one Quick Mode. 855 An optimization that is often useful is to establish Security 856 Associations with peers before they are needed so that when they 857 become needed they are already in place. This ensures there would be 858 no delays due to key management before initial data transmission. 859 This optimization is easily implemented by setting up more than one 860 Security Association with a peer for each requested Security 861 Association and caching those not immediately used. 863 Also, if ISAKMP is implementation is alerted that a SA will soon be 864 needed (e.g. to replace an existing SA that will expire in the near 865 future), then it can establish the new SA before that new SA is 866 needed. 868 7. Security Considerations 870 This entire draft discusses a hybrid protocol, combining Oakley with 871 ISAKMP, to negotiate, and derive keying material for, security 872 associations in a secure and authenticated manner. 874 Confidentiality is assured by the use of a negotiated encryption 875 algorithm. Authentication is assured by the use of a negotiated 876 method: a digital signature algorithm; a public key algorithm which 877 supports encryption; or, a pre-shared key. The confidentiality and 878 authentication of this exchange is only as good as the attributes 879 negotiated as part of the ISAKMP security association. 881 Repeated re-keying using Quick Mode can consume the entropy of the 882 Diffie- Hellman shared secret. Implementors should take note of this 883 fact and set a limit on Quick Mode Exchanges between exponentiations. 884 This draft does not proscribe such a limit. 886 Perfect Forward Secrecy (PFS) of both keying material and identities 887 is possible with this protocol. By specifying a Diffie-Hellman group, 888 and passing public values in KE payloads, ISAKMP peers can establish 889 PFS of keys-- the identities would be protected by SKEYID_e from the 890 ISAKMP SA and would therefore not be protected by PFS. If PFS of both 891 keying material and identities is desired, an ISAKMP peer MUST 892 establish only one non-ISAKMP security association (e.g. IPsec 893 Security Association) per ISAKMP SA. PFS for keys and identities is 894 accomplished by deleting the ISAKMP SA (and optionally issuing a 895 DELETE message) upon establishment of the single non-ISAKMP SA. In 896 this way a phase one negotiation is uniquely tied to a single phase 897 two negotiation, and the ISAKMP SA established during phase one 898 negotiation is never used again. 900 8. Acknowledgements 902 This document is the result of close consultation with Hilarie Orman, 903 Douglas Maughan, Mark Schertler, Mark Schneider, and Jeff Turner. It 904 relies completely on protocols which were written by them. Without 905 their interest and dedication, this would not have been written. 907 We would also like to thank Cheryl Madson, Harry Varnis, Elfed 908 Weaver, and Hugo Krawcyzk for technical input. 910 9. References 912 [KBC96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing 913 for Message Authentication", draft-ietf-ipsec-hmac-md5-01.txt 915 [Kra96] Krawcyzk, H., "SKEME: A Versatile Secure Key Exchange 916 Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium 917 on Network and Distributed Systems Security. 919 [MSST96] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., 920 "Internet Security Association and Key Management Protocol (ISAKMP)", 921 version 6, draft-ietf-ipsec-isakmp-06.{ps,txt}. 923 [Orm96] Orman, H., "The Oakley Key Determination Protocol", version 924 1, draft-ietf-ipsec-oakley-01.txt. 926 [Pip96] Piper, D., "The Internet IP Security Domain Of Interpretation 927 for ISAKMP", version 1, draft-ietf-ipsec-ipsec-doi-00.txt. 929 [Sch94] Schneier, B., "Applied Cryptography, Protocols, Algorithms, 930 and Source Code in C", 1st edition. 932 Appendix A 934 This is a list of DES Weak and Semi-Weak keys. The keys come from 935 [Sch94]. All keys are listed in hexidecimal. 937 DES Weak Keys 938 0101 0101 0101 0101 939 1F1F 1F1F E0E0 E0E0 940 E0E0 E0E0 1F1F 1F1F 941 FEFE FEFE FEFE FEFE 943 DES Semi-Weak Keys 944 01FE 01FE 01FE 01FE 945 1FE0 1FE0 0EF1 0EF1 946 01E0 01E0 01F1 01F1 947 1FFE 1FFE 0EFE 0EFE 948 011F 011F 010E 010E 949 E0FE E0FE F1FE F1FE 951 FE01 FE01 FE01 FE01 952 E01F E01F F10E F10E 953 E001 E001 F101 F101 954 FE1F FE1F FE0E FE0E 955 1F01 1F01 0E01 0E01 956 FEE0 FEE0 FEF1 FEF1 958 Attribute Assigned Numbers 960 Attributes negotiated during phase one use the following definitions. Phase 961 two attributes are defined in the applicable DOI specification (for example, 962 IPsec attributes are defined in the IPsec DOI), with the exception of a group 963 description when Quick Mode includes an ephemeral Diffie-Hellman exchange. 964 Attribute types can be either Basic (B) or Variable-length (V). Encoding of 965 these attributes is defined in the base ISAKMP specification. 967 Attribute Classes 969 class value type 970 --------------------------------------------------------------------------- 971 Encryption Algorithm 1 B 972 Hash Algorithm 2 B 973 Authentication Method 3 B 974 Group Description 4 B 975 Group Type 5 B 976 Group Prime 6 V 977 Group Generator One 7 V 978 Group Generator Two 8 V 979 Group Curve A 9 V 980 Group Curve B 10 V 981 Life Type 11 B 982 Life Duration 12 B/V 984 Class Values 986 Encryption Algorithm 987 DEC-CBC 1 988 IDEA-CBC 2 989 Blowfish-CBC 3 991 values 4-65000 are reserved. Values 65001-65535 are for 992 private use among mutually consenting parties. 994 Hash Algorithm 995 MD5 1 996 SHA 2 997 Tiger 3 999 values 4-65000 are reserved. Values 65001-65535 are for 1000 private use among mutually consenting parties. 1002 Authentication Method 1003 pre-shared key 1 1004 DSS signatures 2 1005 RSA signatures 3 1006 RSA encryption 4 1008 values 5-65000 are reserved. Values 65001-65535 are for 1009 private use among mutually consenting parties. 1011 Group Description 1012 default group (section 5.5.1) 1 1014 values 2-32767 are reserved. Values 32768-65535 are for 1015 private use among mutually consenting parties. 1017 Group Type 1018 MODP (modular exponentiation group) 1 1019 ECP (elliptic curve group) 2 1021 Life Type 1022 seconds 1 1023 kilobytes 2 1025 values 3-65000 are reserved. Values 65001-65535 are for 1026 private use among mutually consenting parties. For a given "Life Type" 1027 the value of the "Life Duration" attribute defines the actual length of 1028 the SA life-- either a number of seconds, or a number of kbytes protected. 1030 Additional Exchanges Defined-- XCHG values 1031 Quick Mode 32 1032 New Group Mode 33 1034 Appendix B 1036 Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in 1037 an algorithm-specific manner. When SKEYID_e is not long enough to supply all 1038 the necessary keying material an algorithm requires, the key is derived from 1039 a concatenation of SKEYID_e and successive keyed hashes of a single 1040 character which contains a monotonically increasing counter beginning at 1041 one (1), and SKEYID_e as the key, using the negotiated hash function. 1043 For example, if (ficticious) algorithm AKULA requires 320-bits of key (and 1044 has no weak key check) and the prf used to generate SKEYID_e only generates 1045 120 bits of material, the key for AKULA, would be the first 320-bits of 1046 Ka, where: 1048 Ka = SKEYID_e | prf(SKEYID_e | 1) | prf(SKEYID_e | 2) 1050 where prf is the HMAC version of the negotiated hash function. SKEYID_e 1051 provides 120-bits, and each of the two additional hashes provide 120-bits, 1052 for a total of 360 bits. 1054 Material for the initialization vector (IV material) for CBC mode encryption 1055 algorithms is derived from a hash of a concatenation of the initiator's 1056 public Diffie-Hellman value and the responder's public Diffie-Hellman value 1057 using the negotiated hash algorithm. 1059 The key for DES-CBC is derived from the first eight (8) non-weak and 1060 semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first 8 bytes 1061 of the IV material derived above. 1063 The key for IDEA-CBC is derived from the first sixteen (16) bytes of SKEYID_e. 1064 The IV is the first 8 bytes of the IV material derived above. 1066 The key for Blowfish-CBC is derived from the first fifty-six (56) bytes of 1067 a key derived in the method described above, by concatenating successive 1068 hashes onto SKEYID_e until the requesite number of bytes has been achieved. 1069 The IV is the first 8 bytes of the IV material derived above. 1071 Editors' Addresses: 1073 Dan Harkins 1074 Dave Carrel 1075 cisco Systems 1076 170 W. Tasman Dr. 1077 San Jose, California, 95134-1706 1078 United States of America 1079 +1 408 526 4000 1081 Editors' Note: 1083 The editors encourage independent implementation, and 1084 interoperability testing, of this hybrid exchange.