idnits 2.17.1 draft-ietf-ipsec-isakmp-oakley-03.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-25) 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. ** 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...' (46 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Implementations SHOULD not use Diffie-Hellman exponents of less than 200 bits to avoid adversely effecting the security of both parties. -- 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 (February 1997) is 9931 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'ACM97' is defined on line 973, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ACM97' -- 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-07 ** 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-02 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-ipsec-doi (ref. 'Pip96') -- Possible downref: Non-RFC (?) normative reference: ref. 'Sch94' Summary: 17 errors (**), 0 flaws (~~), 5 warnings (==), 7 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-03.txt February 1997 5 Expire in six months 7 The resolution of ISAKMP with Oakley 8 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and working groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inapproporiate to use Internet Drafts as reference 20 material or to cite them other than as "work in progress." 22 To learn the current status of any Internet Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Australia), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 1. Abstract 30 [MSST96] (ISAKMP) provides a framework for authentication and key 31 exchange but does not define them. ISAKMP is designed to be key 32 exchange independant; that is, it is designed to support many 33 different key exchanges. 35 [Orm96] (Oakley) describes a series of key exchanges-- called 36 "modes"-- and details the services provided by each (e.g. perfect 37 forward secrecy for keys, identity protection, and authentication). 39 This document describes a proposal for using the Oakley Key Exchange 40 Protocol in conjunction with ISAKMP to obtain authenticated keying 41 material for use with ISAKMP, and for other security associations 42 such as AH and ESP for the IETF IPsec DOI. 44 2. Discussion 46 This draft combines ISAKMP and Oakley. The purpose is to negotiate, 47 and provide authenticated keying material for, security associations 48 in a protected manner. 50 Processes which implement this draft can be used for negotiating 51 virtual private networks (VPNs) and also for providing a remote user 52 from a remote site (whose IP address need not be known beforehand) 53 access to a secure host or network. 55 Proxy negotiation is supported. Proxy mode is where the negotiating 56 parties are not the endpoints for which security association 57 negotiation is taking place. When used in proxy mode, the identities 58 of the end parties remain hidden. 60 This proposal does not implement the entire Oakley protocol, but only 61 a subset necessary to satisfy its goals. It does not claim 62 conformance or compliance with the entire Oakley protocol. For 63 greater understanding of the Oakley protocol and the mathematics 64 behind it, please refer to [Orm96]. 66 3. Terms and Definitions 68 3.1 Requirements Terminology 70 In this document, the words that are used to define the significance 71 of each particular requirement are capitalised. These words 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 g^xi and g^xr are the Diffie-Hellman public values of the 108 initiator and responder respectively. 110 KE is the key exchange payload. 112 Nx is the nonce payload; x can be: i or r for the ISAKMP initiator 113 and responder respectively. 115 IDx is the identity payload for "x". x can be: "ii" or "ir" for 116 the ISAKMP initiator and responder respectively during phase one 117 negotiation; or "ui" or "ur" for the user initiator and responder 118 respectively during phase two. The ID payload format for the 119 Internet DOI is defined in [Pip96]. 121 SIG is the signature payload. The data to sign is exchange- 122 specific. 124 CERT is the certificate payload. 126 HASH (and any derivitive such as HASH(2) or HASH_I) is the hash 127 payload. The contents of the hash are specific to the 128 authentication method. 130 prf(key, msg) is the keyed pseudo-random function-- often a keyed 131 hash function-- used to generate a deterministic output that 132 appears pseudo-random. prf's are used both for key derivations 133 and for authentication (i.e. as a keyed MAC). (See [KBC96]). 135 SKEYID is a string derived from secret material known only to the 136 active players in the exchange. 138 SKEYID_e is the keying material used by the ISAKMP SA to protect 139 it's messages. 141 SKEYID_a is the keying material used by the ISAKMP SA to 142 authenticate it's messages. 144 SKEYID_d is the keying material used to derive keys for non-ISAKMP 145 security associations. 147 y indicates that "x" is encrypted with the key "y". 149 --> signifies "initiator to responder" communication (requests). 151 <-- signifies "responder to initiator" communication (replies). 153 | signifies concatenation of information-- e.g. X | Y is the 154 concatentation of X with Y. 156 [x] indicates that x is optional. 158 Payload encryption (when noted by a '*' after the ISAKMP header) MUST 159 begin immediately after the ISAKMP header. When communication is 160 protected, all payloads following the ISAKMP header MUST be 161 encrypted. Encryption keys are generated from SKEYID_e in a manner 162 that is defined for each algorithm. 164 When used to describe the payloads contained in complete message 165 exchanges, the ISAKMP generic header is implicitly included. When 166 used as part of a prf computation, the ISAKMP generic header is not 167 included. For example, the initiator may send the responder the 168 following message: 169 HDR, KE, Ni 170 The ISAKMP header is included in the KE and Ni payloads. But if the 171 initiator generates the following pseudo-random output: 172 HASH = prf(key, Ni | Nr) 173 the ISAKMP headers of the two nonce payloads are not included-- only 174 the body of the payload-- the nonce itself-- is used. 176 3.3 Perfect Forward Secrecy 178 When used in the draft Perfect Forward Secrecy (PFS) refers to the 179 notion that compromise of a single key will permit access to only 180 data protected by a single key. For PFS to exist the key used to 181 protect transmission of data MUST NOT be used to derive any 182 additional keys, and if the key used to protect transmission of data 183 was derived from some other keying material, that material MUST NOT 184 be used to derive any more keys. 186 Perfect Forward Secrecy for both keys and identities is provided in 187 this protocol. (Sections 5.8 and 7). 189 3.4 Security Association 191 A security association (SA) is a set of policy and key used to 192 protect information. The ISAKMP SA is the shared policy and key used 193 by the negotiating peers in this protocol to protect their 194 communication. 196 4. Introduction 198 Oakley defines a method to establish an authenticated key exchange. 199 This includes how payloads are constructed, the information they 200 carry, the order in which they are processed and how they are used. 202 While Oakley defines "modes", ISAKMP defines "phases". The 203 relationship between the two is very straightforward. ISAKMP's phase 204 1 is where the two ISAKMP peers establish a secure, authenticated 205 channel with which to communicate. This is called the ISAKMP 206 Security Association (SA). Oakley's "Main Mode" and "Aggressive Mode" 207 each accomplish a phase 1 exchange. "Main Mode" and "Aggressive 208 Mode" MUST ONLY be used in phase 1. 210 Phase 2 is where Security Associations are negotiated on behalf of 211 services such as IPsec or any other service which needs key material 212 and/or parameter negotiation. Oakley's "Quick Mode" accomplishes a 213 phase 2 exchange. "Quick Mode" MUST ONLY be used in phase 2. 215 Oakley's "New Group Mode" is not really a phase 1 or phase 2. It 216 follows phase 1, but serves to establish a new group which can be 217 used in future negotiations. "New Group Mode" MUST ONLY be used in 218 phase 2. 220 With the use of ISAKMP phases, an implementation can accomplish very 221 fast keying when necessary. A single phase 1 negotiation may be used 222 for more than one phase 2 negotiation. Additionally a single phase 2 223 negotiation can request multiple Security Associations. With these 224 optimizations, an implementation can see less than one round trip per 225 SA as well as less than one DH exponentiation per SA. "Main Mode" 226 for phase 1 provides identity protection. When identity protection 227 is not needed, "Aggressive Mode" can be used to reduce round trips 228 even further. Developer hints for doing these optimizations are 229 included below. It should also be noted that using public key 230 encryption to authenticate an Aggressive Mode exchange will still 231 provide identity protection. 233 The following attributes are used by Oakley and are negotiated as 234 part of the ISAKMP Security Association. (These attributes pertain 235 only to the ISAKMP Security Association and not to any Security 236 Associations that ISAKMP may be negotiating on behalf of other 237 services.) 238 - encryption algorithm (e.g. DES, IDEA, Blowfish). 240 - hash algorithm (e.g. MD5, SHA) 242 - authentication method (e.g. DSS sig, RSA sig, RSA encryption, 243 pre-shared key) 245 - information about a group over which to do Diffie-Hellman. 247 - prf (e.g. 3DES-CBC-MAC) 249 All of these attributes are mandatory and MUST be negotiated except 250 for the "prf". The "prf" MAY be negotiated, but if it is not, the 251 HMAC (see [KBC96]) version of the negotiated hash algorithm is used 252 as a pseudo-random function. Other non-mandatory attributes are 253 described in Appendix A. The selected hash algorithm MUST support 254 both native and HMAC modes. 256 Oakley implementations MUST support the following attribute values: 258 - DES-CBC with a weak, and semi-weak, key check (weak and semi- 259 weak keys are referenced in [Sch94] and listed in Appendix A). The 260 key is derived according to Appendix B. 262 - MD5 and SHA. 264 - Authentication via pre-shared keys. The Digital Signature 265 Standard SHOULD be supported; RSA SHOULD also be supported. 267 - MODP over the default Oakley group (see below). ECP groups MAY 268 be supported. 270 The Oakley modes described here MUST be implemented whenever the IETF 271 IPsec DOI [Pip96] is implemented. Other DOIs MAY use the Oakley modes 272 described here. 274 5. Exchanges 276 There are two basic methods used to establish an authenticated key 277 exchange: Oakley Main Mode and Oakley Aggressive Mode. Each generates 278 authenticated keying material from an ephemeral Diffie-Hellman 279 exchange. Oakley in Main Mode MUST be implemented; Oakley Aggressive 280 Mode SHOULD be implemented. In addition, Oakley Quick Mode MUST be 281 implemented as a mechanism to generate fresh keying material and 282 negotiate non-ISAKMP security services. In additon, Oakley New Group 283 Mode SHOULD be implemented as a mechanism to define private groups 284 for Diffie-Hellman exchanges. Implementations MUST NOT switch 285 exchange types in the middle of an exchange. 287 Exchanges conform to standard ISAKMP [MSST96] payload syntax. 288 attribute encoding, timeouts and retransmits of messages, and 289 informational messages-- e.g a notify response is sent when, for 290 example, a proposal is unacceptable, or a signature verification or 291 decryption was unsuccessful, etc. 293 Oakley Main Mode is an instantiation of the ISAKMP Identity Protect 294 Exchange: The first two messages negotiate policy; the next two 295 exchange Diffie-Hellman public values and ancillary data (e.g. 296 nonces) necessary for the exchange; and the last two messages 297 authenticate the Diffie-Hellman Exchange. The authentication method 298 negotiated as part of the initial ISAKMP exchange influences the 299 composition of the payloads but not their purpose. The XCHG for 300 Oakley Main Mode is ISAKMP Identity Protect. 302 Similarly, Oakley Aggressive Mode is an instantiation of the ISAKMP 303 Aggressive Exchange. The first two messages negotiate policy, 304 exchange Diffie-Hellman public values and ancillary data necessary 305 for the exchange, and identities. In addition the second message 306 authenticates the responder. The third message authenticates the 307 initiator and provides a proof of participation in the exchange. The 308 XCHG for Oakley Aggressive Mode is ISAKMP Aggressive. The final 309 message is not sent under protection of the ISAKMP SA allowing each 310 party to postpone exponentiation, if desired, until negotiation of 311 this exchange is complete. 313 Quick Mode and New Group Mode have no analog in ISAKMP. The XCHG 314 values for Quick Mode and New Group Mode are defined in Appendix A. 316 Three different authentication methods are allowed with either Main 317 Mode or Aggressive Mode-- digital signature, public key encryption, 318 or pre-shared key. The value SKEYID is computed seperately for each 319 authentication method. 321 For signatures: SKEYID = prf(Ni | Nr, g^xy) 322 For public key encryption: SKEYID = hash(Ni | Nr) 323 For pre-shared keys: SKEYID = prf(pre-shared-key, Ni | Nr) 325 The result of either Main Mode or Aggressive Mode is three groups of 326 authenticated keying material: 328 SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R, 0) 329 SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R, 1) 330 SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R, 2) 332 and agreed upon policy to protect further communications. The values 333 of 0, 1, and 2 above are represented by a single octet. The key used 334 for encryption is derived from SKEYID_e in an algorithm-specific 335 manner (see appendix B). 337 To authenticate either exchange the initiator of the protocol 338 generates HASH_I and the responder generates HASH_R where: 340 HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAp | IDii) 341 HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDir) 343 For authentication with digital signatures, HASH_I and HASH_R are 344 signed and verified; for authentication with either public key 345 encryption or pre-shared keys, HASH_I and HASH_R directly 346 authenticate the exchange. 348 As mentioned above, the negotiated authentication method influences 349 the content and use of messages for Phase 1 Oakley Modes, but not 350 their intent. When using public keys for authentication, the Phase 1 351 Oakley can be accomplished either by using signatures or by using 352 public key encryption (if the algorithm supports it). Following are 353 Main Mode Exchanges with different authentication options. 355 5.1 ISAKMP/Oakley Phase 1 Authenticated With Signatures 357 Using signatures, the ancillary information exchanged during the 358 second roundtrip are nonces; the exchange is authenticated by signing 359 a mutually obtainable hash. Oakley Main Mode with signature 360 authentication is described as follows: 362 Initiator Responder 363 ---------- ----------- 364 HDR, SA --> 365 <-- HDR, SA 366 HDR, KE, Ni --> 367 <-- HDR, KE, Nr 368 HDR*, IDii, [ CERT, ] SIG_I --> 369 <-- HDR*, IDir, [ CERT, ] SIG_R 371 Oakley Aggressive mode with signatures in conjunction with ISAKMP is 372 described as follows: 374 Initiator Responder 375 ----------- ----------- 376 HDR, SA, KE, Ni, IDii --> 377 <-- HDR, SA, KE, Nr, IDir, 378 [ CERT, ] SIG_R 379 HDR, [ CERT, ] SIG_I --> 381 In both modes, the signed data, SIG_I or SIG_R, is the result of the 382 negotiated digital signature algorithm applied to HASH_I or HASH_R 383 respectively. 385 In general the signature will be over HASH_I and HASH_R as above 386 using the negotiated prf, or the HMAC version of the negotiated hash 387 function (if no prf is negotiated). However, this can be overridden 388 for construction of the signature if the signature algorithm is tied 389 to a particular hash algorithm (e.g. DSS is only defined with SHA's 390 160 bit output). In this case, the signature will be over HASH_I and 391 HASH_R as above, except using the HMAC version of the hash algorithm 392 associated with the signature method. The negotiated prf and hash 393 function would continue to be used for all other proscribed pseudo- 394 random functions. 396 RSA signatures MUST be encoded in PKCS #1 format. DSS signatures 397 MUST be encoded as r followed by s. 399 One or more certificate payloads MAY be optionally passed. 401 5.2 Oakley Phase 1 Authenticated With Public Key Encryption 403 Using public key encryption to authenticate the exchange, the 404 ancillary information exchanged is encrypted nonces. Each party's 405 ability to reconstruct a hash (proving that the other party decrypted 406 the nonce) authenticates the exchange. 408 In order to perform the public key encryption, the initiator must 409 already have the responder's public key. In the case where a party 410 has multiple public keys, a hash of the certificate the initiator is 411 using to encrypt the ancillary information is passed as part of the 412 third message. In this way the responder can determine which 413 corresponding private key to use to decrypt the encrypted payloads 414 and identity protection is retained. 416 In addition to the nonce, the identities of the parties (IDii and 417 IDir) are also encrypted with the other parties public key. If the 418 authentication method is public key encryption, the nonce and 419 identity payloads MUST be encrypted with the public key of the other 420 party. Only the body of the payloads are encrypted, the payload 421 headers are left in the clear. 423 When using encrytion for authentication with Oakley, Main Mode is 424 defined as follows. 426 Initiator Responder 427 ----------- ----------- 428 HDR, SA --> 429 <-- HDR, SA 430 HDR, KE, [ HASH(1), ] 431 PubKey_r, 432 PubKey_r --> 433 HDR, KE, PubKey_i, 434 <-- PubKey_i 435 HDR*, HASH_I --> 436 <-- HDR*, HASH_R 438 Oakley Aggressive Mode authenticated with encryption is described as 439 follows: 441 Initiator Responder 442 ----------- ----------- 443 HDR, SA, [ HASH(1),] KE, 444 Pubkey_r, 445 Pubkey_r --> 446 HDR, SA, KE, PubKey_i, 447 <-- PubKey_r, HASH_R 448 HDR, HASH_I --> 450 Where HASH(1) is a hash (using the negotiated hash function) of the 451 certificate which the initiator is using to encrypt the nonce and 452 identity. 454 RSA encryption MUST be encoded in PKCS #1 format. The payload length 455 is the length of the entire encrypted payload plus header. The PKCS 456 #1 encoding allows for determination of the actual length of the 457 cleartext payload upon decryption. 459 Using encryption for authentication provides for a plausably deniable 460 exchange. There is no proof (as with a digital signature) that the 461 conversation ever took place since each party can completely 462 reconstruct both sides of the exchange. In addition, security is 463 added to secret generation since an attacker would have to 464 successfully break not only the Diffie-Hellman exchange but also both 465 RSA encryptions. This exchange was motivated by [Kra96]. 467 Note that, unlike other authentication methods, authentication with 468 public key encryption allows for identity protection with Aggressive 469 Mode. 471 5.3 Oakley Phase 1 Authenticated With a Pre-Shared Key 473 A key derived by some out-of-band mechanism may also be used to 474 authenticate the exchange. The actual establishment of this key is 475 out of the scope of this document. 477 When doing a pre-shared key authentication with Oakley, Main Mode is 478 defined as follows 480 Initiator Responder 481 ---------- ----------- 482 HDR, SA --> 483 <-- HDR, SA 484 HDR, KE, Ni --> 485 <-- HDR, KE, Nr 486 HDR*, IDii, HASH_I --> 487 <-- HDR*, IDir, HASH_R 489 Oakley Aggressive mode with a pre-shared key is described as follows: 491 Initiator Responder 492 ----------- ----------- 493 HDR, SA, KE, Ni, IDii --> 494 <-- HDR, SA, KE, Nr, IDir, HASH_R 495 HDR, HASH_I --> 497 When using pre-shared key authentication with Main Mode the key can 498 only be identified by the IP address of the peers since HASH_I must 499 be computed before the initiator has processed IDir. Aggressive Mode 500 allows for a wider range of identifiers of the pre-shared secret to 501 be used. In addition, Aggressive Mode allows two parties to maintain 502 multiple, different pre-shared keys and identify the correct one for 503 a particular exchange. 505 5.4 Oakley Phase 2 - Quick Mode 507 Oakley Quick Mode is not a complete exchange itself, but is used as 508 part of the ISAKMP SA negotiation process (phase 2) to derive keying 509 material and negotiate shared policy for non-ISAKMP SAs. The 510 information exchanged along with Oakley Quick Mode MUST be protected 511 by the ISAKMP SA-- i.e. all payloads except the ISAKMP header are 512 encrypted. 514 Quick Mode is essentially an exchange of nonces that provides replay 515 protection. The nonces are used to generate fresh key material and 516 prevent replay attacks from generating bogus security associations. 517 An optional Key Exchange payload can be exchanged to allow for an 518 additional Diffie-Hellman exchange and exponentiation per Quick Mode. 519 While use of the key exchange payload with Quick Mode is optional it 520 MUST be supported. 522 Base Quick Mode (without the KE payload) refreshens the keying 523 material derived from the exponentiation in phase 1. This does not 524 provide PFS. Using the optional KE payload, an additional 525 exponentiation is performed and PFS is provided for the keying 526 material. If a KE payload is sent, a Diffie-Hellman group (see 527 section 5.6.1 and [Pip96]) MUST be sent as attributes of the SA being 528 negotiated. 530 Quick Mode is defined as follows: 532 Initiator Responder 533 ----------- ----------- 534 HDR*, HASH(1), SA, Ni 535 [, KE ] [, IDui, IDur ] --> 536 <-- HDR*, HASH(2), SA, Nr 537 [, KE ] [, IDui, IDur ] 538 HDR*, HASH(3) --> 540 Where: 541 HASH(1) and HASH(2) are the prf over the message id (M-ID) from 542 the ISAKMP header concatenated with the entire message that follows 543 the hash including payload headers, but excluding any padding added 544 for encryption. HASH(3)-- for liveliness-- is the prf over the value 545 zero represented as a single octet, followed by a concatenation of 546 the message id and the two nonces-- the initiator's followed by the 547 responder's. In other words, the hashes for the above exchange are: 549 HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDui | IDur ]) 550 HASH(2) = prf(SKEYID_a, M-ID | SA | Nr [ | KE ] [ | IDui | IDur ]) 551 HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni | Nr) 553 If PFS is not needed, and KE payloads are not exchanged, the new 554 keying material is defined as KEYMAT = prf(SKEYID_d, SPI | Ni | Nr). 556 If PFS is desired and KE payloads were exchanged, the new keying 557 material is defined as KEYMAT = prf(SKEYID_d, g(qm)^xy | SPI | Ni | 558 Nr), where g(qm)^xy is the shared secret from the ephemeral Diffie- 559 Hellman exchange of this Quick Mode. 561 The SPI is the value from the SPI field in the SA payload. 563 A single SA negotiation results in two security assocations-- one 564 inbound and one outbound. Different SPIs for each SA (one chosen by 565 the initiator, the other by the responder) guarantee a different key 566 for each direction. The SPI chosen by the destination of the SA is 567 used to derive KEYMAT for that SA. 569 For situations where the amount of keying material desired is greater 570 than that supplied by the prf, KEYMAT is expanded by feeding the 571 results of the prf back into itself and concatenating results until 572 the required keying material has been reached. In other words, 574 KEYMAT = K1 | K2 | K3 | ... 575 where 576 K1 = prf(SKEYID_d, [ g(qm)^xy | ] SPI | Ni | Nr) 577 K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] SPI | Ni | Nr) 578 K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] SPI | Ni | Nr) 579 etc. 581 This keying material (whether with PFS or without, and whether 582 derived directly or through concatenation) MUST be used with the 583 negotiated SA. It is up to the service to define how keys are derived 584 from the keying material (see Appendix B). 586 In the case of an ephemeral Diffie-Hellman exchange in Quick Mode, 587 the exponential (g(qm)^xy) is irretreivably removed from the current 588 state and SKEYID_e and SKEYID_a (derived from phase 1 negotiation) 589 continue to protect and authenticate the ISAKMP SA and SKEYID_d 590 continues to be used to derive keys. 592 If ISAKMP is acting as a proxy negotiator on behalf of another party 593 the identities of the parties MUST be passed as IDui and IDur. Local 594 policy will dictate whether the proposals are acceptible for the 595 identities specified. If IDs are not exchanged, the negotiation is 596 assumed to be done on behalf of each ISAKMP peer. If an ID range 597 (see Appendix A of [Pip96]) is not acceptable (for example, the 598 specified subnet is too large) a BAD_ID_RANGE notify message followed 599 by an acceptible ID range, in an ID payload, MUST be sent. 601 Using Quick Mode, multiple SA's and keys can be negotiated with one 602 exchange as follows: 604 Initiator Responder 605 ----------- ----------- 606 HDR*, HASH(1), SA0, SA1, Ni, 607 [, KE ] [, IDui, IDur ] --> 608 <-- HDR*, HASH(2), SA0, SA1, Nr, 609 [, KE ] [, IDui, IDur ] 610 HDR*, HASH(3) --> 612 The keying material is derived identically as in the case of a single 613 SA. In this case (negotiation of two SA payloads) the result would be 614 four security associations-- two each way for both SAs. 616 5.5 Oakley New Group Mode 618 Oakley New Group Mode MUST NOT be used prior to establishment of an 619 ISAKMP SA. The description of a new group MUST only follow phase 1 620 negotiation. (It is not a phase 2 exchange, though). 622 Initiator Responder 623 ----------- ----------- 624 HDR*, HASH(1), SA --> 625 <-- HDR*, HASH(2), SA 627 where HASH(1) is the prf output, using SKEYID_a as the key, and the 628 entire SA proposal, body and header, as the data; HASH(2) is the prf 629 output, using SKEYID_a as the key, and the reply as the data. 631 The proposal will be an Oakley proposal which specifies the 632 characteristics of the group (see appendix A, "Oakley Attribute 633 Assigned Numbers"). Group descriptions for private Oakley Groups MUST 634 be greater than or equal to 2^15. If the group is not acceptable, 635 the responder MUST reply with a Notify payload with the message type 636 set to GROUP_NOT_ACCEPTABLE (13). 638 ISAKMP implementations MAY require private groups to expire with the 639 SA under which they were established. 641 Groups may be directly negotiated in the SA proposal with Oakley Main 642 Mode. To do this the Prime, Generator (using the Generator One 643 attribute class from Appendix A), and Group Type are passed as SA 644 attributes (see Appendix A in [MSST96]). Alternately, the nature of 645 the group can be hidden using Oakley New Group Mode and only the 646 group identifier is passed in the clear during phase 1 negotiation. 648 5.6 Oakley Groups 650 [Orm96] defines several groups. The value 0 indicates no group. The 651 value 1 indicates the default group described below. The attribute 652 class for "Group" is defined in Appendix A. Other values are also 653 defined in [Orm96]. All values 2^15 and higher are used for private 654 group identifiers. 656 5.6.1 Oakley Default Group 658 Oakley implementations MUST support a MODP group with the following 659 prime and generator. This group is assigned id 1 (one). 661 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 662 Its hexadecimal value is 664 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 665 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 666 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 667 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 669 The generator is: 2. 671 other groups can be defined using Oakley New Group Mode. This default 672 group was generated by Richard Schroeppel at the University of 673 Arizona. Properties of this prime are described by the following 674 exerpt from [Orm96]: 676 The prime for this group was selected to have certain 677 properties. The high order 64 bits are forced to 1. This 678 helps the classical remainder algorithm, because the trial 679 quotient digit can always be taken as the high order word of 680 the dividend, possibly +1. The low order 64 bits are forced to 681 1. This helps the Montgomery-style remainder algorithms, 682 because the multiplier digit can always be taken to be the low 683 order word of the dividend. The middle bits are taken from the 684 binary expansion of pi. This guarantees that they are 685 effectively random, while avoiding any suspicion that the 686 primes have secretly been selected to be weak. 688 The prime is chosen to be a Sophie-Germain prime (i.e., (P-1)/2 689 is also prime), to have the maximum strength against the 690 square-root attack. The starting trial numbers were repeatedly 691 incremented by 2^64 until suitable primes were located. 693 Because this prime is congruent to 7 (mod 8), 2 is a quadratic 694 residue. All powers of 2 will also be quadratic residues. 695 This prevents an opponent from learning the low order bit of 696 the Diffie-Hellman exponent. Using 2 as a generator is 697 efficient for some modular exponentiation algorithms. [Note 698 that 2 is technically not a generator in the number theory 699 sense, because it omits half of the possible residues mod P. 700 From a cryptographic viewpoint, this is a virtue.] 702 A further discussion of the properties of this group, the motivation 703 behind its creation, as well as the definition of several more groups 704 can be found in [Orm96]. 706 5.7 Payload Explosion for Complete ISAKMP-Oakley Exchange 708 This section illustrates how ISAKMP payloads are used with Oakley to: 710 - establish a secure and authenticated channel between ISAKMP 711 processes (phase 1); and 713 - generate key material for, and negotiate, an IPsec SA (phase 2). 715 5.7.1 Phase 1 using Oakley Main Mode 717 The following diagram illustrates the payloads exchanged between the 718 two parties in the first round trip exchange. The initiator MAY 719 propose several proposals; the responder MUST reply with one. 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 ~ ISAKMP Header with XCHG of Oakley Main Mode, ~ 724 ~ and Next Payload of ISA_SA ~ 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 ! 0 ! RESERVED ! Payload Length ! 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 ! Domain of Interpretation (IPsec DOI) ! 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 ! Situation ! 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 ! 0 ! RESERVED ! Payload Length ! 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 ! Proposal #1 ! Proto=ISAKMP ! # of Transforms ! 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 ~ SPI (8 octets) ~ 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 ! ISA_TRANS ! RESERVED ! Payload Length ! 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 ! Transform #1 ! RESERVED | OAKLEY ! 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 ~ preffered SA attributes ~ 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 ! 0 ! RESERVED ! Payload Length ! 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 ! Transform #2 ! RESERVED | OAKLEY ! 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 ~ alternate SA attributes ~ 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 The responder replies in kind but selects, and returns, one transform 752 proposal (the ISAKMP SA attributes). 754 The second exchange consists of the following payloads: 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 ~ ISAKMP Header with XCHG of Oakley Main Mode, ~ 759 ~ and Next Payload of ISA_KE ~ 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 ! ISA_NONCE ! RESERVED ! Payload Length ! 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 ~ D-H Public Value (g^xi from initiator g^xr from responder) ~ 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 ! 0 ! RESERVED ! Payload Length ! 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 ~ Ni (from initiator) or Nr (from responder) ~ 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 The shared keys, SKEYID_e and SKEYID_a, are now used to protect and 771 authenticate all further communication. Note that both SKEYID_e and 772 SKEYID_a are unauthenticated. 774 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 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 ~ ISAKMP Header with XCHG of Oakley Main Mode, ~ 777 ~ and Next Payload of ISA_ID and the encryption bit set ~ 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 ! ISA_SIG ! RESERVED ! Payload Length ! 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 ~ Identification Data of the ISAKMP negotiator ~ 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 ! 0 ! RESERVED ! Payload Length ! 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 ~ signature verified by the public key of the ID above ~ 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 The key exchange is authenticated over a signed hash as described in 789 section 5.1. Once the signature has been verified using the 790 authentication algorithm negotiated as part of the ISAKMP SA, the 791 shared keys, SKEYID_e and SKEYID_a can be marked as authenticated. 792 (For brevity, certificate payloads were not exchanged). 794 5.7.2 Phase 2 using Oakley Quick Mode 796 The following payloads are exchanged in the first round of Oakley 797 Quick Mode with ISAKMP SA negotiation. In this hypothetical exchange, 798 the ISAKMP negotiators are proxies for other parties which have 799 requested authentication. 801 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 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 ~ ISAKMP Header with XCHG of Oakley Quick Mode, ~ 804 ~ Next Payload of ISA_HASH and the encryption bit set ~ 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 ! ISA_SA ! RESERVED ! Payload Length ! 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 ~ keyed hash of message ~ 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 ! ISA_NONCE ! RESERVED ! Payload Length ! 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 ! Domain Of Interpretation (DOI) ! 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 ! Situation ! 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 ! 0 ! RESERVED ! Payload Length ! 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 ! Proposal #1 ! Protocol=AH ! # of Transforms ! 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 ~ SPI (8 octets) ~ 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 ! ISA_TRANS ! RESERVED ! Payload Length ! 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 ! Transform #1 ! RESERVED | SHA ! 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 ! other SA attributes ! 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 ! 0 ! RESERVED ! Payload Length ! 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 ! Transform #1 ! RESERVED | MD5 ! 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 ! other SA attributes ! 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 ! ISA_ID ! RESERVED ! Payload Length ! 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 ~ nonce ~ 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 ! ISA_ID ! RESERVED ! Payload Length ! 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 ~ ID of source for which ISAKMP is a proxy ~ 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 ! 0 ! RESERVED ! Payload Length ! 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 ~ ID of destination for which ISAKMP is a proxy ~ 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 where the contents of the hash are described in 5.4 above. The 848 responder replies with a similar message which only contains one 849 transform-- the selected AH transform. Upon receipt, the initiator 850 can provide the key engine with the negotiated security association 851 and the keying material. As a check against replay attacks, the 852 responder waits until receipt of the next message. 854 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 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 ~ ISAKMP Header with XCHG of Oakley Quick Mode, ~ 857 ~ Next Payload of ISA_HASH and the encryption bit set ~ 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 ! 0 ! RESERVED ! Payload Length ! 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 ~ hash data ~ 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 where the contents of the hash are described in 5.4 above. 866 5.8 Perfect Forward Secrecy Example 867 This protocol can provide PFS of both keys and identities. The 868 identies of both the ISAKMP negotiating peer and, if applicable, the 869 proxy for whom the peers are negotiating can be protected with PFS. 871 To provide Perfect Forward Secrecy of both keys and all identities, 872 two parties would perform the following: 873 o A Main Mode Exchange to protect the identities of the ISAKMP 874 peers. 875 This establishes an ISAKMP SA. o A Quick Mode Exchange to 876 negotiate other security protocol protection. 877 This establishes a SA on each end for this protocol. o Delete 878 the ISAKMP SA and its associated state. 879 Since the key for use in the non-ISAKMP SA was derived from the 880 single ephemeral Diffie-Hellman exchange PFS is preserved. 882 To provide Perfect Forward Secrecy of merely the keys of a non-ISAKMP 883 security association, it in not necessary to do a phase 1 exchange if 884 an ISAKMP SA exists between the two peers. A single Quick Mode in 885 which the optional KE payload is passed, and an additional Diffie- 886 Hellman exchange is performed, is all that is required. At this point 887 the state derived from this Quick Mode must be deleted from the 888 ISAKMP SA as described in section 5.4. 890 6. Implementation Hints 892 Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2 893 negotiations extremely quick. As long as the Phase 1 state remains 894 cached, and PFS is not needed, Phase 2 can proceed without any 895 exponentiation. How many Phase 2 negotiations can be performed for a 896 single Phase 1 is a local policy issue. The decision will depend on 897 the strength of the algorithms being used and level of trust in the 898 peer system. 900 An implementation may wish to negotiate a range of SAs when 901 performing Quick Mode. By doing this they can speed up the "re- 902 keying". Quick Mode defines how KEYMAT is defined for a range of SAs. 903 When one peer feels it is time to change SAs they simple use the next 904 one within the stated range. A range of SAs can be established by 905 negotiating multiple SAs (identical attributes, different SPIs) with 906 one Quick Mode. 908 An optimization that is often useful is to establish Security 909 Associations with peers before they are needed so that when they 910 become needed they are already in place. This ensures there would be 911 no delays due to key management before initial data transmission. 912 This optimization is easily implemented by setting up more than one 913 Security Association with a peer for each requested Security 914 Association and caching those not immediately used. 916 Also, if an ISAKMP implementation is alerted that a SA will soon be 917 needed (e.g. to replace an existing SA that will expire in the near 918 future), then it can establish the new SA before that new SA is 919 needed. 921 7. Security Considerations 923 This entire draft discusses a hybrid protocol, combining Oakley with 924 ISAKMP, to negotiate, and derive keying material for, security 925 associations in a secure and authenticated manner. 927 Confidentiality is assured by the use of a negotiated encryption 928 algorithm. Authentication is assured by the use of a negotiated 929 method: a digital signature algorithm; a public key algorithm which 930 supports encryption; or, a pre-shared key. The confidentiality and 931 authentication of this exchange is only as good as the attributes 932 negotiated as part of the ISAKMP security association. 934 Repeated re-keying using Quick Mode can consume the entropy of the 935 Diffie- Hellman shared secret. Implementors should take note of this 936 fact and set a limit on Quick Mode Exchanges between exponentiations. 937 This draft does not proscribe such a limit. 939 Perfect Forward Secrecy (PFS) of both keying material and identities 940 is possible with this protocol. By specifying a Diffie-Hellman group, 941 and passing public values in KE payloads, ISAKMP peers can establish 942 PFS of keys-- the identities would be protected by SKEYID_e from the 943 ISAKMP SA and would therefore not be protected by PFS. If PFS of both 944 keying material and identities is desired, an ISAKMP peer MUST 945 establish only one non-ISAKMP security association (e.g. IPsec 946 Security Association) per ISAKMP SA. PFS for keys and identities is 947 accomplished by deleting the ISAKMP SA (and optionally issuing a 948 DELETE message) upon establishment of the single non-ISAKMP SA. In 949 this way a phase one negotiation is uniquely tied to a single phase 950 two negotiation, and the ISAKMP SA established during phase one 951 negotiation is never used again. 953 Implementations SHOULD not use Diffie-Hellman exponents of less than 954 200 bits to avoid adversely effecting the security of both parties. 956 It is assumed that the Diffie-Hellman exponents in this exchange are 957 erased from memory after use. In particular, these exponents must not 958 be derived from long-lived secrets like the seed to a pseudo-random 959 generator. 961 8. Acknowledgements 963 This document is the result of close consultation with Hilarie Orman, 964 Douglas Maughan, Mark Schertler, Mark Schneider, and Jeff Turner. It 965 relies completely on protocols which were written by them. Without 966 their interest and dedication, this would not have been written. 968 We would also like to thank Cheryl Madson, Harry Varnis, Elfed 969 Weaver, and Hugo Krawcyzk for technical input. 971 9. References 973 [ACM97] Adams, C.M., "Constructing Symmetric Ciphers Using the CAST 974 Design Procedure", Designs, Codes and Cryptorgraphy (to appear). 976 [KBC96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing 977 for Message Authentication", draft-ietf-ipsec-hmac-md5-01.txt 979 [Kra96] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 980 Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium 981 on Network and Distributed Systems Security. 983 [MSST96] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., 984 "Internet Security Association and Key Management Protocol (ISAKMP)", 985 version 7, draft-ietf-ipsec-isakmp-07.{ps,txt}. 987 [Orm96] Orman, H., "The Oakley Key Determination Protocol", version 988 1, draft-ietf-ipsec-oakley-01.txt. 990 [Pip96] Piper, D., "The Internet IP Security Domain Of Interpretation 991 for ISAKMP", version 2, draft-ietf-ipsec-ipsec-doi-02.txt. 993 [Sch94] Schneier, B., "Applied Cryptography, Protocols, Algorithms, 994 and Source Code in C", 2nd edition. 996 Appendix A 998 This is a list of DES Weak and Semi-Weak keys. The keys come from 999 [Sch94]. All keys are listed in hexidecimal. 1001 DES Weak Keys 1002 0101 0101 0101 0101 1003 1F1F 1F1F E0E0 E0E0 1004 E0E0 E0E0 1F1F 1F1F 1005 FEFE FEFE FEFE FEFE 1007 DES Semi-Weak Keys 1008 01FE 01FE 01FE 01FE 1009 1FE0 1FE0 0EF1 0EF1 1010 01E0 01E0 01F1 01F1 1011 1FFE 1FFE 0EFE 0EFE 1012 011F 011F 010E 010E 1013 E0FE E0FE F1FE F1FE 1015 FE01 FE01 FE01 FE01 1016 E01F E01F F10E F10E 1017 E001 E001 F101 F101 1018 FE1F FE1F FE0E FE0E 1019 1F01 1F01 0E01 0E01 1020 FEE0 FEE0 FEF1 FEF1 1022 Attribute Assigned Numbers 1024 Attributes negotiated during phase one use the following definitions. 1025 Phase two attributes are defined in the applicable DOI specification 1026 (for example, IPsec attributes are defined in the IPsec DOI), with 1027 the exception of a group description when Quick Mode includes an 1028 ephemeral Diffie-Hellman exchange. Attribute types can be either 1029 Basic (B) or Variable-length (V). Encoding of these attributes is 1030 defined in the base ISAKMP specification. 1032 Attribute Classes 1034 class value type 1035 ------------------------------------------------------------------- 1036 Encryption Algorithm 1 B 1037 Hash Algorithm 2 B 1038 Authentication Method 3 B 1039 Group Description 4 B 1040 Group Type 5 B 1041 Group Prime 6 V 1042 Group Generator One 7 V 1043 Group Generator Two 8 V 1044 Group Curve A 9 V 1045 Group Curve B 10 V 1046 Life Type 11 B 1047 Life Duration 12 B/V 1048 PRF 13 B 1049 Key Length 14 B 1051 Class Values 1053 - Encryption Algorithm 1054 DEC-CBC 1 1055 IDEA-CBC 2 1056 Blowfish-CBC 3 1057 RC5-R12-B64-CBC 4 1058 3DES-CBC 5 1059 CAST-CBC 6 1061 values 7-65000 are reserved. Values 65001-65535 are for private use 1062 among mutually consenting parties. 1064 - Hash Algorithm 1065 MD5 1 1066 SHA 2 1067 Tiger 3 1069 values 4-65000 are reserved. Values 65001-65535 are for private use 1070 among mutually consenting parties. 1072 - Authentication Method 1073 pre-shared key 1 1074 DSS signatures 2 1075 RSA signatures 3 1076 RSA encryption 4 1078 values 5-65000 are reserved. Values 65001-65535 are for private use 1079 among mutually consenting parties. 1081 - Group Description 1082 default group (section 5.6.1) 1 1084 values 2-32767 are reserved. Values 32768-65535 are for private use 1085 among mutually consenting parties. 1087 - Group Type 1088 MODP (modular exponentiation group) 1 1089 ECP (elliptic curve group) 2 1091 values 3-65000 are reserved. Values 65001-65535 are for private use 1092 among mutually consenting parties. 1094 - Life Type 1095 seconds 1 1096 kilobytes 2 1098 values 3-65000 are reserved. Values 65001-65535 are for private use 1099 among mutually consenting parties. For a given "Life Type" the 1100 value of the "Life Duration" attribute defines the actual length of 1101 the SA life-- either a number of seconds, or a number of kbytes 1102 protected. 1104 - PRF 1105 3DES-CBC-MAC 1 1107 values 2-65000 are reserved. Values 65001-65535 are for private use 1108 among mutually consenting parties 1110 - Key Length 1112 When using an Encryption Algorithm that has a variable length key, 1113 this attribute specifies the key length in bits. (MUST use network 1114 byte order). 1116 Additional Exchanges Defined-- XCHG values 1117 Quick Mode 32 1118 New Group Mode 33 1120 Appendix B 1122 This appendix describes encryption details to be used ONLY when 1123 encrypting ISAKMP messages. When a service (such as an IPSEC 1124 transform) utilizes ISAKMP to generate keying material, all 1125 encryption algorithm specific details (such as key and IV generation, 1126 padding, etc...) MUST be defined by that service. ISAKMP does not 1127 purport to ever produce keys that are suitable for any encryption 1128 algorithm. ISAKMP produces the requested amount of keying material 1129 from which the service MUST generate a suitable key. Details, such 1130 as weak key checks, are the responsibility of the service. 1132 Encryption keys used to protect the ISAKMP SA are derived from 1133 SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long 1134 enough to supply all the necessary keying material an algorithm 1135 requires, the key is derived from feeding the results of a pseudo- 1136 random function into itself, concatenating the results, and taking 1137 the highest necessary bits. 1139 For example, if (ficticious) algorithm AKULA requires 320-bits of key 1140 (and has no weak key check) and the prf used to generate SKEYID_e 1141 only generates 120 bits of material, the key for AKULA, would be the 1142 first 320-bits of Ka, where: 1144 Ka = K1 | K2 | K3 1145 and 1146 K1 = prf(SKEYID_e, 0) 1147 K2 = prf(SKEYID_e, K1) 1148 K3 = prf(SKEYID_e, K2) 1150 where prf is the HMAC version of the negotiated hash function or the 1151 negotiated prf. Each result of the prf provides 120 bits of material 1152 for a total of 360 bits. AKULA would use the first 320 bits of that 1153 360 bit string. 1155 In phase 1, material for the initialization vector (IV material) for 1156 CBC mode encryption algorithms is derived from a hash of a 1157 concatenation of the initiator's public Diffie-Hellman value and the 1158 responder's public Diffie-Hellman value using the negotiated hash 1159 algorithm. This is used for the first message only. Each message 1160 should be padded up to the nearest block size using bytes containing 1161 0x00. The message length in the header MUST include the length of the 1162 pad since this reflects the size of the cyphertext. Subsequent 1163 messages MUST use the last CBC encryption block from the previous 1164 message as their initialization vector. 1166 In phase 2, material for the initialization vector for CBC mode 1167 encryption of the first message of a Quick Mode exchange is derived 1168 from a hash of a concatenation of the last phase 1 CBC output block 1169 and the phase 2 message id using the negotiated hash algorithm. The 1170 IV for subsequent messages within a Quick Mode exchange is the CBC 1171 output block from the previous message. Padding and IVs for 1172 subsequent messages are done as in phase 1. 1174 Note that the final phase 1 CBC output block, the result of 1175 encryption/decryption of the last phase 1 message, must be retained 1176 in the ISAKMP SA state to allow for generation of unique IVs for each 1177 Quick Mode. Each phase 2 exchange generates IVs independantly to 1178 prevent IVs from getting out of sync when two different Quick Modes 1179 are started simultaneously. 1181 The key for DES-CBC is derived from the first eight (8) non-weak and 1182 semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first 8 1183 bytes of the IV material derived above. 1185 The key for IDEA-CBC is derived from the first sixteen (16) bytes of 1186 SKEYID_e. The IV is the first eight (8) bytes of the IV material 1187 derived above. 1189 The key for Blowfish-CBC is either the negotiated key size, or the 1190 first fifty-six (56) bytes of a key (if no key size is negotiated) 1191 derived in the aforementioned pseudo-random function feedback method. 1192 The IV is the first eight (8) bytes of the IV material derived above. 1194 The key for RC5-R12-B64-CBC is the negotiated key length, or the 1195 first sixteen (16) bytes of a key (if no key size is negotiated) 1196 derived from the aforementioned pseudo-random function feedback 1197 method if necessary. The IV is the first eight (8) bytes of the IV 1198 material derived above. The number of rounds MUST be 12 and the block 1199 size MUST be 64. 1201 The key for 3DES-CBC is the first twenty-four (24) bytes of a key 1202 derived in the aforementioned pseudo-random function feedback method. 1203 3DES-CBC is an encrypt-decrypt-encrypt operation using the first, 1204 middle, and last eight (8) bytes of the entier 3DES-CBC key. The IV 1205 is the first eight (8) bytes of the IV material derived above. 1207 The key for CAST-CBC is either the negotiated key size, or the first 1208 sixteen (16) bytes of a key derived in the aforementioned pseudo- 1209 random function feedback method. The IV is the first eight (8) bytes 1210 of the IV material derived above. 1212 Support for algorithms other than DES-CBC is purely optional. Some 1213 optional algorithms may be subject to intellectual property claims. 1215 Authors' Addresses: 1217 Dan Harkins 1218 cisco Systems 1219 170 W. Tasman Dr. 1220 San Jose, California, 95134-1706 1221 United States of America 1222 +1 408 526 4000 1224 Dave Carrel 1225 76 Lippard Ave. 1226 San Francisco, CA 94131-2947 1227 United States of America 1228 +1 415 337 8469 1230 Authors' Note: 1232 The authors encourage independent implementation, and 1233 interoperability testing, of this hybrid exchange.