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