1 2 3 4 5 6 7Network Working Group D. Harkins 8Request for Comments: 2409 D. Carrel 9Category: Standards Track cisco Systems 10 November 1998 11 12 13 The Internet Key Exchange (IKE) 14 15Status of this Memo 16 17 This document specifies an Internet standards track protocol for the 18 Internet community, and requests discussion and suggestions for 19 improvements. Please refer to the current edition of the "Internet 20 Official Protocol Standards" (STD 1) for the standardization state 21 and status of this protocol. Distribution of this memo is unlimited. 22 23Copyright Notice 24 25 Copyright (C) The Internet Society (1998). All Rights Reserved. 26 27Table Of Contents 28 29 1 Abstract........................................................ 2 30 2 Discussion...................................................... 2 31 3 Terms and Definitions........................................... 3 32 3.1 Requirements Terminology...................................... 3 33 3.2 Notation...................................................... 3 34 3.3 Perfect Forward Secrecty...................................... 5 35 3.4 Security Association.......................................... 5 36 4 Introduction.................................................... 5 37 5 Exchanges....................................................... 8 38 5.1 Authentication with Digital Signatures........................ 10 39 5.2 Authentication with Public Key Encryption..................... 12 40 5.3 A Revised method of Authentication with Public Key Encryption. 13 41 5.4 Authentication with a Pre-Shared Key.......................... 16 42 5.5 Quick Mode.................................................... 16 43 5.6 New Group Mode................................................ 20 44 5.7 ISAKMP Informational Exchanges................................ 20 45 6 Oakley Groups................................................... 21 46 6.1 First Oakley Group............................................ 21 47 6.2 Second Oakley Group........................................... 22 48 6.3 Third Oakley Group............................................ 22 49 6.4 Fourth Oakley Group........................................... 23 50 7 Payload Explosion of Complete Exchange.......................... 23 51 7.1 Phase 1 with Main Mode........................................ 23 52 7.2 Phase 2 with Quick Mode....................................... 25 53 8 Perfect Forward Secrecy Example................................. 27 54 9 Implementation Hints............................................ 27 55 56 57 58Harkins & Carrel Standards Track [Page 1] 59 60RFC 2409 IKE November 1998 61 62 63 10 Security Considerations........................................ 28 64 11 IANA Considerations............................................ 30 65 12 Acknowledgments................................................ 31 66 13 References..................................................... 31 67 Appendix A........................................................ 33 68 Appendix B........................................................ 37 69 Authors' Addresses................................................ 40 70 Authors' Note..................................................... 40 71 Full Copyright Statement.......................................... 41 72 731. Abstract 74 75 ISAKMP ([MSST98]) provides a framework for authentication and key 76 exchange but does not define them. ISAKMP is designed to be key 77 exchange independant; that is, it is designed to support many 78 different key exchanges. 79 80 Oakley ([Orm96]) describes a series of key exchanges-- called 81 "modes"-- and details the services provided by each (e.g. perfect 82 forward secrecy for keys, identity protection, and authentication). 83 84 SKEME ([SKEME]) describes a versatile key exchange technique which 85 provides anonymity, repudiability, and quick key refreshment. 86 87 This document describes a protocol using part of Oakley and part of 88 SKEME in conjunction with ISAKMP to obtain authenticated keying 89 material for use with ISAKMP, and for other security associations 90 such as AH and ESP for the IETF IPsec DOI. 91 922. Discussion 93 94 This memo describes a hybrid protocol. The purpose is to negotiate, 95 and provide authenticated keying material for, security associations 96 in a protected manner. 97 98 Processes which implement this memo can be used for negotiating 99 virtual private networks (VPNs) and also for providing a remote user 100 from a remote site (whose IP address need not be known beforehand) 101 access to a secure host or network. 102 103 Client negotiation is supported. Client mode is where the 104 negotiating parties are not the endpoints for which security 105 association negotiation is taking place. When used in client mode, 106 the identities of the end parties remain hidden. 107 108 109 110 111 112 113 114Harkins & Carrel Standards Track [Page 2] 115 116RFC 2409 IKE November 1998 117 118 119 This does not implement the entire Oakley protocol, but only a subset 120 necessary to satisfy its goals. It does not claim conformance or 121 compliance with the entire Oakley protocol nor is it dependant in any 122 way on the Oakley protocol. 123 124 Likewise, this does not implement the entire SKEME protocol, but only 125 the method of public key encryption for authentication and its 126 concept of fast re-keying using an exchange of nonces. This protocol 127 is not dependant in any way on the SKEME protocol. 128 1293. Terms and Definitions 130 1313.1 Requirements Terminology 132 133 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 134 "MAY" that appear in this document are to be interpreted as described 135 in [Bra97]. 136 1373.2 Notation 138 139 The following notation is used throughout this memo. 140 141 HDR is an ISAKMP header whose exchange type is the mode. When 142 writen as HDR* it indicates payload encryption. 143 144 SA is an SA negotiation payload with one or more proposals. An 145 initiator MAY provide multiple proposals for negotiation; a 146 responder MUST reply with only one. 147 148 <P>_b indicates the body of payload <P>-- the ISAKMP generic 149 vpayload is not included. 150 151 SAi_b is the entire body of the SA payload (minus the ISAKMP 152 generic header)-- i.e. the DOI, situation, all proposals and all 153 transforms offered by the Initiator. 154 155 CKY-I and CKY-R are the Initiator's cookie and the Responder's 156 cookie, respectively, from the ISAKMP header. 157 158 g^xi and g^xr are the Diffie-Hellman ([DH]) public values of the 159 initiator and responder respectively. 160 161 g^xy is the Diffie-Hellman shared secret. 162 163 KE is the key exchange payload which contains the public 164 information exchanged in a Diffie-Hellman exchange. There is no 165 particular encoding (e.g. a TLV) used for the data of a KE payload. 166 167 168 169 170Harkins & Carrel Standards Track [Page 3] 171 172RFC 2409 IKE November 1998 173 174 175 Nx is the nonce payload; x can be: i or r for the ISAKMP initiator 176 and responder respectively. 177 178 IDx is the identification payload for "x". x can be: "ii" or "ir" 179 for the ISAKMP initiator and responder respectively during phase 180 one negotiation; or "ui" or "ur" for the user initiator and 181 responder respectively during phase two. The ID payload format for 182 the Internet DOI is defined in [Pip97]. 183 184 SIG is the signature payload. The data to sign is exchange- 185 specific. 186 187 CERT is the certificate payload. 188 189 HASH (and any derivitive such as HASH(2) or HASH_I) is the hash 190 payload. The contents of the hash are specific to the 191 authentication method. 192 193 prf(key, msg) is the keyed pseudo-random function-- often a keyed 194 hash function-- used to generate a deterministic output that 195 appears pseudo-random. prf's are used both for key derivations and 196 for authentication (i.e. as a keyed MAC). (See [KBC96]). 197 198 SKEYID is a string derived from secret material known only to the 199 active players in the exchange. 200 201 SKEYID_e is the keying material used by the ISAKMP SA to protect 202 the confidentiality of its messages. 203 204 SKEYID_a is the keying material used by the ISAKMP SA to 205 authenticate its messages. 206 207 SKEYID_d is the keying material used to derive keys for non-ISAKMP 208 security associations. 209 210 <x>y indicates that "x" is encrypted with the key "y". 211 212 --> signifies "initiator to responder" communication (requests). 213 214 <-- signifies "responder to initiator" communication (replies). 215 216 | signifies concatenation of information-- e.g. X | Y is the 217 concatentation of X with Y. 218 219 [x] indicates that x is optional. 220 221 222 223 224 225 226Harkins & Carrel Standards Track [Page 4] 227 228RFC 2409 IKE November 1998 229 230 231 Message encryption (when noted by a '*' after the ISAKMP header) MUST 232 begin immediately after the ISAKMP header. When communication is 233 protected, all payloads following the ISAKMP header MUST be 234 encrypted. Encryption keys are generated from SKEYID_e in a manner 235 that is defined for each algorithm. 236 2373.3 Perfect Forward Secrecy 238 239 When used in the memo Perfect Forward Secrecy (PFS) refers to the 240 notion that compromise of a single key will permit access to only 241 data protected by a single key. For PFS to exist the key used to 242 protect transmission of data MUST NOT be used to derive any 243 additional keys, and if the key used to protect transmission of data 244 was derived from some other keying material, that material MUST NOT 245 be used to derive any more keys. 246 247 Perfect Forward Secrecy for both keys and identities is provided in 248 this protocol. (Sections 5.5 and 8). 249 2503.4 Security Association 251 252 A security association (SA) is a set of policy and key(s) used to 253 protect information. The ISAKMP SA is the shared policy and key(s) 254 used by the negotiating peers in this protocol to protect their 255 communication. 256 2574. Introduction 258 259 Oakley and SKEME each define a method to establish an authenticated 260 key exchange. This includes payloads construction, the information 261 payloads carry, the order in which they are processed and how they 262 are used. 263 264 While Oakley defines "modes", ISAKMP defines "phases". The 265 relationship between the two is very straightforward and IKE presents 266 different exchanges as modes which operate in one of two phases. 267 268 Phase 1 is where the two ISAKMP peers establish a secure, 269 authenticated channel with which to communicate. This is called the 270 ISAKMP Security Association (SA). "Main Mode" and "Aggressive Mode" 271 each accomplish a phase 1 exchange. "Main Mode" and "Aggressive Mode" 272 MUST ONLY be used in phase 1. 273 274 Phase 2 is where Security Associations are negotiated on behalf of 275 services such as IPsec or any other service which needs key material 276 and/or parameter negotiation. "Quick Mode" accomplishes a phase 2 277 exchange. "Quick Mode" MUST ONLY be used in phase 2. 278 279 280 281 282Harkins & Carrel Standards Track [Page 5] 283 284RFC 2409 IKE November 1998 285 286 287 "New Group Mode" is not really a phase 1 or phase 2. It follows 288 phase 1, but serves to establish a new group which can be used in 289 future negotiations. "New Group Mode" MUST ONLY be used after phase 290 1. 291 292 The ISAKMP SA is bi-directional. That is, once established, either 293 party may initiate Quick Mode, Informational, and New Group Mode 294 Exchanges. Per the base ISAKMP document, the ISAKMP SA is identified 295 by the Initiator's cookie followed by the Responder's cookie-- the 296 role of each party in the phase 1 exchange dictates which cookie is 297 the Initiator's. The cookie order established by the phase 1 exchange 298 continues to identify the ISAKMP SA regardless of the direction the 299 Quick Mode, Informational, or New Group exchange. In other words, the 300 cookies MUST NOT swap places when the direction of the ISAKMP SA 301 changes. 302 303 With the use of ISAKMP phases, an implementation can accomplish very 304 fast keying when necessary. A single phase 1 negotiation may be used 305 for more than one phase 2 negotiation. Additionally a single phase 2 306 negotiation can request multiple Security Associations. With these 307 optimizations, an implementation can see less than one round trip per 308 SA as well as less than one DH exponentiation per SA. "Main Mode" 309 for phase 1 provides identity protection. When identity protection 310 is not needed, "Aggressive Mode" can be used to reduce round trips 311 even further. Developer hints for doing these optimizations are 312 included below. It should also be noted that using public key 313 encryption to authenticate an Aggressive Mode exchange will still 314 provide identity protection. 315 316 This protocol does not define its own DOI per se. The ISAKMP SA, 317 established in phase 1, MAY use the DOI and situation from a non- 318 ISAKMP service (such as the IETF IPSec DOI [Pip97]). In this case an 319 implementation MAY choose to restrict use of the ISAKMP SA for 320 establishment of SAs for services of the same DOI. Alternately, an 321 ISAKMP SA MAY be established with the value zero in both the DOI and 322 situation (see [MSST98] for a description of these fields) and in 323 this case implementations will be free to establish security services 324 for any defined DOI using this ISAKMP SA. If a DOI of zero is used 325 for establishment of a phase 1 SA, the syntax of the identity 326 payloads used in phase 1 is that defined in [MSST98] and not from any 327 DOI-- e.g. [Pip97]-- which may further expand the syntax and 328 semantics of identities. 329 330 The following attributes are used by IKE and are negotiated as part 331 of the ISAKMP Security Association. (These attributes pertain only 332 to the ISAKMP Security Association and not to any Security 333 Associations that ISAKMP may be negotiating on behalf of other 334 services.) 335 336 337 338Harkins & Carrel Standards Track [Page 6] 339 340RFC 2409 IKE November 1998 341 342 343 - encryption algorithm 344 345 - hash algorithm 346 347 - authentication method 348 349 - information about a group over which to do Diffie-Hellman. 350 351 All of these attributes are mandatory and MUST be negotiated. In 352 addition, it is possible to optionally negotiate a psuedo-random 353 function ("prf"). (There are currently no negotiable pseudo-random 354 functions defined in this document. Private use attribute values can 355 be used for prf negotiation between consenting parties). If a "prf" 356 is not negotiation, the HMAC (see [KBC96]) version of the negotiated 357 hash algorithm is used as a pseudo-random function. Other non- 358 mandatory attributes are described in Appendix A. The selected hash 359 algorithm MUST support both native and HMAC modes. 360 361 The Diffie-Hellman group MUST be either specified using a defined 362 group description (section 6) or by defining all attributes of a 363 group (section 5.6). Group attributes (such as group type or prime-- 364 see Appendix A) MUST NOT be offered in conjunction with a previously 365 defined group (either a reserved group description or a private use 366 description that is established after conclusion of a New Group Mode 367 exchange). 368 369 IKE implementations MUST support the following attribute values: 370 371 - DES [DES] in CBC mode with a weak, and semi-weak, key check 372 (weak and semi-weak keys are referenced in [Sch96] and listed in 373 Appendix A). The key is derived according to Appendix B. 374 375 - MD5 [MD5] and SHA [SHA}. 376 377 - Authentication via pre-shared keys. 378 379 - MODP over default group number one (see below). 380 381 In addition, IKE implementations SHOULD support: 3DES for encryption; 382 Tiger ([TIGER]) for hash; the Digital Signature Standard, RSA [RSA] 383 signatures and authentication with RSA public key encryption; and 384 MODP group number 2. IKE implementations MAY support any additional 385 encryption algorithms defined in Appendix A and MAY support ECP and 386 EC2N groups. 387 388 The IKE modes described here MUST be implemented whenever the IETF 389 IPsec DOI [Pip97] is implemented. Other DOIs MAY use the modes 390 described here. 391 392 393 394Harkins & Carrel Standards Track [Page 7] 395 396RFC 2409 IKE November 1998 397 398 3995. Exchanges 400 401 There are two basic methods used to establish an authenticated key 402 exchange: Main Mode and Aggressive Mode. Each generates authenticated 403 keying material from an ephemeral Diffie-Hellman exchange. Main Mode 404 MUST be implemented; Aggressive Mode SHOULD be implemented. In 405 addition, Quick Mode MUST be implemented as a mechanism to generate 406 fresh keying material and negotiate non-ISAKMP security services. In 407 addition, New Group Mode SHOULD be implemented as a mechanism to 408 define private groups for Diffie-Hellman exchanges. Implementations 409 MUST NOT switch exchange types in the middle of an exchange. 410 411 Exchanges conform to standard ISAKMP payload syntax, attribute 412 encoding, timeouts and retransmits of messages, and informational 413 messages-- e.g a notify response is sent when, for example, a 414 proposal is unacceptable, or a signature verification or decryption 415 was unsuccessful, etc. 416 417 The SA payload MUST precede all other payloads in a phase 1 exchange. 418 Except where otherwise noted, there are no requirements for ISAKMP 419 payloads in any message to be in any particular order. 420 421 The Diffie-Hellman public value passed in a KE payload, in either a 422 phase 1 or phase 2 exchange, MUST be the length of the negotiated 423 Diffie-Hellman group enforced, if necessary, by pre-pending the value 424 with zeros. 425 426 The length of nonce payload MUST be between 8 and 256 bytes 427 inclusive. 428 429 Main Mode is an instantiation of the ISAKMP Identity Protect 430 Exchange: The first two messages negotiate policy; the next two 431 exchange Diffie-Hellman public values and ancillary data (e.g. 432 nonces) necessary for the exchange; and the last two messages 433 authenticate the Diffie-Hellman Exchange. The authentication method 434 negotiated as part of the initial ISAKMP exchange influences the 435 composition of the payloads but not their purpose. The XCHG for Main 436 Mode is ISAKMP Identity Protect. 437 438 Similarly, Aggressive Mode is an instantiation of the ISAKMP 439 Aggressive Exchange. The first two messages negotiate policy, 440 exchange Diffie-Hellman public values and ancillary data necessary 441 for the exchange, and identities. In addition the second message 442 authenticates the responder. The third message authenticates the 443 initiator and provides a proof of participation in the exchange. The 444 XCHG for Aggressive Mode is ISAKMP Aggressive. The final message MAY 445 NOT be sent under protection of the ISAKMP SA allowing each party to 446 447 448 449 450Harkins & Carrel Standards Track [Page 8] 451 452RFC 2409 IKE November 1998 453 454 455 postpone exponentiation, if desired, until negotiation of this 456 exchange is complete. The graphic depictions of Aggressive Mode show 457 the final payload in the clear; it need not be. 458 459 Exchanges in IKE are not open ended and have a fixed number of 460 messages. Receipt of a Certificate Request payload MUST NOT extend 461 the number of messages transmitted or expected. 462 463 Security Association negotiation is limited with Aggressive Mode. Due 464 to message construction requirements the group in which the Diffie- 465 Hellman exchange is performed cannot be negotiated. In addition, 466 different authentication methods may further constrain attribute 467 negotiation. For example, authentication with public key encryption 468 cannot be negotiated and when using the revised method of public key 469 encryption for authentication the cipher and hash cannot be 470 negotiated. For situations where the rich attribute negotiation 471 capabilities of IKE are required Main Mode may be required. 472 473 Quick Mode and New Group Mode have no analog in ISAKMP. The XCHG 474 values for Quick Mode and New Group Mode are defined in Appendix A. 475 476 Main Mode, Aggressive Mode, and Quick Mode do security association 477 negotiation. Security Association offers take the form of Tranform 478 Payload(s) encapsulated in Proposal Payload(s) encapsulated in 479 Security Association (SA) payload(s). If multiple offers are being 480 made for phase 1 exchanges (Main Mode and Aggressive Mode) they MUST 481 take the form of multiple Transform Payloads for a single Proposal 482 Payload in a single SA payload. To put it another way, for phase 1 483 exchanges there MUST NOT be multiple Proposal Payloads for a single 484 SA payload and there MUST NOT be multiple SA payloads. This document 485 does not proscribe such behavior on offers in phase 2 exchanges. 486 487 There is no limit on the number of offers the initiator may send to 488 the responder but conformant implementations MAY choose to limit the 489 number of offers it will inspect for performance reasons. 490 491 During security association negotiation, initiators present offers 492 for potential security associations to responders. Responders MUST 493 NOT modify attributes of any offer, attribute encoding excepted (see 494 Appendix A). If the initiator of an exchange notices that attribute 495 values have changed or attributes have been added or deleted from an 496 offer made, that response MUST be rejected. 497 498 Four different authentication methods are allowed with either Main 499 Mode or Aggressive Mode-- digital signature, two forms of 500 authentication with public key encryption, or pre-shared key. The 501 value SKEYID is computed seperately for each authentication method. 502 503 504 505 506Harkins & Carrel Standards Track [Page 9] 507 508RFC 2409 IKE November 1998 509 510 511 For signatures: SKEYID = prf(Ni_b | Nr_b, g^xy) 512 For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | 513 CKY-R) 514 For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | 515 Nr_b) 516 517 The result of either Main Mode or Aggressive Mode is three groups of 518 authenticated keying material: 519 520 SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) 521 SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) 522 SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) 523 524 and agreed upon policy to protect further communications. The values 525 of 0, 1, and 2 above are represented by a single octet. The key used 526 for encryption is derived from SKEYID_e in an algorithm-specific 527 manner (see appendix B). 528 529 To authenticate either exchange the initiator of the protocol 530 generates HASH_I and the responder generates HASH_R where: 531 532 HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) 533 HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) 534 535 For authentication with digital signatures, HASH_I and HASH_R are 536 signed and verified; for authentication with either public key 537 encryption or pre-shared keys, HASH_I and HASH_R directly 538 authenticate the exchange. The entire ID payload (including ID type, 539 port, and protocol but excluding the generic header) is hashed into 540 both HASH_I and HASH_R. 541 542 As mentioned above, the negotiated authentication method influences 543 the content and use of messages for Phase 1 Modes, but not their 544 intent. When using public keys for authentication, the Phase 1 545 exchange can be accomplished either by using signatures or by using 546 public key encryption (if the algorithm supports it). Following are 547 Phase 1 exchanges with different authentication options. 548 5495.1 IKE Phase 1 Authenticated With Signatures 550 551 Using signatures, the ancillary information exchanged during the 552 second roundtrip are nonces; the exchange is authenticated by signing 553 a mutually obtainable hash. Main Mode with signature authentication 554 is described as follows: 555 556 557 558 559 560 561 562Harkins & Carrel Standards Track [Page 10] 563 564RFC 2409 IKE November 1998 565 566 567 Initiator Responder 568 ----------- ----------- 569 HDR, SA --> 570 <-- HDR, SA 571 HDR, KE, Ni --> 572 <-- HDR, KE, Nr 573 HDR*, IDii, [ CERT, ] SIG_I --> 574 <-- HDR*, IDir, [ CERT, ] SIG_R 575 576 Aggressive mode with signatures in conjunction with ISAKMP is 577 described as follows: 578 579 Initiator Responder 580 ----------- ----------- 581 HDR, SA, KE, Ni, IDii --> 582 <-- HDR, SA, KE, Nr, IDir, 583 [ CERT, ] SIG_R 584 HDR, [ CERT, ] SIG_I --> 585 586 In both modes, the signed data, SIG_I or SIG_R, is the result of the 587 negotiated digital signature algorithm applied to HASH_I or HASH_R 588 respectively. 589 590 In general the signature will be over HASH_I and HASH_R as above 591 using the negotiated prf, or the HMAC version of the negotiated hash 592 function (if no prf is negotiated). However, this can be overridden 593 for construction of the signature if the signature algorithm is tied 594 to a particular hash algorithm (e.g. DSS is only defined with SHA's 595 160 bit output). In this case, the signature will be over HASH_I and 596 HASH_R as above, except using the HMAC version of the hash algorithm 597 associated with the signature method. The negotiated prf and hash 598 function would continue to be used for all other prescribed pseudo- 599 random functions. 600 601 Since the hash algorithm used is already known there is no need to 602 encode its OID into the signature. In addition, there is no binding 603 between the OIDs used for RSA signatures in PKCS #1 and those used in 604 this document. Therefore, RSA signatures MUST be encoded as a private 605 key encryption in PKCS #1 format and not as a signature in PKCS #1 606 format (which includes the OID of the hash algorithm). DSS signatures 607 MUST be encoded as r followed by s. 608 609 One or more certificate payloads MAY be optionally passed. 610 611 612 613 614 615 616 617 618Harkins & Carrel Standards Track [Page 11] 619 620RFC 2409 IKE November 1998 621 622 6235.2 Phase 1 Authenticated With Public Key Encryption 624 625 Using public key encryption to authenticate the exchange, the 626 ancillary information exchanged is encrypted nonces. Each party's 627 ability to reconstruct a hash (proving that the other party decrypted 628 the nonce) authenticates the exchange. 629 630 In order to perform the public key encryption, the initiator must 631 already have the responder's public key. In the case where the 632 responder has multiple public keys, a hash of the certificate the 633 initiator is using to encrypt the ancillary information is passed as 634 part of the third message. In this way the responder can determine 635 which corresponding private key to use to decrypt the encrypted 636 payloads and identity protection is retained. 637 638 In addition to the nonce, the identities of the parties (IDii and 639 IDir) are also encrypted with the other party's public key. If the 640 authentication method is public key encryption, the nonce and 641 identity payloads MUST be encrypted with the public key of the other 642 party. Only the body of the payloads are encrypted, the payload 643 headers are left in the clear. 644 645 When using encryption for authentication, Main Mode is defined as 646 follows. 647 648 Initiator Responder 649 ----------- ----------- 650 HDR, SA --> 651 <-- HDR, SA 652 HDR, KE, [ HASH(1), ] 653 <IDii_b>PubKey_r, 654 <Ni_b>PubKey_r --> 655 HDR, KE, <IDir_b>PubKey_i, 656 <-- <Nr_b>PubKey_i 657 HDR*, HASH_I --> 658 <-- HDR*, HASH_R 659 660 Aggressive Mode authenticated with encryption is described as 661 follows: 662 663 Initiator Responder 664 ----------- ----------- 665 HDR, SA, [ HASH(1),] KE, 666 <IDii_b>Pubkey_r, 667 <Ni_b>Pubkey_r --> 668 HDR, SA, KE, <IDir_b>PubKey_i, 669 <-- <Nr_b>PubKey_i, HASH_R 670 HDR, HASH_I --> 671 672 673 674Harkins & Carrel Standards Track [Page 12] 675 676RFC 2409 IKE November 1998 677 678 679 Where HASH(1) is a hash (using the negotiated hash function) of the 680 certificate which the initiator is using to encrypt the nonce and 681 identity. 682 683 RSA encryption MUST be encoded in PKCS #1 format. While only the body 684 of the ID and nonce payloads is encrypted, the encrypted data must be 685 preceded by a valid ISAKMP generic header. The payload length is the 686 length of the entire encrypted payload plus header. The PKCS #1 687 encoding allows for determination of the actual length of the 688 cleartext payload upon decryption. 689 690 Using encryption for authentication provides for a plausably deniable 691 exchange. There is no proof (as with a digital signature) that the 692 conversation ever took place since each party can completely 693 reconstruct both sides of the exchange. In addition, security is 694 added to secret generation since an attacker would have to 695 successfully break not only the Diffie-Hellman exchange but also both 696 RSA encryptions. This exchange was motivated by [SKEME]. 697 698 Note that, unlike other authentication methods, authentication with 699 public key encryption allows for identity protection with Aggressive 700 Mode. 701 7025.3 Phase 1 Authenticated With a Revised Mode of Public Key Encryption 703 704 Authentication with Public Key Encryption has significant advantages 705 over authentication with signatures (see section 5.2 above). 706 Unfortunately, this is at the cost of 4 public key operations-- two 707 public key encryptions and two private key decryptions. This 708 authentication mode retains the advantages of authentication using 709 public key encryption but does so with half the public key 710 operations. 711 712 In this mode, the nonce is still encrypted using the public key of 713 the peer, however the peer's identity (and the certificate if it is 714 sent) is encrypted using the negotiated symmetric encryption 715 algorithm (from the SA payload) with a key derived from the nonce. 716 This solution adds minimal complexity and state yet saves two costly 717 public key operations on each side. In addition, the Key Exchange 718 payload is also encrypted using the same derived key. This provides 719 additional protection against cryptanalysis of the Diffie-Hellman 720 exchange. 721 722 As with the public key encryption method of authentication (section 723 5.2), a HASH payload may be sent to identify a certificate if the 724 responder has multiple certificates which contain useable public keys 725 (e.g. if the certificate is not for signatures only, either due to 726 certificate restrictions or algorithmic restrictions). If the HASH 727 728 729 730Harkins & Carrel Standards Track [Page 13] 731 732RFC 2409 IKE November 1998 733 734 735 payload is sent it MUST be the first payload of the second message 736 exchange and MUST be followed by the encrypted nonce. If the HASH 737 payload is not sent, the first payload of the second message exchange 738 MUST be the encrypted nonce. In addition, the initiator my optionally 739 send a certificate payload to provide the responder with a public key 740 with which to respond. 741 742 When using the revised encryption mode for authentication, Main Mode 743 is defined as follows. 744 745 Initiator Responder 746 ----------- ----------- 747 HDR, SA --> 748 <-- HDR, SA 749 HDR, [ HASH(1), ] 750 <Ni_b>Pubkey_r, 751 <KE_b>Ke_i, 752 <IDii_b>Ke_i, 753 [<<Cert-I_b>Ke_i] --> 754 HDR, <Nr_b>PubKey_i, 755 <KE_b>Ke_r, 756 <-- <IDir_b>Ke_r, 757 HDR*, HASH_I --> 758 <-- HDR*, HASH_R 759 760 Aggressive Mode authenticated with the revised encryption method is 761 described as follows: 762 763 Initiator Responder 764 ----------- ----------- 765 HDR, SA, [ HASH(1),] 766 <Ni_b>Pubkey_r, 767 <KE_b>Ke_i, <IDii_b>Ke_i 768 [, <Cert-I_b>Ke_i ] --> 769 HDR, SA, <Nr_b>PubKey_i, 770 <KE_b>Ke_r, <IDir_b>Ke_r, 771 <-- HASH_R 772 HDR, HASH_I --> 773 774 where HASH(1) is identical to section 5.2. Ke_i and Ke_r are keys to 775 the symmetric encryption algorithm negotiated in the SA payload 776 exchange. Only the body of the payloads are encrypted (in both public 777 key and symmetric operations), the generic payload headers are left 778 in the clear. The payload length includes that added to perform 779 encryption. 780 781 The symmetric cipher keys are derived from the decrypted nonces as 782 follows. First the values Ne_i and Ne_r are computed: 783 784 785 786Harkins & Carrel Standards Track [Page 14] 787 788RFC 2409 IKE November 1998 789 790 791 Ne_i = prf(Ni_b, CKY-I) 792 Ne_r = prf(Nr_b, CKY-R) 793 794 The keys Ke_i and Ke_r are then taken from Ne_i and Ne_r respectively 795 in the manner described in Appendix B used to derive symmetric keys 796 for use with the negotiated encryption algorithm. If the length of 797 the output of the negotiated prf is greater than or equal to the key 798 length requirements of the cipher, Ke_i and Ke_r are derived from the 799 most significant bits of Ne_i and Ne_r respectively. If the desired 800 length of Ke_i and Ke_r exceed the length of the output of the prf 801 the necessary number of bits is obtained by repeatedly feeding the 802 results of the prf back into itself and concatenating the result 803 until the necessary number has been achieved. For example, if the 804 negotiated encryption algorithm requires 320 bits of key and the 805 output of the prf is only 128 bits, Ke_i is the most significant 320 806 bits of K, where 807 808 K = K1 | K2 | K3 and 809 K1 = prf(Ne_i, 0) 810 K2 = prf(Ne_i, K1) 811 K3 = prf(Ne_i, K2) 812 813 For brevity, only derivation of Ke_i is shown; Ke_r is identical. The 814 length of the value 0 in the computation of K1 is a single octet. 815 Note that Ne_i, Ne_r, Ke_i, and Ke_r are all ephemeral and MUST be 816 discarded after use. 817 818 Save the requirements on the location of the optional HASH payload 819 and the mandatory nonce payload there are no further payload 820 requirements. All payloads-- in whatever order-- following the 821 encrypted nonce MUST be encrypted with Ke_i or Ke_r depending on the 822 direction. 823 824 If CBC mode is used for the symmetric encryption then the 825 initialization vectors (IVs) are set as follows. The IV for 826 encrypting the first payload following the nonce is set to 0 (zero). 827 The IV for subsequent payloads encrypted with the ephemeral symmetric 828 cipher key, Ke_i, is the last ciphertext block of the previous 829 payload. Encrypted payloads are padded up to the nearest block size. 830 All padding bytes, except for the last one, contain 0x00. The last 831 byte of the padding contains the number of the padding bytes used, 832 excluding the last one. Note that this means there will always be 833 padding. 834 835 836 837 838 839 840 841 842Harkins & Carrel Standards Track [Page 15] 843 844RFC 2409 IKE November 1998 845 846 8475.4 Phase 1 Authenticated With a Pre-Shared Key 848 849 A key derived by some out-of-band mechanism may also be used to 850 authenticate the exchange. The actual establishment of this key is 851 out of the scope of this document. 852 853 When doing a pre-shared key authentication, Main Mode is defined as 854 follows: 855 856 Initiator Responder 857 ---------- ----------- 858 HDR, SA --> 859 <-- HDR, SA 860 HDR, KE, Ni --> 861 <-- HDR, KE, Nr 862 HDR*, IDii, HASH_I --> 863 <-- HDR*, IDir, HASH_R 864 865 Aggressive mode with a pre-shared key is described as follows: 866 867 Initiator Responder 868 ----------- ----------- 869 HDR, SA, KE, Ni, IDii --> 870 <-- HDR, SA, KE, Nr, IDir, HASH_R 871 HDR, HASH_I --> 872 873 When using pre-shared key authentication with Main Mode the key can 874 only be identified by the IP address of the peers since HASH_I must 875 be computed before the initiator has processed IDir. Aggressive Mode 876 allows for a wider range of identifiers of the pre-shared secret to 877 be used. In addition, Aggressive Mode allows two parties to maintain 878 multiple, different pre-shared keys and identify the correct one for 879 a particular exchange. 880 8815.5 Phase 2 - Quick Mode 882 883 Quick Mode is not a complete exchange itself (in that it is bound to 884 a phase 1 exchange), but is used as part of the SA negotiation 885 process (phase 2) to derive keying material and negotiate shared 886 policy for non-ISAKMP SAs. The information exchanged along with Quick 887 Mode MUST be protected by the ISAKMP SA-- i.e. all payloads except 888 the ISAKMP header are encrypted. In Quick Mode, a HASH payload MUST 889 immediately follow the ISAKMP header and a SA payload MUST 890 immediately follow the HASH. This HASH authenticates the message and 891 also provides liveliness proofs. 892 893 894 895 896 897 898Harkins & Carrel Standards Track [Page 16] 899 900RFC 2409 IKE November 1998 901 902 903 The message ID in the ISAKMP header identifies a Quick Mode in 904 progress for a particular ISAKMP SA which itself is identified by the 905 cookies in the ISAKMP header. Since each instance of a Quick Mode 906 uses a unique initialization vector (see Appendix B) it is possible 907 to have multiple simultaneous Quick Modes, based off a single ISAKMP 908 SA, in progress at any one time. 909 910 Quick Mode is essentially a SA negotiation and an exchange of nonces 911 that provides replay protection. The nonces are used to generate 912 fresh key material and prevent replay attacks from generating bogus 913 security associations. An optional Key Exchange payload can be 914 exchanged to allow for an additional Diffie-Hellman exchange and 915 exponentiation per Quick Mode. While use of the key exchange payload 916 with Quick Mode is optional it MUST be supported. 917 918 Base Quick Mode (without the KE payload) refreshes the keying 919 material derived from the exponentiation in phase 1. This does not 920 provide PFS. Using the optional KE payload, an additional 921 exponentiation is performed and PFS is provided for the keying 922 material. 923 924 The identities of the SAs negotiated in Quick Mode are implicitly 925 assumed to be the IP addresses of the ISAKMP peers, without any 926 implied constraints on the protocol or port numbers allowed, unless 927 client identifiers are specified in Quick Mode. If ISAKMP is acting 928 as a client negotiator on behalf of another party, the identities of 929 the parties MUST be passed as IDci and then IDcr. Local policy will 930 dictate whether the proposals are acceptable for the identities 931 specified. If the client identities are not acceptable to the Quick 932 Mode responder (due to policy or other reasons), a Notify payload 933 with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent. 934 935 The client identities are used to identify and direct traffic to the 936 appropriate tunnel in cases where multiple tunnels exist between two 937 peers and also to allow for unique and shared SAs with different 938 granularities. 939 940 All offers made during a Quick Mode are logically related and must be 941 consistant. For example, if a KE payload is sent, the attribute 942 describing the Diffie-Hellman group (see section 6.1 and [Pip97]) 943 MUST be included in every transform of every proposal of every SA 944 being negotiated. Similarly, if client identities are used, they MUST 945 apply to every SA in the negotiation. 946 947 Quick Mode is defined as follows: 948 949 950 951 952 953 954Harkins & Carrel Standards Track [Page 17] 955 956RFC 2409 IKE November 1998 957 958 959 Initiator Responder 960 ----------- ----------- 961 HDR*, HASH(1), SA, Ni 962 [, KE ] [, IDci, IDcr ] --> 963 <-- HDR*, HASH(2), SA, Nr 964 [, KE ] [, IDci, IDcr ] 965 HDR*, HASH(3) --> 966 967 Where: 968 HASH(1) is the prf over the message id (M-ID) from the ISAKMP header 969 concatenated with the entire message that follows the hash including 970 all payload headers, but excluding any padding added for encryption. 971 HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni, 972 minus the payload header-- is added after M-ID but before the 973 complete message. The addition of the nonce to HASH(2) is for a 974 liveliness proof. HASH(3)-- for liveliness-- is the prf over the 975 value zero represented as a single octet, followed by a concatenation 976 of the message id and the two nonces-- the initiator's followed by 977 the responder's-- minus the payload header. In other words, the 978 hashes for the above exchange are: 979 980 HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr ) 981 HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | 982 IDcr ) 983 HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b) 984 985 With the exception of the HASH, SA, and the optional ID payloads, 986 there are no payload ordering restrictions on Quick Mode. HASH(1) and 987 HASH(2) may differ from the illustration above if the order of 988 payloads in the message differs from the illustrative example or if 989 any optional payloads, for example a notify payload, have been 990 chained to the message. 991 992 If PFS is not needed, and KE payloads are not exchanged, the new 993 keying material is defined as 994 995 KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b). 996 997 If PFS is desired and KE payloads were exchanged, the new keying 998 material is defined as 999 1000 KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b) 1001 1002 where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman 1003 exchange of this Quick Mode. 1004 1005 In either case, "protocol" and "SPI" are from the ISAKMP Proposal 1006 Payload that contained the negotiated Transform. 1007 1008 1009 1010Harkins & Carrel Standards Track [Page 18] 1011 1012RFC 2409 IKE November 1998 1013 1014 1015 A single SA negotiation results in two security assocations-- one 1016 inbound and one outbound. Different SPIs for each SA (one chosen by 1017 the initiator, the other by the responder) guarantee a different key 1018 for each direction. The SPI chosen by the destination of the SA is 1019 used to derive KEYMAT for that SA. 1020 1021 For situations where the amount of keying material desired is greater 1022 than that supplied by the prf, KEYMAT is expanded by feeding the 1023 results of the prf back into itself and concatenating results until 1024 the required keying material has been reached. In other words, 1025 1026 KEYMAT = K1 | K2 | K3 | ... 1027 where 1028 K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) 1029 K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | 1030 Nr_b) 1031 K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | 1032 Nr_b) 1033 etc. 1034 1035 This keying material (whether with PFS or without, and whether 1036 derived directly or through concatenation) MUST be used with the 1037 negotiated SA. It is up to the service to define how keys are derived 1038 from the keying material. 1039 1040 In the case of an ephemeral Diffie-Hellman exchange in Quick Mode, 1041 the exponential (g(qm)^xy) is irretreivably removed from the current 1042 state and SKEYID_e and SKEYID_a (derived from phase 1 negotiation) 1043 continue to protect and authenticate the ISAKMP SA and SKEYID_d 1044 continues to be used to derive keys. 1045 1046 Using Quick Mode, multiple SA's and keys can be negotiated with one 1047 exchange as follows: 1048 1049 Initiator Responder 1050 ----------- ----------- 1051 HDR*, HASH(1), SA0, SA1, Ni, 1052 [, KE ] [, IDci, IDcr ] --> 1053 <-- HDR*, HASH(2), SA0, SA1, Nr, 1054 [, KE ] [, IDci, IDcr ] 1055 HDR*, HASH(3) --> 1056 1057 The keying material is derived identically as in the case of a single 1058 SA. In this case (negotiation of two SA payloads) the result would be 1059 four security associations-- two each way for both SAs. 1060 1061 1062 1063 1064 1065 1066Harkins & Carrel Standards Track [Page 19] 1067 1068RFC 2409 IKE November 1998 1069 1070 10715.6 New Group Mode 1072 1073 New Group Mode MUST NOT be used prior to establishment of an ISAKMP 1074 SA. The description of a new group MUST only follow phase 1 1075 negotiation. (It is not a phase 2 exchange, though). 1076 1077 Initiator Responder 1078 ----------- ----------- 1079 HDR*, HASH(1), SA --> 1080 <-- HDR*, HASH(2), SA 1081 1082 where HASH(1) is the prf output, using SKEYID_a as the key, and the 1083 message-ID from the ISAKMP header concatenated with the entire SA 1084 proposal, body and header, as the data; HASH(2) is the prf output, 1085 using SKEYID_a as the key, and the message-ID from the ISAKMP header 1086 concatenated with the reply as the data. In other words the hashes 1087 for the above exchange are: 1088 1089 HASH(1) = prf(SKEYID_a, M-ID | SA) 1090 HASH(2) = prf(SKEYID_a, M-ID | SA) 1091 1092 The proposal will specify the characteristics of the group (see 1093 appendix A, "Attribute Assigned Numbers"). Group descriptions for 1094 private Groups MUST be greater than or equal to 2^15. If the group 1095 is not acceptable, the responder MUST reply with a Notify payload 1096 with the message type set to ATTRIBUTES-NOT-SUPPORTED (13). 1097 1098 ISAKMP implementations MAY require private groups to expire with the 1099 SA under which they were established. 1100 1101 Groups may be directly negotiated in the SA proposal with Main Mode. 1102 To do this the component parts-- for a MODP group, the type, prime 1103 and generator; for a EC2N group the type, the Irreducible Polynomial, 1104 Group Generator One, Group Generator Two, Group Curve A, Group Curve 1105 B and Group Order-- are passed as SA attributes (see Appendix A). 1106 Alternately, the nature of the group can be hidden using New Group 1107 Mode and only the group identifier is passed in the clear during 1108 phase 1 negotiation. 1109 11105.7 ISAKMP Informational Exchanges 1111 1112 This protocol protects ISAKMP Informational Exchanges when possible. 1113 Once the ISAKMP security association has been established (and 1114 SKEYID_e and SKEYID_a have been generated) ISAKMP Information 1115 Exchanges, when used with this protocol, are as follows: 1116 1117 1118 1119 1120 1121 1122Harkins & Carrel Standards Track [Page 20] 1123 1124RFC 2409 IKE November 1998 1125 1126 1127 Initiator Responder 1128 ----------- ----------- 1129 HDR*, HASH(1), N/D --> 1130 1131 where N/D is either an ISAKMP Notify Payload or an ISAKMP Delete 1132 Payload and HASH(1) is the prf output, using SKEYID_a as the key, and 1133 a M-ID unique to this exchange concatenated with the entire 1134 informational payload (either a Notify or Delete) as the data. In 1135 other words, the hash for the above exchange is: 1136 1137 HASH(1) = prf(SKEYID_a, M-ID | N/D) 1138 1139 As noted the message ID in the ISAKMP header-- and used in the prf 1140 computation-- is unique to this exchange and MUST NOT be the same as 1141 the message ID of another phase 2 exchange which generated this 1142 informational exchange. The derivation of the initialization vector, 1143 used with SKEYID_e to encrypt this message, is described in Appendix 1144 B. 1145 1146 If the ISAKMP security association has not yet been established at 1147 the time of the Informational Exchange, the exchange is done in the 1148 clear without an accompanying HASH payload. 1149 11506 Oakley Groups 1151 1152 With IKE, the group in which to do the Diffie-Hellman exchange is 1153 negotiated. Four groups-- values 1 through 4-- are defined below. 1154 These groups originated with the Oakley protocol and are therefore 1155 called "Oakley Groups". The attribute class for "Group" is defined in 1156 Appendix A. All values 2^15 and higher are used for private group 1157 identifiers. For a discussion on the strength of the default Oakley 1158 groups please see the Security Considerations section below. 1159 1160 These groups were all generated by Richard Schroeppel at the 1161 University of Arizona. Properties of these groups are described in 1162 [Orm96]. 1163 11646.1 First Oakley Default Group 1165 1166 Oakley implementations MUST support a MODP group with the following 1167 prime and generator. This group is assigned id 1 (one). 1168 1169 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } 1170 Its hexadecimal value is 1171 1172 1173 1174 1175 1176 1177 1178Harkins & Carrel Standards Track [Page 21] 1179 1180RFC 2409 IKE November 1998 1181 1182 1183 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 1184 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 1185 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 1186 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 1187 1188 The generator is: 2. 1189 11906.2 Second Oakley Group 1191 1192 IKE implementations SHOULD support a MODP group with the following 1193 prime and generator. This group is assigned id 2 (two). 1194 1195 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 1196 Its hexadecimal value is 1197 1198 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 1199 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 1200 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 1201 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 1202 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 1203 FFFFFFFF FFFFFFFF 1204 1205 The generator is 2 (decimal) 1206 12076.3 Third Oakley Group 1208 1209 IKE implementations SHOULD support a EC2N group with the following 1210 characteristics. This group is assigned id 3 (three). The curve is 1211 based on the Galois Field GF[2^155]. The field size is 155. The 1212 irreducible polynomial for the field is: 1213 u^155 + u^62 + 1. 1214 The equation for the elliptic curve is: 1215 y^2 + xy = x^3 + ax^2 + b. 1216 1217 Field Size: 155 1218 Group Prime/Irreducible Polynomial: 1219 0x0800000000000000000000004000000000000001 1220 Group Generator One: 0x7b 1221 Group Curve A: 0x0 1222 Group Curve B: 0x07338f 1223 1224 Group Order: 0X0800000000000000000057db5698537193aef944 1225 1226 The data in the KE payload when using this group is the value x from 1227 the solution (x,y), the point on the curve chosen by taking the 1228 randomly chosen secret Ka and computing Ka*P, where * is the 1229 repetition of the group addition and double operations, P is the 1230 curve point with x coordinate equal to generator 1 and the y 1231 1232 1233 1234Harkins & Carrel Standards Track [Page 22] 1235 1236RFC 2409 IKE November 1998 1237 1238 1239 coordinate determined from the defining equation. The equation of 1240 curve is implicitly known by the Group Type and the A and B 1241 coefficients. There are two possible values for the y coordinate; 1242 either one can be used successfully (the two parties need not agree 1243 on the selection). 1244 12456.4 Fourth Oakley Group 1246 1247 IKE implementations SHOULD support a EC2N group with the following 1248 characteristics. This group is assigned id 4 (four). The curve is 1249 based on the Galois Field GF[2^185]. The field size is 185. The 1250 irreducible polynomial for the field is: 1251 u^185 + u^69 + 1. The 1252 equation for the elliptic curve is: 1253 y^2 + xy = x^3 + ax^2 + b. 1254 1255 Field Size: 185 1256 Group Prime/Irreducible Polynomial: 1257 0x020000000000000000000000000000200000000000000001 1258 Group Generator One: 0x18 1259 Group Curve A: 0x0 1260 Group Curve B: 0x1ee9 1261 1262 Group Order: 0X01ffffffffffffffffffffffdbf2f889b73e484175f94ebc 1263 1264 The data in the KE payload when using this group will be identical to 1265 that as when using Oakley Group 3 (three). 1266 1267 Other groups can be defined using New Group Mode. These default 1268 groups were generated by Richard Schroeppel at the University of 1269 Arizona. Properties of these primes are described in [Orm96]. 1270 12717. Payload Explosion for a Complete IKE Exchange 1272 1273 This section illustrates how the IKE protocol is used to: 1274 1275 - establish a secure and authenticated channel between ISAKMP 1276 processes (phase 1); and 1277 1278 - generate key material for, and negotiate, an IPsec SA (phase 2). 1279 12807.1 Phase 1 using Main Mode 1281 1282 The following diagram illustrates the payloads exchanged between the 1283 two parties in the first round trip exchange. The initiator MAY 1284 propose several proposals; the responder MUST reply with one. 1285 1286 1287 1288 1289 1290Harkins & Carrel Standards Track [Page 23] 1291 1292RFC 2409 IKE November 1998 1293 1294 1295 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 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 ~ ISAKMP Header with XCHG of Main Mode, ~ 1298 ~ and Next Payload of ISA_SA ~ 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 ! 0 ! RESERVED ! Payload Length ! 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 ! Domain of Interpretation ! 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 ! Situation ! 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 ! 0 ! RESERVED ! Payload Length ! 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 ! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms ! 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 ! ISA_TRANS ! RESERVED ! Payload Length ! 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 ! Transform #1 ! KEY_OAKLEY | RESERVED2 ! 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 ~ prefered SA attributes ~ 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 ! 0 ! RESERVED ! Payload Length ! 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 ! Transform #2 ! KEY_OAKLEY | RESERVED2 ! 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 ~ alternate SA attributes ~ 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 1323 The responder replies in kind but selects, and returns, one transform 1324 proposal (the ISAKMP SA attributes). 1325 1326 The second exchange consists of the following payloads: 1327 1328 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 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 ~ ISAKMP Header with XCHG of Main Mode, ~ 1331 ~ and Next Payload of ISA_KE ~ 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 ! ISA_NONCE ! RESERVED ! Payload Length ! 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 ~ D-H Public Value (g^xi from initiator g^xr from responder) ~ 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 ! 0 ! RESERVED ! Payload Length ! 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 ~ Ni (from initiator) or Nr (from responder) ~ 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 1342 1343 1344 1345 1346Harkins & Carrel Standards Track [Page 24] 1347 1348RFC 2409 IKE November 1998 1349 1350 1351 The shared keys, SKEYID_e and SKEYID_a, are now used to protect and 1352 authenticate all further communication. Note that both SKEYID_e and 1353 SKEYID_a are unauthenticated. 1354 1355 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 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 ~ ISAKMP Header with XCHG of Main Mode, ~ 1358 ~ and Next Payload of ISA_ID and the encryption bit set ~ 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 ! ISA_SIG ! RESERVED ! Payload Length ! 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 ~ Identification Data of the ISAKMP negotiator ~ 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 ! 0 ! RESERVED ! Payload Length ! 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 ~ signature verified by the public key of the ID above ~ 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 1369 The key exchange is authenticated over a signed hash as described in 1370 section 5.1. Once the signature has been verified using the 1371 authentication algorithm negotiated as part of the ISAKMP SA, the 1372 shared keys, SKEYID_e and SKEYID_a can be marked as authenticated. 1373 (For brevity, certificate payloads were not exchanged). 1374 13757.2 Phase 2 using Quick Mode 1376 1377 The following payloads are exchanged in the first round of Quick Mode 1378 with ISAKMP SA negotiation. In this hypothetical exchange, the ISAKMP 1379 negotiators are proxies for other parties which have requested 1380 authentication. 1381 1382 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 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 ~ ISAKMP Header with XCHG of Quick Mode, ~ 1385 ~ Next Payload of ISA_HASH and the encryption bit set ~ 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 ! ISA_SA ! RESERVED ! Payload Length ! 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 ~ keyed hash of message ~ 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 ! ISA_NONCE ! RESERVED ! Payload Length ! 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 ! Domain Of Interpretation ! 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 ! Situation ! 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 ! 0 ! RESERVED ! Payload Length ! 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 1400 1401 1402Harkins & Carrel Standards Track [Page 25] 1403 1404RFC 2409 IKE November 1998 1405 1406 1407 ! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms ! 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 ~ SPI (4 octets) ~ 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 ! ISA_TRANS ! RESERVED ! Payload Length ! 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 ! Transform #1 ! AH_SHA | RESERVED2 ! 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 ! other SA attributes ! 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 ! 0 ! RESERVED ! Payload Length ! 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 ! Transform #2 ! AH_MD5 | RESERVED2 ! 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 ! other SA attributes ! 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 ! ISA_ID ! RESERVED ! Payload Length ! 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 ~ nonce ~ 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 ! ISA_ID ! RESERVED ! Payload Length ! 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 ~ ID of source for which ISAKMP is a client ~ 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 ! 0 ! RESERVED ! Payload Length ! 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 ~ ID of destination for which ISAKMP is a client ~ 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 1436 where the contents of the hash are described in 5.5 above. The 1437 responder replies with a similar message which only contains one 1438 transform-- the selected AH transform. Upon receipt, the initiator 1439 can provide the key engine with the negotiated security association 1440 and the keying material. As a check against replay attacks, the 1441 responder waits until receipt of the next message. 1442 1443 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 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 ~ ISAKMP Header with XCHG of Quick Mode, ~ 1446 ~ Next Payload of ISA_HASH and the encryption bit set ~ 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 ! 0 ! RESERVED ! Payload Length ! 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 ~ hash data ~ 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 1453 where the contents of the hash are described in 5.5 above. 1454 1455 1456 1457 1458Harkins & Carrel Standards Track [Page 26] 1459 1460RFC 2409 IKE November 1998 1461 1462 14638. Perfect Forward Secrecy Example 1464 1465 This protocol can provide PFS of both keys and identities. The 1466 identies of both the ISAKMP negotiating peer and, if applicable, the 1467 identities for whom the peers are negotiating can be protected with 1468 PFS. 1469 1470 To provide Perfect Forward Secrecy of both keys and all identities, 1471 two parties would perform the following: 1472 1473 o A Main Mode Exchange to protect the identities of the ISAKMP 1474 peers. 1475 This establishes an ISAKMP SA. 1476 o A Quick Mode Exchange to negotiate other security protocol 1477 protection. 1478 This establishes a SA on each end for this protocol. 1479 o Delete the ISAKMP SA and its associated state. 1480 1481 Since the key for use in the non-ISAKMP SA was derived from the 1482 single ephemeral Diffie-Hellman exchange PFS is preserved. 1483 1484 To provide Perfect Forward Secrecy of merely the keys of a non-ISAKMP 1485 security association, it in not necessary to do a phase 1 exchange if 1486 an ISAKMP SA exists between the two peers. A single Quick Mode in 1487 which the optional KE payload is passed, and an additional Diffie- 1488 Hellman exchange is performed, is all that is required. At this point 1489 the state derived from this Quick Mode must be deleted from the 1490 ISAKMP SA as described in section 5.5. 1491 14929. Implementation Hints 1493 1494 Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2 1495 negotiations extremely quick. As long as the Phase 1 state remains 1496 cached, and PFS is not needed, Phase 2 can proceed without any 1497 exponentiation. How many Phase 2 negotiations can be performed for a 1498 single Phase 1 is a local policy issue. The decision will depend on 1499 the strength of the algorithms being used and level of trust in the 1500 peer system. 1501 1502 An implementation may wish to negotiate a range of SAs when 1503 performing Quick Mode. By doing this they can speed up the "re- 1504 keying". Quick Mode defines how KEYMAT is defined for a range of SAs. 1505 When one peer feels it is time to change SAs they simply use the next 1506 one within the stated range. A range of SAs can be established by 1507 negotiating multiple SAs (identical attributes, different SPIs) with 1508 one Quick Mode. 1509 1510 1511 1512 1513 1514Harkins & Carrel Standards Track [Page 27] 1515 1516RFC 2409 IKE November 1998 1517 1518 1519 An optimization that is often useful is to establish Security 1520 Associations with peers before they are needed so that when they 1521 become needed they are already in place. This ensures there would be 1522 no delays due to key management before initial data transmission. 1523 This optimization is easily implemented by setting up more than one 1524 Security Association with a peer for each requested Security 1525 Association and caching those not immediately used. 1526 1527 Also, if an ISAKMP implementation is alerted that a SA will soon be 1528 needed (e.g. to replace an existing SA that will expire in the near 1529 future), then it can establish the new SA before that new SA is 1530 needed. 1531 1532 The base ISAKMP specification describes conditions in which one party 1533 of the protocol may inform the other party of some activity-- either 1534 deletion of a security association or in response to some error in 1535 the protocol such as a signature verification failed or a payload 1536 failed to decrypt. It is strongly suggested that these Informational 1537 exchanges not be responded to under any circumstances. Such a 1538 condition may result in a "notify war" in which failure to understand 1539 a message results in a notify to the peer who cannot understand it 1540 and sends his own notify back which is also not understood. 1541 154210. Security Considerations 1543 1544 This entire memo discusses a hybrid protocol, combining parts of 1545 Oakley and parts of SKEME with ISAKMP, to negotiate, and derive 1546 keying material for, security associations in a secure and 1547 authenticated manner. 1548 1549 Confidentiality is assured by the use of a negotiated encryption 1550 algorithm. Authentication is assured by the use of a negotiated 1551 method: a digital signature algorithm; a public key algorithm which 1552 supports encryption; or, a pre-shared key. The confidentiality and 1553 authentication of this exchange is only as good as the attributes 1554 negotiated as part of the ISAKMP security association. 1555 1556 Repeated re-keying using Quick Mode can consume the entropy of the 1557 Diffie-Hellman shared secret. Implementors should take note of this 1558 fact and set a limit on Quick Mode Exchanges between exponentiations. 1559 This memo does not prescribe such a limit. 1560 1561 Perfect Forward Secrecy (PFS) of both keying material and identities 1562 is possible with this protocol. By specifying a Diffie-Hellman group, 1563 and passing public values in KE payloads, ISAKMP peers can establish 1564 PFS of keys-- the identities would be protected by SKEYID_e from the 1565 ISAKMP SA and would therefore not be protected by PFS. If PFS of both 1566 keying material and identities is desired, an ISAKMP peer MUST 1567 1568 1569 1570Harkins & Carrel Standards Track [Page 28] 1571 1572RFC 2409 IKE November 1998 1573 1574 1575 establish only one non-ISAKMP security association (e.g. IPsec 1576 Security Association) per ISAKMP SA. PFS for keys and identities is 1577 accomplished by deleting the ISAKMP SA (and optionally issuing a 1578 DELETE message) upon establishment of the single non-ISAKMP SA. In 1579 this way a phase one negotiation is uniquely tied to a single phase 1580 two negotiation, and the ISAKMP SA established during phase one 1581 negotiation is never used again. 1582 1583 The strength of a key derived from a Diffie-Hellman exchange using 1584 any of the groups defined here depends on the inherent strength of 1585 the group, the size of the exponent used, and the entropy provided by 1586 the random number generator used. Due to these inputs it is difficult 1587 to determine the strength of a key for any of the defined groups. The 1588 default Diffie-Hellman group (number one) when used with a strong 1589 random number generator and an exponent no less than 160 bits is 1590 sufficient to use for DES. Groups two through four provide greater 1591 security. Implementations should make note of these conservative 1592 estimates when establishing policy and negotiating security 1593 parameters. 1594 1595 Note that these limitations are on the Diffie-Hellman groups 1596 themselves. There is nothing in IKE which prohibits using stronger 1597 groups nor is there anything which will dilute the strength obtained 1598 from stronger groups. In fact, the extensible framework of IKE 1599 encourages the definition of more groups; use of elliptical curve 1600 groups will greatly increase strength using much smaller numbers. 1601 1602 For situations where defined groups provide insufficient strength New 1603 Group Mode can be used to exchange a Diffie-Hellman group which 1604 provides the necessary strength. In is incumbent upon implementations 1605 to check the primality in groups being offered and independently 1606 arrive at strength estimates. 1607 1608 It is assumed that the Diffie-Hellman exponents in this exchange are 1609 erased from memory after use. In particular, these exponents must not 1610 be derived from long-lived secrets like the seed to a pseudo-random 1611 generator. 1612 1613 IKE exchanges maintain running initialization vectors (IV) where the 1614 last ciphertext block of the last message is the IV for the next 1615 message. To prevent retransmissions (or forged messages with valid 1616 cookies) from causing exchanges to get out of sync IKE 1617 implementations SHOULD NOT update their running IV until the 1618 decrypted message has passed a basic sanity check and has been 1619 determined to actually advance the IKE state machine-- i.e. it is not 1620 a retransmission. 1621 1622 1623 1624 1625 1626Harkins & Carrel Standards Track [Page 29] 1627 1628RFC 2409 IKE November 1998 1629 1630 1631 While the last roundtrip of Main Mode (and optionally the last 1632 message of Aggressive Mode) is encrypted it is not, strictly 1633 speaking, authenticated. An active substitution attack on the 1634 ciphertext could result in payload corruption. If such an attack 1635 corrupts mandatory payloads it would be detected by an authentication 1636 failure, but if it corrupts any optional payloads (e.g. notify 1637 payloads chained onto the last message of a Main Mode exchange) it 1638 might not be detectable. 1639 164011. IANA Considerations 1641 1642 This document contains many "magic numbers" to be maintained by the 1643 IANA. This section explains the criteria to be used by the IANA to 1644 assign additional numbers in each of these lists. 1645 164611.1 Attribute Classes 1647 1648 Attributes negotiated in this protocol are identified by their class. 1649 Requests for assignment of new classes must be accompanied by a 1650 standards-track RFC which describes the use of this attribute. 1651 165211.2 Encryption Algorithm Class 1653 1654 Values of the Encryption Algorithm Class define an encryption 1655 algorithm to use when called for in this document. Requests for 1656 assignment of new encryption algorithm values must be accompanied by 1657 a reference to a standards-track or Informational RFC or a reference 1658 to published cryptographic literature which describes this algorithm. 1659 166011.3 Hash Algorithm 1661 1662 Values of the Hash Algorithm Class define a hash algorithm to use 1663 when called for in this document. Requests for assignment of new hash 1664 algorithm values must be accompanied by a reference to a standards- 1665 track or Informational RFC or a reference to published cryptographic 1666 literature which describes this algorithm. Due to the key derivation 1667 and key expansion uses of HMAC forms of hash algorithms in IKE, 1668 requests for assignment of new hash algorithm values must take into 1669 account the cryptographic properties-- e.g it's resistance to 1670 collision-- of the hash algorithm itself. 1671 167211.4 Group Description and Group Type 1673 1674 Values of the Group Description Class identify a group to use in a 1675 Diffie-Hellman exchange. Values of the Group Type Class define the 1676 type of group. Requests for assignment of new groups must be 1677 accompanied by a reference to a standards-track or Informational RFC 1678 which describes this group. Requests for assignment of new group 1679 1680 1681 1682Harkins & Carrel Standards Track [Page 30] 1683 1684RFC 2409 IKE November 1998 1685 1686 1687 types must be accompanied by a reference to a standards-track or 1688 Informational RFC or by a reference to published cryptographic or 1689 mathmatical literature which describes the new type. 1690 169111.5 Life Type 1692 1693 Values of the Life Type Class define a type of lifetime to which the 1694 ISAKMP Security Association applies. Requests for assignment of new 1695 life types must be accompanied by a detailed description of the units 1696 of this type and its expiry. 1697 169812. Acknowledgements 1699 1700 This document is the result of close consultation with Hugo Krawczyk, 1701 Douglas Maughan, Hilarie Orman, Mark Schertler, Mark Schneider, and 1702 Jeff Turner. It relies on protocols which were written by them. 1703 Without their interest and dedication, this would not have been 1704 written. 1705 1706 Special thanks Rob Adams, Cheryl Madson, Derrell Piper, Harry Varnis, 1707 and Elfed Weaver for technical input, encouragement, and various 1708 sanity checks along the way. 1709 1710 We would also like to thank the many members of the IPSec working 1711 group that contributed to the development of this protocol over the 1712 past year. 1713 171413. References 1715 1716 [CAST] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, 1717 May 1997. 1718 1719 [BLOW] Schneier, B., "The Blowfish Encryption Algorithm", Dr. 1720 Dobb's Journal, v. 19, n. 4, April 1994. 1721 1722 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 1723 Requirement Levels", BCP 14, RFC 2119, March 1997. 1724 1725 [DES] ANSI X3.106, "American National Standard for Information 1726 Systems-Data Link Encryption", American National Standards 1727 Institute, 1983. 1728 1729 [DH] Diffie, W., and Hellman M., "New Directions in 1730 Cryptography", IEEE Transactions on Information Theory, V. 1731 IT-22, n. 6, June 1977. 1732 1733 1734 1735 1736 1737 1738Harkins & Carrel Standards Track [Page 31] 1739 1740RFC 2409 IKE November 1998 1741 1742 1743 [DSS] NIST, "Digital Signature Standard", FIPS 186, National 1744 Institute of Standards and Technology, U.S. Department of 1745 Commerce, May, 1994. 1746 1747 [IDEA] Lai, X., "On the Design and Security of Block Ciphers," ETH 1748 Series in Information Processing, v. 1, Konstanz: Hartung- 1749 Gorre Verlag, 1992 1750 1751 [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1752 Hashing for Message Authentication", RFC 2104, February 1753 1997. 1754 1755 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 1756 Mechanism for Internet", from IEEE Proceedings of the 1996 1757 Symposium on Network and Distributed Systems Security. 1758 1759 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 1760 April 1992. 1761 1762 [MSST98] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, 1763 "Internet Security Association and Key Management Protocol 1764 (ISAKMP)", RFC 2408, November 1998. 1765 1766 [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC 1767 2412, November 1998. 1768 1769 [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard", 1770 November 1993. 1771 1772 [Pip98] Piper, D., "The Internet IP Security Domain Of 1773 Interpretation for ISAKMP", RFC 2407, November 1998. 1774 1775 [RC5] Rivest, R., "The RC5 Encryption Algorithm", Dr. Dobb's 1776 Journal, v. 20, n. 1, January 1995. 1777 1778 [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for 1779 Obtaining Digital Signatures and Public-Key Cryptosystems", 1780 Communications of the ACM, v. 21, n. 2, February 1978. 1781 1782 [Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms, 1783 and Source Code in C", 2nd edition. 1784 1785 [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institue 1786 of Standards and Technology, U.S. Department of Commerce, 1787 May 1994. 1788 1789 [TIGER] Anderson, R., and Biham, E., "Fast Software Encryption", 1790 Springer LNCS v. 1039, 1996. 1791 1792 1793 1794Harkins & Carrel Standards Track [Page 32] 1795 1796RFC 2409 IKE November 1998 1797 1798 1799Appendix A 1800 1801 This is a list of DES Weak and Semi-Weak keys. The keys come from 1802 [Sch96]. All keys are listed in hexidecimal. 1803 1804 DES Weak Keys 1805 0101 0101 0101 0101 1806 1F1F 1F1F E0E0 E0E0 1807 E0E0 E0E0 1F1F 1F1F 1808 FEFE FEFE FEFE FEFE 1809 1810 DES Semi-Weak Keys 1811 01FE 01FE 01FE 01FE 1812 1FE0 1FE0 0EF1 0EF1 1813 01E0 01E0 01F1 01F1 1814 1FFE 1FFE 0EFE 0EFE 1815 011F 011F 010E 010E 1816 E0FE E0FE F1FE F1FE 1817 1818 FE01 FE01 FE01 FE01 1819 E01F E01F F10E F10E 1820 E001 E001 F101 F101 1821 FE1F FE1F FE0E FE0E 1822 1F01 1F01 0E01 0E01 1823 FEE0 FEE0 FEF1 FEF1 1824 1825 Attribute Assigned Numbers 1826 1827 Attributes negotiated during phase one use the following definitions. 1828 Phase two attributes are defined in the applicable DOI specification 1829 (for example, IPsec attributes are defined in the IPsec DOI), with 1830 the exception of a group description when Quick Mode includes an 1831 ephemeral Diffie-Hellman exchange. Attribute types can be either 1832 Basic (B) or Variable-length (V). Encoding of these attributes is 1833 defined in the base ISAKMP specification as Type/Value (Basic) and 1834 Type/Length/Value (Variable). 1835 1836 Attributes described as basic MUST NOT be encoded as variable. 1837 Variable length attributes MAY be encoded as basic attributes if 1838 their value can fit into two octets. If this is the case, an 1839 attribute offered as variable (or basic) by the initiator of this 1840 protocol MAY be returned to the initiator as a basic (or variable). 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850Harkins & Carrel Standards Track [Page 33] 1851 1852RFC 2409 IKE November 1998 1853 1854 1855 Attribute Classes 1856 1857 class value type 1858 ------------------------------------------------------------------- 1859 Encryption Algorithm 1 B 1860 Hash Algorithm 2 B 1861 Authentication Method 3 B 1862 Group Description 4 B 1863 Group Type 5 B 1864 Group Prime/Irreducible Polynomial 6 V 1865 Group Generator One 7 V 1866 Group Generator Two 8 V 1867 Group Curve A 9 V 1868 Group Curve B 10 V 1869 Life Type 11 B 1870 Life Duration 12 V 1871 PRF 13 B 1872 Key Length 14 B 1873 Field Size 15 B 1874 Group Order 16 V 1875 1876 values 17-16383 are reserved to IANA. Values 16384-32767 are for 1877 private use among mutually consenting parties. 1878 1879 Class Values 1880 1881 - Encryption Algorithm Defined In 1882 DES-CBC 1 RFC 2405 1883 IDEA-CBC 2 1884 Blowfish-CBC 3 1885 RC5-R16-B64-CBC 4 1886 3DES-CBC 5 1887 CAST-CBC 6 1888 1889 values 7-65000 are reserved to IANA. Values 65001-65535 are for 1890 private use among mutually consenting parties. 1891 1892 - Hash Algorithm Defined In 1893 MD5 1 RFC 1321 1894 SHA 2 FIPS 180-1 1895 Tiger 3 See Reference [TIGER] 1896 1897 values 4-65000 are reserved to IANA. Values 65001-65535 are for 1898 private use among mutually consenting parties. 1899 1900 1901 1902 1903 1904 1905 1906Harkins & Carrel Standards Track [Page 34] 1907 1908RFC 2409 IKE November 1998 1909 1910 1911 - Authentication Method 1912 pre-shared key 1 1913 DSS signatures 2 1914 RSA signatures 3 1915 Encryption with RSA 4 1916 Revised encryption with RSA 5 1917 1918 values 6-65000 are reserved to IANA. Values 65001-65535 are for 1919 private use among mutually consenting parties. 1920 1921 - Group Description 1922 default 768-bit MODP group (section 6.1) 1 1923 1924 alternate 1024-bit MODP group (section 6.2) 2 1925 1926 EC2N group on GP[2^155] (section 6.3) 3 1927 1928 EC2N group on GP[2^185] (section 6.4) 4 1929 1930 values 5-32767 are reserved to IANA. Values 32768-65535 are for 1931 private use among mutually consenting parties. 1932 1933 - Group Type 1934 MODP (modular exponentiation group) 1 1935 ECP (elliptic curve group over GF[P]) 2 1936 EC2N (elliptic curve group over GF[2^N]) 3 1937 1938 values 4-65000 are reserved to IANA. Values 65001-65535 are for 1939 private use among mutually consenting parties. 1940 1941 - Life Type 1942 seconds 1 1943 kilobytes 2 1944 1945 values 3-65000 are reserved to IANA. Values 65001-65535 are for 1946 private use among mutually consenting parties. For a given "Life 1947 Type" the value of the "Life Duration" attribute defines the actual 1948 length of the SA life-- either a number of seconds, or a number of 1949 kbytes protected. 1950 1951 - PRF 1952 There are currently no pseudo-random functions defined. 1953 1954 values 1-65000 are reserved to IANA. Values 65001-65535 are for 1955 private use among mutually consenting parties. 1956 1957 1958 1959 1960 1961 1962Harkins & Carrel Standards Track [Page 35] 1963 1964RFC 2409 IKE November 1998 1965 1966 1967 - Key Length 1968 1969 When using an Encryption Algorithm that has a variable length key, 1970 this attribute specifies the key length in bits. (MUST use network 1971 byte order). This attribute MUST NOT be used when the specified 1972 Encryption Algorithm uses a fixed length key. 1973 1974 - Field Size 1975 1976 The field size, in bits, of a Diffie-Hellman group. 1977 1978 - Group Order 1979 1980 The group order of an elliptical curve group. Note the length of 1981 this attribute depends on the field size. 1982 1983 Additional Exchanges Defined-- XCHG values 1984 Quick Mode 32 1985 New Group Mode 33 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018Harkins & Carrel Standards Track [Page 36] 2019 2020RFC 2409 IKE November 1998 2021 2022 2023Appendix B 2024 2025 This appendix describes encryption details to be used ONLY when 2026 encrypting ISAKMP messages. When a service (such as an IPSEC 2027 transform) utilizes ISAKMP to generate keying material, all 2028 encryption algorithm specific details (such as key and IV generation, 2029 padding, etc...) MUST be defined by that service. ISAKMP does not 2030 purport to ever produce keys that are suitable for any encryption 2031 algorithm. ISAKMP produces the requested amount of keying material 2032 from which the service MUST generate a suitable key. Details, such 2033 as weak key checks, are the responsibility of the service. 2034 2035 Use of negotiated PRFs may require the PRF output to be expanded due 2036 to the PRF feedback mechanism employed by this document. For example, 2037 if the (ficticious) DOORAK-MAC requires 24 bytes of key but produces 2038 only 8 bytes of output, the output must be expanded three times 2039 before being used as the key for another instance of itself. The 2040 output of a PRF is expanded by feeding back the results of the PRF 2041 into itself to generate successive blocks. These blocks are 2042 concatenated until the requisite number of bytes has been acheived. 2043 For example, for pre-shared key authentication with DOORAK-MAC as the 2044 negotiated PRF: 2045 2046 BLOCK1-8 = prf(pre-shared-key, Ni_b | Nr_b) 2047 BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni_b | Nr_b) 2048 BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni_b | Nr_b) 2049 and 2050 SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 2051 2052 so therefore to derive SKEYID_d: 2053 2054 BLOCK1-8 = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) 2055 BLOCK9-16 = prf(SKEYID, BLOCK1-8 | g^xy | CKY-I | CKY-R | 0) 2056 BLOCK17-24 = prf(SKEYID, BLOCK9-16 | g^xy | CKY-I | CKY-R | 0) 2057 and 2058 SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 2059 2060 Subsequent PRF derivations are done similarly. 2061 2062 Encryption keys used to protect the ISAKMP SA are derived from 2063 SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long 2064 enough to supply all the necessary keying material an algorithm 2065 requires, the key is derived from feeding the results of a pseudo- 2066 random function into itself, concatenating the results, and taking 2067 the highest necessary bits. 2068 2069 2070 2071 2072 2073 2074Harkins & Carrel Standards Track [Page 37] 2075 2076RFC 2409 IKE November 1998 2077 2078 2079 For example, if (ficticious) algorithm AKULA requires 320-bits of key 2080 (and has no weak key check) and the prf used to generate SKEYID_e 2081 only generates 120 bits of material, the key for AKULA, would be the 2082 first 320-bits of Ka, where: 2083 2084 Ka = K1 | K2 | K3 2085 and 2086 K1 = prf(SKEYID_e, 0) 2087 K2 = prf(SKEYID_e, K1) 2088 K3 = prf(SKEYID_e, K2) 2089 2090 where prf is the negotiated prf or the HMAC version of the negotiated 2091 hash function (if no prf was negotiated) and 0 is represented by a 2092 single octet. Each result of the prf provides 120 bits of material 2093 for a total of 360 bits. AKULA would use the first 320 bits of that 2094 360 bit string. 2095 2096 In phase 1, material for the initialization vector (IV material) for 2097 CBC mode encryption algorithms is derived from a hash of a 2098 concatenation of the initiator's public Diffie-Hellman value and the 2099 responder's public Diffie-Hellman value using the negotiated hash 2100 algorithm. This is used for the first message only. Each message 2101 should be padded up to the nearest block size using bytes containing 2102 0x00. The message length in the header MUST include the length of the 2103 pad since this reflects the size of the ciphertext. Subsequent 2104 messages MUST use the last CBC encryption block from the previous 2105 message as their initialization vector. 2106 2107 In phase 2, material for the initialization vector for CBC mode 2108 encryption of the first message of a Quick Mode exchange is derived 2109 from a hash of a concatenation of the last phase 1 CBC output block 2110 and the phase 2 message id using the negotiated hash algorithm. The 2111 IV for subsequent messages within a Quick Mode exchange is the CBC 2112 output block from the previous message. Padding and IVs for 2113 subsequent messages are done as in phase 1. 2114 2115 After the ISAKMP SA has been authenticated all Informational 2116 Exchanges are encrypted using SKEYID_e. The initiaization vector for 2117 these exchanges is derived in exactly the same fashion as that for a 2118 Quick Mode-- i.e. it is derived from a hash of a concatenation of the 2119 last phase 1 CBC output block and the message id from the ISAKMP 2120 header of the Informational Exchange (not the message id from the 2121 message that may have prompted the Informational Exchange). 2122 2123 Note that the final phase 1 CBC output block, the result of 2124 encryption/decryption of the last phase 1 message, must be retained 2125 in the ISAKMP SA state to allow for generation of unique IVs for each 2126 Quick Mode. Each post- phase 1 exchange (Quick Modes and 2127 2128 2129 2130Harkins & Carrel Standards Track [Page 38] 2131 2132RFC 2409 IKE November 1998 2133 2134 2135 Informational Exchanges) generates IVs independantly to prevent IVs 2136 from getting out of sync when two different exchanges are started 2137 simultaneously. 2138 2139 In all cases, there is a single bidirectional cipher/IV context. 2140 Having each Quick Mode and Informational Exchange maintain a unique 2141 context prevents IVs from getting out of sync. 2142 2143 The key for DES-CBC is derived from the first eight (8) non-weak and 2144 non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first 2145 8 bytes of the IV material derived above. 2146 2147 The key for IDEA-CBC is derived from the first sixteen (16) bytes of 2148 SKEYID_e. The IV is the first eight (8) bytes of the IV material 2149 derived above. 2150 2151 The key for Blowfish-CBC is either the negotiated key size, or the 2152 first fifty-six (56) bytes of a key (if no key size is negotiated) 2153 derived in the aforementioned pseudo-random function feedback method. 2154 The IV is the first eight (8) bytes of the IV material derived above. 2155 2156 The key for RC5-R16-B64-CBC is the negotiated key size, or the first 2157 sixteen (16) bytes of a key (if no key size is negotiated) derived 2158 from the aforementioned pseudo-random function feedback method if 2159 necessary. The IV is the first eight (8) bytes of the IV material 2160 derived above. The number of rounds MUST be 16 and the block size 2161 MUST be 64. 2162 2163 The key for 3DES-CBC is the first twenty-four (24) bytes of a key 2164 derived in the aforementioned pseudo-random function feedback method. 2165 3DES-CBC is an encrypt-decrypt-encrypt operation using the first, 2166 middle, and last eight (8) bytes of the entire 3DES-CBC key. The IV 2167 is the first eight (8) bytes of the IV material derived above. 2168 2169 The key for CAST-CBC is either the negotiated key size, or the first 2170 sixteen (16) bytes of a key derived in the aforementioned pseudo- 2171 random function feedback method. The IV is the first eight (8) bytes 2172 of the IV material derived above. 2173 2174 Support for algorithms other than DES-CBC is purely optional. Some 2175 optional algorithms may be subject to intellectual property claims. 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186Harkins & Carrel Standards Track [Page 39] 2187 2188RFC 2409 IKE November 1998 2189 2190 2191Authors' Addresses 2192 2193 Dan Harkins 2194 cisco Systems 2195 170 W. Tasman Dr. 2196 San Jose, California, 95134-1706 2197 United States of America 2198 2199 Phone: +1 408 526 4000 2200 EMail: dharkins@cisco.com 2201 2202 2203 Dave Carrel 2204 76 Lippard Ave. 2205 San Francisco, CA 94131-2947 2206 United States of America 2207 2208 Phone: +1 415 337 8469 2209 EMail: carrel@ipsec.org 2210 2211Authors' Note 2212 2213 The authors encourage independent implementation, and 2214 interoperability testing, of this hybrid protocol. 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242Harkins & Carrel Standards Track [Page 40] 2243 2244RFC 2409 IKE November 1998 2245 2246 2247Full Copyright Statement 2248 2249 Copyright (C) The Internet Society (1998). All Rights Reserved. 2250 2251 This document and translations of it may be copied and furnished to 2252 others, and derivative works that comment on or otherwise explain it 2253 or assist in its implementation may be prepared, copied, published 2254 and distributed, in whole or in part, without restriction of any 2255 kind, provided that the above copyright notice and this paragraph are 2256 included on all such copies and derivative works. However, this 2257 document itself may not be modified in any way, such as by removing 2258 the copyright notice or references to the Internet Society or other 2259 Internet organizations, except as needed for the purpose of 2260 developing Internet standards in which case the procedures for 2261 copyrights defined in the Internet Standards process must be 2262 followed, or as required to translate it into languages other than 2263 English. 2264 2265 The limited permissions granted above are perpetual and will not be 2266 revoked by the Internet Society or its successors or assigns. 2267 2268 This document and the information contained herein is provided on an 2269 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2270 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2271 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2272 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2273 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298Harkins & Carrel Standards Track [Page 41] 2299 2300