1 2 3 4 5 6 7Network Working Group D. Maughan 8Request for Comments: 2408 National Security Agency 9Category: Standards Track M. Schertler 10 Securify, Inc. 11 M. Schneider 12 National Security Agency 13 J. Turner 14 RABA Technologies, Inc. 15 November 1998 16 17 18 Internet Security Association and Key Management Protocol (ISAKMP) 19 20Status of this Memo 21 22 This document specifies an Internet standards track protocol for the 23 Internet community, and requests discussion and suggestions for 24 improvements. Please refer to the current edition of the "Internet 25 Official Protocol Standards" (STD 1) for the standardization state 26 and status of this protocol. Distribution of this memo is unlimited. 27 28Copyright Notice 29 30 Copyright (C) The Internet Society (1998). All Rights Reserved. 31 32Abstract 33 34 This memo describes a protocol utilizing security concepts necessary 35 for establishing Security Associations (SA) and cryptographic keys in 36 an Internet environment. A Security Association protocol that 37 negotiates, establishes, modifies and deletes Security Associations 38 and their attributes is required for an evolving Internet, where 39 there will be numerous security mechanisms and several options for 40 each security mechanism. The key management protocol must be robust 41 in order to handle public key generation for the Internet community 42 at large and private key requirements for those private networks with 43 that requirement. The Internet Security Association and Key 44 Management Protocol (ISAKMP) defines the procedures for 45 authenticating a communicating peer, creation and management of 46 Security Associations, key generation techniques, and threat 47 mitigation (e.g. denial of service and replay attacks). All of 48 these are necessary to establish and maintain secure communications 49 (via IP Security Service or any other security protocol) in an 50 Internet environment. 51 52 53 54 55 56 57 58Maughan, et. al. Standards Track [Page 1] 59 60RFC 2408 ISAKMP November 1998 61 62 63Table of Contents 64 65 1 Introduction 4 66 1.1 Requirements Terminology . . . . . . . . . . . . . . . . . 5 67 1.2 The Need for Negotiation . . . . . . . . . . . . . . . . . 5 68 1.3 What can be Negotiated? . . . . . . . . . . . . . . . . . 6 69 1.4 Security Associations and Management . . . . . . . . . . . 7 70 1.4.1 Security Associations and Registration . . . . . . . . 7 71 1.4.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 8 72 1.5 Authentication . . . . . . . . . . . . . . . . . . . . . . 8 73 1.5.1 Certificate Authorities . . . . . . . . . . . . . . . 9 74 1.5.2 Entity Naming . . . . . . . . . . . . . . . . . . . . 9 75 1.5.3 ISAKMP Requirements . . . . . . . . . . . . . . . . . 10 76 1.6 Public Key Cryptography . . . . . . . . . . . . . . . . . . 10 77 1.6.1 Key Exchange Properties . . . . . . . . . . . . . . . 11 78 1.6.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 12 79 1.7 ISAKMP Protection . . . . . . . . . . . . . . . . . . . . . 12 80 1.7.1 Anti-Clogging (Denial of Service) . . . . . . . . . . 12 81 1.7.2 Connection Hijacking . . . . . . . . . . . . . . . . . 13 82 1.7.3 Man-in-the-Middle Attacks . . . . . . . . . . . . . . 13 83 1.8 Multicast Communications . . . . . . . . . . . . . . . . . 13 84 2 Terminology and Concepts 14 85 2.1 ISAKMP Terminology . . . . . . . . . . . . . . . . . . . . 14 86 2.2 ISAKMP Placement . . . . . . . . . . . . . . . . . . . . . 16 87 2.3 Negotiation Phases . . . . . . . . . . . . . . . . . . . . 16 88 2.4 Identifying Security Associations . . . . . . . . . . . . . 17 89 2.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . 20 90 2.5.1 Transport Protocol . . . . . . . . . . . . . . . . . . 20 91 2.5.2 RESERVED Fields . . . . . . . . . . . . . . . . . . . 20 92 2.5.3 Anti-Clogging Token ("Cookie") Creation . . . . . . . 20 93 3 ISAKMP Payloads 21 94 3.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 21 95 3.2 Generic Payload Header . . . . . . . . . . . . . . . . . . 25 96 3.3 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 25 97 3.4 Security Association Payload . . . . . . . . . . . . . . . 27 98 3.5 Proposal Payload . . . . . . . . . . . . . . . . . . . . . 28 99 3.6 Transform Payload . . . . . . . . . . . . . . . . . . . . . 29 100 3.7 Key Exchange Payload . . . . . . . . . . . . . . . . . . . 31 101 3.8 Identification Payload . . . . . . . . . . . . . . . . . . 32 102 3.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . 33 103 3.10 Certificate Request Payload . . . . . . . . . . . . . . . 34 104 3.11 Hash Payload . . . . . . . . . . . . . . . . . . . . . . 36 105 3.12 Signature Payload . . . . . . . . . . . . . . . . . . . . 37 106 3.13 Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 37 107 3.14 Notification Payload . . . . . . . . . . . . . . . . . . 38 108 3.14.1 Notify Message Types . . . . . . . . . . . . . . . . 40 109 3.15 Delete Payload . . . . . . . . . . . . . . . . . . . . . 41 110 3.16 Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 43 111 112 113 114Maughan, et. al. Standards Track [Page 2] 115 116RFC 2408 ISAKMP November 1998 117 118 119 4 ISAKMP Exchanges 44 120 4.1 ISAKMP Exchange Types . . . . . . . . . . . . . . . . . . . 45 121 4.1.1 Notation . . . . . . . . . . . . . . . . . . . . . . . 46 122 4.2 Security Association Establishment . . . . . . . . . . . . 46 123 4.2.1 Security Association Establishment Examples . . . . . 48 124 4.3 Security Association Modification . . . . . . . . . . . . . 50 125 4.4 Base Exchange . . . . . . . . . . . . . . . . . . . . . . . 51 126 4.5 Identity Protection Exchange . . . . . . . . . . . . . . . 52 127 4.6 Authentication Only Exchange . . . . . . . . . . . . . . . 54 128 4.7 Aggressive Exchange . . . . . . . . . . . . . . . . . . . . 55 129 4.8 Informational Exchange . . . . . . . . . . . . . . . . . . 57 130 5 ISAKMP Payload Processing 58 131 5.1 General Message Processing . . . . . . . . . . . . . . . . 58 132 5.2 ISAKMP Header Processing . . . . . . . . . . . . . . . . . 59 133 5.3 Generic Payload Header Processing . . . . . . . . . . . . . 61 134 5.4 Security Association Payload Processing . . . . . . . . . . 62 135 5.5 Proposal Payload Processing . . . . . . . . . . . . . . . . 63 136 5.6 Transform Payload Processing . . . . . . . . . . . . . . . 64 137 5.7 Key Exchange Payload Processing . . . . . . . . . . . . . . 65 138 5.8 Identification Payload Processing . . . . . . . . . . . . . 66 139 5.9 Certificate Payload Processing . . . . . . . . . . . . . . 66 140 5.10 Certificate Request Payload Processing . . . . . . . . . 67 141 5.11 Hash Payload Processing . . . . . . . . . . . . . . . . . 69 142 5.12 Signature Payload Processing . . . . . . . . . . . . . . 69 143 5.13 Nonce Payload Processing . . . . . . . . . . . . . . . . 70 144 5.14 Notification Payload Processing . . . . . . . . . . . . . 71 145 5.15 Delete Payload Processing . . . . . . . . . . . . . . . . 73 146 6 Conclusions 75 147 A ISAKMP Security Association Attributes 77 148 A.1 Background/Rationale . . . . . . . . . . . . . . . . . . . 77 149 A.2 Internet IP Security DOI Assigned Value . . . . . . . . . . 77 150 A.3 Supported Security Protocols . . . . . . . . . . . . . . . 77 151 A.4 ISAKMP Identification Type Values . . . . . . . . . . . . . 78 152 A.4.1 ID_IPV4_ADDR . . . . . . . . . . . . . . . . . . . . . 78 153 A.4.2 ID_IPV4_ADDR_SUBNET . . . . . . . . . . . . . . . . . . 78 154 A.4.3 ID_IPV6_ADDR . . . . . . . . . . . . . . . . . . . . . 78 155 A.4.4 ID_IPV6_ADDR_SUBNET . . . . . . . . . . . . . . . . . 78 156 B Defining a new Domain of Interpretation 79 157 B.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . 79 158 B.2 Security Policies . . . . . . . . . . . . . . . . . . . . . 80 159 B.3 Naming Schemes . . . . . . . . . . . . . . . . . . . . . . 80 160 B.4 Syntax for Specifying Security Services . . . . . . . . . . 80 161 B.5 Payload Specification . . . . . . . . . . . . . . . . . . . 80 162 B.6 Defining new Exchange Types . . . . . . . . . . . . . . . . 80 163 Security Considerations 81 164 IANA Considerations 81 165 Domain of Interpretation 81 166 Supported Security Protocols 82 167 168 169 170Maughan, et. al. Standards Track [Page 3] 171 172RFC 2408 ISAKMP November 1998 173 174 175 Acknowledgements 82 176 References 82 177 Authors' Addresses 85 178 Full Copyright Statement 86 179 180List of Figures 181 182 1 ISAKMP Relationships . . . . . . . . . . . . . . . . . . . 16 183 2 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 22 184 3 Generic Payload Header . . . . . . . . . . . . . . . . . . 25 185 4 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 26 186 5 Security Association Payload . . . . . . . . . . . . . . . 27 187 6 Proposal Payload Format . . . . . . . . . . . . . . . . . . 28 188 7 Transform Payload Format . . . . . . . . . . . . . . . . . 30 189 8 Key Exchange Payload Format . . . . . . . . . . . . . . . . 31 190 9 Identification Payload Format . . . . . . . . . . . . . . . 32 191 10 Certificate Payload Format . . . . . . . . . . . . . . . . 33 192 11 Certificate Request Payload Format . . . . . . . . . . . . 34 193 12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . 36 194 13 Signature Payload Format . . . . . . . . . . . . . . . . . 37 195 14 Nonce Payload Format . . . . . . . . . . . . . . . . . . . 38 196 15 Notification Payload Format . . . . . . . . . . . . . . . . 39 197 16 Delete Payload Format . . . . . . . . . . . . . . . . . . . 42 198 17 Vendor ID Payload Format . . . . . . . . . . . . . . . . . 44 199 2001 Introduction 201 202 This document describes an Internet Security Association and Key 203 Management Protocol (ISAKMP). ISAKMP combines the security concepts 204 of authentication, key management, and security associations to 205 establish the required security for government, commercial, and 206 private communications on the Internet. 207 208 The Internet Security Association and Key Management Protocol 209 (ISAKMP) defines procedures and packet formats to establish, 210 negotiate, modify and delete Security Associations (SA). SAs contain 211 all the information required for execution of various network 212 security services, such as the IP layer services (such as header 213 authentication and payload encapsulation), transport or application 214 layer services, or self-protection of negotiation traffic. ISAKMP 215 defines payloads for exchanging key generation and authentication 216 data. These formats provide a consistent framework for transferring 217 key and authentication data which is independent of the key 218 generation technique, encryption algorithm and authentication 219 mechanism. 220 221 222 223 224 225 226Maughan, et. al. Standards Track [Page 4] 227 228RFC 2408 ISAKMP November 1998 229 230 231 ISAKMP is distinct from key exchange protocols in order to cleanly 232 separate the details of security association management (and key 233 management) from the details of key exchange. There may be many 234 different key exchange protocols, each with different security 235 properties. However, a common framework is required for agreeing to 236 the format of SA attributes, and for negotiating, modifying, and 237 deleting SAs. ISAKMP serves as this common framework. 238 239 Separating the functionality into three parts adds complexity to the 240 security analysis of a complete ISAKMP implementation. However, the 241 separation is critical for interoperability between systems with 242 differing security requirements, and should also simplify the 243 analysis of further evolution of a ISAKMP server. 244 245 ISAKMP is intended to support the negotiation of SAs for security 246 protocols at all layers of the network stack (e.g., IPSEC, TLS, TLSP, 247 OSPF, etc.). By centralizing the management of the security 248 associations, ISAKMP reduces the amount of duplicated functionality 249 within each security protocol. ISAKMP can also reduce connection 250 setup time, by negotiating a whole stack of services at once. 251 252 The remainder of section 1 establishes the motivation for security 253 negotiation and outlines the major components of ISAKMP, i.e. 254 Security Associations and Management, Authentication, Public Key 255 Cryptography, and Miscellaneous items. Section 2 presents the 256 terminology and concepts associated with ISAKMP. Section 3 describes 257 the different ISAKMP payload formats. Section 4 describes how the 258 payloads of ISAKMP are composed together as exchange types to 259 establish security associations and perform key exchanges in an 260 authenticated manner. Additionally, security association 261 modification, deletion, and error notification are discussed. 262 Section 5 describes the processing of each payload within the context 263 of ISAKMP exchanges, including error handling and associated actions. 264 The appendices provide the attribute values necessary for ISAKMP and 265 requirement for defining a new Domain of Interpretation (DOI) within 266 ISAKMP. 267 2681.1 Requirements Terminology 269 270 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 271 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 272 document, are to be interpreted as described in [RFC-2119]. 273 2741.2 The Need for Negotiation 275 276 ISAKMP extends the assertion in [DOW92] that authentication and key 277 exchanges must be combined for better security to include security 278 association exchanges. The security services required for 279 280 281 282Maughan, et. al. Standards Track [Page 5] 283 284RFC 2408 ISAKMP November 1998 285 286 287 communications depends on the individual network configurations and 288 environments. Organizations are setting up Virtual Private Networks 289 (VPN), also known as Intranets, that will require one set of security 290 functions for communications within the VPN and possibly many 291 different security functions for communications outside the VPN to 292 support geographically separate organizational components, customers, 293 suppliers, sub-contractors (with their own VPNs), government, and 294 others. Departments within large organizations may require a number 295 of security associations to separate and protect data (e.g. 296 personnel data, company proprietary data, medical) on internal 297 networks and other security associations to communicate within the 298 same department. Nomadic users wanting to "phone home" represent 299 another set of security requirements. These requirements must be 300 tempered with bandwidth challenges. Smaller groups of people may 301 meet their security requirements by setting up "Webs of Trust". 302 ISAKMP exchanges provide these assorted networking communities the 303 ability to present peers with the security functionality that the 304 user supports in an authenticated and protected manner for agreement 305 upon a common set of security attributes, i.e. an interoperable 306 security association. 307 3081.3 What can be Negotiated? 309 310 Security associations must support different encryption algorithms, 311 authentication mechanisms, and key establishment algorithms for other 312 security protocols, as well as IP Security. Security associations 313 must also support host-oriented certificates for lower layer 314 protocols and user- oriented certificates for higher level protocols. 315 Algorithm and mechanism independence is required in applications such 316 as e-mail, remote login, and file transfer, as well as in session 317 oriented protocols, routing protocols, and link layer protocols. 318 ISAKMP provides a common security association and key establishment 319 protocol for this wide range of security protocols, applications, 320 security requirements, and network environments. 321 322 ISAKMP is not bound to any specific cryptographic algorithm, key 323 generation technique, or security mechanism. This flexibility is 324 beneficial for a number of reasons. First, it supports the dynamic 325 communications environment described above. Second, the independence 326 from specific security mechanisms and algorithms provides a forward 327 migration path to better mechanisms and algorithms. When improved 328 security mechanisms are developed or new attacks against current 329 encryption algorithms, authentication mechanisms and key exchanges 330 are discovered, ISAKMP will allow the updating of the algorithms and 331 mechanisms without having to develop a completely new KMP or patch 332 the current one. 333 334 335 336 337 338Maughan, et. al. Standards Track [Page 6] 339 340RFC 2408 ISAKMP November 1998 341 342 343 ISAKMP has basic requirements for its authentication and key exchange 344 components. These requirements guard against denial of service, 345 replay / reflection, man-in-the-middle, and connection hijacking 346 attacks. This is important because these are the types of attacks 347 that are targeted against protocols. Complete Security Association 348 (SA) support, which provides mechanism and algorithm independence, 349 and protection from protocol threats are the strengths of ISAKMP. 350 3511.4 Security Associations and Management 352 353 A Security Association (SA) is a relationship between two or more 354 entities that describes how the entities will utilize security 355 services to communicate securely. This relationship is represented 356 by a set of information that can be considered a contract between the 357 entities. The information must be agreed upon and shared between all 358 the entities. Sometimes the information alone is referred to as an 359 SA, but this is just a physical instantiation of the existing 360 relationship. The existence of this relationship, represented by the 361 information, is what provides the agreed upon security information 362 needed by entities to securely interoperate. All entities must 363 adhere to the SA for secure communications to be possible. When 364 accessing SA attributes, entities use a pointer or identifier refered 365 to as the Security Parameter Index (SPI). [SEC-ARCH] provides details 366 on IP Security Associations (SA) and Security Parameter Index (SPI) 367 definitions. 368 3691.4.1 Security Associations and Registration 370 371 The SA attributes required and recommended for the IP Security (AH, 372 ESP) are defined in [SEC-ARCH]. The attributes specified for an IP 373 Security SA include, but are not limited to, authentication 374 mechanism, cryptographic algorithm, algorithm mode, key length, and 375 Initialization Vector (IV). Other protocols that provide algorithm 376 and mechanism independent security MUST define their requirements for 377 SA attributes. The separation of ISAKMP from a specific SA 378 definition is important to ensure ISAKMP can es tablish SAs for all 379 possible security protocols and applications. 380 381 NOTE: See [IPDOI] for a discussion of SA attributes that should be 382 considered when defining a security protocol or application. 383 384 In order to facilitate easy identification of specific attributes 385 (e.g. a specific encryption algorithm) among different network 386 entites the attributes must be assigned identifiers and these 387 identifiers must be registered by a central authority. The Internet 388 Assigned Numbers Authority (IANA) provides this function for the 389 Internet. 390 391 392 393 394Maughan, et. al. Standards Track [Page 7] 395 396RFC 2408 ISAKMP November 1998 397 398 3991.4.2 ISAKMP Requirements 400 401 Security Association (SA) establishment MUST be part of the key 402 management protocol defined for IP based networks. The SA concept is 403 required to support security protocols in a diverse and dynamic 404 networking environment. Just as authentication and key exchange must 405 be linked to provide assurance that the key is established with the 406 authenticated party [DOW92], SA establishment must be linked with the 407 authentication and the key exchange protocol. 408 409 ISAKMP provides the protocol exchanges to establish a security 410 association between negotiating entities followed by the 411 establishment of a security association by these negotiating entities 412 in behalf of some protocol (e.g. ESP/AH). First, an initial protocol 413 exchange allows a basic set of security attributes to be agreed upon. 414 This basic set provides protection for subsequent ISAKMP exchanges. 415 It also indicates the authentication method and key exchange that 416 will be performed as part of the ISAKMP protocol. If a basic set of 417 security attributes is already in place between the negotiating 418 server entities, the initial ISAKMP exchange may be skipped and the 419 establishment of a security association can be done directly. After 420 the basic set of security attributes has been agreed upon, initial 421 identity authenticated, and required keys generated, the established 422 SA can be used for subsequent communications by the entity that 423 invoked ISAKMP. The basic set of SA attributes that MUST be 424 implemented to provide ISAKMP interoperability are defined in 425 Appendix A. 426 4271.5 Authentication 428 429 A very important step in establishing secure network communications 430 is authentication of the entity at the other end of the 431 communication. Many authentication mechanisms are available. 432 Authentication mechanisms fall into two catagories of strength - weak 433 and strong. Sending cleartext keys or other unprotected 434 authenticating information over a network is weak, due to the threat 435 of reading them with a network sniffer. Additionally, sending one- 436 way hashed poorly-chosen keys with low entropy is also weak, due to 437 the threat of brute-force guessing attacks on the sniffed messages. 438 While passwords can be used for establishing identity, they are not 439 considered in this context because of recent statements from the 440 Internet Architecture Board [IAB]. Digital signatures, such as the 441 Digital Signature Standard (DSS) and the Rivest-Shamir-Adleman (RSA) 442 signature, are public key based strong authentication mechanisms. 443 When using public key digital signatures each entity requires a 444 public key and a private key. Certificates are an essential part of 445 a digital signature authentication mechanism. Certificates bind a 446 specific entity's identity (be it host, network, user, or 447 448 449 450Maughan, et. al. Standards Track [Page 8] 451 452RFC 2408 ISAKMP November 1998 453 454 455 application) to its public keys and possibly other security-related 456 information such as privileges, clearances, and compartments. 457 Authentication based on digital signatures requires a trusted third 458 party or certificate authority to create, sign and properly 459 distribute certificates. For more detailed information on digital 460 signatures, such as DSS and RSA, and certificates see [Schneier]. 461 4621.5.1 Certificate Authorities 463 464 Certificates require an infrastructure for generation, verification, 465 revocation, management and distribution. The Internet Policy 466 Registration Authority (IPRA) [RFC-1422] has been established to 467 direct this infrastructure for the IETF. The IPRA certifies Policy 468 Certification Authorities (PCA). PCAs control Certificate Authorities 469 (CA) which certify users and subordinate entities. Current 470 certificate related work includes the Domain Name System (DNS) 471 Security Extensions [DNSSEC] which will provide signed entity keys in 472 the DNS. The Public Key Infrastucture (PKIX) working group is 473 specifying an Internet profile for X.509 certificates. There is also 474 work going on in industry to develop X.500 Directory Services which 475 would provide X.509 certificates to users. The U.S. Post Office is 476 developing a (CA) hierarchy. The NIST Public Key Infrastructure 477 Working Group has also been doing work in this area. The DOD Multi 478 Level Information System Security Initiative (MISSI) program has 479 begun deploying a certificate infrastructure for the U.S. Government. 480 Alternatively, if no infrastructure exists, the PGP Web of Trust 481 certificates can be used to provide user authentication and privacy 482 in a community of users who know and trust each other. 483 4841.5.2 Entity Naming 485 486 An entity's name is its identity and is bound to its public keys in 487 certificates. The CA MUST define the naming semantics for the 488 certificates it issues. See the UNINETT PCA Policy Statements 489 [Berge] for an example of how a CA defines its naming policy. When 490 the certificate is verified, the name is verified and that name will 491 have meaning within the realm of that CA. An example is the DNS 492 security extensions which make DNS servers CAs for the zones and 493 nodes they serve. Resource records are provided for public keys and 494 signatures on those keys. The names associated with the keys are IP 495 addresses and domain names which have meaning to entities accessing 496 the DNS for this information. A Web of Trust is another example. 497 When webs of trust are set up, names are bound with the public keys. 498 In PGP the name is usually the entity's e-mail address which has 499 meaning to those, and only those, who understand e-mail. Another web 500 of trust could use an entirely different naming scheme. 501 502 503 504 505 506Maughan, et. al. Standards Track [Page 9] 507 508RFC 2408 ISAKMP November 1998 509 510 5111.5.3 ISAKMP Requirements 512 513 Strong authentication MUST be provided on ISAKMP exchanges. Without 514 being able to authenticate the entity at the other end, the Security 515 Association (SA) and session key established are suspect. Without 516 authentication you are unable to trust an entity's identification, 517 which makes access control questionable. While encryption (e.g. 518 ESP) and integrity (e.g. AH) will protect subsequent communications 519 from passive eavesdroppers, without authentication it is possible 520 that the SA and key may have been established with an adversary who 521 performed an active man-in-the-middle attack and is now stealing all 522 your personal data. 523 524 A digital signature algorithm MUST be used within ISAKMP's 525 authentication component. However, ISAKMP does not mandate a 526 specific signature algorithm or certificate authority (CA). ISAKMP 527 allows an entity initiating communications to indicate which CAs it 528 supports. After selection of a CA, the protocol provides the 529 messages required to support the actual authentication exchange. The 530 protocol provides a facility for identification of different 531 certificate authorities, certificate types (e.g. X.509, PKCS #7, 532 PGP, DNS SIG and KEY records), and the exchange of the certificates 533 identified. 534 535 ISAKMP utilizes digital signatures, based on public key cryptography, 536 for authentication. There are other strong authentication systems 537 available, which could be specified as additional optional 538 authentication mechanisms for ISAKMP. Some of these authentication 539 systems rely on a trusted third party called a key distribution 540 center (KDC) to distribute secret session keys. An example is 541 Kerberos, where the trusted third party is the Kerberos server, which 542 holds secret keys for all clients and servers within its network 543 domain. A client's proof that it holds its secret key provides 544 authenticaton to a server. 545 546 The ISAKMP specification does not specify the protocol for 547 communicating with the trusted third parties (TTP) or certificate 548 directory services. These protocols are defined by the TTP and 549 directory service themselves and are outside the scope of this 550 specification. The use of these additional services and protocols 551 will be described in a Key Exchange specific document. 552 5531.6 Public Key Cryptography 554 555 Public key cryptography is the most flexible, scalable, and efficient 556 way for users to obtain the shared secrets and session keys needed to 557 support the large number of ways Internet users will interoperate. 558 Many key generation algorithms, that have different properties, are 559 560 561 562Maughan, et. al. Standards Track [Page 10] 563 564RFC 2408 ISAKMP November 1998 565 566 567 available to users (see [DOW92], [ANSI], and [Oakley]). Properties 568 of key exchange protocols include the key establishment method, 569 authentication, symmetry, perfect forward secrecy, and back traffic 570 protection. 571 572 NOTE: Cryptographic keys can protect information for a considerable 573 length of time. However, this is based on the assumption that keys 574 used for protection of communications are destroyed after use and not 575 kept for any reason. 576 5771.6.1 Key Exchange Properties 578 579 Key Establishment (Key Generation / Key Transport): The two common 580 methods of using public key cryptography for key establishment are 581 key transport and key generation. An example of key transport is the 582 use of the RSA algorithm to encrypt a randomly generated session key 583 (for encrypting subsequent communications) with the recipient's 584 public key. The encrypted random key is then sent to the recipient, 585 who decrypts it using his private key. At this point both sides have 586 the same session key, however it was created based on input from only 587 one side of the communications. The benefit of the key transport 588 method is that it has less computational overhead than the following 589 method. The Diffie-Hellman (D-H) algorithm illustrates key 590 generation using public key cryptography. The D-H algorithm is begun 591 by two users exchanging public information. Each user then 592 mathematically combines the other's public information along with 593 their own secret information to compute a shared secret value. This 594 secret value can be used as a session key or as a key encryption key 595 for encrypting a randomly generated session key. This method 596 generates a session key based on public and secret information held 597 by both users. The benefit of the D-H algorithm is that the key used 598 for encrypting messages is based on information held by both users 599 and the independence of keys from one key exchange to another 600 provides perfect forward secrecy. Detailed descriptions of these 601 algorithms can be found in [Schneier]. There are a number of 602 variations on these two key generation schemes and these variations 603 do not necessarily interoperate. 604 605 Key Exchange Authentication: Key exchanges may be authenticated 606 during the protocol or after protocol completion. Authentication of 607 the key exchange during the protocol is provided when each party 608 provides proof it has the secret session key before the end of the 609 protocol. Proof can be provided by encrypting known data in the 610 secret session key during the protocol echange. Authentication after 611 the protocol must occur in subsequent commu nications. 612 Authentication during the protocol is preferred so subsequent 613 communications are not initiated if the secret session key is not 614 established with the desired party. 615 616 617 618Maughan, et. al. Standards Track [Page 11] 619 620RFC 2408 ISAKMP November 1998 621 622 623 Key Exchange Symmetry: A key exchange provides symmetry if either 624 party can initiate the exchange and exchanged messages can cross in 625 transit without affecting the key that is generated. This is 626 desirable so that computation of the keys does not require either 627 party to know who initated the exchange. While key exchange symmetry 628 is desirable, symmetry in the entire key management protocol may 629 provide a vulnerablity to reflection attacks. 630 631 Perfect Forward Secrecy: As described in [DOW92], an authenticated 632 key exchange protocol provides perfect forward secrecy if disclosure 633 of longterm secret keying material does not compromise the secrecy of 634 the exchanged keys from previous communications. The property of 635 perfect forward secrecy does not apply to key exchange without 636 authentication. 637 6381.6.2 ISAKMP Requirements 639 640 An authenticated key exchange MUST be supported by ISAKMP. Users 641 SHOULD choose additional key establishment algorithms based on their 642 requirements. ISAKMP does not specify a specific key exchange. 643 However, [IKE] describes a proposal for using the Oakley key exchange 644 [Oakley] in conjunction with ISAKMP. Requirements that should be 645 evaluated when choosing a key establishment algorithm include 646 establishment method (generation vs. transport), perfect forward 647 secrecy, computational overhead, key escrow, and key strength. Based 648 on user requirements, ISAKMP allows an entity initiating 649 communications to indicate which key exchanges it supports. After 650 selection of a key exchange, the protocol provides the messages 651 required to support the actual key establishment. 652 6531.7 ISAKMP Protection 654 6551.7.1 Anti-Clogging (Denial of Service) 656 657 Of the numerous security services available, protection against 658 denial of service always seems to be one of the most difficult to 659 address. A "cookie" or anti-clogging token (ACT) is aimed at 660 protecting the computing resources from attack without spending 661 excessive CPU resources to determine its authenticity. An exchange 662 prior to CPU-intensive public key operations can thwart some denial 663 of service attempts (e.g. simple flooding with bogus IP source 664 addresses). Absolute protection against denial of service is 665 impossible, but this anti-clogging token provides a technique for 666 making it easier to handle. The use of an anti-clogging token was 667 introduced by Karn and Simpson in [Karn]. 668 669 670 671 672 673 674Maughan, et. al. Standards Track [Page 12] 675 676RFC 2408 ISAKMP November 1998 677 678 679 It should be noted that in the exchanges shown in section 4, the 680 anticlogging mechanism should be used in conjuction with a garbage- 681 state collection mechanism; an attacker can still flood a server 682 using packets with bogus IP addresses and cause state to be created. 683 Such aggressive memory management techniques SHOULD be employed by 684 protocols using ISAKMP that do not go through an initial, anti- 685 clogging only phase, as was done in [Karn]. 686 6871.7.2 Connection Hijacking 688 689 ISAKMP prevents connection hijacking by linking the authentication, 690 key exchange and security association exchanges. This linking 691 prevents an attacker from allowing the authentication to complete and 692 then jumping in and impersonating one entity to the other during the 693 key and security association exchanges. 694 6951.7.3 Man-in-the-Middle Attacks 696 697 Man-in-the-Middle attacks include interception, insertion, deletion, 698 and modification of messages, reflecting messages back at the sender, 699 replaying old messages and redirecting messages. ISAKMP features 700 prevent these types of attacks from being successful. The linking of 701 the ISAKMP exchanges prevents the insertion of messages in the 702 protocol exchange. The ISAKMP protocol state machine is defined so 703 deleted messages will not cause a partial SA to be created, the state 704 machine will clear all state and return to idle. The state machine 705 also prevents reflection of a message from causing harm. The 706 requirement for a new cookie with time variant material for each new 707 SA establishment prevents attacks that involve replaying old 708 messages. The ISAKMP strong authentication requirement prevents an 709 SA from being established with anyone other than the intended party. 710 Messages may be redirected to a different destination or modified but 711 this will be detected and an SA will not be established. The ISAKMP 712 specification defines where abnormal processing has occurred and 713 recommends notifying the appropriate party of this abnormality. 714 7151.8 Multicast Communications 716 717 It is expected that multicast communications will require the same 718 security services as unicast communications and may introduce the 719 need for additional security services. The issues of distributing 720 SPIs for multicast traffic are presented in [SEC-ARCH]. Multicast 721 security issues are also discussed in [RFC-1949] and [BC]. A future 722 extension to ISAKMP will support multicast key distribution. For an 723 introduction to the issues related to multicast security, consult the 724 Internet Drafts, [RFC-2094] and [RFC-2093], describing Sparta's 725 research in this area. 726 727 728 729 730Maughan, et. al. Standards Track [Page 13] 731 732RFC 2408 ISAKMP November 1998 733 734 7352 Terminology and Concepts 736 7372.1 ISAKMP Terminology 738 739 Security Protocol: A Security Protocol consists of an entity at a 740 single point in the network stack, performing a security service for 741 network communication. For example, IPSEC ESP and IPSEC AH are two 742 different security protocols. TLS is another example. Security 743 Protocols may perform more than one service, for example providing 744 integrity and confidentiality in one module. 745 746 Protection Suite: A protection suite is a list of the security 747 services that must be applied by various security protocols. For 748 example, a protection suite may consist of DES encryption in IP ESP, 749 and keyed MD5 in IP AH. All of the protections in a suite must be 750 treated as a single unit. This is necessary because security 751 services in different security protocols can have subtle 752 interactions, and the effects of a suite must be analyzed and 753 verified as a whole. 754 755 Security Association (SA): A Security Association is a security- 756 protocol- specific set of parameters that completely defines the 757 services and mechanisms necessary to protect traffic at that security 758 protocol location. These parameters can include algorithm 759 identifiers, modes, cryptographic keys, etc. The SA is referred to 760 by its associated security protocol (for example, "ISAKMP SA", "ESP 761 SA", "TLS SA"). 762 763 ISAKMP SA: An SA used by the ISAKMP servers to protect their own 764 traffic. Sections 2.3 and 2.4 provide more details about ISAKMP SAs. 765 766 Security Parameter Index (SPI): An identifier for a Security 767 Assocation, relative to some security protocol. Each security 768 protocol has its own "SPI-space". A (security protocol, SPI) pair 769 may uniquely identify an SA. The uniqueness of the SPI is 770 implementation dependent, but could be based per system, per 771 protocol, or other options. Depending on the DOI, additional 772 information (e.g. host address) may be necessary to identify an SA. 773 The DOI will also determine which SPIs (i.e. initiator's or 774 responder's) are sent during communication. 775 776 Domain of Interpretation: A Domain of Interpretation (DOI) defines 777 payload formats, exchange types, and conventions for naming 778 security-relevant information such as security policies or 779 cryptographic algorithms and modes. A Domain of Interpretation (DOI) 780 identifier is used to interpret the payloads of ISAKMP payloads. A 781 system SHOULD support multiple Domains of Interpretation 782 simultaneously. The concept of a DOI is based on previous work by 783 784 785 786Maughan, et. al. Standards Track [Page 14] 787 788RFC 2408 ISAKMP November 1998 789 790 791 the TSIG CIPSO Working Group, but extends beyond security label 792 interpretation to include naming and interpretation of security 793 services. A DOI defines: 794 795 o A "situation": the set of information that will be used to 796 determine the required security services. 797 798 o The set of security policies that must, and may, be supported. 799 800 o A syntax for the specification of proposed security services. 801 802 o A scheme for naming security-relevant information, including 803 encryption algorithms, key exchange algorithms, security policy 804 attributes, and certificate authorities. 805 806 o The specific formats of the various payload contents. 807 808 o Additional exchange types, if required. 809 810 The rules for the IETF IP Security DOI are presented in [IPDOI]. 811 Specifications of the rules for customized DOIs will be presented in 812 separate documents. 813 814 Situation: A situation contains all of the security-relevant 815 information that a system considers necessary to decide the security 816 services required to protect the session being negotiated. The 817 situation may include addresses, security classifications, modes of 818 operation (normal vs. emergency), etc. 819 820 Proposal: A proposal is a list, in decreasing order of preference, of 821 the protection suites that a system considers acceptable to protect 822 traffic under a given situation. 823 824 Payload: ISAKMP defines several types of payloads, which are used to 825 transfer information such as security association data, or key 826 exchange data, in DOI-defined formats. A payload consists of a 827 generic payload header and a string of octects that is opaque to 828 ISAKMP. ISAKMP uses DOI- specific functionality to synthesize and 829 interpret these payloads. Multiple payloads can be sent in a single 830 ISAKMP message. See section 3 for more details on the payload types, 831 and [IPDOI] for the formats of the IETF IP Security DOI payloads. 832 833 Exchange Type: An exchange type is a specification of the number of 834 messages in an ISAKMP exchange, and the payload types that are 835 contained in each of those messages. Each exchange type is designed 836 to provide a particular set of security services, such as anonymity 837 of the participants, perfect forward secrecy of the keying material, 838 authentication of the participants, etc. Section 4.1 defines the 839 840 841 842Maughan, et. al. Standards Track [Page 15] 843 844RFC 2408 ISAKMP November 1998 845 846 847 default set of ISAKMP exchange types. Other exchange types can be 848 added to support additional key exchanges, if required. 849 8502.2 ISAKMP Placement 851 852 Figure 1 is a high level view of the placement of ISAKMP within a 853 system context in a network architecture. An important part of 854 negotiating security services is to consider the entire "stack" of 855 individual SAs as a unit. This is referred to as a "protection 856 suite". 857 858 +------------+ +--------+ +--------------+ 859 ! DOI ! ! ! ! Application ! 860 ! Definition ! <----> ! ISAKMP ! ! Process ! 861 +------------+ --> ! ! !--------------! 862 +--------------+ ! +--------+ ! Appl Protocol! 863 ! Key Exchange ! ! ^ ^ +--------------+ 864 ! Definition !<-- ! ! ^ 865 +--------------+ ! ! ! 866 ! ! ! 867 !----------------! ! ! 868 v ! ! 869 +-------+ v v 870 ! API ! +---------------------------------------------+ 871 +-------+ ! Socket Layer ! 872 ! !---------------------------------------------! 873 v ! Transport Protocol (TCP / UDP) ! 874 +----------+ !---------------------------------------------! 875 ! Security ! <----> ! IP ! 876 ! Protocol ! !---------------------------------------------! 877 +----------+ ! Link Layer Protocol ! 878 +---------------------------------------------+ 879 880 881 Figure 1: ISAKMP Relationships 882 8832.3 Negotiation Phases 884 885 ISAKMP offers two "phases" of negotiation. In the first phase, two 886 entities (e.g. ISAKMP servers) agree on how to protect further 887 negotiation traffic between themselves, establishing an ISAKMP SA. 888 This ISAKMP SA is then used to protect the negotiations for the 889 Protocol SA being requested. Two entities (e.g. ISAKMP servers) can 890 negotiate (and have active) multiple ISAKMP SAs. 891 892 893 894 895 896 897 898Maughan, et. al. Standards Track [Page 16] 899 900RFC 2408 ISAKMP November 1998 901 902 903 The second phase of negotiation is used to establish security 904 associations for other security protocols. This second phase can be 905 used to establish many security associations. The security 906 associations established by ISAKMP during this phase can be used by a 907 security protocol to protect many message/data exchanges. 908 909 While the two-phased approach has a higher start-up cost for most 910 simple scenarios, there are several reasons that it is beneficial for 911 most cases. 912 913 First, entities (e.g. ISAKMP servers) can amortize the cost of the 914 first phase across several second phase negotiations. This allows 915 multiple SAs to be established between peers over time without having 916 to start over for each communication. 917 918 Second, security services negotiated during the first phase provide 919 security properties for the second phase. For example, after the 920 first phase of negotiation, the encryption provided by the ISAKMP SA 921 can provide identity protection, potentially allowing the use of 922 simpler second-phase exchanges. On the other hand, if the channel 923 established during the first phase is not adequate to protect 924 identities, then the second phase must negotiate adequate security 925 mechanisms. 926 927 Third, having an ISAKMP SA in place considerably reduces the cost of 928 ISAKMP management activity - without the "trusted path" that an 929 ISAKMP SA gives you, the entities (e.g. ISAKMP servers) would have 930 to go through a complete re-authentication for each error 931 notification or deletion of an SA. 932 933 Negotiation during each phase is accomplished using ISAKMP-defined 934 exchanges (see section 4) or exchanges defined for a key exchange 935 within a DOI. 936 937 Note that security services may be applied differently in each 938 negotiation phase. For example, different parties are being 939 authenticated during each of the phases of negotiation. During the 940 first phase, the parties being authenticated may be the ISAKMP 941 servers/hosts, while during the second phase, users or application 942 level programs are being authenticated. 943 9442.4 Identifying Security Associations 945 946 While bootstrapping secure channels between systems, ISAKMP cannot 947 assume the existence of security services, and must provide some 948 protections for itself. Therefore, ISAKMP considers an ISAKMP 949 Security Association to be different than other types, and manages 950 ISAKMP SAs itself, in their own name space. ISAKMP uses the two 951 952 953 954Maughan, et. al. Standards Track [Page 17] 955 956RFC 2408 ISAKMP November 1998 957 958 959 cookie fields in the ISAKMP header to identify ISAKMP SAs. The 960 Message ID in the ISAKMP Header and the SPI field in the Proposal 961 payload are used during SA establishment to identify the SA for other 962 security protocols. The interpretation of these four fields is 963 dependent on the operation taking place. 964 965 The following table shows the presence or absence of several fields 966 during SA establishment. The following fields are necessary for 967 various operations associated with SA establishment: cookies in the 968 ISAKMP header, the ISAKMP Header Message ID field, and the SPI field 969 in the Proposal payload. An 'X' in the column means the value MUST 970 be present. An 'NA' in the column means a value in the column is Not 971 Applicable to the operation. 972 973 # Operation I-Cookie R-Cookie Message ID SPI 974 (1) Start ISAKMP SA negotiation X 0 0 0 975 (2) Respond ISAKMP SA negotiation X X 0 0 976 (3) Init other SA negotiation X X X X 977 (4) Respond other SA negotiation X X X X 978 (5) Other (KE, ID, etc.) X X X/0 NA 979 (6) Security Protocol (ESP, AH) NA NA NA X 980 981 In the first line (1) of the table, the initiator includes the 982 Initiator Cookie field in the ISAKMP Header, using the procedures 983 outlined in sections 2.5.3 and 3.1. 984 985 In the second line (2) of the table, the responder includes the 986 Initiator and Responder Cookie fields in the ISAKMP Header, using the 987 procedures outlined in sections 2.5.3 and 3.1. Additional messages 988 may be exchanged between ISAKMP peers, depending on the ISAKMP 989 exchange type used during the phase 1 negotiation. Once the phase 1 990 exchange is completed, the Initiator and Responder cookies are 991 included in the ISAKMP Header of all subsequent communications 992 between the ISAKMP peers. 993 994 During phase 1 negotiations, the initiator and responder cookies 995 determine the ISAKMP SA. Therefore, the SPI field in the Proposal 996 payload is redundant and MAY be set to 0 or it MAY contain the 997 transmitting entity's cookie. 998 999 In the third line (3) of the table, the initiator associates a 1000 Message ID with the Protocols contained in the SA Proposal. This 1001 Message ID and the initiator's SPI(s) to be associated with each 1002 protocol in the Proposal are sent to the responder. The SPI(s) will 1003 be used by the security protocols once the phase 2 negotiation is 1004 completed. 1005 1006 1007 1008 1009 1010Maughan, et. al. Standards Track [Page 18] 1011 1012RFC 2408 ISAKMP November 1998 1013 1014 1015 In the fourth line (4) of the table, the responder includes the same 1016 Message ID and the responder's SPI(s) to be associated with each 1017 protocol in the accepted Proposal. This information is returned to 1018 the initiator. 1019 1020 In the fifth line (5) of the table, the initiator and responder use 1021 the Message ID field in the ISAKMP Header to keep track of the in- 1022 progress protocol negotiation. This is only applicable for a phase 2 1023 exchange and the value MUST be 0 for a phase 1 exchange because the 1024 combined cookies identify the ISAKMP SA. The SPI field in the 1025 Proposal payload is not applicable because the Proposal payload is 1026 only used during the SA negotiation message exchange (steps 3 and 4). 1027 1028 In the sixth line (6) of the table, the phase 2 negotiation is 1029 complete. The security protocols use the SPI(s) to determine which 1030 security services and mechanisms to apply to the communication 1031 between them. The SPI value shown in the sixth line (6) is not the 1032 SPI field in the Proposal payload, but the SPI field contained within 1033 the security protocol header. 1034 1035 During the SA establishment, a SPI MUST be generated. ISAKMP is 1036 designed to handle variable sized SPIs. This is accomplished by 1037 using the SPI Size field within the Proposal payload during SA 1038 establishment. Handling of SPIs will be outlined by the DOI 1039 specification (e.g. [IPDOI]). 1040 1041 When a security association (SA) is initially established, one side 1042 assumes the role of initiator and the other the role of responder. 1043 Once the SA is established, both the original initiator and responder 1044 can initiate a phase 2 negotiation with the peer entity. Thus, 1045 ISAKMP SAs are bidirectional in nature. 1046 1047 Additionally, ISAKMP allows both initiator and responder to have some 1048 control during the negotiation process. While ISAKMP is designed to 1049 allow an SA negotiation that includes multiple proposals, the 1050 initiator can maintain some control by only making one proposal in 1051 accordance with the initiator's local security policy. Once the 1052 initiator sends a proposal containing more than one proposal (which 1053 are sent in decreasing preference order), the initiator relinquishes 1054 control to the responder. Once the responder is controlling the SA 1055 establishment, the responder can make its policy take precedence over 1056 the initiator within the context of the multiple options offered by 1057 the initiator. This is accomplished by selecting the proposal best 1058 suited for the responder's local security policy and returning this 1059 selection to the initiator. 1060 1061 1062 1063 1064 1065 1066Maughan, et. al. Standards Track [Page 19] 1067 1068RFC 2408 ISAKMP November 1998 1069 1070 10712.5 Miscellaneous 1072 10732.5.1 Transport Protocol 1074 1075 ISAKMP can be implemented over any transport protocol or over IP 1076 itself. Implementations MUST include send and receive capability for 1077 ISAKMP using the User Datagram Protocol (UDP) on port 500. UDP Port 1078 500 has been assigned to ISAKMP by the Internet Assigned Numbers 1079 Authority (IANA). Implementations MAY additionally support ISAKMP 1080 over other transport protocols or over IP itself. 1081 10822.5.2 RESERVED Fields 1083 1084 The existence of RESERVED fields within ISAKMP payloads are used 1085 strictly to preserve byte alignment. All RESERVED fields in the 1086 ISAKMP protocol MUST be set to zero (0) when a packet is issued. The 1087 receiver SHOULD check the RESERVED fields for a zero (0) value and 1088 discard the packet if other values are found. 1089 10902.5.3 Anti-Clogging Token ("Cookie") Creation 1091 1092 The details of cookie generation are implementation dependent, but 1093 MUST satisfy these basic requirements (originally stated by Phil Karn 1094 in [Karn]): 1095 1096 1. The cookie must depend on the specific parties. This 1097 prevents an attacker from obtaining a cookie using a real IP 1098 address and UDP port, and then using it to swamp the victim 1099 with Diffie-Hellman requests from randomly chosen IP 1100 addresses or ports. 1101 1102 2. It must not be possible for anyone other than the issuing 1103 entity to generate cookies that will be accepted by that 1104 entity. This implies that the issuing entity must use local 1105 secret information in the generation and subsequent 1106 verification of a cookie. It must not be possible to deduce 1107 this secret information from any particular cookie. 1108 1109 3. The cookie generation function must be fast to thwart 1110 attacks intended to sabotage CPU resources. 1111 1112 Karn's suggested method for creating the cookie is to perform a fast 1113 hash (e.g. MD5) over the IP Source and Destination Address, the UDP 1114 Source and Destination Ports and a locally generated secret random 1115 value. ISAKMP requires that the cookie be unique for each SA 1116 establishment to help prevent replay attacks, therefore, the date and 1117 time MUST be added to the information hashed. The generated cookies 1118 are placed in the ISAKMP Header (described in section 3.1) Initiator 1119 1120 1121 1122Maughan, et. al. Standards Track [Page 20] 1123 1124RFC 2408 ISAKMP November 1998 1125 1126 1127 and Responder cookie fields. These fields are 8 octets in length, 1128 thus, requiring a generated cookie to be 8 octets. Notify and Delete 1129 messages (see sections 3.14, 3.15, and 4.8) are uni-directional 1130 transmissions and are done under the protection of an existing ISAKMP 1131 SA, thus, not requiring the generation of a new cookie. One 1132 exception to this is the transmission of a Notify message during a 1133 Phase 1 exchange, prior to completing the establishment of an SA. 1134 Sections 3.14 and 4.8 provide additional details. 1135 11363 ISAKMP Payloads 1137 1138 ISAKMP payloads provide modular building blocks for constructing 1139 ISAKMP messages. The presence and ordering of payloads in ISAKMP is 1140 defined by and dependent upon the Exchange Type Field located in the 1141 ISAKMP Header (see Figure 2). The ISAKMP payload types are discussed 1142 in sections 3.4 through 3.15. The descriptions of the ISAKMP 1143 payloads, messages, and exchanges (see Section 4) are shown using 1144 network octet ordering. 1145 11463.1 ISAKMP Header Format 1147 1148 An ISAKMP message has a fixed header format, shown in Figure 2, 1149 followed by a variable number of payloads. A fixed header simplifies 1150 parsing, providing the benefit of protocol parsing software that is 1151 less complex and easier to implement. The fixed header contains the 1152 information required by the protocol to maintain state, process 1153 payloads and possibly prevent denial of service or replay attacks. 1154 1155 The ISAKMP Header fields are defined as follows: 1156 1157 o Initiator Cookie (8 octets) - Cookie of entity that initiated SA 1158 establishment, SA notification, or SA deletion. 1159 1160 o Responder Cookie (8 octets) - Cookie of entity that is responding 1161 to an SA establishment request, SA notification, or SA deletion. 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178Maughan, et. al. Standards Track [Page 21] 1179 1180RFC 2408 ISAKMP November 1998 1181 1182 1183 1 2 3 1184 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 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 ! Initiator ! 1187 ! Cookie ! 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 ! Responder ! 1190 ! Cookie ! 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 ! Message ID ! 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 ! Length ! 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 1199 1200 Figure 2: ISAKMP Header Format 1201 1202 o Next Payload (1 octet) - Indicates the type of the first payload 1203 in the message. The format for each payload is defined in 1204 sections 3.4 through 3.16. The processing for the payloads is 1205 defined in section 5. 1206 1207 1208 Next Payload Type Value 1209 NONE 0 1210 Security Association (SA) 1 1211 Proposal (P) 2 1212 Transform (T) 3 1213 Key Exchange (KE) 4 1214 Identification (ID) 5 1215 Certificate (CERT) 6 1216 Certificate Request (CR) 7 1217 Hash (HASH) 8 1218 Signature (SIG) 9 1219 Nonce (NONCE) 10 1220 Notification (N) 11 1221 Delete (D) 12 1222 Vendor ID (VID) 13 1223 RESERVED 14 - 127 1224 Private USE 128 - 255 1225 1226 o Major Version (4 bits) - indicates the major version of the ISAKMP 1227 protocol in use. Implementations based on this version of the 1228 ISAKMP Internet-Draft MUST set the Major Version to 1. 1229 Implementations based on previous versions of ISAKMP Internet- 1230 Drafts MUST set the Major Version to 0. Implementations SHOULD 1231 1232 1233 1234Maughan, et. al. Standards Track [Page 22] 1235 1236RFC 2408 ISAKMP November 1998 1237 1238 1239 never accept packets with a major version number larger than its 1240 own. 1241 1242 o Minor Version (4 bits) - indicates the minor version of the 1243 ISAKMP protocol in use. Implementations based on this version of 1244 the ISAKMP Internet-Draft MUST set the Minor Version to 0. 1245 Implementations based on previous versions of ISAKMP Internet- 1246 Drafts MUST set the Minor Version to 1. Implementations SHOULD 1247 never accept packets with a minor version number larger than its 1248 own, given the major version numbers are identical. 1249 1250 o Exchange Type (1 octet) - indicates the type of exchange being 1251 used. This dictates the message and payload orderings in the 1252 ISAKMP exchanges. 1253 1254 1255 Exchange Type Value 1256 NONE 0 1257 Base 1 1258 Identity Protection 2 1259 Authentication Only 3 1260 Aggressive 4 1261 Informational 5 1262 ISAKMP Future Use 6 - 31 1263 DOI Specific Use 32 - 239 1264 Private Use 240 - 255 1265 1266 o Flags (1 octet) - indicates specific options that are set for the 1267 ISAKMP exchange. The flags listed below are specified in the 1268 Flags field beginning with the least significant bit, i.e the 1269 Encryption bit is bit 0 of the Flags field, the Commit bit is bit 1270 1 of the Flags field, and the Authentication Only bit is bit 2 of 1271 the Flags field. The remaining bits of the Flags field MUST be 1272 set to 0 prior to transmission. 1273 1274 -- E(ncryption Bit) (1 bit) - If set (1), all payloads following 1275 the header are encrypted using the encryption algorithm 1276 identified in the ISAKMP SA. The ISAKMP SA Identifier is the 1277 combination of the initiator and responder cookie. It is 1278 RECOMMENDED that encryption of communications be done as soon 1279 as possible between the peers. For all ISAKMP exchanges 1280 described in section 4.1, the encryption SHOULD begin after 1281 both parties have exchanged Key Exchange payloads. If the 1282 E(ncryption Bit) is not set (0), the payloads are not 1283 encrypted. 1284 1285 1286 1287 1288 1289 1290Maughan, et. al. Standards Track [Page 23] 1291 1292RFC 2408 ISAKMP November 1998 1293 1294 1295 -- C(ommit Bit) (1 bit) - This bit is used to signal key exchange 1296 synchronization. It is used to ensure that encrypted material 1297 is not received prior to completion of the SA establishment. 1298 The Commit Bit can be set (at anytime) by either party 1299 participating in the SA establishment, and can be used during 1300 both phases of an ISAKMP SA establishment. However, the value 1301 MUST be reset after the Phase 1 negotiation. If set(1), the 1302 entity which did not set the Commit Bit MUST wait for an 1303 Informational Exchange containing a Notify payload (with the 1304 CONNECTED Notify Message) from the entity which set the Commit 1305 Bit. In this instance, the Message ID field of the 1306 Informational Exchange MUST contain the Message ID of the 1307 original ISAKMP Phase 2 SA negotiation. This is done to 1308 ensure that the Informational Exchange with the CONNECTED 1309 Notify Message can be associated with the correct Phase 2 SA. 1310 The receipt and processing of the Informational Exchange 1311 indicates that the SA establishment was successful and either 1312 entity can now proceed with encrypted traffic communication. 1313 In addition to synchronizing key exchange, the Commit Bit can 1314 be used to protect against loss of transmissions over 1315 unreliable networks and guard against the need for multiple 1316 re-transmissions. 1317 1318 NOTE: It is always possible that the final message of an 1319 exchange can be lost. In this case, the entity expecting to 1320 receive the final message of an exchange would receive the 1321 Phase 2 SA negotiation message following a Phase 1 exchange or 1322 encrypted traffic following a Phase 2 exchange. Handling of 1323 this situation is not standardized, but we propose the 1324 following possibilities. If the entity awaiting the 1325 Informational Exchange can verify the received message (i.e. 1326 Phase 2 SA negotiation message or encrypted traffic), then 1327 they MAY consider the SA was established and continue 1328 processing. The other option is to retransmit the last ISAKMP 1329 message to force the other entity to retransmit the final 1330 message. This suggests that implementations may consider 1331 retaining the last message (locally) until they are sure the 1332 SA is established. 1333 1334 -- A(uthentication Only Bit) (1 bit) - This bit is intended for 1335 use with the Informational Exchange with a Notify payload and 1336 will allow the transmission of information with integrity 1337 checking, but no encryption (e.g. "emergency mode"). Section 1338 4.8 states that a Phase 2 Informational Exchange MUST be sent 1339 under the protection of an ISAKMP SA. This is the only 1340 exception to that policy. If the Authentication Only bit is 1341 set (1), only authentication security services will be applied 1342 to the entire Notify payload of the Informational Exchange and 1343 1344 1345 1346Maughan, et. al. Standards Track [Page 24] 1347 1348RFC 2408 ISAKMP November 1998 1349 1350 1351 the payload will not be encrypted. 1352 1353 o Message ID (4 octets) - Unique Message Identifier used to 1354 identify protocol state during Phase 2 negotiations. This value 1355 is randomly generated by the initiator of the Phase 2 1356 negotiation. In the event of simultaneous SA establishments 1357 (i.e. collisions), the value of this field will likely be 1358 different because they are independently generated and, thus, two 1359 security associations will progress toward establishment. 1360 However, it is unlikely there will be absolute simultaneous 1361 establishments. During Phase 1 negotiations, the value MUST be 1362 set to 0. 1363 1364 o Length (4 octets) - Length of total message (header + payloads) 1365 in octets. Encryption can expand the size of an ISAKMP message. 1366 13673.2 Generic Payload Header 1368 1369 Each ISAKMP payload defined in sections 3.4 through 3.16 begins with 1370 a generic header, shown in Figure 3, which provides a payload 1371 "chaining" capability and clearly defines the boundaries of a 1372 payload. 1373 1374 1 2 3 1375 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 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 ! Next Payload ! RESERVED ! Payload Length ! 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 1380 Figure 3: Generic Payload Header 1381 1382 The Generic Payload Header fields are defined as follows: 1383 1384 o Next Payload (1 octet) - Identifier for the payload type of the 1385 next payload in the message. If the current payload is the last 1386 in the message, then this field will be 0. This field provides 1387 the "chaining" capability. 1388 1389 o RESERVED (1 octet) - Unused, set to 0. 1390 1391 o Payload Length (2 octets) - Length in octets of the current 1392 payload, including the generic payload header. 1393 13943.3 Data Attributes 1395 1396 There are several instances within ISAKMP where it is necessary to 1397 represent Data Attributes. An example of this is the Security 1398 Association (SA) Attributes contained in the Transform payload 1399 1400 1401 1402Maughan, et. al. Standards Track [Page 25] 1403 1404RFC 2408 ISAKMP November 1998 1405 1406 1407 (described in section 3.6). These Data Attributes are not an ISAKMP 1408 payload, but are contained within ISAKMP payloads. The format of the 1409 Data Attributes provides the flexibility for representation of many 1410 different types of information. There can be multiple Data 1411 Attributes within a payload. The length of the Data Attributes will 1412 either be 4 octets or defined by the Attribute Length field. This is 1413 done using the Attribute Format bit described below. Specific 1414 information about the attributes for each domain will be described in 1415 a DOI document, e.g. IPSEC DOI [IPDOI]. 1416 1417 1 2 3 1418 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 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 !A! Attribute Type ! AF=0 Attribute Length ! 1421 !F! ! AF=1 Attribute Value ! 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 . AF=0 Attribute Value . 1424 . AF=1 Not Transmitted . 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 1427 1428 Figure 4: Data Attributes 1429 1430 The Data Attributes fields are defined as follows: 1431 1432 o Attribute Type (2 octets) - Unique identifier for each type of 1433 attribute. These attributes are defined as part of the DOI- 1434 specific information. 1435 1436 The most significant bit, or Attribute Format (AF), indicates 1437 whether the data attributes follow the Type/Length/Value (TLV) 1438 format or a shortened Type/Value (TV) format. If the AF bit is a 1439 zero (0), then the Data Attributes are of the Type/Length/Value 1440 (TLV) form. If the AF bit is a one (1), then the Data Attributes 1441 are of the Type/Value form. 1442 1443 o Attribute Length (2 octets) - Length in octets of the Attribute 1444 Value. When the AF bit is a one (1), the Attribute Value is only 1445 2 octets and the Attribute Length field is not present. 1446 1447 o Attribute Value (variable length) - Value of the attribute 1448 associated with the DOI-specific Attribute Type. If the AF bit 1449 is a zero (0), this field has a variable length defined by the 1450 Attribute Length field. If the AF bit is a one (1), the 1451 Attribute Value has a length of 2 octets. 1452 1453 1454 1455 1456 1457 1458Maughan, et. al. Standards Track [Page 26] 1459 1460RFC 2408 ISAKMP November 1998 1461 1462 14633.4 Security Association Payload 1464 1465 The Security Association Payload is used to negotiate security 1466 attributes and to indicate the Domain of Interpretation (DOI) and 1467 Situation under which the negotiation is taking place. Figure 5 1468 shows the format of the Security Association payload. 1469 1470 1 2 3 1471 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 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 ! Next Payload ! RESERVED ! Payload Length ! 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 ! Domain of Interpretation (DOI) ! 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 ! ! 1478 ~ Situation ~ 1479 ! ! 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 1482 1483 Figure 5: Security Association Payload 1484 1485 o Next Payload (1 octet) - Identifier for the payload type of the 1486 next payload in the message. If the current payload is the last 1487 in the message, then this field will be 0. This field MUST NOT 1488 contain the values for the Proposal or Transform payloads as they 1489 are considered part of the security association negotiation. For 1490 example, this field would contain the value "10" (Nonce payload) 1491 in the first message of a Base Exchange (see Section 4.4) and the 1492 value "0" in the first message of an Identity Protect Exchange 1493 (see Section 4.5). 1494 1495 o RESERVED (1 octet) - Unused, set to 0. 1496 1497 o Payload Length (2 octets) - Length in octets of the entire 1498 Security Association payload, including the SA payload, all 1499 Proposal payloads, and all Transform payloads associated with the 1500 proposed Security Association. 1501 1502 o Domain of Interpretation (4 octets) - Identifies the DOI (as 1503 described in Section 2.1) under which this negotiation is taking 1504 place. The DOI is a 32-bit unsigned integer. A DOI value of 0 1505 during a Phase 1 exchange specifies a Generic ISAKMP SA which can 1506 be used for any protocol during the Phase 2 exchange. The 1507 necessary SA Attributes are defined in A.4. A DOI value of 1 is 1508 assigned to the IPsec DOI [IPDOI]. All other DOI values are 1509 reserved to IANA for future use. IANA will not normally assign a 1510 DOI value without referencing some public specification, such as 1511 1512 1513 1514Maughan, et. al. Standards Track [Page 27] 1515 1516RFC 2408 ISAKMP November 1998 1517 1518 1519 an Internet RFC. Other DOI's can be defined using the description 1520 in appendix B. This field MUST be present within the Security 1521 Association payload. 1522 1523 o Situation (variable length) - A DOI-specific field that 1524 identifies the situation under which this negotiation is taking 1525 place. The Situation is used to make policy decisions regarding 1526 the security attributes being negotiated. Specifics for the IETF 1527 IP Security DOI Situation are detailed in [IPDOI]. This field 1528 MUST be present within the Security Association payload. 1529 15303.5 Proposal Payload 1531 1532 The Proposal Payload contains information used during Security 1533 Association negotiation. The proposal consists of security 1534 mechanisms, or transforms, to be used to secure the communications 1535 channel. Figure 6 shows the format of the Proposal Payload. A 1536 description of its use can be found in section 4.2. 1537 1538 1 2 3 1539 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 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 ! Next Payload ! RESERVED ! Payload Length ! 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms! 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 ! SPI (variable) ! 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 1548 1549 Figure 6: Proposal Payload Format 1550 1551 The Proposal Payload fields are defined as follows: 1552 1553 o Next Payload (1 octet) - Identifier for the payload type of the 1554 next payload in the message. This field MUST only contain the 1555 value "2" or "0". If there are additional Proposal payloads in 1556 the message, then this field will be 2. If the current Proposal 1557 payload is the last within the security association proposal, 1558 then this field will be 0. 1559 1560 o RESERVED (1 octet) - Unused, set to 0. 1561 1562 o Payload Length (2 octets) - Length in octets of the entire 1563 Proposal payload, including generic payload header, the Proposal 1564 payload, and all Transform payloads associated with this 1565 proposal. In the event there are multiple proposals with the 1566 same proposal number (see section 4.2), the Payload Length field 1567 1568 1569 1570Maughan, et. al. Standards Track [Page 28] 1571 1572RFC 2408 ISAKMP November 1998 1573 1574 1575 only applies to the current Proposal payload and not to all 1576 Proposal payloads. 1577 1578 o Proposal # (1 octet) - Identifies the Proposal number for the 1579 current payload. A description of the use of this field is found 1580 in section 4.2. 1581 1582 o Protocol-Id (1 octet) - Specifies the protocol identifier for the 1583 current negotiation. Examples might include IPSEC ESP, IPSEC AH, 1584 OSPF, TLS, etc. 1585 1586 o SPI Size (1 octet) - Length in octets of the SPI as defined by 1587 the Protocol-Id. In the case of ISAKMP, the Initiator and 1588 Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, 1589 therefore, the SPI Size is irrelevant and MAY be from zero (0) to 1590 sixteen (16). If the SPI Size is non-zero, the content of the 1591 SPI field MUST be ignored. If the SPI Size is not a multiple of 1592 4 octets it will have some impact on the SPI field and the 1593 alignment of all payloads in the message. The Domain of 1594 Interpretation (DOI) will dictate the SPI Size for other 1595 protocols. 1596 1597 o # of Transforms (1 octet) - Specifies the number of transforms 1598 for the Proposal. Each of these is contained in a Transform 1599 payload. 1600 1601 o SPI (variable) - The sending entity's SPI. In the event the SPI 1602 Size is not a multiple of 4 octets, there is no padding applied 1603 to the payload, however, it can be applied at the end of the 1604 message. 1605 1606 The payload type for the Proposal Payload is two (2). 1607 16083.6 Transform Payload 1609 1610 The Transform Payload contains information used during Security 1611 Association negotiation. The Transform payload consists of a 1612 specific security mechanism, or transforms, to be used to secure the 1613 communications channel. The Transform payload also contains the 1614 security association attributes associated with the specific 1615 transform. These SA attributes are DOI-specific. Figure 7 shows the 1616 format of the Transform Payload. A description of its use can be 1617 found in section 4.2. 1618 1619 1620 1621 1622 1623 1624 1625 1626Maughan, et. al. Standards Track [Page 29] 1627 1628RFC 2408 ISAKMP November 1998 1629 1630 1631 1 2 3 1632 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 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 ! Next Payload ! RESERVED ! Payload Length ! 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 ! Transform # ! Transform-Id ! RESERVED2 ! 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 ! ! 1639 ~ SA Attributes ~ 1640 ! ! 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 1643 1644 Figure 7: Transform Payload Format 1645 1646 The Transform Payload fields are defined as follows: 1647 1648 o Next Payload (1 octet) - Identifier for the payload type of the 1649 next payload in the message. This field MUST only contain the 1650 value "3" or "0". If there are additional Transform payloads in 1651 the proposal, then this field will be 3. If the current 1652 Transform payload is the last within the proposal, then this 1653 field will be 0. 1654 1655 o RESERVED (1 octet) - Unused, set to 0. 1656 1657 o Payload Length (2 octets) - Length in octets of the current 1658 payload, including the generic payload header, Transform values, 1659 and all SA Attributes. 1660 1661 o Transform # (1 octet) - Identifies the Transform number for the 1662 current payload. If there is more than one transform proposed 1663 for a specific protocol within the Proposal payload, then each 1664 Transform payload has a unique Transform number. A description 1665 of the use of this field is found in section 4.2. 1666 1667 o Transform-Id (1 octet) - Specifies the Transform identifier for 1668 the protocol within the current proposal. These transforms are 1669 defined by the DOI and are dependent on the protocol being 1670 negotiated. 1671 1672 o RESERVED2 (2 octets) - Unused, set to 0. 1673 1674 o SA Attributes (variable length) - This field contains the 1675 security association attributes as defined for the transform 1676 given in the Transform-Id field. The SA Attributes SHOULD be 1677 represented using the Data Attributes format described in section 1678 3.3. If the SA Attributes are not aligned on 4-byte boundaries, 1679 1680 1681 1682Maughan, et. al. Standards Track [Page 30] 1683 1684RFC 2408 ISAKMP November 1998 1685 1686 1687 then subsequent payloads will not be aligned and any padding will 1688 be added at the end of the message to make the message 4-octet 1689 aligned. 1690 1691 The payload type for the Transform Payload is three (3). 1692 16933.7 Key Exchange Payload 1694 1695 The Key Exchange Payload supports a variety of key exchange 1696 techniques. Example key exchanges are Oakley [Oakley], Diffie- 1697 Hellman, the enhanced Diffie-Hellman key exchange described in X9.42 1698 [ANSI], and the RSA-based key exchange used by PGP. Figure 8 shows 1699 the format of the Key Exchange payload. 1700 1701 The Key Exchange Payload fields are defined as follows: 1702 1703 o Next Payload (1 octet) - Identifier for the payload type of the 1704 nextpayload in the message. If the current payload is the last 1705 in the message, then this field will be 0. 1706 1707 1 2 3 1708 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 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 ! Next Payload ! RESERVED ! Payload Length ! 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 ! ! 1713 ~ Key Exchange Data ~ 1714 ! ! 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 1717 1718 Figure 8: Key Exchange Payload Format 1719 1720 o RESERVED (1 octet) - Unused, set to 0. 1721 1722 o Payload Length (2 octets) - Length in octets of the current 1723 payload, including the generic payload header. 1724 1725 o Key Exchange Data (variable length) - Data required to generate a 1726 session key. The interpretation of this data is specified by the 1727 DOI and the associated Key Exchange algorithm. This field may 1728 also contain pre-placed key indicators. 1729 1730 The payload type for the Key Exchange Payload is four (4). 1731 1732 1733 1734 1735 1736 1737 1738Maughan, et. al. Standards Track [Page 31] 1739 1740RFC 2408 ISAKMP November 1998 1741 1742 17433.8 Identification Payload 1744 1745 The Identification Payload contains DOI-specific data used to 1746 exchange identification information. This information is used for 1747 determining the identities of communicating peers and may be used for 1748 determining authenticity of information. Figure 9 shows the format 1749 of the Identification Payload. 1750 1751 The Identification Payload fields are defined as follows: 1752 1753 o Next Payload (1 octet) - Identifier for the payload type of the 1754 next payload in the message. If the current payload is the last 1755 in the message, then this field will be 0. 1756 1757 o RESERVED (1 octet) - Unused, set to 0. 1758 1759 o Payload Length (2 octets) - Length in octets of the current 1760 payload, including the generic payload header. 1761 1762 o ID Type (1 octet) - Specifies the type of Identification being 1763 used. 1764 1765 1 2 3 1766 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 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 ! Next Payload ! RESERVED ! Payload Length ! 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 ! ID Type ! DOI Specific ID Data ! 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 ! ! 1773 ~ Identification Data ~ 1774 ! ! 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 1777 1778 Figure 9: Identification Payload Format 1779 1780 This field is DOI-dependent. 1781 1782 o DOI Specific ID Data (3 octets) - Contains DOI specific 1783 Identification data. If unused, then this field MUST be set to 1784 0. 1785 1786 o Identification Data (variable length) - Contains identity 1787 information. The values for this field are DOI-specific and the 1788 format is specified by the ID Type field. Specific details for 1789 the IETF IP Security DOI Identification Data are detailed in 1790 [IPDOI]. 1791 1792 1793 1794Maughan, et. al. Standards Track [Page 32] 1795 1796RFC 2408 ISAKMP November 1998 1797 1798 1799 The payload type for the Identification Payload is five (5). 1800 18013.9 Certificate Payload 1802 1803 The Certificate Payload provides a means to transport certificates or 1804 other certificate-related information via ISAKMP and can appear in 1805 any ISAKMP message. Certificate payloads SHOULD be included in an 1806 exchange whenever an appropriate directory service (e.g. Secure DNS 1807 [DNSSEC]) is not available to distribute certificates. The 1808 Certificate payload MUST be accepted at any point during an exchange. 1809 Figure 10 shows the format of the Certificate Payload. 1810 1811 NOTE: Certificate types and formats are not generally bound to a DOI 1812 - it is expected that there will only be a few certificate types, and 1813 that most DOIs will accept all of these types. 1814 1815 The Certificate Payload fields are defined as follows: 1816 1817 o Next Payload (1 octet) - Identifier for the payload type of the 1818 next payload in the message. If the current payload is the last 1819 in the message, then this field will be 0. 1820 1821 1 2 3 1822 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 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 ! Next Payload ! RESERVED ! Payload Length ! 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 ! Cert Encoding ! ! 1827 +-+-+-+-+-+-+-+-+ ! 1828 ~ Certificate Data ~ 1829 ! ! 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 1832 1833 Figure 10: Certificate Payload Format 1834 1835 o RESERVED (1 octet) - Unused, set to 0. 1836 1837 o Payload Length (2 octets) - Length in octets of the current 1838 payload, including the generic payload header. 1839 1840 o Certificate Encoding (1 octet) - This field indicates the type of 1841 certificate or certificate-related information contained in the 1842 Certificate Data field. 1843 1844 1845 1846 1847 1848 1849 1850Maughan, et. al. Standards Track [Page 33] 1851 1852RFC 2408 ISAKMP November 1998 1853 1854 1855 Certificate Type Value 1856 NONE 0 1857 PKCS #7 wrapped X.509 certificate 1 1858 PGP Certificate 2 1859 DNS Signed Key 3 1860 X.509 Certificate - Signature 4 1861 X.509 Certificate - Key Exchange 5 1862 Kerberos Tokens 6 1863 Certificate Revocation List (CRL) 7 1864 Authority Revocation List (ARL) 8 1865 SPKI Certificate 9 1866 X.509 Certificate - Attribute 10 1867 RESERVED 11 - 255 1868 1869 o Certificate Data (variable length) - Actual encoding of 1870 certificate data. The type of certificate is indicated by the 1871 Certificate Encoding field. 1872 1873 The payload type for the Certificate Payload is six (6). 1874 18753.10 Certificate Request Payload 1876 1877 The Certificate Request Payload provides a means to request 1878 certificates via ISAKMP and can appear in any message. Certificate 1879 Request payloads SHOULD be included in an exchange whenever an 1880 appropriate directory service (e.g. Secure DNS [DNSSEC]) is not 1881 available to distribute certificates. The Certificate Request 1882 payload MUST be accepted at any point during the exchange. The 1883 responder to the Certificate Request payload MUST send its 1884 certificate, if certificates are supported, based on the values 1885 contained in the payload. If multiple certificates are required, 1886 then multiple Certificate Request payloads SHOULD be transmitted. 1887 Figure 11 shows the format of the Certificate Request Payload. 1888 1889 1 2 3 1890 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 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 ! Next Payload ! RESERVED ! Payload Length ! 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 ! Cert. Type ! ! 1895 +-+-+-+-+-+-+-+-+ ! 1896 ~ Certificate Authority ~ 1897 ! ! 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 1900 1901 Figure 11: Certificate Request Payload Format 1902 1903 1904 1905 1906Maughan, et. al. Standards Track [Page 34] 1907 1908RFC 2408 ISAKMP November 1998 1909 1910 1911 The Certificate Payload fields are defined as follows: 1912 1913 o Next Payload (1 octet) - Identifier for the payload type of the 1914 next payload in the message. If the current payload is the last 1915 in the message, then this field will be 0. 1916 1917 o RESERVED (1 octet) - Unused, set to 0. 1918 1919 o Payload Length (2 octets) - Length in octets of the current 1920 payload, including the generic payload header. 1921 1922 o Certificate Type (1 octet) - Contains an encoding of the type of 1923 certificate requested. Acceptable values are listed in section 1924 3.9. 1925 1926 o Certificate Authority (variable length) - Contains an encoding of 1927 an acceptable certificate authority for the type of certificate 1928 requested. As an example, for an X.509 certificate this field 1929 would contain the Distinguished Name encoding of the Issuer Name 1930 of an X.509 certificate authority acceptable to the sender of 1931 this payload. This would be included to assist the responder in 1932 determining how much of the certificate chain would need to be 1933 sent in response to this request. If there is no specific 1934 certificate authority requested, this field SHOULD not be 1935 included. 1936 1937 The payload type for the Certificate Request Payload is seven (7). 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962Maughan, et. al. Standards Track [Page 35] 1963 1964RFC 2408 ISAKMP November 1998 1965 1966 19673.11 Hash Payload 1968 1969 The Hash Payload contains data generated by the hash function 1970 (selected during the SA establishment exchange), over some part of 1971 the message and/or ISAKMP state. This payload may be used to verify 1972 the integrity of the data in an ISAKMP message or for authentication 1973 of the negotiating entities. Figure 12 shows the format of the Hash 1974 Payload. 1975 1976 1 2 3 1977 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 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 ! Next Payload ! RESERVED ! Payload Length ! 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 ! ! 1982 ~ Hash Data ~ 1983 ! ! 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 1986 1987 Figure 12: Hash Payload Format 1988 1989 The Hash Payload fields are defined as follows: 1990 1991 o Next Payload (1 octet) - Identifier for the payload type of the 1992 next payload in the message. If the current payload is the last 1993 in the message, then this field will be 0. 1994 1995 o RESERVED (1 octet) - Unused, set to 0. 1996 1997 o Payload Length (2 octets) - Length in octets of the current 1998 payload, including the generic payload header. 1999 2000 o Hash Data (variable length) - Data that results from applying the 2001 hash routine to the ISAKMP message and/or state. 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018Maughan, et. al. Standards Track [Page 36] 2019 2020RFC 2408 ISAKMP November 1998 2021 2022 20233.12 Signature Payload 2024 2025 The Signature Payload contains data generated by the digital 2026 signature function (selected during the SA establishment exchange), 2027 over some part of the message and/or ISAKMP state. This payload is 2028 used to verify the integrity of the data in the ISAKMP message, and 2029 may be of use for non-repudiation services. Figure 13 shows the 2030 format of the Signature Payload. 2031 2032 1 2 3 2033 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 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 ! Next Payload ! RESERVED ! Payload Length ! 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 ! ! 2038 ~ Signature Data ~ 2039 ! ! 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 2042 2043 Figure 13: Signature Payload Format 2044 2045 The Signature Payload fields are defined as follows: 2046 2047 o Next Payload (1 octet) - Identifier for the payload type of the 2048 next payload in the message. If the current payload is the last 2049 in the message, then this field will be 0. 2050 2051 o RESERVED (1 octet) - Unused, set to 0. 2052 2053 o Payload Length (2 octets) - Length in octets of the current 2054 payload, including the generic payload header. 2055 2056 o Signature Data (variable length) - Data that results from 2057 applying the digital signature function to the ISAKMP message 2058 and/or state. 2059 2060 The payload type for the Signature Payload is nine (9). 2061 20623.13 Nonce Payload 2063 2064 The Nonce Payload contains random data used to guarantee liveness 2065 during an exchange and protect against replay attacks. Figure 14 2066 shows the format of the Nonce Payload. If nonces are used by a 2067 particular key exchange, the use of the Nonce payload will be 2068 dictated by the key exchange. The nonces may be transmitted as part 2069 of the key exchange data, or as a separate payload. However, this is 2070 defined by the key exchange, not by ISAKMP. 2071 2072 2073 2074Maughan, et. al. Standards Track [Page 37] 2075 2076RFC 2408 ISAKMP November 1998 2077 2078 2079 1 2 3 2080 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 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 ! Next Payload ! RESERVED ! Payload Length ! 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 ! ! 2085 ~ Nonce Data ~ 2086 ! ! 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2088 2089 2090 Figure 14: Nonce Payload Format 2091 2092 The Nonce Payload fields are defined as follows: 2093 2094 o Next Payload (1 octet) - Identifier for the payload type of the 2095 next payload in the message. If the current payload is the last 2096 in the message, then this field will be 0. 2097 2098 o RESERVED (1 octet) - Unused, set to 0. 2099 2100 o Payload Length (2 octets) - Length in octets of the current 2101 payload, including the generic payload header. 2102 2103 o Nonce Data (variable length) - Contains the random data generated 2104 by the transmitting entity. 2105 2106 The payload type for the Nonce Payload is ten (10). 2107 21083.14 Notification Payload 2109 2110 The Notification Payload can contain both ISAKMP and DOI-specific 2111 data and is used to transmit informational data, such as error 2112 conditions, to an ISAKMP peer. It is possible to send multiple 2113 Notification payloads in a single ISAKMP message. Figure 15 shows 2114 the format of the Notification Payload. 2115 2116 Notification which occurs during, or is concerned with, a Phase 1 2117 negotiation is identified by the Initiator and Responder cookie pair 2118 in the ISAKMP Header. The Protocol Identifier, in this case, is 2119 ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP 2120 Header identifies the ISAKMP SA. If the notification takes place 2121 prior to the completed exchange of keying information, then the 2122 notification will be unprotected. 2123 2124 2125 2126 2127 2128 2129 2130Maughan, et. al. Standards Track [Page 38] 2131 2132RFC 2408 ISAKMP November 1998 2133 2134 2135 Notification which occurs during, or is concerned with, a Phase 2 2136 negotiation is identified by the Initiator and Responder cookie pair 2137 in the ISAKMP Header and the Message ID and SPI associated with the 2138 current negotiation. One example for this type of notification is to 2139 indicate why a proposal was rejected. 2140 2141 1 2 3 2142 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 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 ! Next Payload ! RESERVED ! Payload Length ! 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 ! Domain of Interpretation (DOI) ! 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 ! Protocol-ID ! SPI Size ! Notify Message Type ! 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 ! ! 2151 ~ Security Parameter Index (SPI) ~ 2152 ! ! 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 ! ! 2155 ~ Notification Data ~ 2156 ! ! 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 2159 2160 Figure 15: Notification Payload Format 2161 2162 The Notification Payload fields are defined as follows: 2163 2164 o Next Payload (1 octet) - Identifier for the payload type of the 2165 next payload in the message. If the current payload is the last 2166 in the message, then this field will be 0. 2167 2168 o RESERVED (1 octet) - Unused, set to 0. 2169 2170 o Payload Length (2 octets) - Length in octets of the current 2171 payload, including the generic payload header. 2172 2173 o Domain of Interpretation (4 octets) - Identifies the DOI (as 2174 described in Section 2.1) under which this notification is taking 2175 place. For ISAKMP this value is zero (0) and for the IPSEC DOI 2176 it is one (1). Other DOI's can be defined using the description 2177 in appendix B. 2178 2179 o Protocol-Id (1 octet) - Specifies the protocol identifier for the 2180 current notification. Examples might include ISAKMP, IPSEC ESP, 2181 IPSEC AH, OSPF, TLS, etc. 2182 2183 2184 2185 2186Maughan, et. al. Standards Track [Page 39] 2187 2188RFC 2408 ISAKMP November 1998 2189 2190 2191 o SPI Size (1 octet) - Length in octets of the SPI as defined by 2192 the Protocol-Id. In the case of ISAKMP, the Initiator and 2193 Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, 2194 therefore, the SPI Size is irrelevant and MAY be from zero (0) to 2195 sixteen (16). If the SPI Size is non-zero, the content of the 2196 SPI field MUST be ignored. The Domain of Interpretation (DOI) 2197 will dictate the SPI Size for other protocols. 2198 2199 o Notify Message Type (2 octets) - Specifies the type of 2200 notification message (see section 3.14.1). Additional text, if 2201 specified by the DOI, is placed in the Notification Data field. 2202 2203 o SPI (variable length) - Security Parameter Index. The receiving 2204 entity's SPI. The use of the SPI field is described in section 2205 2.4. The length of this field is determined by the SPI Size 2206 field and is not necessarily aligned to a 4 octet boundary. 2207 2208 o Notification Data (variable length) - Informational or error data 2209 transmitted in addition to the Notify Message Type. Values for 2210 this field are DOI-specific. 2211 2212 The payload type for the Notification Payload is eleven (11). 2213 22143.14.1 Notify Message Types 2215 2216 Notification information can be error messages specifying why an SA 2217 could not be established. It can also be status data that a process 2218 managing an SA database wishes to communicate with a peer process. 2219 For example, a secure front end or security gateway may use the 2220 Notify message to synchronize SA communication. The table below 2221 lists the Nofitication messages and their corresponding values. 2222 Values in the Private Use range are expected to be DOI-specific 2223 values. 2224 2225 NOTIFY MESSAGES - ERROR TYPES 2226 2227 Errors Value 2228 INVALID-PAYLOAD-TYPE 1 2229 DOI-NOT-SUPPORTED 2 2230 SITUATION-NOT-SUPPORTED 3 2231 INVALID-COOKIE 4 2232 INVALID-MAJOR-VERSION 5 2233 INVALID-MINOR-VERSION 6 2234 INVALID-EXCHANGE-TYPE 7 2235 INVALID-FLAGS 8 2236 INVALID-MESSAGE-ID 9 2237 INVALID-PROTOCOL-ID 10 2238 INVALID-SPI 11 2239 2240 2241 2242Maughan, et. al. Standards Track [Page 40] 2243 2244RFC 2408 ISAKMP November 1998 2245 2246 2247 INVALID-TRANSFORM-ID 12 2248 ATTRIBUTES-NOT-SUPPORTED 13 2249 NO-PROPOSAL-CHOSEN 14 2250 BAD-PROPOSAL-SYNTAX 15 2251 PAYLOAD-MALFORMED 16 2252 INVALID-KEY-INFORMATION 17 2253 INVALID-ID-INFORMATION 18 2254 INVALID-CERT-ENCODING 19 2255 INVALID-CERTIFICATE 20 2256 CERT-TYPE-UNSUPPORTED 21 2257 INVALID-CERT-AUTHORITY 22 2258 INVALID-HASH-INFORMATION 23 2259 AUTHENTICATION-FAILED 24 2260 INVALID-SIGNATURE 25 2261 ADDRESS-NOTIFICATION 26 2262 NOTIFY-SA-LIFETIME 27 2263 CERTIFICATE-UNAVAILABLE 28 2264 UNSUPPORTED-EXCHANGE-TYPE 29 2265 UNEQUAL-PAYLOAD-LENGTHS 30 2266 RESERVED (Future Use) 31 - 8191 2267 Private Use 8192 - 16383 2268 2269 2270 2271 NOTIFY MESSAGES - STATUS TYPES 2272 Status Value 2273 CONNECTED 16384 2274 RESERVED (Future Use) 16385 - 24575 2275 DOI-specific codes 24576 - 32767 2276 Private Use 32768 - 40959 2277 RESERVED (Future Use) 40960 - 65535 2278 22793.15 Delete Payload 2280 2281 The Delete Payload contains a protocol-specific security association 2282 identifier that the sender has removed from its security association 2283 database and is, therefore, no longer valid. Figure 16 shows the 2284 format of the Delete Payload. It is possible to send multiple SPIs 2285 in a Delete payload, however, each SPI MUST be for the same protocol. 2286 Mixing of Protocol Identifiers MUST NOT be performed with the Delete 2287 payload. 2288 2289 Deletion which is concerned with an ISAKMP SA will contain a 2290 Protocol-Id of ISAKMP and the SPIs are the initiator and responder 2291 cookies from the ISAKMP Header. Deletion which is concerned with a 2292 Protocol SA, such as ESP or AH, will contain the Protocol-Id of that 2293 protocol (e.g. ESP, AH) and the SPI is the sending entity's SPI(s). 2294 2295 2296 2297 2298Maughan, et. al. Standards Track [Page 41] 2299 2300RFC 2408 ISAKMP November 1998 2301 2302 2303 NOTE: The Delete Payload is not a request for the responder to delete 2304 an SA, but an advisory from the initiator to the responder. If the 2305 responder chooses to ignore the message, the next communication from 2306 the responder to the initiator, using that security association, will 2307 fail. A responder is not expected to acknowledge receipt of a Delete 2308 payload. 2309 2310 1 2 3 2311 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 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 ! Next Payload ! RESERVED ! Payload Length ! 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 ! Domain of Interpretation (DOI) ! 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 ! Protocol-Id ! SPI Size ! # of SPIs ! 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2319 ! ! 2320 ~ Security Parameter Index(es) (SPI) ~ 2321 ! ! 2322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2323 2324 2325 Figure 16: Delete Payload Format 2326 2327 The Delete Payload fields are defined as follows: 2328 2329 o Next Payload (1 octet) - Identifier for the payload type of the 2330 next payload in the message. If the current payload is the last 2331 in the message, then this field will be 0. 2332 2333 o RESERVED (1 octet) - Unused, set to 0. 2334 2335 o Payload Length (2 octets) - Length in octets of the current 2336 payload, including the generic payload header. 2337 2338 o Domain of Interpretation (4 octets) - Identifies the DOI (as 2339 described in Section 2.1) under which this deletion is taking 2340 place. For ISAKMP this value is zero (0) and for the IPSEC DOI 2341 it is one (1). Other DOI's can be defined using the description 2342 in appendix B. 2343 2344 o Protocol-Id (1 octet) - ISAKMP can establish security 2345 associations for various protocols, including ISAKMP and IPSEC. 2346 This field identifies which security association database to 2347 apply the delete request. 2348 2349 2350 2351 2352 2353 2354Maughan, et. al. Standards Track [Page 42] 2355 2356RFC 2408 ISAKMP November 1998 2357 2358 2359 o SPI Size (1 octet) - Length in octets of the SPI as defined by 2360 the Protocol-Id. In the case of ISAKMP, the Initiator and 2361 Responder cookie pair is the ISAKMP SPI. In this case, the SPI 2362 Size would be 16 octets for each SPI being deleted. 2363 2364 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 2365 payload. The size of each SPI is defined by the SPI Size field. 2366 2367 o Security Parameter Index(es) (variable length) - Identifies the 2368 specific security association(s) to delete. Values for this 2369 field are DOI and protocol specific. The length of this field is 2370 determined by the SPI Size and # of SPIs fields. 2371 2372 The payload type for the Delete Payload is twelve (12). 2373 23743.16 Vendor ID Payload 2375 2376 The Vendor ID Payload contains a vendor defined constant. The 2377 constant is used by vendors to identify and recognize remote 2378 instances of their implementations. This mechanism allows a vendor 2379 to experiment with new features while maintaining backwards 2380 compatibility. This is not a general extension facility of ISAKMP. 2381 Figure 17 shows the format of the Vendor ID Payload. 2382 2383 The Vendor ID payload is not an announcement from the sender that it 2384 will send private payload types. A vendor sending the Vendor ID MUST 2385 not make any assumptions about private payloads that it may send 2386 unless a Vendor ID is received as well. Multiple Vendor ID payloads 2387 MAY be sent. An implementation is NOT REQUIRED to understand any 2388 Vendor ID payloads. An implementation is NOT REQUIRED to send any 2389 Vendor ID payload at all. If a private payload was sent without 2390 prior agreement to send it, a compliant implementation may reject a 2391 proposal with a notify message of type INVALID-PAYLOAD-TYPE. 2392 2393 If a Vendor ID payload is sent, it MUST be sent during the Phase 1 2394 negotiation. Reception of a familiar Vendor ID payload in the Phase 2395 1 negotiation allows an implementation to make use of Private USE 2396 payload numbers (128-255), described in section 3.1 for vendor 2397 specific extensions during Phase 2 negotiations. The definition of 2398 "familiar" is left to implementations to determine. Some vendors may 2399 wish to implement another vendor's extension prior to 2400 standardization. However, this practice SHOULD not be widespread and 2401 vendors should work towards standardization instead. 2402 2403 The vendor defined constant MUST be unique. The choice of hash and 2404 text to hash is left to the vendor to decide. As an example, vendors 2405 could generate their vendor id by taking a plain (non-keyed) hash of 2406 a string containing the product name, and the version of the product. 2407 2408 2409 2410Maughan, et. al. Standards Track [Page 43] 2411 2412RFC 2408 ISAKMP November 1998 2413 2414 2415 A hash is used instead of a vendor registry to avoid local 2416 cryptographic policy problems with having a list of "approved" 2417 products, to keep away from maintaining a list of vendors, and to 2418 allow classified products to avoid having to appear on any list. For 2419 instance: 2420 2421 "Example Company IPsec. Version 97.1" 2422 2423 (not including the quotes) has MD5 hash: 2424 48544f9b1fe662af98b9b39e50c01a5a, when using MD5file. Vendors may 2425 include all of the hash, or just a portion of it, as the payload 2426 length will bound the data. There are no security implications of 2427 this hash, so its choice is arbitrary. 2428 2429 1 2 3 2430 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 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 ! Next Payload ! RESERVED ! Payload Length ! 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 ! ! 2435 ~ Vendor ID (VID) ~ 2436 ! ! 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 2439 2440 Figure 17: Vendor ID Payload Format 2441 2442 The Vendor ID Payload fields are defined as follows: 2443 2444 o Next Payload (1 octet) - Identifier for the payload type of the 2445 next payload in the message. If the current payload is the last 2446 in the message, then this field will be 0. 2447 2448 o RESERVED (1 octet) - Unused, set to 0. 2449 2450 o Payload Length (2 octets) - Length in octets of the current 2451 payload, including the generic payload header. 2452 2453 o Vendor ID (variable length) - Hash of the vendor string plus 2454 version (as described above). 2455 2456 The payload type for the Vendor ID Payload is thirteen (13). 2457 24584 ISAKMP Exchanges 2459 2460 ISAKMP supplies the basic syntax of a message exchange. The basic 2461 building blocks for ISAKMP messages are the payload types described 2462 in section 3. This section describes the procedures for SA 2463 2464 2465 2466Maughan, et. al. Standards Track [Page 44] 2467 2468RFC 2408 ISAKMP November 1998 2469 2470 2471 establishment and SA modification, followed by a default set of 2472 exchanges that MAY be used for initial interoperability. Other 2473 exchanges will be defined depending on the DOI and key exchange. 2474 [IPDOI] and [IKE] are examples of how this is achieved. Appendix B 2475 explains the procedures for accomplishing these additions. 2476 24774.1 ISAKMP Exchange Types 2478 2479 ISAKMP allows the creation of exchanges for the establishment of 2480 Security Associations and keying material. There are currently five 2481 default Exchange Types defined for ISAKMP. Sections 4.4 through 4.8 2482 describe these exchanges. Exchanges define the content and ordering 2483 of ISAKMP messages during communications between peers. Most 2484 exchanges will include all the basic payload types - SA, KE, ID, SIG 2485 - and may include others. The primary difference between exchange 2486 types is the ordering of the messages and the payload ordering within 2487 each message. While the ordering of payloads within messages is not 2488 mandated, for processing efficiency it is RECOMMENDED that the 2489 Security Association payload be the first payload within an exchange. 2490 Processing of each payload within an exchange is described in section 2491 5. 2492 2493 Sections 4.4 through 4.8 provide a default set of ISAKMP exchanges. 2494 These exchanges provide different security protection for the 2495 exchange itself and information exchanged. The diagrams in each of 2496 the following sections show the message ordering for each exchange 2497 type as well as the payloads included in each message, and provide 2498 basic notes describing what has happened after each message exchange. 2499 None of the examples include any "optional payloads", like 2500 certificate and certificate request. Additionally, none of the 2501 examples include an initial exchange of ISAKMP Headers (containing 2502 initiator and responder cookies) which would provide protection 2503 against clogging (see section 2.5.3). 2504 2505 The defined exchanges are not meant to satisfy all DOI and key 2506 exchange protocol requirements. If the defined exchanges meet the 2507 DOI requirements, then they can be used as outlined. If the defined 2508 exchanges do not meet the security requirements defined by the DOI, 2509 then the DOI MUST specify new exchange type(s) and the valid 2510 sequences of payloads that make up a successful exchange, and how to 2511 build and interpret those payloads. All ISAKMP implementations MUST 2512 implement the Informational Exchange and SHOULD implement the other 2513 four exchanges. However, this is dependent on the definition of the 2514 DOI and associated key exchange protocols. 2515 2516 2517 2518 2519 2520 2521 2522Maughan, et. al. Standards Track [Page 45] 2523 2524RFC 2408 ISAKMP November 1998 2525 2526 2527 As discussed above, these exchange types can be used in either phase 2528 of negotiation. However, they may provide different security 2529 properties in each of the phases. With each of these exchanges, the 2530 combination of cookies and SPI fields identifies whether this 2531 exchange is being used in the first or second phase of a negotiation. 2532 25334.1.1 Notation 2534 2535 The following notation is used to describe the ISAKMP exchange types, 2536 shown in the next section, with the message formats and associated 2537 payloads: 2538 2539 HDR is an ISAKMP header whose exchange type defines the payload 2540 orderings 2541 SA is an SA negotiation payload with one or more Proposal and 2542 Transform payloads. An initiator MAY provide multiple proposals 2543 for negotiation; a responder MUST reply with only one. 2544 KE is the key exchange payload. 2545 IDx is the identity payload for "x". x can be: "ii" or "ir" 2546 for the ISAKMP initiator and responder, respectively, or x can 2547 be: "ui", "ur" (when the ISAKMP daemon is a proxy negotiator), 2548 for the user initiator and responder, respectively. 2549 HASH is the hash payload. 2550 SIG is the signature payload. The data to sign is exchange-specific. 2551 AUTH is a generic authentication mechanism, such as HASH or SIG. 2552 NONCE is the nonce payload. 2553 '*' signifies payload encryption after the ISAKMP header. This 2554 encryption MUST begin immediately after the ISAKMP header and 2555 all payloads following the ISAKMP header MUST be encrypted. 2556 2557 => signifies "initiator to responder" communication 2558 <= signifies "responder to initiator" communication 2559 25604.2 Security Association Establishment 2561 2562 The Security Association, Proposal, and Transform payloads are used 2563 to build ISAKMP messages for the negotiation and establishment of 2564 SAs. An SA establishment message consists of a single SA payload 2565 followed by at least one, and possibly many, Proposal payloads and at 2566 least one, and possibly many, Transform payloads associated with each 2567 Proposal payload. Because these payloads are considered together, 2568 the SA payload will point to any following payloads and not to the 2569 Proposal payload included with the SA payload. The SA Payload 2570 contains the DOI and Situation for the proposed SA. Each Proposal 2571 payload contains a Security Parameter Index (SPI) and ensures that 2572 the SPI is associated with the Protocol-Id in accordance with the 2573 Internet Security Architecture [SEC-ARCH]. Proposal payloads may or 2574 may not have the same SPI, as this is implementation dependent. Each 2575 2576 2577 2578Maughan, et. al. Standards Track [Page 46] 2579 2580RFC 2408 ISAKMP November 1998 2581 2582 2583 Transform Payload contains the specific security mechanisms to be 2584 used for the designated protocol. It is expected that the Proposal 2585 and Transform payloads will be used only during SA establishment 2586 negotiation. The creation of payloads for security association 2587 negotiation and establishment described here in this section are 2588 applicable for all ISAKMP exchanges described later in sections 4.4 2589 through 4.8. The examples shown in 4.2.1 contain only the SA, 2590 Proposal, and Transform payloads and do not contain other payloads 2591 that might exist for a given ISAKMP exchange. 2592 2593 The Proposal payload provides the initiating entity with the 2594 capability to present to the responding entity the security protocols 2595 and associated security mechanisms for use with the security 2596 association being negotiated. If the SA establishment negotiation is 2597 for a combined protection suite consisting of multiple protocols, 2598 then there MUST be multiple Proposal payloads each with the same 2599 Proposal number. These proposals MUST be considered as a unit and 2600 MUST NOT be separated by a proposal with a different proposal number. 2601 The use of the same Proposal number in multiple Proposal payloads 2602 provides a logical AND operation, i.e. Protocol 1 AND Protocol 2. 2603 The first example below shows an ESP AND AH protection suite. If the 2604 SA establishment negotiation is for different protection suites, then 2605 there MUST be multiple Proposal payloads each with a monotonically 2606 increasing Proposal number. The different proposals MUST be 2607 presented in the initiator's preference order. The use of different 2608 Proposal numbers in multiple Proposal payloads provides a logical OR 2609 operation, i.e. Proposal 1 OR Proposal 2, where each proposal may 2610 have more than one protocol. The second example below shows either 2611 an AH AND ESP protection suite OR just an ESP protection suite. Note 2612 that the Next Payload field of the Proposal payload points to another 2613 Proposal payload (if it exists). The existence of a Proposal payload 2614 implies the existence of one or more Transform payloads. 2615 2616 The Transform payload provides the initiating entity with the 2617 capability to present to the responding entity multiple mechanisms, 2618 or transforms, for a given protocol. The Proposal payload identifies 2619 a Protocol for which services and mechanisms are being negotiated. 2620 The Transform payload allows the initiating entity to present several 2621 possible supported transforms for that proposed protocol. There may 2622 be several transforms associated with a specific Proposal payload 2623 each identified in a separate Transform payload. The multiple 2624 transforms MUST be presented with monotonically increasing numbers in 2625 the initiator's preference order. The receiving entity MUST select a 2626 single transform for each protocol in a proposal or reject the entire 2627 proposal. The use of the Transform number in multiple Transform 2628 payloads provides a second level OR operation, i.e. Transform 1 OR 2629 Transform 2 OR Transform 3. Example 1 below shows two possible 2630 transforms for ESP and a single transform for AH. Example 2 below 2631 2632 2633 2634Maughan, et. al. Standards Track [Page 47] 2635 2636RFC 2408 ISAKMP November 1998 2637 2638 2639 shows one transform for AH AND one transform for ESP OR two 2640 transforms for ESP alone. Note that the Next Payload field of the 2641 Transform payload points to another Transform payload or 0. The 2642 Proposal payload delineates the different proposals. 2643 2644 When responding to a Security Association payload, the responder MUST 2645 send a Security Association payload with the selected proposal, which 2646 may consist of multiple Proposal payloads and their associated 2647 Transform payloads. Each of the Proposal payloads MUST contain a 2648 single Transform payload associated with the Protocol. The responder 2649 SHOULD retain the Proposal # field in the Proposal payload and the 2650 Transform # field in each Transform payload of the selected Proposal. 2651 Retention of Proposal and Transform numbers should speed the 2652 initiator's protocol processing by negating the need to compare the 2653 respondor's selection with every offered option. These values enable 2654 the initiator to perform the comparison directly and quickly. The 2655 initiator MUST verify that the Security Association payload received 2656 from the responder matches one of the proposals sent initially. 2657 26584.2.1 Security Association Establishment Examples 2659 2660 This example shows a Proposal for a combined protection suite with 2661 two different protocols. The first protocol is presented with two 2662 transforms supported by the proposer. The second protocol is 2663 presented with a single transform. An example for this proposal 2664 might be: Protocol 1 is ESP with Transform 1 as 3DES and Transform 2 2665 as DES AND Protocol 2 is AH with Transform 1 as SHA. The responder 2666 MUST select from the two transforms proposed for ESP. The resulting 2667 protection suite will be either (1) 3DES AND SHA OR (2) DES AND SHA, 2668 depending on which ESP transform was selected by the responder. Note 2669 this example is shown using the Base Exchange. 2670 2671 1 2 3 2672 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 2673 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2674 / ! NP = Nonce ! RESERVED ! Payload Length ! 2675 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2676SA Pay ! Domain of Interpretation (DOI) ! 2677 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2678 \ ! Situation ! 2679 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2680 / ! NP = Proposal ! RESERVED ! Payload Length ! 2681 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans. = 2! 2683Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2684 \ ! SPI (variable) ! 2685 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2686 / ! NP = Transform! RESERVED ! Payload Length ! 2687 2688 2689 2690Maughan, et. al. Standards Track [Page 48] 2691 2692RFC 2408 ISAKMP November 1998 2693 2694 2695 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2696Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 2697 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2698 \ ! SA Attributes ! 2699 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 / ! NP = 0 ! RESERVED ! Payload Length ! 2701 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! 2703 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2704 \ ! SA Attributes ! 2705 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2706 / ! NP = 0 ! RESERVED ! Payload Length ! 2707 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2708Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! 2709Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2710 \ ! SPI (variable) ! 2711 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2712 / ! NP = 0 ! RESERVED ! Payload Length ! 2713 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2714Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 2715 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2716 \ ! SA Attributes ! 2717 \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2718 2719 This second example shows a Proposal for two different protection 2720 suites. The SA Payload was omitted for space reasons. The first 2721 protection suite is presented with one transform for the first 2722 protocol and one transform for the second protocol. The second 2723 protection suite is presented with two transforms for a single 2724 protocol. An example for this proposal might be: Proposal 1 with 2725 Protocol 1 as AH with Transform 1 as MD5 AND Protocol 2 as ESP with 2726 Transform 1 as 3DES. This is followed by Proposal 2 with Protocol 1 2727 as ESP with Transform 1 as DES and Transform 2 as 3DES. The responder 2728 MUST select from the two different proposals. If the second Proposal 2729 is selected, the responder MUST select from the two transforms for 2730 ESP. The resulting protection suite will be either (1) MD5 AND 3DES 2731 OR the selection between (2) DES OR (3) 3DES. 2732 2733 1 2 3 2734 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 2735 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 / ! NP = Proposal ! RESERVED ! Payload Length ! 2737 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! 2739Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 \ ! SPI (variable) ! 2741 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2742 / ! NP = 0 ! RESERVED ! Payload Length ! 2743 2744 2745 2746Maughan, et. al. Standards Track [Page 49] 2747 2748RFC 2408 ISAKMP November 1998 2749 2750 2751 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2752Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 2753 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2754 \ ! SA Attributes ! 2755 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 / ! NP = Proposal ! RESERVED ! Payload Length ! 2757 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2758Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! 2759Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2760 \ ! SPI (variable) ! 2761 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2762 / ! NP = 0 ! RESERVED ! Payload Length ! 2763 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2764Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 2765 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2766 \ ! SA Attributes ! 2767 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 / ! NP = 0 ! RESERVED ! Payload Length ! 2769 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2770Prop 2 ! Proposal # = 2! Protocol ID ! SPI Size !# of Trans. = 2! 2771Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2772 \ ! SPI (variable) ! 2773 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 / ! NP = Transform! RESERVED ! Payload Length ! 2775 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2776Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 2777 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2778 \ ! SA Attributes ! 2779 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2780 / ! NP = 0 ! RESERVED ! Payload Length ! 2781 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! 2783 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2784 \ ! SA Attributes ! 2785 \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2786 27874.3 Security Association Modification 2788 2789 Security Association modification within ISAKMP is accomplished by 2790 creating a new SA and initiating communications using that new SA. 2791 Deletion of the old SA can be done anytime after the new SA is 2792 established. Deletion of the old SA is dependent on local security 2793 policy. Modification of SAs by using a "Create New SA followed by 2794 Delete Old SA" method is done to avoid potential vulnerabilities in 2795 synchronizing modification of existing SA attributes. The procedure 2796 for creating new SAs is outlined in section 4.2. The procedure for 2797 deleting SAs is outlined in section 5.15. 2798 2799 2800 2801 2802Maughan, et. al. Standards Track [Page 50] 2803 2804RFC 2408 ISAKMP November 1998 2805 2806 2807 Modification of an ISAKMP SA (phase 1 negotiation) follows the same 2808 procedure as creation of an ISAKMP SA. There is no relationship 2809 between the two SAs and the initiator and responder cookie pairs 2810 SHOULD be different, as outlined in section 2.5.3. 2811 2812 Modification of a Protocol SA (phase 2 negotiation) follows the same 2813 procedure as creation of a Protocol SA. The creation of a new SA is 2814 protected by the existing ISAKMP SA. There is no relationship between 2815 the two Protocol SAs. A protocol implementation SHOULD begin using 2816 the newly created SA for outbound traffic and SHOULD continue to 2817 support incoming traffic on the old SA until it is deleted or until 2818 traffic is received under the protection of the newly created SA. As 2819 stated previously in this section, deletion of an old SA is then 2820 dependent on local security policy. 2821 28224.4 Base Exchange 2823 2824 The Base Exchange is designed to allow the Key Exchange and 2825 Authentication related information to be transmitted together. 2826 Combining the Key Exchange and Authentication-related information 2827 into one message reduces the number of round-trips at the expense of 2828 not providing identity protection. Identity protection is not 2829 provided because identities are exchanged before a common shared 2830 secret has been established and, therefore, encryption of the 2831 identities is not possible. The following diagram shows the messages 2832 with the possible payloads sent in each message and notes for an 2833 example of the Base Exchange. 2834 2835 BASE EXCHANGE 2836 2837 # Initiator Direction Responder NOTE 2838(1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation 2839 2840(2) <= HDR; SA; NONCE 2841 Basic SA agreed upon 2842(3) HDR; KE; => 2843 IDii; AUTH Key Generated (by responder) 2844 Initiator Identity Verified by 2845 Responder 2846(4) <= HDR; KE; 2847 IDir; AUTH 2848 Responder Identity Verified by 2849 Initiator Key Generated (by 2850 initiator) SA established 2851 2852 2853 2854 2855 2856 2857 2858Maughan, et. al. Standards Track [Page 51] 2859 2860RFC 2408 ISAKMP November 1998 2861 2862 2863 In the first message (1), the initiator generates a proposal it 2864 considers adequate to protect traffic for the given situation. The 2865 Security Association, Proposal, and Transform payloads are included 2866 in the Security Association payload (for notation purposes). Random 2867 information which is used to guarantee liveness and protect against 2868 replay attacks is also transmitted. Random information provided by 2869 both parties SHOULD be used by the authentication mechanism to 2870 provide shared proof of participation in the exchange. 2871 2872 In the second message (2), the responder indicates the protection 2873 suite it has accepted with the Security Association, Proposal, and 2874 Transform payloads. Again, random information which is used to 2875 guarantee liveness and protect against replay attacks is also 2876 transmitted. Random information provided by both parties SHOULD be 2877 used by the authentication mechanism to provide shared proof of 2878 participation in the exchange. Local security policy dictates the 2879 action of the responder if no proposed protection suite is accepted. 2880 One possible action is the transmission of a Notify payload as part 2881 of an Informational Exchange. 2882 2883 In the third (3) and fourth (4) messages, the initiator and 2884 responder, respectively, exchange keying material used to arrive at a 2885 common shared secret and identification information. This 2886 information is transmitted under the protection of the agreed upon 2887 authentication function. Local security policy dictates the action 2888 if an error occurs during these messages. One possible action is the 2889 transmission of a Notify payload as part of an Informational 2890 Exchange. 2891 28924.5 Identity Protection Exchange 2893 2894 The Identity Protection Exchange is designed to separate the Key 2895 Exchange information from the Identity and Authentication related 2896 information. Separating the Key Exchange from the Identity and 2897 Authentication related information provides protection of the 2898 communicating identities at the expense of two additional messages. 2899 Identities are exchanged under the protection of a previously 2900 established common shared secret. The following diagram shows the 2901 messages with the possible payloads sent in each message and notes 2902 for an example of the Identity Protection Exchange. 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914Maughan, et. al. Standards Track [Page 52] 2915 2916RFC 2408 ISAKMP November 1998 2917 2918 2919 IDENTITY PROTECTION EXCHANGE 2920 2921 # Initiator Direction Responder NOTE 2922(1) HDR; SA => Begin ISAKMP-SA or 2923 Proxy negotiation 2924(2) <= HDR; SA 2925 Basic SA agreed upon 2926(3) HDR; KE; NONCE => 2927(4) <= HDR; KE; NONCE 2928 Key Generated (by 2929 Initiator and 2930 Responder) 2931(5) HDR*; IDii; AUTH => 2932 Initiator Identity 2933 Verified by 2934 Responder 2935(6) <= HDR*; IDir; AUTH 2936 Responder Identity 2937 Verified by 2938 Initiator 2939 SA established 2940 2941 In the first message (1), the initiator generates a proposal it 2942 considers adequate to protect traffic for the given situation. The 2943 Security Association, Proposal, and Transform payloads are included 2944 in the Security Association payload (for notation purposes). 2945 2946 In the second message (2), the responder indicates the protection 2947 suite it has accepted with the Security Association, Proposal, and 2948 Transform payloads. Local security policy dictates the action of the 2949 responder if no proposed protection suite is accepted. One possible 2950 action is the transmission of a Notify payload as part of an 2951 Informational Exchange. 2952 2953 In the third (3) and fourth (4) messages, the initiator and 2954 responder, respectively, exchange keying material used to arrive at a 2955 common shared secret and random information which is used to 2956 guarantee liveness and protect against replay attacks. Random 2957 information provided by both parties SHOULD be used by the 2958 authentication mechanism to provide shared proof of participation in 2959 the exchange. Local security policy dictates the action if an error 2960 occurs during these messages. One possible action is the 2961 transmission of a Notify payload as part of an Informational 2962 Exchange. 2963 2964 In the fifth (5) and sixth (6) messages, the initiator and responder, 2965 respectively, exchange identification information and the results of 2966 the agreed upon authentication function. This information is 2967 2968 2969 2970Maughan, et. al. Standards Track [Page 53] 2971 2972RFC 2408 ISAKMP November 1998 2973 2974 2975 transmitted under the protection of the common shared secret. Local 2976 security policy dictates the action if an error occurs during these 2977 messages. One possible action is the transmission of a Notify 2978 payload as part of an Informational Exchange. 2979 29804.6 Authentication Only Exchange 2981 2982 The Authentication Only Exchange is designed to allow only 2983 Authentication related information to be transmitted. The benefit of 2984 this exchange is the ability to perform only authentication without 2985 the computational expense of computing keys. Using this exchange 2986 during negotiation, none of the transmitted information will be 2987 encrypted. However, the information may be encrypted in other 2988 places. For example, if encryption is negotiated during the first 2989 phase of a negotiation and the authentication only exchange is used 2990 in the second phase of a negotiation, then the authentication only 2991 exchange will be encrypted by the ISAKMP SAs negotiated in the first 2992 phase. The following diagram shows the messages with possible 2993 payloads sent in each message and notes for an example of the 2994 Authentication Only Exchange. 2995 2996 AUTHENTICATION ONLY EXCHANGE 2997 2998 # Initiator Direction Responder NOTE 2999(1) HDR; SA; NONCE => Begin ISAKMP-SA or 3000 Proxy negotiation 3001(2) <= HDR; SA; NONCE; 3002 IDir; AUTH 3003 Basic SA agreed upon 3004 Responder Identity 3005 Verified by Initiator 3006(3) HDR; IDii; AUTH => 3007 Initiator Identity 3008 Verified by Responder 3009 SA established 3010 3011 In the first message (1), the initiator generates a proposal it 3012 considers adequate to protect traffic for the given situation. The 3013 Security Association, Proposal, and Transform payloads are included 3014 in the Security Association payload (for notation purposes). Random 3015 information which is used to guarantee liveness and protect against 3016 replay attacks is also transmitted. Random information provided by 3017 both parties SHOULD be used by the authentication mechanism to 3018 provide shared proof of participation in the exchange. 3019 3020 In the second message (2), the responder indicates the protection 3021 suite it has accepted with the Security Association, Proposal, and 3022 Transform payloads. Again, random information which is used to 3023 3024 3025 3026Maughan, et. al. Standards Track [Page 54] 3027 3028RFC 2408 ISAKMP November 1998 3029 3030 3031 guarantee liveness and protect against replay attacks is also 3032 transmitted. Random information provided by both parties SHOULD be 3033 used by the authentication mechanism to provide shared proof of 3034 participation in the exchange. Additionally, the responder transmits 3035 identification information. All of this information is transmitted 3036 under the protection of the agreed upon authentication function. 3037 Local security policy dictates the action of the responder if no 3038 proposed protection suite is accepted. One possible action is the 3039 transmission of a Notify payload as part of an Informational 3040 Exchange. 3041 3042 In the third message (3), the initiator transmits identification 3043 information. This information is transmitted under the protection of 3044 the agreed upon authentication function. Local security policy 3045 dictates the action if an error occurs during these messages. One 3046 possible action is the transmission of a Notify payload as part of an 3047 Informational Exchange. 3048 30494.7 Aggressive Exchange 3050 3051 The Aggressive Exchange is designed to allow the Security 3052 Association, Key Exchange and Authentication related payloads to be 3053 transmitted together. Combining the Security Association, Key 3054 Exchange, and Authentication-related information into one message 3055 reduces the number of round-trips at the expense of not providing 3056 identity protection. Identity protection is not provided because 3057 identities are exchanged before a common shared secret has been 3058 established and, therefore, encryption of the identities is not 3059 possible. Additionally, the Aggressive Exchange is attempting to 3060 establish all security relevant information in a single exchange. 3061 The following diagram shows the messages with possible payloads sent 3062 in each message and notes for an example of the Aggressive Exchange. 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082Maughan, et. al. Standards Track [Page 55] 3083 3084RFC 2408 ISAKMP November 1998 3085 3086 3087 AGGRESSIVE EXCHANGE 3088 3089 # Initiator Direction Responder NOTE 3090(1) HDR; SA; KE; => Begin ISAKMP-SA or 3091 Proxy negotiation 3092 NONCE; IDii and Key Exchange 3093 3094(2) <= HDR; SA; KE; 3095 NONCE; IDir; AUTH 3096 Initiator Identity 3097 Verified by Responder 3098 Key Generated 3099 Basic SA agreed upon 3100(3) HDR*; AUTH => 3101 Responder Identity 3102 Verified by Initiator 3103 SA established 3104 3105 In the first message (1), the initiator generates a proposal it 3106 considers adequate to protect traffic for the given situation. The 3107 Security Association, Proposal, and Transform payloads are included 3108 in the Security Association payload (for notation purposes). There 3109 can be only one Proposal and one Transform offered (i.e. no choices) 3110 in order for the aggressive exchange to work. Keying material used 3111 to arrive at a common shared secret and random information which is 3112 used to guarantee liveness and protect against replay attacks are 3113 also transmitted. Random information provided by both parties SHOULD 3114 be used by the authentication mechanism to provide shared proof of 3115 participation in the exchange. Additionally, the initiator transmits 3116 identification information. 3117 3118 In the second message (2), the responder indicates the protection 3119 suite it has accepted with the Security Association, Proposal, and 3120 Transform payloads. Keying material used to arrive at a common 3121 shared secret and random information which is used to guarantee 3122 liveness and protect against replay attacks is also transmitted. 3123 Random information provided by both parties SHOULD be used by the 3124 authentication mechanism to provide shared proof of participation in 3125 the exchange. Additionally, the responder transmits identification 3126 information. All of this information is transmitted under the 3127 protection of the agreed upon authentication function. Local 3128 security policy dictates the action of the responder if no proposed 3129 protection suite is accepted. One possible action is the 3130 transmission of a Notify payload as part of an Informational 3131 Exchange. 3132 3133 3134 3135 3136 3137 3138Maughan, et. al. Standards Track [Page 56] 3139 3140RFC 2408 ISAKMP November 1998 3141 3142 3143 In the third (3) message, the initiator transmits the results of the 3144 agreed upon authentication function. This information is transmitted 3145 under the protection of the common shared secret. Local security 3146 policy dictates the action if an error occurs during these messages. 3147 One possible action is the transmission of a Notify payload as part 3148 of an Informational Exchange. 3149 31504.8 Informational Exchange 3151 3152 The Informational Exchange is designed as a one-way transmittal of 3153 information that can be used for security association management. 3154 The following diagram shows the messages with possible payloads sent 3155 in each message and notes for an example of the Informational 3156 Exchange. 3157 3158 INFORMATIONAL EXCHANGE 3159 3160 # Initiator Direction Responder NOTE 3161 (1) HDR*; N/D => Error Notification or Deletion 3162 3163 In the first message (1), the initiator or responder transmits an 3164 ISAKMP Notify or Delete payload. 3165 3166 If the Informational Exchange occurs prior to the exchange of keying 3167 meterial during an ISAKMP Phase 1 negotiation, there will be no 3168 protection provided for the Informational Exchange. Once keying 3169 material has been exchanged or an ISAKMP SA has been established, the 3170 Informational Exchange MUST be transmitted under the protection 3171 provided by the keying material or the ISAKMP SA. 3172 3173 All exchanges are similar in that with the beginning of any exchange, 3174 cryptographic synchronization MUST occur. The Informational Exchange 3175 is an exchange and not an ISAKMP message. Thus, the generation of an 3176 Message ID (MID) for an Informational Exchange SHOULD be independent 3177 of IVs of other on-going communication. This will ensure 3178 cryptographic synchronization is maintained for existing 3179 communications and the Informational Exchange will be processed 3180 correctly. The only exception to this is when the Commit Bit of the 3181 ISAKMP Header is set. When the Commit Bit is set, the Message ID 3182 field of the Informational Exchange MUST contain the Message ID of 3183 the original ISAKMP Phase 2 SA negotiation, rather than a new Message 3184 ID (MID). This is done to ensure that the Informational Exchange with 3185 the CONNECTED Notify Message can be associated with the correct Phase 3186 2 SA. For a description of the Commit Bit, see section 3.1. 3187 3188 3189 3190 3191 3192 3193 3194Maughan, et. al. Standards Track [Page 57] 3195 3196RFC 2408 ISAKMP November 1998 3197 3198 31995 ISAKMP Payload Processing 3200 3201 Section 3 describes the ISAKMP payloads. These payloads are used in 3202 the exchanges described in section 4 and can be used in exchanges 3203 defined for a specific DOI. This section describes the processing for 3204 each of the payloads. This section suggests the logging of events to 3205 a system audit file. This action is controlled by a system security 3206 policy and is, therefore, only a suggested action. 3207 32085.1 General Message Processing 3209 3210 Every ISAKMP message has basic processing applied to insure protocol 3211 reliability, and to minimize threats, such as denial of service and 3212 replay attacks. All processing SHOULD include packet length checks 3213 to insure the packet received is at least as long as the length given 3214 in the ISAKMP Header. If the ISAKMP message length and the value in 3215 the Payload Length field of the ISAKMP Header are not the same, then 3216 the ISAKMP message MUST be rejected. The receiving entity (initiator 3217 or responder) MUST do the following: 3218 3219 1. The event, UNEQUAL PAYLOAD LENGTHS, MAY be logged in the 3220 appropriate system audit file. 3221 3222 2. An Informational Exchange with a Notification payload containing 3223 the UNEQUAL-PAYLOAD-LENGTHS message type MAY be sent to the 3224 transmitting entity. This action is dictated by a system 3225 security policy. 3226 3227 When transmitting an ISAKMP message, the transmitting entity 3228 (initiator or responder) MUST do the following: 3229 3230 1. Set a timer and initialize a retry counter. 3231 3232 NOTE: Implementations MUST NOT use a fixed timer. Instead, 3233 transmission timer values should be adjusted dynamically based on 3234 measured round trip times. In addition, successive 3235 retransmissions of the same packet should be separated by 3236 increasingly longer time intervals (e.g., exponential backoff). 3237 3238 2. If the timer expires, the ISAKMP message is resent and the retry 3239 counter is decremented. 3240 3241 3. If the retry counter reaches zero (0), the event, RETRY LIMIT 3242 REACHED, MAY be logged in the appropriate system audit file. 3243 3244 4. The ISAKMP protocol machine clears all states and returns to 3245 IDLE. 3246 3247 3248 3249 3250Maughan, et. al. Standards Track [Page 58] 3251 3252RFC 2408 ISAKMP November 1998 3253 3254 32555.2 ISAKMP Header Processing 3256 3257 When creating an ISAKMP message, the transmitting entity (initiator 3258 or responder) MUST do the following: 3259 3260 1. Create the respective cookie. See section 2.5.3 for details. 3261 3262 2. Determine the relevant security characteristics of the session 3263 (i.e. DOI and situation). 3264 3265 3. Construct an ISAKMP Header with fields as described in section 3266 3.1. 3267 3268 4. Construct other ISAKMP payloads, depending on the exchange type. 3269 3270 5. Transmit the message to the destination host as described in 3271 section5.1. 3272 3273 When an ISAKMP message is received, the receiving entity (initiator 3274 or responder) MUST do the following: 3275 3276 1. Verify the Initiator and Responder "cookies". If the cookie 3277 validation fails, the message is discarded and the following 3278 actions are taken: 3279 3280 (a) The event, INVALID COOKIE, MAY be logged in the 3281 appropriate system audit file. 3282 3283 (b) An Informational Exchange with a Notification payload 3284 containing the INVALID-COOKIE message type MAY be sent to 3285 the transmitting entity. This action is dictated by a 3286 system security policy. 3287 3288 2. Check the Next Payload field to confirm it is valid. If the Next 3289 Payload field validation fails, the message is discarded and the 3290 following actions are taken: 3291 3292 (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the 3293 appropriate system audit file. 3294 3295 (b) An Informational Exchange with a Notification payload 3296 containing the INVALID-PAYLOAD-TYPE message type MAY be sent 3297 to the transmitting entity. This action is dictated by a 3298 system security policy. 3299 3300 3. Check the Major and Minor Version fields to confirm they are 3301 correct (see section 3.1). If the Version field validation 3302 fails, the message is discarded and the following actions are 3303 3304 3305 3306Maughan, et. al. Standards Track [Page 59] 3307 3308RFC 2408 ISAKMP November 1998 3309 3310 3311 taken: 3312 3313 (a) The event, INVALID ISAKMP VERSION, MAY be logged in the 3314 appropriate system audit file. 3315 3316 (b) An Informational Exchange with a Notification payload 3317 containing the INVALID-MAJOR-VERSION or INVALID-MINOR- 3318 VERSION message type MAY be sent to the transmitting entity. 3319 This action is dictated by a system security policy. 3320 3321 4. Check the Exchange Type field to confirm it is valid. If the 3322 Exchange Type field validation fails, the message is discarded 3323 and the following actions are taken: 3324 3325 (a) The event, INVALID EXCHANGE TYPE, MAY be logged in the 3326 appropriate system audit file. 3327 3328 (b) An Informational Exchange with a Notification payload 3329 containing the INVALID-EXCHANGE-TYPE message type MAY be 3330 sent to the transmitting entity. This action is dictated by 3331 a system security policy. 3332 3333 5. Check the Flags field to ensure it contains correct values. If 3334 the Flags field validation fails, the message is discarded and 3335 the following actions are taken: 3336 3337 (a) The event, INVALID FLAGS, MAY be logged in the appropriate 3338 systemaudit file. 3339 3340 (b) An Informational Exchange with a Notification payload 3341 containing the INVALID-FLAGS message type MAY be sent to the 3342 transmitting entity. This action is dictated by a system 3343 security policy. 3344 3345 6. Check the Message ID field to ensure it contains correct values. 3346 If the Message ID validation fails, the message is discarded and 3347 the following actions are taken: 3348 3349 (a) The event, INVALID MESSAGE ID, MAY be logged in the 3350 appropriate system audit file. 3351 3352 (b) An Informational Exchange with a Notification payload 3353 containing the INVALID-MESSAGE-ID message type MAY be sent 3354 to the transmitting entity. This action is dictated by a 3355 system security policy. 3356 3357 7. Processing of the ISAKMP message continues using the value in the 3358 Next Payload field. 3359 3360 3361 3362Maughan, et. al. Standards Track [Page 60] 3363 3364RFC 2408 ISAKMP November 1998 3365 3366 33675.3 Generic Payload Header Processing 3368 3369 When creating any of the ISAKMP Payloads described in sections 3.4 3370 through 3.15 a Generic Payload Header is placed at the beginning of 3371 these payloads. When creating the Generic Payload Header, the 3372 transmitting entity (initiator or responder) MUST do the following: 3373 3374 1. Place the value of the Next Payload in the Next Payload field. 3375 These values are described in section 3.1. 3376 3377 2. Place the value zero (0) in the RESERVED field. 3378 3379 3. Place the length (in octets) of the payload in the Payload Length 3380 field. 3381 3382 4. Construct the payloads as defined in the remainder of this 3383 section. 3384 3385 When any of the ISAKMP Payloads are received, the receiving entity 3386 (initiator or responder) MUST do the following: 3387 3388 1. Check the Next Payload field to confirm it is valid. If the Next 3389 Payload field validation fails, the message is discarded and the 3390 following actions are taken: 3391 3392 (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the 3393 appropriate system audit file. 3394 3395 (b) An Informational Exchange with a Notification payload 3396 containing the INVALID-PAYLOAD-TYPE message type MAY be sent 3397 to the transmitting entity. This action is dictated by a 3398 system security policy. 3399 3400 2. Verify the RESERVED field contains the value zero. If the value 3401 in the RESERVED field is not zero, the message is discarded and 3402 the following actions are taken: 3403 3404 (a) The event, INVALID RESERVED FIELD, MAY be logged in the 3405 appropriate system audit file. 3406 3407 (b) An Informational Exchange with a Notification payload 3408 containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED 3409 message type MAY be sent to the transmitting entity. This 3410 action is dictated by a system security policy. 3411 3412 3. Process the remaining payloads as defined by the Next Payload 3413 field. 3414 3415 3416 3417 3418Maughan, et. al. Standards Track [Page 61] 3419 3420RFC 2408 ISAKMP November 1998 3421 3422 34235.4 Security Association Payload Processing 3424 3425 When creating a Security Association Payload, the transmitting entity 3426 (initiator or responder) MUST do the following: 3427 3428 1. Determine the Domain of Interpretation for which this negotiation 3429 is being performed. 3430 3431 2. Determine the situation within the determined DOI for which this 3432 negotiation is being performed. 3433 3434 3. Determine the proposal(s) and transform(s) within the situation. 3435 These are described, respectively, in sections 3.5 and 3.6. 3436 3437 4. Construct a Security Association payload. 3438 3439 5. Transmit the message to the receiving entity as described in 3440 section 5.1. 3441 3442 When a Security Association payload is received, the receiving entity 3443 (initiator or responder) MUST do the following: 3444 3445 1. Determine if the Domain of Interpretation (DOI) is supported. If 3446 the DOI determination fails, the message is discarded and the 3447 following actions are taken: 3448 3449 (a) The event, INVALID DOI, MAY be logged in the appropriate 3450 system audit file. 3451 3452 (b) An Informational Exchange with a Notification payload 3453 containing the DOI-NOT-SUPPORTED message type MAY be sent to 3454 the transmitting entity. This action is dictated by a 3455 system security policy. 3456 3457 2. Determine if the given situation can be protected. If the 3458 Situation determination fails, the message is discarded and the 3459 following actions are taken: 3460 3461 (a) The event, INVALID SITUATION, MAY be logged in the 3462 appropriate system audit file. 3463 3464 (b) An Informational Exchange with a Notification payload 3465 containing the SITUATION-NOT-SUPPORTED message type MAY be 3466 sent to the transmitting entity. This action is dictated by 3467 a system security policy. 3468 3469 3. Process the remaining payloads (i.e. Proposal, Transform) of the 3470 Security Association Payload. If the Security Association 3471 3472 3473 3474Maughan, et. al. Standards Track [Page 62] 3475 3476RFC 2408 ISAKMP November 1998 3477 3478 3479 Proposal (as described in sections 5.5 and 5.6) is not accepted, 3480 then the following actions are taken: 3481 3482 (a) The event, INVALID PROPOSAL, MAY be logged in the 3483 appropriate system audit file. 3484 3485 (b) An Informational Exchange with a Notification payload 3486 containing the NO-PROPOSAL-CHOSEN message type MAY be sent 3487 to the transmitting entity. This action is dictated by a 3488 system security policy. 3489 34905.5 Proposal Payload Processing 3491 3492 When creating a Proposal Payload, the transmitting entity (initiator 3493 or responder) MUST do the following: 3494 3495 1. Determine the Protocol for this proposal. 3496 3497 2. Determine the number of proposals to be offered for this protocol 3498 and the number of transforms for each proposal. Transforms are 3499 described in section 3.6. 3500 3501 3. Generate a unique pseudo-random SPI. 3502 3503 4. Construct a Proposal payload. 3504 3505 When a Proposal payload is received, the receiving entity (initiator 3506 or responder) MUST do the following: 3507 3508 1. Determine if the Protocol is supported. If the Protocol-ID field 3509 is invalid, the payload is discarded and the following actions 3510 are taken: 3511 3512 (a) The event, INVALID PROTOCOL, MAY be logged in the 3513 appropriate system audit file. 3514 3515 (b) An Informational Exchange with a Notification payload 3516 containing the INVALID-PROTOCOL-ID message type MAY be sent 3517 to the transmitting entity. This action is dictated by a 3518 system security policy. 3519 3520 2. Determine if the SPI is valid. If the SPI is invalid, the 3521 payload is discarded and the following actions are taken: 3522 3523 (a) The event, INVALID SPI, MAY be logged in the appropriate 3524 system audit file. 3525 3526 3527 3528 3529 3530Maughan, et. al. Standards Track [Page 63] 3531 3532RFC 2408 ISAKMP November 1998 3533 3534 3535 (b) An Informational Exchange with a Notification payload 3536 containing the INVALID-SPI message type MAY be sent to the 3537 transmitting entity. This action is dictated by a system 3538 security policy. 3539 3540 3. Ensure the Proposals are presented according to the details given 3541 in section 3.5 and 4.2. If the proposals are not formed 3542 correctly, the following actions are taken: 3543 3544 (a) Possible events, BAD PROPOSAL SYNTAX, INVALID PROPOSAL, are 3545 logged in the appropriate system audit file. 3546 3547 (b) An Informational Exchange with a Notification payload 3548 containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED 3549 message type MAY be sent to the transmitting entity. This 3550 action is dictated by a system security policy. 3551 3552 4. Process the Proposal and Transform payloads as defined by the 3553 Next Payload field. Examples of processing these payloads are 3554 given in section 4.2.1. 3555 35565.6 Transform Payload Processing 3557 3558 When creating a Transform Payload, the transmitting entity (initiator 3559 or responder) MUST do the following: 3560 3561 1. Determine the Transform # for this transform. 3562 3563 2. Determine the number of transforms to be offered for this 3564 proposal. Transforms are described in sections 3.6. 3565 3566 3. Construct a Transform payload. 3567 3568 When a Transform payload is received, the receiving entity (initiator 3569 or responder) MUST do the following: 3570 3571 1. Determine if the Transform is supported. If the Transform-ID 3572 field contains an unknown or unsupported value, then that 3573 Transform payload MUST be ignored and MUST NOT cause the 3574 generation of an INVALID TRANSFORM event. If the Transform-ID 3575 field is invalid, the payload is discarded and the following 3576 actions are taken: 3577 3578 (a) The event, INVALID TRANSFORM, MAY be logged in the 3579 appropriate system audit file. 3580 3581 (b) An Informational Exchange with a Notification payload 3582 containing the INVALID-TRANSFORM-ID message type MAY be sent 3583 3584 3585 3586Maughan, et. al. Standards Track [Page 64] 3587 3588RFC 2408 ISAKMP November 1998 3589 3590 3591 to the transmitting entity. This action is dictated by a 3592 system security policy. 3593 3594 2. Ensure the Transforms are presented according to the details 3595 given in section 3.6 and 4.2. If the transforms are not formed 3596 correctly, the following actions are taken: 3597 3598 (a) Possible events, BAD PROPOSAL SYNTAX, INVALID TRANSFORM, 3599 INVALID ATTRIBUTES, are logged in the appropriate system 3600 audit file. 3601 3602 (b) An Informational Exchange with a Notification payload 3603 containing the BAD-PROPOSAL-SYNTAX, PAYLOAD-MALFORMED or 3604 ATTRIBUTES-NOT-SUPPORTED message type MAY be sent to the 3605 transmitting entity. This action is dictated by a system 3606 security policy. 3607 3608 3. Process the subsequent Transform and Proposal payloads as defined 3609 by the Next Payload field. Examples of processing these payloads 3610 are given in section 4.2.1. 3611 36125.7 Key Exchange Payload Processing 3613 3614 When creating a Key Exchange Payload, the transmitting entity 3615 (initiator or responder) MUST do the following: 3616 3617 1. Determine the Key Exchange to be used as defined by the DOI. 3618 3619 2. Determine the usage of the Key Exchange Data field as defined by 3620 the DOI. 3621 3622 3. Construct a Key Exchange payload. 3623 3624 4. Transmit the message to the receiving entity as described in 3625 section 5.1. 3626 3627 When a Key Exchange payload is received, the receiving entity 3628 (initiator or responder) MUST do the following: 3629 3630 1. Determine if the Key Exchange is supported. If the Key Exchange 3631 determination fails, the message is discarded and the following 3632 actions are taken: 3633 3634 (a) The event, INVALID KEY INFORMATION, MAY be logged in the 3635 appropriate system audit file. 3636 3637 (b) An Informational Exchange with a Notification payload 3638 containing the INVALID-KEY-INFORMATION message type MAY be 3639 3640 3641 3642Maughan, et. al. Standards Track [Page 65] 3643 3644RFC 2408 ISAKMP November 1998 3645 3646 3647 sent to the transmitting entity. This action is dictated by 3648 a system security policy. 3649 36505.8 Identification Payload Processing 3651 3652 When creating an Identification Payload, the transmitting entity 3653 (initiator or responder) MUST do the following: 3654 3655 1. Determine the Identification information to be used as defined by 3656 the DOI (and possibly the situation). 3657 3658 2. Determine the usage of the Identification Data field as defined 3659 by the DOI. 3660 3661 3. Construct an Identification payload. 3662 3663 4. Transmit the message to the receiving entity as described in 3664 section 5.1. 3665 3666 When an Identification payload is received, the receiving entity 3667 (initiator or responder) MUST do the following: 3668 3669 1. Determine if the Identification Type is supported. This may be 3670 based on the DOI and Situation. If the Identification 3671 determination fails, the message is discarded and the following 3672 actions are taken: 3673 3674 (a) The event, INVALID ID INFORMATION, MAY be logged in the 3675 appropriate system audit file. 3676 3677 (b) An Informational Exchange with a Notification payload 3678 containing the INVALID-ID-INFORMATION message type MAY be 3679 sent to the transmitting entity. This action is dictated by 3680 a system security policy. 3681 36825.9 Certificate Payload Processing 3683 3684 When creating a Certificate Payload, the transmitting entity 3685 (initiator or responder) MUST do the following: 3686 3687 1. Determine the Certificate Encoding to be used. This may be 3688 specified by the DOI. 3689 3690 2. Ensure the existence of a certificate formatted as defined by the 3691 Certificate Encoding. 3692 3693 3. Construct a Certificate payload. 3694 3695 3696 3697 3698Maughan, et. al. Standards Track [Page 66] 3699 3700RFC 2408 ISAKMP November 1998 3701 3702 3703 4. Transmit the message to the receiving entity as described in 3704 section 5.1. 3705 3706 When a Certificate payload is received, the receiving entity 3707 (initiator or responder) MUST do the following: 3708 3709 1. Determine if the Certificate Encoding is supported. If the 3710 Certificate Encoding is not supported, the payload is discarded 3711 and the following actions are taken: 3712 3713 (a) The event, INVALID CERTIFICATE TYPE, MAY be logged in the 3714 appropriate system audit file. 3715 3716 (b) An Informational Exchange with a Notification payload 3717 containing the INVALID-CERT-ENCODING message type MAY be 3718 sent to the transmitting entity. This action is dictated by 3719 a system security policy. 3720 3721 2. Process the Certificate Data field. If the Certificate Data is 3722 invalid or improperly formatted, the payload is discarded and the 3723 following actions are taken: 3724 3725 (a) The event, INVALID CERTIFICATE, MAY be logged in the 3726 appropriate system audit file. 3727 3728 (b) An Informational Exchange with a Notification payload 3729 containing the INVALID-CERTIFICATE message type MAY be sent 3730 to the transmitting entity. This action is dictated by a 3731 system security policy. 3732 37335.10 Certificate Request Payload Processing 3734 3735 When creating a Certificate Request Payload, the transmitting entity 3736 (initiator or responder) MUST do the following: 3737 3738 1. Determine the type of Certificate Encoding to be requested. This 3739 may be specified by the DOI. 3740 3741 2. Determine the name of an acceptable Certificate Authority which 3742 is to be requested (if applicable). 3743 3744 3. Construct a Certificate Request payload. 3745 3746 4. Transmit the message to the receiving entity as described in 3747 section 5.1. 3748 3749 When a Certificate Request payload is received, the receiving entity 3750 (initiator or responder) MUST do the following: 3751 3752 3753 3754Maughan, et. al. Standards Track [Page 67] 3755 3756RFC 2408 ISAKMP November 1998 3757 3758 3759 1. Determine if the Certificate Encoding is supported. If the 3760 Certificate Encoding is invalid, the payload is discarded and the 3761 following actions are taken: 3762 3763 (a) The event, INVALID CERTIFICATE TYPE, MAY be logged in 3764 the appropriate system audit file. 3765 3766 (b) An Informational Exchange with a Notification payload 3767 containing the INVALID-CERT-ENCODING message type MAY be 3768 sent to the transmitting entity. This action is dictated by 3769 a system security policy. 3770 3771 If the Certificate Encoding is not supported, the payload is 3772 discarded and the following actions are taken: 3773 3774 (a) The event, CERTIFICATE TYPE UNSUPPORTED, MAY be logged in 3775 the appropriate system audit file. 3776 3777 (b) An Informational Exchange with a Notification payload 3778 containing the CERT-TYPE-UNSUPPORTED message type MAY be 3779 sent to the transmitting entity. This action is dictated by 3780 a system security policy. 3781 3782 2. Determine if the Certificate Authority is supported for the 3783 specified Certificate Encoding. If the Certificate Authority is 3784 invalid or improperly formatted, the payload is discarded and the 3785 following actions are taken: 3786 3787 (a) The event, INVALID CERTIFICATE AUTHORITY, MAY be logged in 3788 the appropriate system audit file. 3789 3790 (b) An Informational Exchange with a Notification payload 3791 containing the INVALID-CERT-AUTHORITY message type MAY be 3792 sent to the transmitting entity. This action is dictated by 3793 a system security policy. 3794 3795 3. Process the Certificate Request. If a requested Certificate Type 3796 with the specified Certificate Authority is not available, then 3797 the payload is discarded and the following actions are taken: 3798 3799 (a) The event, CERTIFICATE-UNAVAILABLE, MAY be logged in the 3800 appropriate system audit file. 3801 3802 (b) An Informational Exchange with a Notification payload 3803 containing the CERTIFICATE-UNAVAILABLE message type MAY be 3804 sent to the transmitting entity. This action is dictated by 3805 a system security policy. 3806 3807 3808 3809 3810Maughan, et. al. Standards Track [Page 68] 3811 3812RFC 2408 ISAKMP November 1998 3813 3814 38155.11 Hash Payload Processing 3816 3817 When creating a Hash Payload, the transmitting entity (initiator or 3818 responder) MUST do the following: 3819 3820 1. Determine the Hash function to be used as defined by the SA 3821 negotiation. 3822 3823 2. Determine the usage of the Hash Data field as defined by the DOI. 3824 3825 3. Construct a Hash payload. 3826 3827 4. Transmit the message to the receiving entity as described in 3828 section 5.1. 3829 3830 When a Hash payload is received, the receiving entity (initiator or 3831 responder) MUST do the following: 3832 3833 1. Determine if the Hash is supported. If the Hash determination 3834 fails, the message is discarded and the following actions are 3835 taken: 3836 3837 (a) The event, INVALID HASH INFORMATION, MAY be logged in the 3838 appropriate system audit file. 3839 3840 (b) An Informational Exchange with a Notification payload 3841 containing the INVALID-HASH-INFORMATION message type MAY be 3842 sent to the transmitting entity. This action is dictated by 3843 a system security policy. 3844 3845 2. Perform the Hash function as outlined in the DOI and/or Key 3846 Exchange protocol documents. If the Hash function fails, the 3847 message is discarded and the following actions are taken: 3848 3849 (a) The event, INVALID HASH VALUE, MAY be logged in the 3850 appropriate system audit file. 3851 3852 (b) An Informational Exchange with a Notification payload 3853 containing the AUTHENTICATION-FAILED message type MAY be 3854 sent to the transmitting entity. This action is dictated by 3855 a system security policy. 3856 38575.12 Signature Payload Processing 3858 3859 When creating a Signature Payload, the transmitting entity (initiator 3860 or responder) MUST do the following: 3861 3862 3863 3864 3865 3866Maughan, et. al. Standards Track [Page 69] 3867 3868RFC 2408 ISAKMP November 1998 3869 3870 3871 1. Determine the Signature function to be used as defined by the SA 3872 negotiation. 3873 3874 2. Determine the usage of the Signature Data field as defined by the 3875 DOI. 3876 3877 3. Construct a Signature payload. 3878 3879 4. Transmit the message to the receiving entity as described in 3880 section 5.1. 3881 3882 When a Signature payload is received, the receiving entity (initiator 3883 or responder) MUST do the following: 3884 3885 1. Determine if the Signature is supported. If the Signature 3886 determination fails, the message is discarded and the following 3887 actions are taken: 3888 3889 (a) The event, INVALID SIGNATURE INFORMATION, MAY be logged in 3890 the appropriate system audit file. 3891 3892 (b) An Informational Exchange with a Notification payload 3893 containing the INVALID-SIGNATURE message type MAY be sent to 3894 the transmitting entity. This action is dictated by a 3895 system security policy. 3896 3897 2. Perform the Signature function as outlined in the DOI and/or Key 3898 Exchange protocol documents. If the Signature function fails, 3899 the message is discarded and the following actions are taken: 3900 3901 (a) The event, INVALID SIGNATURE VALUE, MAY be logged in the 3902 appropriate system audit file. 3903 3904 (b) An Informational Exchange with a Notification payload 3905 containing the AUTHENTICATION-FAILED message type MAY be 3906 sent to the transmitting entity. This action is dictated by 3907 a system security policy. 3908 39095.13 Nonce Payload Processing 3910 3911 When creating a Nonce Payload, the transmitting entity (initiator or 3912 responder) MUST do the following: 3913 3914 1. Create a unique random value to be used as a nonce. 3915 3916 2. Construct a Nonce payload. 3917 3918 3919 3920 3921 3922Maughan, et. al. Standards Track [Page 70] 3923 3924RFC 2408 ISAKMP November 1998 3925 3926 3927 3. Transmit the message to the receiving entity as described in 3928 section 5.1. 3929 3930 When a Nonce payload is received, the receiving entity (initiator or 3931 responder) MUST do the following: 3932 3933 1. There are no specific procedures for handling Nonce payloads. 3934 The procedures are defined by the exchange types (and possibly 3935 the DOI and Key Exchange descriptions). 3936 39375.14 Notification Payload Processing 3938 3939 During communications it is possible that errors may occur. The 3940 Informational Exchange with a Notify Payload provides a controlled 3941 method of informing a peer entity that errors have occurred during 3942 protocol processing. It is RECOMMENDED that Notify Payloads be sent 3943 in a separate Informational Exchange rather than appending a Notify 3944 Payload to an existing exchange. 3945 3946 When creating a Notification Payload, the transmitting entity 3947 (initiator or responder) MUST do the following: 3948 3949 1. Determine the DOI for this Notification. 3950 3951 2. Determine the Protocol-ID for this Notification. 3952 3953 3. Determine the SPI size based on the Protocol-ID field. This 3954 field is necessary because different security protocols have 3955 different SPI sizes. For example, ISAKMP combines the Initiator 3956 and Responder cookie pair (16 octets) as a SPI, while ESP and AH 3957 have 4 octet SPIs. 3958 3959 4. Determine the Notify Message Type based on the error or status 3960 message desired. 3961 3962 5. Determine the SPI which is associated with this notification. 3963 3964 6. Determine if additional Notification Data is to be included. 3965 This is additional information specified by the DOI. 3966 3967 7. Construct a Notification payload. 3968 3969 8. Transmit the message to the receiving entity as described in 3970 section 5.1. 3971 3972 Because the Informational Exchange with a Notification payload is a 3973 unidirectional message a retransmission will not be performed. The 3974 local security policy will dictate the procedures for continuing. 3975 3976 3977 3978Maughan, et. al. Standards Track [Page 71] 3979 3980RFC 2408 ISAKMP November 1998 3981 3982 3983 However, we RECOMMEND that a NOTIFICATION PAYLOAD ERROR event be 3984 logged in the appropriate system audit file by the receiving entity. 3985 3986 If the Informational Exchange occurs prior to the exchange of keying 3987 material during an ISAKMP Phase 1 negotiation there will be no 3988 protection provided for the Informational Exchange. Once the keying 3989 material has been exchanged or the ISAKMP SA has been established, 3990 the Informational Exchange MUST be transmitted under the protection 3991 provided by the keying material or the ISAKMP SA. 3992 3993 When a Notification payload is received, the receiving entity 3994 (initiator or responder) MUST do the following: 3995 3996 1. Determine if the Informational Exchange has any protection 3997 applied to it by checking the Encryption Bit and the 3998 Authentication Only Bit in the ISAKMP Header. If the Encryption 3999 Bit is set, i.e. the Informational Exchange is encrypted, then 4000 the message MUST be decrypted using the (in-progress or 4001 completed) ISAKMP SA. Once the decryption is complete the 4002 processing can continue as described below. If the 4003 Authentication Only Bit is set, then the message MUST be 4004 authenticated using the (in-progress or completed) ISAKMP SA. 4005 Once the authentication is completed, the processing can continue 4006 as described below. If the Informational Exchange is not 4007 encrypted or authentication, the payload processing can continue 4008 as described below. 4009 4010 2. Determine if the Domain of Interpretation (DOI) is supported. If 4011 the DOI determination fails, the payload is discarded and the 4012 following action is taken: 4013 4014 (a) The event, INVALID DOI, MAY be logged in the appropriate 4015 system audit file. 4016 4017 3. Determine if the Protocol-Id is supported. If the Protocol-Id 4018 determination fails, the payload is discarded and the following 4019 action is taken: 4020 4021 (a) The event, INVALID PROTOCOL-ID, MAY be logged in the 4022 appropriate system audit file. 4023 4024 4. Determine if the SPI is valid. If the SPI is invalid, the 4025 payload is discarded and the following action is taken: 4026 4027 (a) The event, INVALID SPI, MAY be logged in the appropriate 4028 system audit file. 4029 4030 4031 4032 4033 4034Maughan, et. al. Standards Track [Page 72] 4035 4036RFC 2408 ISAKMP November 1998 4037 4038 4039 5. Determine if the Notify Message Type is valid. If the Notify 4040 Message Type is invalid, the payload is discarded and the 4041 following action is taken: 4042 4043 (a) The event, INVALID MESSAGE TYPE, MAY be logged in the 4044 appropriate system audit file. 4045 4046 6. Process the Notification payload, including additional 4047 Notification Data, and take appropriate action, according to 4048 local security policy. 4049 40505.15 Delete Payload Processing 4051 4052 During communications it is possible that hosts may be compromised or 4053 that information may be intercepted during transmission. Determining 4054 whether this has occurred is not an easy task and is outside the 4055 scope of this memo. However, if it is discovered that transmissions 4056 are being compromised, then it is necessary to establish a new SA and 4057 delete the current SA. 4058 4059 The Informational Exchange with a Delete Payload provides a 4060 controlled method of informing a peer entity that the transmitting 4061 entity has deleted the SA(s). Deletion of Security Associations MUST 4062 always be performed under the protection of an ISAKMP SA. The 4063 receiving entity SHOULD clean up its local SA database. However, 4064 upon receipt of a Delete message the SAs listed in the Security 4065 Parameter Index (SPI) field of the Delete payload cannot be used with 4066 the transmitting entity. The SA Establishment procedure must be 4067 invoked to re-establish secure communications. 4068 4069 When creating a Delete Payload, the transmitting entity (initiator or 4070 responder) MUST do the following: 4071 4072 1. Determine the DOI for this Deletion. 4073 4074 2. Determine the Protocol-ID for this Deletion. 4075 4076 3. Determine the SPI size based on the Protocol-ID field. This 4077 field is necessary because different security protocols have 4078 different SPI sizes. For example, ISAKMP combines the Initiator 4079 and Responder cookie pair (16 octets) as a SPI, while ESP and AH 4080 have 4 octet SPIs. 4081 4082 4. Determine the # of SPIs to be deleted for this protocol. 4083 4084 5. Determine the SPI(s) which is (are) associated with this 4085 deletion. 4086 4087 4088 4089 4090Maughan, et. al. Standards Track [Page 73] 4091 4092RFC 2408 ISAKMP November 1998 4093 4094 4095 6. Construct a Delete payload. 4096 4097 7. Transmit the message to the receiving entity as described in 4098 section 5.1. 4099 4100 Because the Informational Exchange with a Delete payload is a 4101 unidirectional message a retransmission will not be performed. The 4102 local security policy will dictate the procedures for continuing. 4103 However, we RECOMMEND that a DELETE PAYLOAD ERROR event be logged in 4104 the appropriate system audit file by the receiving entity. 4105 4106 As described above, the Informational Exchange with a Delete payload 4107 MUST be transmitted under the protection provided by an ISAKMP SA. 4108 4109 When a Delete payload is received, the receiving entity (initiator or 4110 responder) MUST do the following: 4111 4112 1. Because the Informational Exchange is protected by some security 4113 service (e.g. authentication for an Auth-Only SA, encryption for 4114 other exchanges), the message MUST have these security services 4115 applied using the ISAKMP SA. Once the security service processing 4116 is complete the processing can continue as described below. Any 4117 errors that occur during the security service processing will be 4118 evident when checking information in the Delete payload. The 4119 local security policy SHOULD dictate any action to be taken as a 4120 result of security service processing errors. 4121 4122 2. Determine if the Domain of Interpretation (DOI) is supported. If 4123 the DOI determination fails, the payload is discarded and the 4124 following action is taken: 4125 4126 (a) The event, INVALID DOI, MAY be logged in the appropriate 4127 system audit file. 4128 4129 3. Determine if the Protocol-Id is supported. If the Protocol-Id 4130 determination fails, the payload is discarded and the following 4131 action is taken: 4132 4133 (a) The event, INVALID PROTOCOL-ID, MAY be logged in the 4134 appropriate system audit file. 4135 4136 4. Determine if the SPI is valid for each SPI included in the Delete 4137 payload. For each SPI that is invalid, the following action is 4138 taken: 4139 4140 (a) The event, INVALID SPI, MAY be logged in the appropriate 4141 system audit file. 4142 4143 4144 4145 4146Maughan, et. al. Standards Track [Page 74] 4147 4148RFC 2408 ISAKMP November 1998 4149 4150 4151 5. Process the Delete payload and take appropriate action, according 4152 to local security policy. As described above, one appropriate 4153 action SHOULD include cleaning up the local SA database. 4154 41556 Conclusions 4156 4157 The Internet Security Association and Key Management Protocol 4158 (ISAKMP) is a well designed protocol aimed at the Internet of the 4159 future. The massive growth of the Internet will lead to great 4160 diversity in network utilization, communications, security 4161 requirements, and security mechanisms. ISAKMP contains all the 4162 features that will be needed for this dynamic and expanding 4163 communications environment. 4164 4165 ISAKMP's Security Association (SA) feature coupled with 4166 authentication and key establishment provides the security and 4167 flexibility that will be needed for future growth and diversity. 4168 This security diversity of multiple key exchange techniques, 4169 encryption algorithms, authentication mechanisms, security services, 4170 and security attributes will allow users to select the appropriate 4171 security for their network, communications, and security needs. The 4172 SA feature allows users to specify and negotiate security 4173 requirements with other users. An additional benefit of supporting 4174 multiple techniques in a single protocol is that as new techniques 4175 are developed they can easily be added to the protocol. This 4176 provides a path for the growth of Internet security services. ISAKMP 4177 supports both publicly or privately defined SAs, making it ideal for 4178 government, commercial, and private communications. 4179 4180 ISAKMP provides the ability to establish SAs for multiple security 4181 protocols and applications. These protocols and applications may be 4182 session-oriented or sessionless. Having one SA establishment 4183 protocol that supports multiple security protocols eliminates the 4184 need for multiple, nearly identical authentication, key exchange and 4185 SA establishment protocols when more than one security protocol is in 4186 use or desired. Just as IP has provided the common networking layer 4187 for the Internet, a common security establishment protocol is needed 4188 if security is to become a reality on the Internet. ISAKMP provides 4189 the common base that allows all other security protocols to 4190 interoperate. 4191 4192 ISAKMP follows good security design principles. It is not coupled to 4193 other insecure transport protocols, therefore it is not vulnerable or 4194 weakened by attacks on other protocols. Also, when more secure 4195 transport protocols are developed, ISAKMP can be easily migrated to 4196 them. ISAKMP also provides protection against protocol related 4197 attacks. This protection provides the assurance that the SAs and 4198 keys established are with the desired party and not with an attacker. 4199 4200 4201 4202Maughan, et. al. Standards Track [Page 75] 4203 4204RFC 2408 ISAKMP November 1998 4205 4206 4207 ISAKMP also follows good protocol design principles. Protocol 4208 specific information only is in the protocol header, following the 4209 design principles of IPv6. The data transported by the protocol is 4210 separated into functional payloads. As the Internet grows and 4211 evolves, new payloads to support new security functionality can be 4212 added without modifying the entire protocol. 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258Maughan, et. al. Standards Track [Page 76] 4259 4260RFC 2408 ISAKMP November 1998 4261 4262 4263A ISAKMP Security Association Attributes 4264 4265A.1 Background/Rationale 4266 4267 As detailed in previous sections, ISAKMP is designed to provide a 4268 flexible and extensible framework for establishing and managing 4269 Security Associations and cryptographic keys. The framework provided 4270 by ISAKMP consists of header and payload definitions, exchange types 4271 for guiding message and payload exchanges, and general processing 4272 guidelines. ISAKMP does not define the mechanisms that will be used 4273 to establish and manage Security Associations and cryptographic keys 4274 in an authenticated and confidential manner. The definition of 4275 mechanisms and their application is the purview of individual Domains 4276 of Interpretation (DOIs). 4277 4278 This section describes the ISAKMP values for the Internet IP Security 4279 DOI, supported security protocols, and identification values for 4280 ISAKMP Phase 1 negotiations. The Internet IP Security DOI is 4281 MANDATORY to implement for IP Security. [Oakley] and [IKE] describe, 4282 in detail, the mechanisms and their application for establishing and 4283 managing Security Associations and cryptographic keys for IP 4284 Security. 4285 4286A.2 Internet IP Security DOI Assigned Value 4287 4288 As described in [IPDOI], the Internet IP Security DOI Assigned Number 4289 is one (1). 4290 4291A.3 Supported Security Protocols 4292 4293 Values for supported security protocols are specified in the most 4294 recent "Assigned Numbers" RFC [STD-2]. Presented in the following 4295 table are the values for the security protocols supported by ISAKMP 4296 for the Internet IP Security DOI. 4297 4298 4299 Protocol Assigned Value 4300 RESERVED 0 4301 ISAKMP 1 4302 4303 All DOIs MUST reserve ISAKMP with a Protocol-ID of 1. All other 4304 security protocols within that DOI will be numbered accordingly. 4305 4306 Security protocol values 2-15359 are reserved to IANA for future use. 4307 Values 15360-16383 are permanently reserved for private use amongst 4308 mutually consenting implementations. Such private use values are 4309 unlikely to be interoperable across different implementations. 4310 4311 4312 4313 4314Maughan, et. al. Standards Track [Page 77] 4315 4316RFC 2408 ISAKMP November 1998 4317 4318 4319A.4 ISAKMP Identification Type Values 4320 4321 The following table lists the assigned values for the Identification 4322 Type field found in the Identification payload during a generic Phase 4323 1 exchange, which is not for a specific protocol. 4324 4325 4326 ID Type Value 4327 ID_IPV4_ADDR 0 4328 ID_IPV4_ADDR_SUBNET 1 4329 ID_IPV6_ADDR 2 4330 ID_IPV6_ADDR_SUBNET 3 4331 4332A.4.1 ID_IPV4_ADDR 4333 4334 The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. 4335 4336A.4.2 ID_IPV4_ADDR_SUBNET 4337 4338 The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, 4339 represented by two four (4) octet values. The first value is an IPv4 4340 address. The second is an IPv4 network mask. Note that ones (1s) in 4341 the network mask indicate that the corresponding bit in the address 4342 is fixed, while zeros (0s) indicate a "wildcard" bit. 4343 4344A.4.3 ID_IPV6_ADDR 4345 4346 The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 4347 address. 4348 4349A.4.4 ID_IPV6_ADDR_SUBNET 4350 4351 The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, 4352 represented by two sixteen (16) octet values. The first value is an 4353 IPv6 address. The second is an IPv6 network mask. Note that ones 4354 (1s) in the network mask indicate that the corresponding bit in the 4355 address is fixed, while zeros (0s) indicate a "wildcard" bit. 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370Maughan, et. al. Standards Track [Page 78] 4371 4372RFC 2408 ISAKMP November 1998 4373 4374 4375B Defining a new Domain of Interpretation 4376 4377 The Internet DOI may be sufficient to meet the security requirements 4378 of a large portion of the internet community. However, some groups 4379 may have a need to customize some aspect of a DOI, perhaps to add a 4380 different set of cryptographic algorithms, or perhaps because they 4381 want to make their security-relevant decisions based on something 4382 other than a host id or user id. Also, a particular group may have a 4383 need for a new exchange type, for example to support key management 4384 for multicast groups. 4385 4386 This section discusses guidelines for defining a new DOI. The full 4387 specification for the Internet DOI can be found in [IPDOI]. 4388 4389 Defining a new DOI is likely to be a time-consuming process. If at 4390 all possible, it is recommended that the designer begin with an 4391 existing DOI and customize only the parts that are unacceptable. 4392 4393 If a designer chooses to start from scratch, the following MUST be 4394 defined: 4395 4396 o A "situation": the set of information that will be used to 4397 determine the required security services. 4398 4399 o The set of security policies that must be supported. 4400 4401 o A scheme for naming security-relevant information, including 4402 encryption algorithms, key exchange algorithms, etc. 4403 4404 o A syntax for the specification of proposed security services, 4405 attributes, and certificate authorities. 4406 4407 o The specific formats of the various payload contents. 4408 4409 o Additional exchange types, if required. 4410 4411B.1 Situation 4412 4413 The situation is the basis for deciding how to protect a 4414 communications channel. It must contain all of the data that will be 4415 used to determine the types and strengths of protections applied in 4416 an SA. For example, a US Department of Defense DOI would probably use 4417 unpublished algorithms and have additional special attributes to 4418 negotiate. These additional security attributes would be included in 4419 the situation. 4420 4421 4422 4423 4424 4425 4426Maughan, et. al. Standards Track [Page 79] 4427 4428RFC 2408 ISAKMP November 1998 4429 4430 4431B.2 Security Policies 4432 4433 Security policies define how various types of information must be 4434 categorized and protected. The DOI must define the set of security 4435 policies supported, because both parties in a negotiation must trust 4436 that the other party understands a situation, and will protect 4437 information appropriately, both in transit and in storage. In a 4438 corporate setting, for example, both parties in a negotiation must 4439 agree to the meaning of the term "proprietary information" before 4440 they can negotiate how to protect it. 4441 4442 Note that including the required security policies in the DOI only 4443 specifies that the participating hosts understand and implement those 4444 policies in a full system context. 4445 4446B.3 Naming Schemes 4447 4448 Any DOI must define a consistent way to name cryptographic 4449 algorithms, certificate authorities, etc. This can usually be done 4450 by using IANA naming conventions, perhaps with some private 4451 extensions. 4452 4453B.4 Syntax for Specifying Security Services 4454 4455 In addition to simply specifying how to name entities, the DOI must 4456 also specify the format for complete proposals of how to protect 4457 traffic under a given situation. 4458 4459B.5 Payload Specification 4460 4461 The DOI must specify the format of each of the payload types. For 4462 several of the payload types, ISAKMP has included fields that would 4463 have to be present across all DOI (such as a certificate authority in 4464 the certificate payload, or a key exchange identifier in the key 4465 exchange payload). 4466 4467B.6 Defining new Exchange Types 4468 4469 If the basic exchange types are inadequate to meet the requirements 4470 within a DOI, a designer can define up to thirteen extra exchange 4471 types per DOI. The designer creates a new exchange type by choosing 4472 an unused exchange type value, and defining a sequence of messages 4473 composed of strings of the ISAKMP payload types. 4474 4475 Note that any new exchange types must be rigorously analyzed for 4476 vulnerabilities. Since this is an expensive and imprecise 4477 undertaking, a new exchange type should only be created when 4478 absolutely necessary. 4479 4480 4481 4482Maughan, et. al. Standards Track [Page 80] 4483 4484RFC 2408 ISAKMP November 1998 4485 4486 4487Security Considerations 4488 4489 Cryptographic analysis techniques are improving at a steady pace. 4490 The continuing improvement in processing power makes once 4491 computationally prohibitive cryptographic attacks more realistic. 4492 New cryptographic algorithms and public key generation techniques are 4493 also being developed at a steady pace. New security services and 4494 mechanisms are being developed at an accelerated pace. A consistent 4495 method of choosing from a variety of security services and mechanisms 4496 and to exchange attributes required by the mechanisms is important to 4497 security in the complex structure of the Internet. However, a system 4498 that locks itself into a single cryptographic algorithm, key exchange 4499 technique, or security mechanism will become increasingly vulnerable 4500 as time passes. 4501 4502 UDP is an unreliable datagram protocol and therefore its use in 4503 ISAKMP introduces a number of security considerations. Since UDP is 4504 unreliable, but a key management protocol must be reliable, the 4505 reliability is built into ISAKMP. While ISAKMP utilizes UDP as its 4506 transport mechanism, it doesn't rely on any UDP information (e.g. 4507 checksum, length) for its processing. 4508 4509 Another issue that must be considered in the development of ISAKMP is 4510 the effect of firewalls on the protocol. Many firewalls filter out 4511 all UDP packets, making reliance on UDP questionable in certain 4512 environments. 4513 4514 A number of very important security considerations are presented in 4515 [SEC-ARCH]. One bears repeating. Once a private session key is 4516 created, it must be safely stored. Failure to properly protect the 4517 private key from access both internal and external to the system 4518 completely nullifies any protection provided by the IP Security 4519 services. 4520 4521IANA Considerations 4522 4523 This document contains many "magic" numbers to be maintained by the 4524 IANA. This section explains the criteria to be used by the IANA to 4525 assign additional numbers in each of these lists. 4526 4527Domain of Interpretation 4528 4529 The Domain of Interpretation (DOI) is a 32-bit field which identifies 4530 the domain under which the security association negotiation is taking 4531 place. Requests for assignments of new DOIs must be accompanied by a 4532 standards-track RFC which describes the specific domain. 4533 4534 4535 4536 4537 4538Maughan, et. al. Standards Track [Page 81] 4539 4540RFC 2408 ISAKMP November 1998 4541 4542 4543Supported Security Protocols 4544 4545 ISAKMP is designed to provide security association negotiation and 4546 key management for many security protocols. Requests for identifiers 4547 for additional security protocols must be accompanied by a 4548 standards-track RFC which describes the security protocol and its 4549 relationship to ISAKMP. 4550 4551Acknowledgements 4552 4553 Dan Harkins, Dave Carrel, and Derrell Piper of Cisco Systems provided 4554 design assistance with the protocol and coordination for the [IKE] 4555 and [IPDOI] documents. 4556 4557 Hilarie Orman, via the Oakley key exchange protocol, has 4558 significantly influenced the design of ISAKMP. 4559 4560 Marsha Gross, Bill Kutz, Mike Oehler, Pete Sell, and Ruth Taylor 4561 provided significant input and review to this document. 4562 4563 Scott Carlson ported the TIS DNSSEC prototype to FreeBSD for use with 4564 the ISAKMP prototype. 4565 4566 Jeff Turner and Steve Smalley contributed to the prototype 4567 development and integration with ESP and AH. 4568 4569 Mike Oehler and Pete Sell performed interoperability testing with 4570 other ISAKMP implementors. 4571 4572 Thanks to Carl Muckenhirn of SPARTA, Inc. for his assistance with 4573 LaTeX. 4574 4575References 4576 4577 [ANSI] ANSI, X9.42: Public Key Cryptography for the Financial 4578 Services Industry -- Establishment of Symmetric Algorithm 4579 Keys Using Diffie-Hellman, Working Draft, April 19, 1996. 4580 4581 [BC] Ballardie, A., and J. Crowcroft, Multicast-specific 4582 Security Threats and Countermeasures, Proceedings of 1995 4583 ISOC Symposium on Networks & Distributed Systems Security, 4584 pp. 17-30, Internet Society, San Diego, CA, February 1995. 4585 4586 [Berge] Berge, N., "UNINETT PCA Policy Statements", RFC 1875, 4587 December 1995. 4588 4589 4590 4591 4592 4593 4594Maughan, et. al. Standards Track [Page 82] 4595 4596RFC 2408 ISAKMP November 1998 4597 4598 4599 [CW87] Clark, D.D. and D.R. Wilson, A Comparison of Commercial 4600 and Military Computer Security Policies, Proceedings of 4601 the IEEE Symposium on Security & Privacy, Oakland, CA, 4602 1987, pp. 184-193. 4603 4604 [DNSSEC] D. Eastlake III, Domain Name System Protocol Security 4605 Extensions, Work in Progress. 4606 4607 [DOW92] Diffie, W., M.Wiener, P. Van Oorschot, Authentication and 4608 Authenticated Key Exchanges, Designs, Codes, and 4609 Cryptography, 2, 107-125, Kluwer Academic Publishers, 4610 1992. 4611 4612 [IAB] Bellovin, S., "Report of the IAB Security Architecture 4613 Workshop", RFC 2316, April 1998. 4614 4615 [IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange 4616 (IKE)", RFC 2409, November 1998. 4617 4618 [IPDOI] Piper, D., "The Internet IP Security Domain of 4619 Interpretation for ISAKMP", RFC 2407, November 1998. 4620 4621 [Karn] Karn, P., and B. Simpson, Photuris: Session Key 4622 Management Protocol, Work in Progress. 4623 4624 [Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August 4625 10, 1994. 4626 4627 [Oakley] Orman, H., "The Oakley Key Determination Protocol", RFC 4628 2412, November 1998. 4629 4630 [RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic 4631 Mail: Part II: Certificate-Based Key Management", RFC 4632 1422, February 1993. 4633 4634 [RFC-1949] Ballardie, A., "Scalable Multicast Key Distribution", RFC 4635 1949, May 1996. 4636 4637 [RFC-2093] Harney, H., and C. Muckenhirn, "Group Key Management 4638 Protocol (GKMP) Specification", RFC 2093, July 1997. 4639 4640 [RFC-2094] Harney, H., and C. Muckenhirn, "Group Key Management 4641 Protocol (GKMP) Architecture", RFC 2094, July 1997. 4642 4643 [RFC-2119] Bradner, S., "Key Words for use in RFCs to Indicate 4644 Requirement Levels", BCP 14, RFC 2119, March 1997. 4645 4646 4647 4648 4649 4650Maughan, et. al. Standards Track [Page 83] 4651 4652RFC 2408 ISAKMP November 1998 4653 4654 4655 [Schneier] Bruce Schneier, Applied Cryptography - Protocols, 4656 Algorithms, and Source Code in C (Second Edition), John 4657 Wiley & Sons, Inc., 1996. 4658 4659 [SEC-ARCH] Atkinson, R., and S. Kent, "Security Architecture for the 4660 Internet Protocol", RFC 2401, November 1998. 4661 4662 [STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 4663 1700, October 1994. See also: 4664 http://www.iana.org/numbers.html 4665 4666 4667 4668 4669 4670 4671 4672 4673 4674 4675 4676 4677 4678 4679 4680 4681 4682 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706Maughan, et. al. Standards Track [Page 84] 4707 4708RFC 2408 ISAKMP November 1998 4709 4710 4711Authors' Addresses 4712 4713 Douglas Maughan 4714 National Security Agency 4715 ATTN: R23 4716 9800 Savage Road 4717 Ft. Meade, MD. 20755-6000 4718 4719 Phone: 301-688-0847 4720 EMail:wdm@tycho.ncsc.mil 4721 4722 4723 Mark Schneider 4724 National Security Agency 4725 ATTN: R23 4726 9800 Savage Road 4727 Ft. Meade, MD. 20755-6000 4728 4729 Phone: 301-688-0851 4730 EMail:mss@tycho.ncsc.mil 4731 4732 4733 Mark Schertler 4734 Securify, Inc. 4735 2415-B Charleston Road 4736 Mountain View, CA 94043 4737 4738 Phone: 650-934-9303 4739 EMail:mjs@securify.com 4740 4741 4742 Jeff Turner 4743 RABA Technologies, Inc. 4744 10500 Little Patuxent Parkway 4745 Columbia, MD. 21044 4746 4747 Phone: 410-715-9399 4748 EMail:jeff.turner@raba.com 4749 4750 4751 4752 4753 4754 4755 4756 4757 4758 4759 4760 4761 4762Maughan, et. al. Standards Track [Page 85] 4763 4764RFC 2408 ISAKMP November 1998 4765 4766 4767Full Copyright Statement 4768 4769 Copyright (C) The Internet Society (1998). All Rights Reserved. 4770 4771 This document and translations of it may be copied and furnished to 4772 others, and derivative works that comment on or otherwise explain it 4773 or assist in its implementation may be prepared, copied, published 4774 and distributed, in whole or in part, without restriction of any 4775 kind, provided that the above copyright notice and this paragraph are 4776 included on all such copies and derivative works. However, this 4777 document itself may not be modified in any way, such as by removing 4778 the copyright notice or references to the Internet Society or other 4779 Internet organizations, except as needed for the purpose of 4780 developing Internet standards in which case the procedures for 4781 copyrights defined in the Internet Standards process must be 4782 followed, or as required to translate it into languages other than 4783 English. 4784 4785 The limited permissions granted above are perpetual and will not be 4786 revoked by the Internet Society or its successors or assigns. 4787 4788 This document and the information contained herein is provided on an 4789 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4790 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4791 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4792 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4793 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4794 4795 4796 4797 4798 4799 4800 4801 4802 4803 4804 4805 4806 4807 4808 4809 4810 4811 4812 4813 4814 4815 4816 4817 4818Maughan, et. al. Standards Track [Page 86] 4819 4820