idnits 2.17.1 draft-ietf-ipsec-isakmp-oakley-04.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-16) 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 ([Kra96], [Orm96], [MSST96]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The 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 (July 1997) is 9772 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) == Missing Reference: 'P' is mentioned on line 1155, but not defined == Unused Reference: 'Acm97' is defined on line 1035, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Acm97' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'KBC96') -- Possible downref: Non-RFC (?) normative reference: ref. 'Kra96' == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-isakmp-08 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. 'MSST96') -- Possible downref: Non-RFC (?) normative reference: ref. 'Orm96' == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-ipsec-doi-03 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-ipsec-doi (ref. 'Pip96') -- Possible downref: Non-RFC (?) normative reference: ref. 'Sch94' Summary: 15 errors (**), 0 flaws (~~), 6 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-04.txt July 1997 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 [Kra96] (SKEME) describes a versatile key exchange technique which 39 provides anonymity, repudiability, and quick key refreshment. 41 This document describes a protocol using part of Oakley and part of 42 SKEME in conjunction with ISAKMP to obtain authenticated keying 43 material for use with ISAKMP, and for other security associations 44 such as AH and ESP for the IETF IPsec DOI. 46 2. Discussion 48 This draft describes a hybrid protocol. The purpose is to negotiate, 49 and provide authenticated keying material for, security associations 50 in a protected manner. 52 Processes which implement this draft can be used for negotiating 53 virtual private networks (VPNs) and also for providing a remote user 54 from a remote site (whose IP address need not be known beforehand) 55 access to a secure host or network. 57 Proxy negotiation is supported. Proxy mode is where the negotiating 58 parties are not the endpoints for which security association 59 negotiation is taking place. When used in proxy mode, the identities 60 of the end parties remain hidden. 62 This does not implement the entire Oakley protocol, but only a subset 63 necessary to satisfy its goals. It does not claim conformance or 64 compliance with the entire Oakley protocol. 66 Likewise, this does not implement the entire SKEME protocol, but only 67 the method of public key encryption for authentication and its 68 concept of fast re-keying using an exchange of nonces. 70 3. Terms and Definitions 72 3.1 Requirements Terminology 74 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 75 "MAY" that appear in this document are to be interpreted as described 76 in [Bra97]. 78 3.2 Notation 80 The following notation is used throughout this draft. 82 HDR is an ISAKMP header whose exchange type is the mode. When 83 writen as HDR* it indicates payload encryption. 85 SA is an SA negotiation payload with one or more proposals. An 86 initiator MAY provide multiple proposals for negotiation; a 87 responder MUST reply with only one. 89 SAp is the entire body of the SA payload (minus the ISAKMP generic 90 header)-- i.e. the DOI, situation, all proposals and all 91 transforms offered by the Initiator. 93 g^xi and g^xr are the Diffie-Hellman public values of the 94 initiator and responder respectively. 96 KE is the key exchange payload. 98 Nx is the nonce payload; x can be: i or r for the ISAKMP initiator 99 and responder respectively. 101 IDx is the identity payload for "x". x can be: "ii" or "ir" for 102 the ISAKMP initiator and responder respectively during phase one 103 negotiation; or "ui" or "ur" for the user initiator and responder 104 respectively during phase two. The ID payload format for the 105 Internet DOI is defined in [Pip96]. 107 SIG is the signature payload. The data to sign is exchange- 108 specific. 110 CERT is the certificate payload. 112 HASH (and any derivitive such as HASH(2) or HASH_I) is the hash 113 payload. The contents of the hash are specific to the 114 authentication method. 116 prf(key, msg) is the keyed pseudo-random function-- often a keyed 117 hash function-- used to generate a deterministic output that 118 appears pseudo-random. prf's are used both for key derivations 119 and for authentication (i.e. as a keyed MAC). (See [KBC96]). 121 SKEYID is a string derived from secret material known only to the 122 active players in the exchange. 124 SKEYID_e is the keying material used by the ISAKMP SA to protect 125 it's messages. 127 SKEYID_a is the keying material used by the ISAKMP SA to 128 authenticate it's messages. 130 SKEYID_d is the keying material used to derive keys for non-ISAKMP 131 security associations. 133 y indicates that "x" is encrypted with the key "y". 135 --> signifies "initiator to responder" communication (requests). 137 <-- signifies "responder to initiator" communication (replies). 139 | signifies concatenation of information-- e.g. X | Y is the 140 concatentation of X with Y. 142 [x] indicates that x is optional. 144 Payload encryption (when noted by a '*' after the ISAKMP header) MUST 145 begin immediately after the ISAKMP header. When communication is 146 protected, all payloads following the ISAKMP header MUST be 147 encrypted. Encryption keys are generated from SKEYID_e in a manner 148 that is defined for each algorithm. 150 When used to describe the payloads contained in complete message 151 exchanges, the ISAKMP generic header is implicitly included. When 152 used as part of a prf computation, the ISAKMP generic header is not 153 included unless specifically noted. For example, the initiator may 154 send the responder the following message: 155 HDR, KE, Ni 156 The ISAKMP header is included in the KE and Ni payloads. But if the 157 initiator generates the following pseudo-random output: 158 HASH = prf(key, Ni | Nr) 159 the ISAKMP headers of the two nonce payloads are not included-- only 160 the body of the payload-- the nonce itself-- is used. 162 3.3 Perfect Forward Secrecy 164 When used in the draft Perfect Forward Secrecy (PFS) refers to the 165 notion that compromise of a single key will permit access to only 166 data protected by a single key. For PFS to exist the key used to 167 protect transmission of data MUST NOT be used to derive any 168 additional keys, and if the key used to protect transmission of data 169 was derived from some other keying material, that material MUST NOT 170 be used to derive any more keys. 172 Perfect Forward Secrecy for both keys and identities is provided in 173 this protocol. (Sections 5.8 and 7). 175 3.4 Security Association 177 A security association (SA) is a set of policy and key used to 178 protect information. The ISAKMP SA is the shared policy and key used 179 by the negotiating peers in this protocol to protect their 180 communication. 182 4. Introduction 184 Oakley defines a method to establish an authenticated key exchange. 185 This includes how payloads are constructed, the information they 186 carry, the order in which they are processed and how they are used. 188 While Oakley defines "modes", ISAKMP defines "phases". The 189 relationship between the two is very straightforward. ISAKMP's phase 190 1 is where the two ISAKMP peers establish a secure, authenticated 191 channel with which to communicate. This is called the ISAKMP 192 Security Association (SA). "Main Mode" and "Aggressive Mode" each 193 accomplish a phase 1 exchange. "Main Mode" and "Aggressive Mode" 194 MUST ONLY be used in phase 1. 196 Phase 2 is where Security Associations are negotiated on behalf of 197 services such as IPsec or any other service which needs key material 198 and/or parameter negotiation. "Quick Mode" accomplishes a phase 2 199 exchange. "Quick Mode" MUST ONLY be used in phase 2. 201 "New Group Mode" is not really a phase 1 or phase 2. It follows 202 phase 1, but serves to establish a new group which can be used in 203 future negotiations. "New Group Mode" MUST ONLY be used in phase 2. 205 The ISAKMP SA is bi-directional. That is, once established, either 206 party may initiate Quick Mode, Informational, and New Group Mode 207 Exchanges. Per the base ISAKMP document, the ISAKMP SA is identified 208 by the Initiator's cookie followed by the Responder's cookie-- the 209 role of each party in the phase 1 exchange dictates which cookie is 210 the Initiator's. The cookie order established by the phase 1 exchange 211 continues to identify the ISAKMP SA regardless of the direction the 212 Quick Mode, Informational, or New Group exchange. In other words, the 213 cookies MUST NOT swap places when the direction of the ISAKMP SA 214 changes. 216 With the use of ISAKMP phases, an implementation can accomplish very 217 fast keying when necessary. A single phase 1 negotiation may be used 218 for more than one phase 2 negotiation. Additionally a single phase 2 219 negotiation can request multiple Security Associations. With these 220 optimizations, an implementation can see less than one round trip per 221 SA as well as less than one DH exponentiation per SA. "Main Mode" 222 for phase 1 provides identity protection. When identity protection 223 is not needed, "Aggressive Mode" can be used to reduce round trips 224 even further. Developer hints for doing these optimizations are 225 included below. It should also be noted that using public key 226 encryption to authenticate an Aggressive Mode exchange will still 227 provide identity protection. 229 The following attributes are used by ISAKMP/Oakley and are negotiated 230 as part of the ISAKMP Security Association. (These attributes 231 pertain only to the ISAKMP Security Association and not to any 232 Security Associations that ISAKMP may be negotiating on behalf of 233 other services.) 235 - encryption algorithm (e.g. DES, IDEA, Blowfish). 237 - hash algorithm (e.g. MD5, SHA) 238 - authentication method (e.g. DSS sig, RSA sig, RSA encryption, 239 pre-shared key) 241 - information about a group over which to do Diffie-Hellman. 243 - prf (e.g. 3DES-CBC-MAC) 245 All of these attributes are mandatory and MUST be negotiated except 246 for the "prf". The "prf" MAY be negotiated, but if it is not, the 247 HMAC (see [KBC96]) version of the negotiated hash algorithm is used 248 as a pseudo-random function. Other non-mandatory attributes are 249 described in Appendix A. The selected hash algorithm MUST support 250 both native and HMAC modes. 252 ISAKMP/Oakley implementations MUST support the following attribute 253 values: 255 - DES-CBC with a weak, and semi-weak, key check (weak and semi- 256 weak keys are referenced in [Sch94] and listed in Appendix A). The 257 key is derived according to Appendix B. 259 - MD5 and SHA. 261 - Authentication via pre-shared keys. The Digital Signature 262 Standard SHOULD be supported; RSA SHOULD also be supported. 264 - MODP over the default group (see below). ECP groups MAY be 265 supported. 267 The ISAKMP/Oakley modes described here MUST be implemented whenever 268 the IETF IPsec DOI [Pip96] is implemented. Other DOIs MAY use the 269 modes described here. 271 5. Exchanges 273 There are two basic methods used to establish an authenticated key 274 exchange: Main Mode and Aggressive Mode. Each generates authenticated 275 keying material from an ephemeral Diffie-Hellman exchange. Main Mode 276 MUST be implemented; Aggressive Mode SHOULD be implemented. In 277 addition, Quick Mode MUST be implemented as a mechanism to generate 278 fresh keying material and negotiate non-ISAKMP security services. In 279 additon, New Group Mode SHOULD be implemented as a mechanism to 280 define private groups for Diffie-Hellman exchanges. Implementations 281 MUST NOT switch exchange types in the middle of an exchange. 283 Exchanges conform to standard ISAKMP [MSST96] payload syntax, 284 attribute encoding, timeouts and retransmits of messages, and 285 informational messages-- e.g a notify response is sent when, for 286 example, a proposal is unacceptable, or a signature verification or 287 decryption was unsuccessful, etc. 289 Main Mode is an instantiation of the ISAKMP Identity Protect 290 Exchange: The first two messages negotiate policy; the next two 291 exchange Diffie-Hellman public values and ancillary data (e.g. 292 nonces) necessary for the exchange; and the last two messages 293 authenticate the Diffie-Hellman Exchange. The authentication method 294 negotiated as part of the initial ISAKMP exchange influences the 295 composition of the payloads but not their purpose. The XCHG for Main 296 Mode is ISAKMP Identity Protect. 298 Similarly, Aggressive Mode is an instantiation of the ISAKMP 299 Aggressive Exchange. The first two messages negotiate policy, 300 exchange Diffie-Hellman public values and ancillary data necessary 301 for the exchange, and identities. In addition the second message 302 authenticates the responder. The third message authenticates the 303 initiator and provides a proof of participation in the exchange. The 304 XCHG for Aggressive Mode is ISAKMP Aggressive. The final message is 305 not sent under protection of the ISAKMP SA allowing each party to 306 postpone exponentiation, if desired, until negotiation of this 307 exchange is complete. 309 Quick Mode and New Group Mode have no analog in ISAKMP. The XCHG 310 values for Quick Mode and New Group Mode are defined in Appendix A. 312 Except where noted, there is no requirement for ISAKMP payloads in 313 any exchagen to be in any particular order. 315 Three different authentication methods are allowed with either Main 316 Mode or Aggressive Mode-- digital signature, public key encryption, 317 or pre-shared key. The value SKEYID is computed seperately for each 318 authentication method. 320 For signatures: SKEYID = prf(Ni | Nr, g^xy) 321 For public key encryption: SKEYID = prf(Ni | Nr, CKY-I | CKY-R) 322 For pre-shared keys: SKEYID = prf(pre-shared-key, Ni | Nr) 324 The result of either Main Mode or Aggressive Mode is three groups of 325 authenticated keying material: 327 SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) 328 SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) 329 SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) 331 and agreed upon policy to protect further communications. The values 332 of 0, 1, and 2 above are represented by a single octet. The key used 333 for encryption is derived from SKEYID_e in an algorithm-specific 334 manner (see appendix B). 336 To authenticate either exchange the initiator of the protocol 337 generates HASH_I and the responder generates HASH_R where: 339 HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAp | IDii) 340 HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDir) 342 For authentication with digital signatures, HASH_I and HASH_R are 343 signed and verified; for authentication with either public key 344 encryption or pre-shared keys, HASH_I and HASH_R directly 345 authenticate the exchange. 347 As mentioned above, the negotiated authentication method influences 348 the content and use of messages for Phase 1 Modes, but not their 349 intent. When using public keys for authentication, the Phase 1 350 exchange can be accomplished either by using signatures or by using 351 public key encryption (if the algorithm supports it). Following are 352 Main Mode Exchanges with different authentication options. 354 5.1 ISAKMP/Oakley Phase 1 Authenticated With Signatures 356 Using signatures, the ancillary information exchanged during the 357 second roundtrip are nonces; the exchange is authenticated by signing 358 a mutually obtainable hash. Main Mode with signature authentication 359 is described as follows: 361 Initiator Responder 362 ---------- ----------- 363 HDR, SA --> 364 <-- HDR, SA 365 HDR, KE, Ni --> 366 <-- HDR, KE, Nr 367 HDR*, IDii, [ CERT, ] SIG_I --> 368 <-- HDR*, IDir, [ CERT, ] SIG_R 370 Aggressive mode with signatures in conjunction with ISAKMP is 371 described as follows: 373 Initiator Responder 374 ----------- ----------- 375 HDR, SA, KE, Ni, IDii --> 376 <-- HDR, SA, KE, Nr, IDir, 377 [ CERT, ] SIG_R 378 HDR, [ CERT, ] SIG_I --> 380 In both modes, the signed data, SIG_I or SIG_R, is the result of the 381 negotiated digital signature algorithm applied to HASH_I or HASH_R 382 respectively. 384 In general the signature will be over HASH_I and HASH_R as above 385 using the negotiated prf, or the HMAC version of the negotiated hash 386 function (if no prf is negotiated). However, this can be overridden 387 for construction of the signature if the signature algorithm is tied 388 to a particular hash algorithm (e.g. DSS is only defined with SHA's 389 160 bit output). In this case, the signature will be over HASH_I and 390 HASH_R as above, except using the HMAC version of the hash algorithm 391 associated with the signature method. The negotiated prf and hash 392 function would continue to be used for all other proscribed pseudo- 393 random functions. 395 Since the hash algorithm used is already known there is no need to 396 encode its OID into the signature. In addition, there is no binding 397 between the OIDs used for RSA signatures in PKCS #1 and those used in 398 this document. Therefore, RSA signatures MUST be encoded as a private 399 key encryption in PKCS #1 format. DSS signatures MUST be encoded as r 400 followed by s. 402 One or more certificate payloads MAY be optionally passed. 404 5.2 Phase 1 Authenticated With Public Key Encryption 406 Using public key encryption to authenticate the exchange, the 407 ancillary information exchanged is encrypted nonces. Each party's 408 ability to reconstruct a hash (proving that the other party decrypted 409 the nonce) authenticates the exchange. 411 In order to perform the public key encryption, the initiator must 412 already have the responder's public key. In the case where the 413 responder has multiple public keys, a hash of the certificate the 414 initiator is using to encrypt the ancillary information is passed as 415 part of the third message. In this way the responder can determine 416 which corresponding private key to use to decrypt the encrypted 417 payloads and identity protection is retained. 419 In addition to the nonce, the identities of the parties (IDii and 420 IDir) are also encrypted with the other party's public key. If the 421 authentication method is public key encryption, the nonce and 422 identity payloads MUST be encrypted with the public key of the other 423 party. Only the body of the payloads are encrypted, the payload 424 headers are left in the clear. 426 When using encrytion for authentication, Main Mode is defined as 427 follows. 429 Initiator Responder 430 ----------- ----------- 431 HDR, SA --> 432 <-- HDR, SA 433 HDR, KE, [ HASH(1), ] 434 PubKey_r, 435 PubKey_r --> 436 HDR, KE, PubKey_i, 437 <-- PubKey_i 438 HDR*, HASH_I --> 439 <-- HDR*, HASH_R 441 Aggressive Mode authenticated with encryption is described as 442 follows: 444 Initiator Responder 445 ----------- ----------- 446 HDR, SA, [ HASH(1),] KE, 447 Pubkey_r, 448 Pubkey_r --> 449 HDR, SA, KE, PubKey_i, 450 <-- PubKey_r, HASH_R 451 HDR, HASH_I --> 453 Where HASH(1) is a hash (using the negotiated hash function) of the 454 certificate which the initiator is using to encrypt the nonce and 455 identity. 457 RSA encryption MUST be encoded in PKCS #1 format. The payload length 458 is the length of the entire encrypted payload plus header. The PKCS 459 #1 encoding allows for determination of the actual length of the 460 cleartext payload upon decryption. 462 Using encryption for authentication provides for a plausably deniable 463 exchange. There is no proof (as with a digital signature) that the 464 conversation ever took place since each party can completely 465 reconstruct both sides of the exchange. In addition, security is 466 added to secret generation since an attacker would have to 467 successfully break not only the Diffie-Hellman exchange but also both 468 RSA encryptions. This exchange was motivated by [Kra96]. 470 Note that, unlike other authentication methods, authentication with 471 public key encryption allows for identity protection with Aggressive 472 Mode. 474 5.3 Phase 1 Authenticated With a Pre-Shared Key 476 A key derived by some out-of-band mechanism may also be used to 477 authenticate the exchange. The actual establishment of this key is 478 out of the scope of this document. 480 When doing a pre-shared key authentication, Main Mode is defined as 481 follows: 483 Initiator Responder 484 ---------- ----------- 485 HDR, SA --> 486 <-- HDR, SA 487 HDR, KE, Ni --> 488 <-- HDR, KE, Nr 489 HDR*, IDii, HASH_I --> 490 <-- HDR*, IDir, HASH_R 492 Aggressive mode with a pre-shared key is described as follows: 494 Initiator Responder 495 ----------- ----------- 496 HDR, SA, KE, Ni, IDii --> 497 <-- HDR, SA, KE, Nr, IDir, HASH_R 498 HDR, HASH_I --> 500 When using pre-shared key authentication with Main Mode the key can 501 only be identified by the IP address of the peers since HASH_I must 502 be computed before the initiator has processed IDir. Aggressive Mode 503 allows for a wider range of identifiers of the pre-shared secret to 504 be used. In addition, Aggressive Mode allows two parties to maintain 505 multiple, different pre-shared keys and identify the correct one for 506 a particular exchange. 508 5.4 Phase 2 - Quick Mode 510 Quick Mode is not a complete exchange itself, but is used as part of 511 the ISAKMP SA negotiation process (phase 2) to derive keying material 512 and negotiate shared policy for non-ISAKMP SAs. The information 513 exchanged along with Quick Mode MUST be protected by the ISAKMP SA-- 514 i.e. all payloads except the ISAKMP header are encrypted. In Quick 515 Mode, a HASH payload must immediately follow the ISAKMP header. This 516 HASH authenticates the message and also provides liveliness proofs. 518 Quick Mode is essentially an exchange of nonces that provides replay 519 protection. The nonces are used to generate fresh key material and 520 prevent replay attacks from generating bogus security associations. 521 An optional Key Exchange payload can be exchanged to allow for an 522 additional Diffie-Hellman exchange and exponentiation per Quick Mode. 523 While use of the key exchange payload with Quick Mode is optional it 524 MUST be supported. 526 Base Quick Mode (without the KE payload) refreshens the keying 527 material derived from the exponentiation in phase 1. This does not 528 provide PFS. Using the optional KE payload, an additional 529 exponentiation is performed and PFS is provided for the keying 530 material. If a KE payload is sent, a Diffie-Hellman group (see 531 section 5.7.1 and [Pip96]) MUST be sent as attributes of the SA being 532 negotiated. 534 Quick Mode is defined as follows: 536 Initiator Responder 537 ----------- ----------- 538 HDR*, HASH(1), SA, Ni 539 [, KE ] [, IDui, IDur ] --> 540 <-- HDR*, HASH(2), SA, Nr 541 [, KE ] [, IDui, IDur ] 542 HDR*, HASH(3) --> 544 Where: 545 HASH(1) is the prf over the message id (M-ID) from the ISAKMP 546 header concatenated with the entire message that follows the hash 547 including all payload headers, but excluding any padding added for 548 encryption. HASH(2) is identical to HASH(1) except the initiator's 549 nonce-- Ni, minus the payload header-- is added after M-ID but before 550 the complete message. The addition of the nonce to HASH(2) is for a 551 liveliness proff. HASH(3)-- for liveliness-- is the prf over the 552 value zero represented as a single octet, followed by a concatenation 553 of the message id and the two nonces-- the initiator's followed by 554 the responder's-- minus the payload header. In other words, the 555 hashes for the above exchange are: 557 HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDui | IDur ]) 558 HASH(2) = prf(SKEYID_a, M-ID | Ni | SA | Nr [ | KE ] [ | IDui | 559 IDur ]) 560 HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni | Nr) 562 If PFS is not needed, and KE payloads are not exchanged, the new 563 keying material is defined as KEYMAT = prf(SKEYID_d, protocol | SPI | 564 Ni | Nr). 566 If PFS is desired and KE payloads were exchanged, the new keying 567 material is defined as KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | 568 SPI | Ni | Nr), where g(qm)^xy is the shared secret from the 569 ephemeral Diffie-Hellman exchange of this Quick Mode. 571 In either case, "protocol" and "SPI" are from the ISAKMP Proposal 572 Payload that contained the negotiated Transform. 574 A single SA negotiation results in two security assocations-- one 575 inbound and one outbound. Different SPIs for each SA (one chosen by 576 the initiator, the other by the responder) guarantee a different key 577 for each direction. The SPI chosen by the destination of the SA is 578 used to derive KEYMAT for that SA. 580 For situations where the amount of keying material desired is greater 581 than that supplied by the prf, KEYMAT is expanded by feeding the 582 results of the prf back into itself and concatenating results until 583 the required keying material has been reached. In other words, 585 KEYMAT = K1 | K2 | K3 | ... 586 where 587 K1 = prf(SKEYID_d, [ g(qm)^xy | ] SPI | Ni | Nr) 588 K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] SPI | Ni | Nr) 589 K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] SPI | Ni | Nr) 590 etc. 592 This keying material (whether with PFS or without, and whether 593 derived directly or through concatenation) MUST be used with the 594 negotiated SA. It is up to the service to define how keys are derived 595 from the keying material. 597 In the case of an ephemeral Diffie-Hellman exchange in Quick Mode, 598 the exponential (g(qm)^xy) is irretreivably removed from the current 599 state and SKEYID_e and SKEYID_a (derived from phase 1 negotiation) 600 continue to protect and authenticate the ISAKMP SA and SKEYID_d 601 continues to be used to derive keys. 603 If ISAKMP is acting as a proxy negotiator on behalf of another party 604 the identities of the parties MUST be passed as IDui and then IDur. 605 Local policy will dictate whether the proposals are acceptible for 606 the identities specified. If IDs are not exchanged, the negotiation 607 is assumed to be done on behalf of each ISAKMP peer. If an ID range 608 (see Appendix A of [Pip96]) is not acceptable (for example, the 609 specified subnet is too large) a BAD_ID_RANGE notify message followed 610 by an acceptible ID range, in an ID payload, MUST be sent. 612 Using Quick Mode, multiple SA's and keys can be negotiated with one 613 exchange as follows: 615 Initiator Responder 616 ----------- ----------- 617 HDR*, HASH(1), SA0, SA1, Ni, 618 [, KE ] [, IDui, IDur ] --> 619 <-- HDR*, HASH(2), SA0, SA1, Nr, 620 [, KE ] [, IDui, IDur ] 621 HDR*, HASH(3) --> 623 The keying material is derived identically as in the case of a single 624 SA. In this case (negotiation of two SA payloads) the result would be 625 four security associations-- two each way for both SAs. 627 5.5 New Group Mode 629 New Group Mode MUST NOT be used prior to establishment of an ISAKMP 630 SA. The description of a new group MUST only follow phase 1 631 negotiation. (It is not a phase 2 exchange, though). 633 Initiator Responder 634 ----------- ----------- 635 HDR*, HASH(1), SA --> 636 <-- HDR*, HASH(2), SA 638 where HASH(1) is the prf output, using SKEYID_a as the key, and the 639 message-ID from the ISAKMP header concatenated with the entire SA 640 proposal, body and header, as the data; HASH(2) is the prf output, 641 using SKEYID_a as the key, and the message-ID from the ISAKMP header 642 concatenated with the reply as the data. In other words the hashes 643 for the above exchange are: 645 HASH(1) = prf(SKEYID_a, M-ID | SA) 646 HASH(2) = prf(SKEYID_a, M-ID | SA) 648 The proposal will specify the characteristics of the group (see 649 appendix A, "Attribute Assigned Numbers"). Group descriptions for 650 private Groups MUST be greater than or equal to 2^15. If the group 651 is not acceptable, the responder MUST reply with a Notify payload 652 with the message type set to GROUP_NOT_ACCEPTABLE (13). 654 ISAKMP implementations MAY require private groups to expire with the 655 SA under which they were established. 657 Groups may be directly negotiated in the SA proposal with Main Mode. 658 To do this the Prime, Generator (using the Generator One attribute 659 class from Appendix A), and Group Type are passed as SA attributes 660 (see Appendix A in [MSST96]). Alternately, the nature of the group 661 can be hidden using New Group Mode and only the group identifier is 662 passed in the clear during phase 1 negotiation. 664 5.6 ISAKMP Informational Exchanges 666 This protocol protects ISAKMP Informational Exchanges when possible. 667 Once the ISAKMP security association has been established (and 668 SKEYID_e and SKEYID_a have been generated) ISAKMP Information 669 Exchanges, when used with this protocol, are as follows: 671 Initiator Responder 672 ----------- ----------- 673 HDR*, HASH(1), N/D --> 675 where N/D is either an ISAKMP Notify Payload or an ISAKMP Delete 676 Payload and HASH(1) is the prf output, using SKEYID_a as the key, and 677 the entire informational payload (either a Notify or Delete) as the 678 data. In other words, the hash for the above exchange is: 680 HASH(1) = prf(SKEYID_a, M-ID | N/D) 682 If the ISAKMP security association has not yet been established at 683 the time of the Informational Exchange, the exchange is done in the 684 clear without an accompanying HASH payload. 686 5.7 Oakley Groups 688 With ISAKMP/Oakley, the group in which to do the Diffie-Hellman 689 exchange is negotiated. The value 0 indicates no group. The values 1 690 and 2 indicate the default groups described below. The attribute 691 class for "Group" is defined in Appendix A. Other groups are also 692 defined in [Orm96]. All values 2^15 and higher are used for private 693 group identifiers. For a discussion on the strength of the default 694 Oakley groups please see the Security Considerations section below. 696 5.7.1 First Oakley Default Group 698 Oakley implementations MUST support a MODP group with the following 699 prime and generator. This group is assigned id 1 (one). 701 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 702 Its hexadecimal value is 704 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 705 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 706 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 707 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 709 The generator is: 2. 711 5.7.2 Second Oakley Group 713 ISAKMP/Oakley implementations MUST support a MODP group with the 714 following prime and generator. This group is assigned id 2 (two). 716 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 717 Its hexadecimal value is 719 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 720 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 721 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 722 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 723 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 724 FFFFFFFF FFFFFFFF 726 The generator is 2 (decimal) 728 Other groups can be defined using New Group Mode. These default 729 groups were generated by Richard Schroeppel at the University of 730 Arizona. Properties of these primes are described in [Orm96]. 732 5.8 Payload Explosion for Complete a ISAKMP/Oakley Exchange 734 This section illustrates how the ISAKMP/Oakley protocol is used to: 736 - establish a secure and authenticated channel between ISAKMP 737 processes (phase 1); and 739 - generate key material for, and negotiate, an IPsec SA (phase 2). 741 5.8.1 Phase 1 using Main Mode 743 The following diagram illustrates the payloads exchanged between the 744 two parties in the first round trip exchange. The initiator MAY 745 propose several proposals; the responder MUST reply with one. 747 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 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 ~ ISAKMP Header with XCHG of Main Mode, ~ 750 ~ and Next Payload of ISA_SA ~ 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 ! 0 ! RESERVED ! Payload Length ! 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 ! Domain of Interpretation (IPsec DOI) ! 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 ! Situation ! 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 ! 0 ! RESERVED ! Payload Length ! 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 ! Proposal #1 ! PROTO_ISAKMP ! SPI size | # Transforms ! 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 ~ SPI (8 octets) ~ 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 ! ISA_TRANS ! RESERVED ! Payload Length ! 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 ! Transform #1 ! KEY_OAKLEY | RESERVED2 ! 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 ~ prefered SA attributes ~ 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 ! 0 ! RESERVED ! Payload Length ! 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 ! Transform #2 ! KEY_OAKLEY | RESERVED2 ! 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 ~ alternate SA attributes ~ 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 The responder replies in kind but selects, and returns, one transform 778 proposal (the ISAKMP SA attributes). 780 The second exchange consists of the following payloads: 782 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 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 ~ ISAKMP Header with XCHG of Main Mode, ~ 785 ~ and Next Payload of ISA_KE ~ 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 ! ISA_NONCE ! RESERVED ! Payload Length ! 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 ~ D-H Public Value (g^xi from initiator g^xr from responder) ~ 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 ! 0 ! RESERVED ! Payload Length ! 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 ~ Ni (from initiator) or Nr (from responder) ~ 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 The shared keys, SKEYID_e and SKEYID_a, are now used to protect and 797 authenticate all further communication. Note that both SKEYID_e and 798 SKEYID_a are unauthenticated. 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 ~ ISAKMP Header with XCHG of Main Mode, ~ 803 ~ and Next Payload of ISA_ID and the encryption bit set ~ 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 ! ISA_SIG ! RESERVED ! Payload Length ! 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 ~ Identification Data of the ISAKMP negotiator ~ 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 ! 0 ! RESERVED ! Payload Length ! 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 ~ signature verified by the public key of the ID above ~ 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 The key exchange is authenticated over a signed hash as described in 815 section 5.1. Once the signature has been verified using the 816 authentication algorithm negotiated as part of the ISAKMP SA, the 817 shared keys, SKEYID_e and SKEYID_a can be marked as authenticated. 818 (For brevity, certificate payloads were not exchanged). 820 5.8.2 Phase 2 using Quick Mode 822 The following payloads are exchanged in the first round of Quick 823 Mode with ISAKMP SA negotiation. In this hypothetical exchange, the 824 ISAKMP negotiators are proxies for other parties which have requested 825 authentication. 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 ~ ISAKMP Header with XCHG of Quick Mode, ~ 830 ~ Next Payload of ISA_HASH and the encryption bit set ~ 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 ! ISA_SA ! RESERVED ! Payload Length ! 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 ~ keyed hash of message ~ 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 ! ISA_NONCE ! RESERVED ! Payload Length ! 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 ! Domain Of Interpretation (DOI) ! 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 ! Situation ! 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 ! 0 ! RESERVED ! Payload Length ! 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 ! Proposal #1 ! PROTO_IPSEC_AH! SPI size | # Transforms ! 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 ~ SPI (8 octets) ~ 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 ! ISA_TRANS ! RESERVED ! Payload Length ! 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 ! Transform #1 ! AH_SHA | RESERVED2 ! 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 ! other SA attributes ! 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 ! 0 ! RESERVED ! Payload Length ! 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 ! Transform #1 ! AH_MD5 | RESERVED2 ! 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 ! other SA attributes ! 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 ! ISA_ID ! RESERVED ! Payload Length ! 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 ~ nonce ~ 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 ! ISA_ID ! RESERVED ! Payload Length ! 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 ~ ID of source for which ISAKMP is a proxy ~ 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 ! 0 ! RESERVED ! Payload Length ! 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 ~ ID of destination for which ISAKMP is a proxy ~ 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 where the contents of the hash are described in 5.4 above. The 874 responder replies with a similar message which only contains one 875 transform-- the selected AH transform. Upon receipt, the initiator 876 can provide the key engine with the negotiated security association 877 and the keying material. As a check against replay attacks, the 878 responder waits until receipt of the next message. 880 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 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 ~ ISAKMP Header with XCHG of Quick Mode, ~ 883 ~ Next Payload of ISA_HASH and the encryption bit set ~ 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 ! 0 ! RESERVED ! Payload Length ! 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 ~ hash data ~ 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 where the contents of the hash are described in 5.4 above. 892 5.9 Perfect Forward Secrecy Example 893 This protocol can provide PFS of both keys and identities. The 894 identies of both the ISAKMP negotiating peer and, if applicable, the 895 identities for whom the peers are negotiating can be protected with 896 PFS. 898 To provide Perfect Forward Secrecy of both keys and all identities, 899 two parties would perform the following: 900 o A Main Mode Exchange to protect the identities of the ISAKMP 901 peers. 902 This establishes an ISAKMP SA. 903 o A Quick Mode Exchange to negotiate other security protocol 904 protection. 905 This establishes a SA on each end for this protocol. 906 o Delete the ISAKMP SA and its associated state. 907 Since the key for use in the non-ISAKMP SA was derived from the 908 single ephemeral Diffie-Hellman exchange PFS is preserved. 910 To provide Perfect Forward Secrecy of merely the keys of a non-ISAKMP 911 security association, it in not necessary to do a phase 1 exchange if 912 an ISAKMP SA exists between the two peers. A single Quick Mode in 913 which the optional KE payload is passed, and an additional Diffie- 914 Hellman exchange is performed, is all that is required. At this point 915 the state derived from this Quick Mode must be deleted from the 916 ISAKMP SA as described in section 5.4. 918 6. Implementation Hints 920 Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2 921 negotiations extremely quick. As long as the Phase 1 state remains 922 cached, and PFS is not needed, Phase 2 can proceed without any 923 exponentiation. How many Phase 2 negotiations can be performed for a 924 single Phase 1 is a local policy issue. The decision will depend on 925 the strength of the algorithms being used and level of trust in the 926 peer system. 928 An implementation may wish to negotiate a range of SAs when 929 performing Quick Mode. By doing this they can speed up the "re- 930 keying". Quick Mode defines how KEYMAT is defined for a range of SAs. 931 When one peer feels it is time to change SAs they simply use the next 932 one within the stated range. A range of SAs can be established by 933 negotiating multiple SAs (identical attributes, different SPIs) with 934 one Quick Mode. 936 An optimization that is often useful is to establish Security 937 Associations with peers before they are needed so that when they 938 become needed they are already in place. This ensures there would be 939 no delays due to key management before initial data transmission. 940 This optimization is easily implemented by setting up more than one 941 Security Association with a peer for each requested Security 942 Association and caching those not immediately used. 944 Also, if an ISAKMP implementation is alerted that a SA will soon be 945 needed (e.g. to replace an existing SA that will expire in the near 946 future), then it can establish the new SA before that new SA is 947 needed. 949 The base ISAKMP specification describes conditions in which one party 950 of the protocol may inform the other party of some activity-- either 951 deletion of a security association or in response to some error in 952 the protocol such as a signature verification failed or a payload 953 failed to decrypt. It is strongly suggested that these Informational 954 exchanges not be responded to under any circumstances. Such a 955 condition may result in a "notify war" in which failure to understand 956 a message results in a notify to the peer who cannot understand it 957 and sends his own notify back which is also not understood. 959 7. Security Considerations 961 This entire draft discusses a hybrid protocol, combining Oakley with 962 ISAKMP, to negotiate, and derive keying material for, security 963 associations in a secure and authenticated manner. 965 Confidentiality is assured by the use of a negotiated encryption 966 algorithm. Authentication is assured by the use of a negotiated 967 method: a digital signature algorithm; a public key algorithm which 968 supports encryption; or, a pre-shared key. The confidentiality and 969 authentication of this exchange is only as good as the attributes 970 negotiated as part of the ISAKMP security association. 972 Repeated re-keying using Quick Mode can consume the entropy of the 973 Diffie- Hellman shared secret. Implementors should take note of this 974 fact and set a limit on Quick Mode Exchanges between exponentiations. 975 This draft does not prescribe such a limit. 977 Perfect Forward Secrecy (PFS) of both keying material and identities 978 is possible with this protocol. By specifying a Diffie-Hellman group, 979 and passing public values in KE payloads, ISAKMP peers can establish 980 PFS of keys-- the identities would be protected by SKEYID_e from the 981 ISAKMP SA and would therefore not be protected by PFS. If PFS of both 982 keying material and identities is desired, an ISAKMP peer MUST 983 establish only one non-ISAKMP security association (e.g. IPsec 984 Security Association) per ISAKMP SA. PFS for keys and identities is 985 accomplished by deleting the ISAKMP SA (and optionally issuing a 986 DELETE message) upon establishment of the single non-ISAKMP SA. In 987 this way a phase one negotiation is uniquely tied to a single phase 988 two negotiation, and the ISAKMP SA established during phase one 989 negotiation is never used again. 991 The strength of a key derived from a MODP Diffie-Hellman exchange 992 depends on the size of the prime used and also the inherent strength 993 of the group. The first default Oakley group for Diffie-Hellman 994 exchanges defined in this document provides enough strength for DES-- 995 56 bits-- with an exponent no less than 160 bits. The second default 996 Oakley group for Diffie-Hellman exchanges defined in this document 997 provides around 80 bits of strength with an exponent no less than 160 998 bits. Implementations should make note of these conservative 999 estimates when establishing policy and negotiating security 1000 parameters. 1002 Note that these limitations are on the Diffie-Hellman groups 1003 themselves. There is nothing in ISAKMP/Oakley which prohibits using 1004 stronger groups nor is there anything which will dilute the strength 1005 obtained from stronger groups. In fact, the extensible framework of 1006 ISAKMP/Oakley encourages the definition of more groups; use of 1007 elliptical curve groups will greatly increase strength using much 1008 smaller numbers. At the time of this writing there were no Elliptical 1009 Curve groups to use with ISAKMP/Oakley. 1011 For situations where defined groups provide insufficient strength New 1012 Group Mode can be used to exchange a Diffie-Hellman group which 1013 provides the necessary strength. In is incumbent upon implementations 1014 to check the primality in groups being offered and independently 1015 arrive at strength estimates. 1017 It is assumed that the Diffie-Hellman exponents in this exchange are 1018 erased from memory after use. In particular, these exponents must not 1019 be derived from long-lived secrets like the seed to a pseudo-random 1020 generator. 1022 8. Acknowledgements 1024 This document is the result of close consultation with Hugo Krawczyk, 1025 Douglas Maughan, Hilarie Orman, Mark Schertler, Mark Schneider, and 1026 Jeff Turner. It relies on protocols which were written by them. 1027 Without their interest and dedication, this would not have been 1028 written. 1030 We would also like to thank Cheryl Madson, Harry Varnis, and Elfed 1031 Weaver for technical input. 1033 9. References 1035 [Acm97] Adams, C.M., "Constructing Symmetric Ciphers Using the CAST 1036 Design Procedure", Designs, Codes and Cryptorgraphy (to appear). 1038 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 1039 Requirement Levels", RFC2119, March 1997. 1041 [KBC96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing 1042 for Message Authentication", RFC 2104, February 1997. 1044 [Kra96] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 1045 Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium 1046 on Network and Distributed Systems Security. 1048 [MSST96] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., 1049 "Internet Security Association and Key Management Protocol (ISAKMP)", 1050 version 8, draft-ietf-ipsec-isakmp-08.{ps,txt}. 1052 [Orm96] Orman, H., "The Oakley Key Determination Protocol", version 1053 1, TR97-92, Department of Computer Science Technical Report, 1054 University of Arizona. 1056 [Pip96] Piper, D., "The Internet IP Security Domain Of Interpretation 1057 for ISAKMP", version 3, draft-ietf-ipsec-ipsec-doi-03.txt. 1059 [Sch94] Schneier, B., "Applied Cryptography, Protocols, Algorithms, 1060 and Source Code in C", 2nd edition. 1062 Appendix A 1064 This is a list of DES Weak and Semi-Weak keys. The keys come from 1065 [Sch94]. All keys are listed in hexidecimal. 1067 DES Weak Keys 1068 0101 0101 0101 0101 1069 1F1F 1F1F E0E0 E0E0 1070 E0E0 E0E0 1F1F 1F1F 1071 FEFE FEFE FEFE FEFE 1073 DES Semi-Weak Keys 1074 01FE 01FE 01FE 01FE 1075 1FE0 1FE0 0EF1 0EF1 1076 01E0 01E0 01F1 01F1 1077 1FFE 1FFE 0EFE 0EFE 1078 011F 011F 010E 010E 1079 E0FE E0FE F1FE F1FE 1081 FE01 FE01 FE01 FE01 1082 E01F E01F F10E F10E 1083 E001 E001 F101 F101 1084 FE1F FE1F FE0E FE0E 1085 1F01 1F01 0E01 0E01 1086 FEE0 FEE0 FEF1 FEF1 1088 Attribute Assigned Numbers 1090 Attributes negotiated during phase one use the following definitions. 1091 Phase two attributes are defined in the applicable DOI specification 1092 (for example, IPsec attributes are defined in the IPsec DOI), with 1093 the exception of a group description when Quick Mode includes an 1094 ephemeral Diffie-Hellman exchange. Attribute types can be either 1095 Basic (B) or Variable-length (V). Encoding of these attributes is 1096 defined in the base ISAKMP specification. 1098 Attribute Classes 1100 class value type 1101 ------------------------------------------------------------------- 1102 Encryption Algorithm 1 B 1103 Hash Algorithm 2 B 1104 Authentication Method 3 B 1105 Group Description 4 B 1106 Group Type 5 B 1107 Group Prime 6 V 1108 Group Generator One 7 V 1109 Group Generator Two 8 V 1110 Group Curve A 9 V 1111 Group Curve B 10 V 1112 Life Type 11 B 1113 Life Duration 12 B/V 1114 PRF 13 B 1115 Key Length 14 B 1117 Class Values 1119 - Encryption Algorithm 1120 DEC-CBC 1 1121 IDEA-CBC 2 1122 Blowfish-CBC 3 1123 RC5-R16-B64-CBC 4 1124 3DES-CBC 5 1125 CAST-CBC 6 1127 values 7-65000 are reserved. Values 65001-65535 are for private use 1128 among mutually consenting parties. 1130 - Hash Algorithm 1131 MD5 1 1132 SHA 2 1133 Tiger 3 1135 values 4-65000 are reserved. Values 65001-65535 are for private use 1136 among mutually consenting parties. 1138 - Authentication Method 1139 pre-shared key 1 1140 DSS signatures 2 1141 RSA signatures 3 1142 RSA encryption 4 1144 values 5-65000 are reserved. Values 65001-65535 are for private use 1145 among mutually consenting parties. 1147 - Group Description 1148 default group (section 5.7.1) 1 1150 values 2-32767 are reserved. Values 32768-65535 are for private use 1151 among mutually consenting parties. 1153 - Group Type 1154 MODP (modular exponentiation group) 1 1155 ECP (elliptic curve group over GF[P]) 2 1156 EC2N (elliptic curve group over GF[2^N]) 3 1158 values 4-65000 are reserved. Values 65001-65535 are for private use 1159 among mutually consenting parties. 1161 - Life Type 1162 seconds 1 1163 kilobytes 2 1165 values 3-65000 are reserved. Values 65001-65535 are for private use 1166 among mutually consenting parties. For a given "Life Type" the 1167 value of the "Life Duration" attribute defines the actual length of 1168 the SA life-- either a number of seconds, or a number of kbytes 1169 protected. 1171 - PRF 1172 3DES-CBC-MAC 1 1174 values 2-65000 are reserved. Values 65001-65535 are for private use 1175 among mutually consenting parties 1177 - Key Length 1179 When using an Encryption Algorithm that has a variable length key, 1180 this attribute specifies the key length in bits. (MUST use network 1181 byte order). 1183 Additional Exchanges Defined-- XCHG values 1184 Quick Mode 32 1185 New Group Mode 33 1187 Appendix B 1189 This appendix describes encryption details to be used ONLY when 1190 encrypting ISAKMP messages. When a service (such as an IPSEC 1191 transform) utilizes ISAKMP to generate keying material, all 1192 encryption algorithm specific details (such as key and IV generation, 1193 padding, etc...) MUST be defined by that service. ISAKMP does not 1194 purport to ever produce keys that are suitable for any encryption 1195 algorithm. ISAKMP produces the requested amount of keying material 1196 from which the service MUST generate a suitable key. Details, such 1197 as weak key checks, are the responsibility of the service. 1199 Use of negotiated PRFs may require the PRF output to be expanded. For 1200 instance, 3DES-CBC-MAC produces 8 bytes of output which must be used 1201 as a key to another 3DES-CBC-MAC function call. The output of a PRF 1202 is expanded by feeding back the results of the PRF into itself to 1203 generate successive blocks. These blocks are concatenated until the 1204 requisite number of bytes has been acheived. For example, for pre- 1205 shared key authentication with 3DES-CBC-MAC as the negotiated PRF: 1207 BLOCK1-8 = prf(pre-shared-key, Ni | Nr) 1208 BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni | Nr) 1209 BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni | Nr) 1210 and 1211 SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 1213 so therefore to derive SKEYID_d: 1215 BLOCK1-8 = prf(SKEYID, g^xy | CKY-I | CKY-R) 1216 BLOCK9-16 = prf(SKEYID, BLOCK1-8 | g^xy | CKY-I | CKY-R) 1217 BLOCK17-24 = prf(SKEYID, BLOCK9-16 | g^xy | CKY-I | CKY-R) 1218 and 1219 SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 1221 Subsequent PRF derivations are done similarly. 1223 Encryption keys used to protect the ISAKMP SA are derived from 1224 SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long 1225 enough to supply all the necessary keying material an algorithm 1226 requires, the key is derived from feeding the results of a pseudo- 1227 random function into itself, concatenating the results, and taking 1228 the highest necessary bits. 1230 For example, if (ficticious) algorithm AKULA requires 320-bits of key 1231 (and has no weak key check) and the prf used to generate SKEYID_e 1232 only generates 120 bits of material, the key for AKULA, would be the 1233 first 320-bits of Ka, where: 1235 Ka = K1 | K2 | K3 1236 and 1237 K1 = prf(SKEYID_e, 0) 1238 K2 = prf(SKEYID_e, K1) 1239 K3 = prf(SKEYID_e, K2) 1241 where prf is the HMAC version of the negotiated hash function or the 1242 negotiated prf. and 0 is represented by a single octet. Each result 1243 of the prf provides 120 bits of material for a total of 360 bits. 1244 AKULA would use the first 320 bits of that 360 bit string. 1246 In phase 1, material for the initialization vector (IV material) for 1247 CBC mode encryption algorithms is derived from a hash of a 1248 concatenation of the initiator's public Diffie-Hellman value and the 1249 responder's public Diffie-Hellman value using the negotiated hash 1250 algorithm. This is used for the first message only. Each message 1251 should be padded up to the nearest block size using bytes containing 1252 0x00. The message length in the header MUST include the length of the 1253 pad since this reflects the size of the cyphertext. Subsequent 1254 messages MUST use the last CBC encryption block from the previous 1255 message as their initialization vector. 1257 In phase 2, material for the initialization vector for CBC mode 1258 encryption of the first message of a Quick Mode exchange is derived 1259 from a hash of a concatenation of the last phase 1 CBC output block 1260 and the phase 2 message id using the negotiated hash algorithm. The 1261 IV for subsequent messages within a Quick Mode exchange is the CBC 1262 output block from the previous message. Padding and IVs for 1263 subsequent messages are done as in phase 1. 1265 Note that the final phase 1 CBC output block, the result of 1266 encryption/decryption of the last phase 1 message, must be retained 1267 in the ISAKMP SA state to allow for generation of unique IVs for each 1268 Quick Mode. Each phase 2 exchange generates IVs independantly to 1269 prevent IVs from getting out of sync when two different Quick Modes 1270 are started simultaneously. 1272 The key for DES-CBC is derived from the first eight (8) non-weak and 1273 non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first 1274 8 bytes of the IV material derived above. 1276 The key for IDEA-CBC is derived from the first sixteen (16) bytes of 1277 SKEYID_e. The IV is the first eight (8) bytes of the IV material 1278 derived above. 1280 The key for Blowfish-CBC is either the negotiated key size, or the 1281 first fifty-six (56) bytes of a key (if no key size is negotiated) 1282 derived in the aforementioned pseudo-random function feedback method. 1284 The IV is the first eight (8) bytes of the IV material derived above. 1286 The key for RC5-R16-B64-CBC is the negotiated key length, or the 1287 first sixteen (16) bytes of a key (if no key size is negotiated) 1288 derived from the aforementioned pseudo-random function feedback 1289 method if necessary. The IV is the first eight (8) bytes of the IV 1290 material derived above. The number of rounds MUST be 16 and the block 1291 size MUST be 64. 1293 The key for 3DES-CBC is the first twenty-four (24) bytes of a key 1294 derived in the aforementioned pseudo-random function feedback method. 1295 3DES-CBC is an encrypt-decrypt-encrypt operation using the first, 1296 middle, and last eight (8) bytes of the entire 3DES-CBC key. The IV 1297 is the first eight (8) bytes of the IV material derived above. 1299 The key for CAST-CBC is either the negotiated key size, or the first 1300 sixteen (16) bytes of a key derived in the aforementioned pseudo- 1301 random function feedback method. The IV is the first eight (8) bytes 1302 of the IV material derived above. 1304 Support for algorithms other than DES-CBC is purely optional. Some 1305 optional algorithms may be subject to intellectual property claims. 1307 Authors' Addresses: 1309 Dan Harkins 1310 cisco Systems 1311 170 W. Tasman Dr. 1312 San Jose, California, 95134-1706 1313 United States of America 1314 +1 408 526 4000 1316 Dave Carrel 1317 76 Lippard Ave. 1318 San Francisco, CA 94131-2947 1319 United States of America 1320 +1 415 337 8469 1322 Authors' Note: 1324 The authors encourage independent implementation, and 1325 interoperability testing, of this hybrid protocol.