idnits 2.17.1 draft-ietf-ipsec-isakmp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-ipsec-isakmp-08.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-ipsec-isakmp-08.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-ipsec-isakmp-08.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-ipsec-isakmp-08.txt,', but the file name used is 'draft-ietf-ipsec-isakmp-08' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 791 instances of too long lines in the document, the longest one being 22 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 227: '... - MUST...' RFC 2119 keyword, line 232: '... - MUST NOT...' RFC 2119 keyword, line 237: '... - SHOULD...' RFC 2119 keyword, line 245: '... - MAY...' RFC 2119 keyword, line 256: '...to-implement, or MUST, items MUST be f...' (137 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 26, 1997) is 9771 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'CW87' is defined on line 3389, but no explicit reference was found in the text == Unused Reference: 'Kent94' is defined on line 3408, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ANSI' ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) -- Possible downref: Non-RFC (?) normative reference: ref. 'BC' ** Downref: Normative reference to an Experimental RFC: RFC 1949 -- Possible downref: Non-RFC (?) normative reference: ref. 'Berge' -- Possible downref: Non-RFC (?) normative reference: ref. 'CW87' -- Possible downref: Non-RFC (?) normative reference: ref. 'DOW92' == Outdated reference: A later version (-07) exists of draft-ietf-dnssec-secext2-00 == Outdated reference: A later version (-18) exists of draft-simpson-photuris-15 ** Downref: Normative reference to an Experimental draft: draft-simpson-photuris (ref. 'Karn') ** Downref: Normative reference to an Historic RFC: RFC 1422 -- Possible downref: Non-RFC (?) normative reference: ref. 'Kent94' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-oakley is -01, but you're referring to -02. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-oakley (ref. 'Oakley') == Outdated reference: A later version (-07) exists of draft-ietf-ipsec-isakmp-oakley-04 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'IO-Res') == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-ipsec-doi-03 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-ipsec-doi (ref. 'IPDOI') -- Possible downref: Non-RFC (?) normative reference: ref. 'STD-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' ** Downref: Normative reference to an Experimental RFC: RFC 2094 ** Downref: Normative reference to an Experimental RFC: RFC 2093 Summary: 22 errors (**), 1 flaw (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSEC Working Group Douglas Maughan, Mark Schertler 3 INTERNET-DRAFT Mark Schneider, Jeff Turner 4 draft-ietf-ipsec-isakmp-08.txt, .ps July 26, 1997 6 Internet Security Association and Key Management Protocol (ISAKMP) 8 Abstract 10 This memo describes a protocol utilizing security concepts 11 necessary for establishing Security Associations (SA) and crypto- 12 graphic keys in an Internet environment. A Security Association 13 protocol that negotiates, establishes, modifies and deletes 14 Security Associations and their attributes is required for an 15 evolving Internet, where there will be numerous security mecha- 16 nisms and several options for each security mechanism. The key 17 management protocol must be robust in order to handle public key 18 generation for the Internet community at large and private key 19 requirements for those private networks with that requirement. 20 The Internet Security Association and Key Management Protocol 21 (ISAKMP) defines the procedures for authenticating a communicat- 22 ing peer, creation and management of Security Associations, key 23 generation techniques, and threat mitigation (e.g. denial of 24 service and replay attacks). All of these are necessary to es- 25 tablish and maintain secure communications (via IP Security Ser- 26 vice or any other security protocol) in an Internet environment. 28 Status of this memo 30 This document is being submitted to the IETF Internet Protocol Security 31 (IPSEC) Working Group for consideration as a method for the establishment 32 and management of security associations and their appropriate security at- 33 tributes. Additionally, this document proposes a method for key manage- 34 ment to support IPSEC and IPv6. It is intended that a future version of 35 this draft be submitted to the IESG for publication as a Draft Standard 36 RFC. Comments are solicited and should be addressed to the authors and/or 37 the IPSEC working group mailing list at ipsec@tis.com. 39 This document is an Internet Draft. Internet Drafts are working documents 40 of the Internet Engineering Task Force (IETF), its Areas, and its Working 41 Groups. Note that other groups may also distribute working documents as 42 Internet Drafts. 44 Internet Drafts are draft documents valid for a maximum of six months. 45 Internet Drafts may be updated, replaced, or obsoleted by other documents 46 at any time. It is not appropriate to use Internet Drafts as reference 47 material or to cite them other than as ``working draft'' or ``work in 48 progress.'' 50 To learn the current status of any Internet-Draft, please check the ``1id- 51 abstracts.txt'' listing contained in the Internet- Drafts Shadow Di- 52 rectories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 53 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 55 Distribution of this document is unlimited. 57 Contents 59 1 Introduction 6 60 1.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . . 7 61 1.2 The Need for Negotiation . . . . . . . . . . . . . . . . . . . . 8 62 1.3 What can be Negotiated? . . . . . . . . . . . . . . . . . . . . . 8 63 1.4 Security Associations and Management . . . . . . . . . . . . . . 9 64 1.4.1Security Associations and Registration . . . . . . . . . . . . 9 65 1.4.2ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 10 66 1.5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 1.5.1Certificate Authorities . . . . . . . . . . . . . . . . . . . 11 68 1.5.2Entity Naming . . . . . . . . . . . . . . . . . . . . . . . . 11 69 1.5.3ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 11 70 1.6 Public Key Cryptography . . . . . . . . . . . . . . . . . . . . . 12 71 1.6.1Key Exchange Properties . . . . . . . . . . . . . . . . . . . 13 72 1.6.2ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 14 73 1.7 ISAKMP Protection . . . . . . . . . . . . . . . . . . . . . . . . 14 74 1.7.1Anti-Clogging (Denial of Service) . . . . . . . . . . . . . . 14 75 1.7.2Connection Hijacking . . . . . . . . . . . . . . . . . . . . . 14 76 1.7.3Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . 15 77 1.8 Multicast Communications . . . . . . . . . . . . . . . . . . . . 15 79 2 Terminology and Concepts 15 80 2.1 ISAKMP Terminology . . . . . . . . . . . . . . . . . . . . . . . 15 81 2.2 ISAKMP Placement . . . . . . . . . . . . . . . . . . . . . . . . 17 82 2.3 Negotiation Phases . . . . . . . . . . . . . . . . . . . . . . . 18 83 2.4 Identifying Security Associations . . . . . . . . . . . . . . . . 19 84 2.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 2.5.1Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 21 86 2.5.2RESERVED Fields . . . . . . . . . . . . . . . . . . . . . . . 21 87 2.5.3Anti-Clogging Token (``Cookie'') Creation . . . . . . . . . . 22 88 3 ISAKMP Payloads 22 89 3.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 23 90 3.2 Payload Generic Header . . . . . . . . . . . . . . . . . . . . . 26 91 3.3 Data Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 27 92 3.4 Security Association Payload . . . . . . . . . . . . . . . . . . 28 93 3.5 Proposal Payload . . . . . . . . . . . . . . . . . . . . . . . . 29 94 3.6 Transform Payload . . . . . . . . . . . . . . . . . . . . . . . . 30 95 3.7 Key Exchange Payload . . . . . . . . . . . . . . . . . . . . . . 31 96 3.8 Identification Payload . . . . . . . . . . . . . . . . . . . . . 32 97 3.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . 33 98 3.10Certificate Request Payload . . . . . . . . . . . . . . . . . . . 35 99 3.11Hash Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 36 100 3.12Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . 37 101 3.13Nonce Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 38 102 3.14Notification Payload . . . . . . . . . . . . . . . . . . . . . . 38 103 3.14.1Notify Message Types . . . . . . . . . . . . . . . . . . . . . 40 104 3.15Delete Payload . . . . . . . . . . . . . . . . . . . . . . . . . 41 106 4 ISAKMP Exchanges 43 107 4.1 Security Association Establishment . . . . . . . . . . . . . . . 43 108 4.1.1Security Association Establishment Examples . . . . . . . . . 45 109 4.2 Security Association Modification . . . . . . . . . . . . . . . . 47 110 4.3 ISAKMP Exchange Types . . . . . . . . . . . . . . . . . . . . . . 48 111 4.3.1Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 112 4.4 Base Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . 49 113 4.5 Identity Protection Exchange . . . . . . . . . . . . . . . . . . 50 114 4.6 Authentication Only Exchange . . . . . . . . . . . . . . . . . . 51 115 4.7 Aggressive Exchange . . . . . . . . . . . . . . . . . . . . . . . 53 116 4.8 Informational Exchange . . . . . . . . . . . . . . . . . . . . . 54 118 5 ISAKMP Payload Processing 54 119 5.1 General Message Processing . . . . . . . . . . . . . . . . . . . 55 120 5.2 ISAKMP Header Processing . . . . . . . . . . . . . . . . . . . . 55 121 5.3 Generic Payload Header Processing . . . . . . . . . . . . . . . . 57 122 5.4 Security Association Payload Processing . . . . . . . . . . . . . 58 123 5.4.1Proposal Payload Processing . . . . . . . . . . . . . . . . . 60 124 5.4.2Transform Payload Processing . . . . . . . . . . . . . . . . . 61 125 5.5 Key Exchange Payload Processing . . . . . . . . . . . . . . . . . 62 126 5.6 Identification Payload Processing . . . . . . . . . . . . . . . . 63 127 5.7 Certificate Payload Processing . . . . . . . . . . . . . . . . . 63 128 5.8 Certificate Request Payload Processing . . . . . . . . . . . . . 64 129 5.9 Hash Payload Processing . . . . . . . . . . . . . . . . . . . . . 66 130 5.10Signature Payload Processing . . . . . . . . . . . . . . . . . . 67 131 5.11Nonce Payload Processing . . . . . . . . . . . . . . . . . . . . 68 132 5.12Notification Payload Processing . . . . . . . . . . . . . . . . . 68 133 5.13Delete Payload Processing . . . . . . . . . . . . . . . . . . . . 70 134 6 Conclusions 73 136 A ISAKMP Security Association Attributes 74 137 A.1 Background/Rationale . . . . . . . . . . . . . . . . . . . . . . 74 138 A.2 Assigned Values for the Internet IP Security DOI . . . . . . . . 74 139 A.2.1Internet IP Security DOI Assigned Value . . . . . . . . . . . 74 140 A.2.2Supported Security Protocols . . . . . . . . . . . . . . . . . 74 141 B Defining a new Domain of Interpretation 76 142 B.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 143 B.2 Security Policies . . . . . . . . . . . . . . . . . . . . . . . . 77 144 B.3 Naming Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 77 145 B.4 Syntax for Specifying Security Services . . . . . . . . . . . . . 77 146 B.5 Payload Specification . . . . . . . . . . . . . . . . . . . . . . 77 147 B.6 Defining new Exchange Types . . . . . . . . . . . . . . . . . . . 77 149 List of Figures 151 1 ISAKMP Relationships . . . . . . . . . . . . . . . . . . . . . . 18 152 2 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 23 153 3 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . 26 154 4 Data Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 27 155 5 Security Association Payload . . . . . . . . . . . . . . . . . . 28 156 6 Proposal Payload Format . . . . . . . . . . . . . . . . . . . . . 29 157 7 Transform Payload Format . . . . . . . . . . . . . . . . . . . . 30 158 8 Key Exchange Payload Format . . . . . . . . . . . . . . . . . . . 32 159 9 Identification Payload Format . . . . . . . . . . . . . . . . . . 33 160 10 Certificate Payload Format . . . . . . . . . . . . . . . . . . . 34 161 11 Certificate Request Payload Format . . . . . . . . . . . . . . . 35 162 12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . . . . 36 163 13 Signature Payload Format . . . . . . . . . . . . . . . . . . . . 37 164 14 Nonce Payload Format . . . . . . . . . . . . . . . . . . . . . . 38 165 15 Notification Payload Format . . . . . . . . . . . . . . . . . . . 39 166 16 Delete Payload Format . . . . . . . . . . . . . . . . . . . . . . 42 168 1 Introduction 170 This document describes an Internet Security Association and Key Manage- 171 ment Protocol (ISAKMP). ISAKMP combines the security concepts of authen- 172 tication, key management, and security associations to establish the re- 173 quired security for government, commercial, and private communications on 174 the Internet. 176 The Internet Security Association and Key Management Protocol (ISAKMP) de- 177 fines procedures and packet formats to establish, negotiate, modify and 178 delete Security Associations (SA). SAs contain all the information re- 179 quired for execution of various network security services, such as the 180 IP layer services (such as header authentication and payload encapsula- 181 tion), transport or application layer services, or self-protection of ne- 182 gotiation traffic. ISAKMP defines payloads for exchanging key generation 183 and authentication data. These formats provide a consistent framework for 184 transferring key and authentication data which is independent of the key 185 generation technique, encryption algorithm and authentication mechanism. 187 ISAKMP is distinct from key exchange protocols in order to cleanly sepa- 188 rate the details of security association management (and key management) 189 from the details of key exchange. There may be many different key ex- 190 change protocols, each with different security properties. However, a 191 common framework is required for agreeing to the format of SA attributes, 192 and for negotiating, modifying, and deleting SAs. ISAKMP serves as this 193 common framework. 195 Separating the functionality into three parts adds complexity to the se- 196 curity analysis of a complete ISAKMP implementation. However, the sep- 197 aration is critical for interoperability between systems with differing 198 security requirements, and should also simplify the analysis of further 199 evolution of a ISAKMP server. 201 ISAKMP is intended to support the negotiation of SAs for security proto- 202 cols at all layers of the network stack (e.g., IPSEC, TLS, TLSP, OSPF, 203 etc.). By centralizing the management of the security associations, 204 ISAKMP reduces the amount of duplicated functionality within each security 205 protocol. ISAKMP can also reduce connection setup time, by negotiating a 206 whole stack of services at once. 208 The remainder of section 1 establishes the motivation for security nego- 209 tiation and outlines the major components of ISAKMP, i.e. Security As- 210 sociations and Management, Authentication, Public Key Cryptography, and 211 Miscellaneous items. Section 2 presents the terminology and concepts as- 212 sociated with ISAKMP. Section 3 describes the different ISAKMP payload 213 formats. Section 4 describes how the payloads of ISAKMP are composed to- 214 gether as exchange types to establish security associations and perform 215 key exchanges in an authenticated manner. Additionally, security as- 216 sociation modification, deletion, and error notification are discussed. 217 Section 5 describes the processing of each payload within the context of 218 ISAKMP exchanges, including error handling and associated actions. The 219 appendices provide the attribute values necessary for ISAKMP and require- 220 ment for defining a new Domain of Interpretation (DOI) within ISAKMP. 222 1.1 Requirements Terminology 224 In this document, the words that are used to define the significance of 225 each particular requirement are usually capitalised. These words are: 227 - MUST 229 This word or the adjective "REQUIRED" means that implementation of 230 the item is an absolute requirement of the specification. 232 - MUST NOT 234 This phrase means that the definition is an absolute prohibition 235 of the specification. 237 - SHOULD 239 This word or the adjective "RECOMMENDED" means that there might 240 exist valid reasons in particular circumstances to not implement 241 this item, but the full implications should be understood and the 242 case carefully weighed before not implementing this or not 243 implementing in a conforming manner. 245 - MAY 247 This word or the adjective "OPTIONAL" means that implementation of 248 this item is truly optional. One vendor might choose to include 249 the item because particular buyers require it or it enhances the 250 product, while another vendor may omit the same item. 252 - CONFORMANCE and COMPLIANCE 254 Conformance to this specification has the same meaning as 255 compliance to this specification. In either case, the 256 mandatory-to-implement, or MUST, items MUST be fully implemented 257 as specified here. If any mandatory item is not implemented as 258 specified here, that implementation is not conforming and not 259 compliant with this specification. 261 1.2 The Need for Negotiation 263 ISAKMP extends the assertion in [DOW92] that authentication and key ex- 264 changes must be combined for better security to include security associa- 265 tion exchanges. The security services required for communications depends 266 on the individual network configurations and environments. Organizations 267 are setting up Virtual Private Networks (VPN), also known as Intranets, 268 that will require one set of security functions for communications within 269 the VPN and possibly many different security functions for communications 270 outside the VPN to support geographically separate organizational compo- 271 nents, customers, suppliers, sub-contractors (with their own VPNs), gov- 272 ernment, and others. Departments within large organizations may require a 273 number of security associations to separate and protect data (e.g. per- 274 sonnel data, company proprietary data, medical) on internal networks and 275 other security associations to communicate within the same department. 276 Nomadic users wanting to ``phone home'' represent another set of secu- 277 rity requirements. These requirements must be tempered with bandwidth 278 challenges. Smaller groups of people may meet their security require- 279 ments by setting up ``Webs of Trust''. ISAKMP exchanges provide these 280 assorted networking communities the ability to present peers with the se- 281 curity functionality that the user supports in an authenticated and pro- 282 tected manner for agreement upon a common set of security attributes, i.e. 283 an interoperable security association. 285 1.3 What can be Negotiated? 287 Security associations must support different encryption algorithms, au- 288 thentication mechanisms, and key establishment algorithms for other secu- 289 rity protocols, as well as IP Security. Security associations must also 290 support host-oriented certificates for lower layer protocols and user- 291 oriented certificates for higher level protocols. Algorithm and mecha- 292 nism independence is required in applications such as e-mail, remote lo- 293 gin, and file transfer, as well as in session oriented protocols, routing 294 protocols, and link layer protocols. ISAKMP provides a common security 295 association and key establishment protocol for this wide range of security 296 protocols, applications, security requirements, and network environments. 298 ISAKMP is not bound to any specific cryptographic algorithm, key gener- 299 ation technique, or security mechanism. This flexibility is beneficial 300 for a number of reasons. First, it supports the dynamic communications 301 environment described above. Second, the independence from specific secu- 302 rity mechanisms and algorithms provides a forward migration path to better 303 mechanisms and algorithms. When improved security mechanisms are devel- 304 oped or new attacks against current encryption algorithms, authentica- 305 tion mechanisms and key exchanges are discovered, ISAKMP will allow the 306 updating of the algorithms and mechanisms without having to develop a com- 307 pletely new KMP or patch the current one. 309 ISAKMP has basic requirements for its authentication and key exchange com- 310 ponents. These requirements guard against denial of service, replay / re- 311 flection, man-in-the-middle, and connection hijacking attacks. This is 312 important because these are the types of attacks that are targeted against 313 protocols. Complete Security Association (SA) support, which provides 314 mechanism and algorithm independence, and protection from protocol threats 315 are the strengths of ISAKMP. 317 1.4 Security Associations and Management 319 A Security Association (SA) is a relationship between two or more entities 320 that describes how the entities will utilize security services to communi- 321 cate securely. This relationship is represented by a set of information 322 that can be considered a contract between the entities. The information 323 must be agreed upon and shared between all the entities. Sometimes the 324 information alone is referred to as an SA, but this is just a physical in- 325 stantiation of the existing relationship. The existence of this relation- 326 ship, represented by the information, is what provides the agreed upon se- 327 curity information needed by entities to securely interoperate. All enti- 328 ties must adhere to the SA for secure communications to be possible. When 329 accessing SA attributes, entities use a pointer or identifier refered to 330 as the Security Parameter Index (SPI). [RFC-1825] provides details on IP 331 Security Associations (SA) and Security Parameter Index (SPI) definitions. 333 1.4.1 Security Associations and Registration 335 The SA attributes required and recommended for the IP Security (AH, ESP) 336 are defined in [RFC-1825]. The attributes specified for an IP Security SA 337 include, but are not limited to, authentication mechanism, cryptographic 338 algorithm, algorithm mode, key length, and Initialization Vector (IV). 339 Other protocols that provide algorithm and mechanism independent secu- 340 rity MUST define their requirements for SA attributes. The separation of 341 ISAKMP from a specific SA definition is important to ensure ISAKMP can es- 342 tablish SAs for all possible security protocols and applications. 344 NOTE: See [IPDOI] for a discussion of SA attributes that should be consid- 345 ered when defining a security protocol or application. 347 In order to facilitate easy identification of specific attributes (e.g. 348 a specific encryption algorithm) among different network entites the at- 349 tributes must be assigned identifiers and these identifiers must be reg- 350 istered by a central authority. The Internet Assigned Numbers Authority 351 (IANA) provides this function for the Internet. 353 1.4.2 ISAKMP Requirements 355 Security Association (SA) establishment MUST be part of the key manage- 356 ment protocol defined for IP based networks. The SA concept is required 357 to support security protocols in a diverse and dynamic networking envi- 358 ronment. Just as authentication and key exchange must be linked to pro- 359 vide assurance that the key is established with the authenticated party 360 [DOW92], SA establishment must be linked with the authentication and the 361 key exchange protocol. 363 ISAKMP provides the protocol exchanges to establish a security association 364 between negotiating entities followed by the establishment of a security 365 association by these negotiated entities in behalf of some protocol (e.g. 366 ESP/AH). First, an initial protocol exchange allows a basic set of secu- 367 rity attributes to be agreed upon. This basic set provides protection for 368 subsequent ISAKMP exchanges. It also indicates the authentication method 369 and key exchange that will be performed as part of the ISAKMP protocol. 370 If a basic set of security attributes is already in place between the ne- 371 gotiating server entities, the initial ISAKMP exchange may be skipped and 372 the establishment of a security association can be done directly. After 373 the basic set of security attributes has been agreed upon, initial iden- 374 tity authenticated, and required keys generated, the established SA can 375 be used for subsequent communications by the entity that invoked ISAKMP. 376 The basic set of SA attributes that MUST be implemented to provide ISAKMP 377 interoperability are defined in Appendix A. 379 1.5 Authentication 381 A very important step in establishing secure network communications is au- 382 thentication of the entity at the other end of the communication. Many 383 authentication mechanisms are available. Authentication mechanisms fall 384 into two catagories of strength - weak and strong. Passwords are an ex- 385 ample of a mechanism that provides weak authentication. The reason pass- 386 words are considered weak is the fact that most users pick passwords that 387 are easy to guess and when used over an unprotected network are easily 388 read by network sniffers. Digital signatures, such as the Digital Sig- 389 nature Standard (DSS) and the Rivest-Shamir-Adleman (RSA) signature, are 390 public key based strong authentication mechanisms. When using public 391 key digital signatures each entity requires a public key and a private 392 key. Certificates are an essential part of a digital signature authen- 393 tication mechanism. Certificates bind a specific entity's identity (be 394 it host, network, user, or application) to its public keys and possi- 395 bly other security-related information such as privileges, clearances, 396 and compartments. Authentication based on digital signatures requires a 397 trusted third party or certificate authority to create, sign and properly 398 distribute certificates. For more detailed information on digital signa- 399 tures, such as DSS and RSA, and certificates see [Schneier]. 401 1.5.1 Certificate Authorities 403 Certificates require an infrastructure for generation, verification, re- 404 vocation, management and distribution. The Internet Policy Registration 405 Authority (IPRA) [RFC-1422] has been established to direct this infras- 406 tructure for the IETF. The IPRA certifies Policy Certification Authori- 407 ties (PCA). PCAs control Certificate Authorities (CA) which certify users 408 and subordinate entities. Current certificate related work includes the 409 Domain Name System (DNS) Security Extensions [DNSSEC] which will provide 410 signed entity keys in the DNS. The Public Key Infrastucture (PKIX) working 411 group is specifying an Internet profile for X.509 certificates. There is 412 also work going on in industry to develop X.500 Directory Services which 413 would provide X.509 certificates to users. The U.S. Post Office is devel- 414 oping a (CA) hierarchy. The NIST Public Key Infrastructure Working Group 415 has also been doing work in this area. The DOD Multi Level Information 416 System Security Initiative (MISSI) program has begun deploying a certifi- 417 cate infrastructure for the U.S. Government. Alternatively, if no infras- 418 tructure exists, the PGP Web of Trust certificates can be used to provide 419 user authentication and privacy in a community of users who know and trust 420 each other. 422 1.5.2 Entity Naming 424 An entity's name is its identity and is bound to its public keys in cer- 425 tificates. The CA MUST define the naming semantics for the certificates 426 it issues. See the UNINETT PCA Policy Statements [Berge] for an example 427 of how a CA defines its naming policy. When the certificate is verified, 428 the name is verified and that name will have meaning within the realm of 429 that CA. An example is the DNS security extensions which make DNS servers 430 CAs for the zones and nodes they serve. Resource records are provided for 431 public keys and signatures on those keys. The names associatied with the 432 keys are IP addresses and domain names which have meaning to entities ac- 433 cessing the DNS for this information. A Web of Trust is another example. 434 When webs of trust are set up, names are bound with the public keys. In 435 PGP the name is usually the entity's e-mail address which has meaning to 436 those, and only those, who understand e-mail. Another web of trust could 437 use an entirely different naming scheme. 439 1.5.3 ISAKMP Requirements 441 Strong authentication MUST be provided on ISAKMP exchanges. Without being 442 able to authenticate the entity at the other end, the Security Association 443 (SA) and session key established are suspect. Without authentication you 444 are unable to trust an entity's identification, this makes access control 445 questionable. While encryption (e.g. ESP) and integrity (e.g. AH) will 446 protect subsequent communications from passive eavesdroppers, without au- 447 thentication it is possible that the SA and key may have been established 448 with an adversary who performed an active man-in-the-middle attack and is 449 now stealing all your personal data. 451 A digital signature algorithm MUST be used within ISAKMP's authentication 452 component. However, ISAKMP does not mandate a specific signature algo- 453 rithm or certificate authority (CA). ISAKMP allows an entity initiating 454 communications to indicate which CAs it supports. After selection of a 455 CA, the protocol provides the messages required to support the actual au- 456 thentication exchange. The protocol provides a facility for identifica- 457 tion of different certificate authorities, certificate types (e.g. X.509, 458 PKCS #7, PGP, DNS SIG and KEY records), and the exchange of the certifi- 459 cates identified. 461 ISAKMP utilizes digital signatures, based on public cryptography, for au- 462 thentication. There are other strong authentication systems available, 463 which could be specified as additional optional authentication mechanisms 464 for ISAKMP. Some of these authentication systems rely on a trusted third 465 party called a key distribution center (KDC) to distribute secret session 466 keys. An example is Kerberos, where the trusted third party is the Ker- 467 beros server, which holds secret keys for all clients and servers within 468 its network domain. A client's proof that it holds its secret key pro- 469 vides authenticaton to a server. 471 The ISAKMP specification does not specify the protocol for communicating 472 with the trusted third parties (TTP) or certificate directory services. 473 These protocols are defined by the TTP and directory service themselves 474 and are outside the scope of this specification. The use of these addi- 475 tional services and protocols will be described in a Key Exchange specific 476 document. 478 1.6 Public Key Cryptography 480 Public key cryptography is the most flexible, scalable, and efficient way 481 for users to obtain the shared secrets and session keys needed to support 482 the large number of ways Internet users will interoperate. Many key gen- 483 eration algorithms, that have different properties, are available to users 484 (see [DOW92], [ANSI], and [Oakley]). Properties of key exchange protocols 485 include the key establishment method, authentication, symmetry, perfect 486 forward secrecy, and back traffic protection. 488 NOTE: Cryptographic keys can protect information for a considerable length 489 of time. However, this is based on the assumption that keys used for pro- 490 tection of communications are destroyed after use and not kept for any 491 reason. 493 1.6.1 Key Exchange Properties 495 Key Establishment (Key Generation / Key Transport) The two common methods 496 of using public key cryptography for key establishment are key transport 497 and key generation. An example of key transport is the use of the RSA al- 498 gorithm to encrypt a randomly generated session key (for encrypting subse- 499 quent communications) with the recipient's public key. The encrypted ran- 500 dom key is then sent to the recipient, who decrypts it using his private 501 key. At this point both sides have the same session key, however it was 502 created based on input from only one side of the communications. The ben- 503 efit of the key transport method is that it has less computational over- 504 head than the following method. The Diffie-Hellman (D-H) algorithm il- 505 lustrates key generation using public key cryptography. The D-H algorithm 506 is begun by two users exchanging public information. Each user then math- 507 ematically combines the other's public information along with their own 508 secret information to compute a shared secret value. This secret value 509 can be used as a session key or as a key encryption key for encrypting a 510 randomly generated session key. This method generates a session key based 511 on public and secret information held by both users. The benefit of the 512 D-H algorithm is that the key used for encrypting messages is based on 513 information held by both users and the independence of keys from one key 514 exchange to another provides perfect forward secrecy. Detailed descrip- 515 tions of these algorithms can be found in [Schneier]. There are a number 516 of variations on these two key generation schemes and these variations do 517 not necessarily interoperate. 519 Key Exchange Authentication Key exchanges may be authenticated during the 520 protocol or after protocol completion. Authentication of the key exchange 521 during the protocol is provided when each party provides proof it has the 522 secret session key before the end of the protocol. Proof can be provided 523 by encrypting known data in the secret session key during the protocol ex- 524 change. Authentication after the protocol must occur in subsequent commu- 525 nications. Authentication during the protocol is preferred so subsequent 526 communications are not initiated if the secret session key is not estab- 527 lished with the desired party. 529 Key Exchange Symmetry A key exchange provides symmetry if either party can 530 initiate the exchange and exchanged messages can cross in transit with- 531 out affecting the key that is generated. This is desirable so that com- 532 putation of the keys does not require either party to know who initiated 533 the exchange. While key exchange symmetry is desirable, symmetry in the 534 entire key management protocol may provide a vulnerablity to reflection 535 attacks. 537 Perfect Forward Secrecy As described in [DOW92], an authenticated key ex- 538 change protocol provides perfect forward secrecy if disclosure of long- 539 term secret keying material does not compromise the secrecy of the ex- 540 changed keys from previous communications. The property of perfect for- 541 ward secrecy does not apply to key exchange without authentication. 543 1.6.2 ISAKMP Requirements 545 An authenticated key exchange MUST be supported by ISAKMP. Users SHOULD 546 choose additional key establishment algorithms based on their require- 547 ments. ISAKMP does not specify a specific key exchange. However, 548 [IO-Res] describes a proposal for using the Oakley key exchange [Oakley] 549 in conjunction with ISAKMP. Requirements that should be evaluated when 550 choosing a key establishment algorithm include establishment method (gen- 551 eration vs. transport), perfect forward secrecy, computational overhead, 552 key escrow, and key strength. Based on user requirements, ISAKMP allows 553 an entity initiating communications to indicate which key exchanges it 554 supports. After selection of a key exchange, the protocol provides the 555 messages required to support the actual key establishment. 557 1.7 ISAKMP Protection 559 1.7.1 Anti-Clogging (Denial of Service) 561 Of the numerous security services available, protection against denial 562 of service always seems to be one of the most difficult to address. A 563 ``cookie'' or anti-clogging token (ACT) is aimed at protecting the com- 564 puting resources from attack without spending excessive CPU resources to 565 determine its authenticity. An exchange prior to CPU-intensive public key 566 operations can thwart some denial of service attempts (e.g. simple flood- 567 ing with bogus IP source addresses). Absolute protection against denial 568 of service is impossible, but this anti-clogging token provides a tech- 569 nique for making it easier to handle. The use of an anti-clogging token 570 was introduced by Karn and Simpson in [Karn]. 572 1.7.2 Connection Hijacking 574 ISAKMP prevents connection hijacking by linking the authentication, key 575 exchange and security association exchanges. This linking prevents an 576 attacker from allowing the authentication to complete and then jumping 577 in and impersonating one entity to the other during the key and security 578 association exchanges. 580 1.7.3 Man-in-the-Middle Attacks 582 Man-in-the-Middle attacks include interception, insertion, deletion, and 583 modification of messages, reflecting messages back at the sender, re- 584 playing old messages and redirecting messages. ISAKMP features prevent 585 these types of attacks from being successful. The linking of the ISAKMP 586 exchanges prevents the insertion of messages in the protocol exchange. 587 The ISAKMP protocol state machine is defined so deleted messages will not 588 cause a partial SA to be created, the state machine will clear all state 589 and return to idle. The state machine also prevents reflection of a mes- 590 sage from causing harm. The requirement for a new cookie with time vari- 591 ant material for each new SA establishment prevents attacks that involve 592 replaying old messages. The ISAKMP strong authentication requirement pre- 593 vents an SA from being established with anyone other than the intended 594 party. Messages may be redirected to a different destination or modified 595 but this will be detected and an SA will not be established. The ISAKMP 596 specification defines where abnormal processing has occurred and recom- 597 mends notifying the appropriate party of this abnormality. 599 1.8 Multicast Communications 601 It is expected that multicast communications will require the same secu- 602 rity services as unicast communications and may introduce the need for 603 additional security services. The issues of distributing SPIs for mul- 604 ticast traffic are presented in [RFC-1825]. Multicast security issues are 605 also discussed in [RFC-1949] and [BC]. A future extension to ISAKMP will 606 support multicast key distribution. For an introduction to the issues re- 607 lated to multicast security, consult the Internet Drafts, [RFC-2094] and 608 [RFC-2093], describing Sparta's research in this area. 610 2 Terminology and Concepts 612 2.1 ISAKMP Terminology 614 Security Protocol A Security Protocol consists of an entity at a single 615 point in the network stack, performing a security service for network com- 616 munication. For example, IPSEC ESP and IPSEC AH are two different secu- 617 rity protocols. TLS is another example. Security Protocols may perform 618 more than one service, for example providing integrity and confidentiality 619 in one module. 621 Protection Suite A protection suite is a list of the security services 622 that must be applied by various security protocols. For example, a pro- 623 tection suite may consist of DES encryption in IP ESP, and keyed MD5 in IP 624 AH. All of the protections in a suite must be treated as a single unit. 625 This is necessary because security services in different security pro- 626 tocols can have subtle interactions, and the effects of a suite must be 627 analyzed and verified as a whole. 629 Security Association (SA) A Security Association is a security-protocol- 630 specific set of parameters that completely defines the services and mech- 631 anisms necessary to protect traffic at that security protocol location. 632 These parameters can include algorithm identifiers, modes, cryptographic 633 keys, etc. The SA is referred to by its associated security protocol (for 634 example, ``ISAKMP SA'', ``ESP SA'', ``TLS SA''). 636 ISAKMP SA An SA used by the ISAKMP servers to protect their own traffic. 637 Sections 2.3 and 2.4 provide more details about ISAKMP SAs. 639 Security Parameter Index (SPI) An identifier for a Security Assocation, 640 relative to some security protocol. Each security protocol has its own 641 ``SPI-space''. A (security protocol, SPI) pair may uniquely identify an 642 SA. The uniqueness of the SPI is implementation dependent, but could be 643 based per system, per protocol, or other options. Depending on the DOI, 644 additional information (e.g. host address) may be necessary to identify 645 an SA. The DOI will also determine which SPIs (i.e. initiator's or re- 646 sponder's) are sent during communication. 648 Domain of Interpretation A Domain of Interpretation (DOI) defines payload 649 formats, exchange types, and conventions for naming security-relevant in- 650 formation such as security policies or cryptographic algorithms and modes. 651 A Domain of Interpretation (DOI) identifier is used to interpret the pay- 652 loads of ISAKMP payloads. A system SHOULD support multiple Domains of In- 653 terpretation simultaneously. The concept of a DOI is based on previous 654 work by the TSIG CIPSO Working Group, but extends beyond security label 655 interpretation to include naming and interpretation of security services. 656 A DOI defines: 658 o A ``situation'': the set of information that will be used to 659 determine the required security services. 661 o The set of security policies that must, and may, be supported. 663 o A syntax for the specification of proposed security services. 665 o A scheme for naming security-relevant information, including 666 encryption algorithms, key exchange algorithms, security policy 667 attributes, and certificate authorities. 669 o The specific formats of the various payload contents. 671 o Additional exchange types, if required. 673 The rules for the IETF IP Security DOI are presented in [IPDOI]. Speci- 674 fications of the rules for customized DOIs will be presented in separate 675 documents. 677 Situation A situation contains all of the security-relevant information 678 that a system considers necessary to decide the security services required 679 to protect the session being negotiated. The situation may include ad- 680 dresses, security classifications, modes of operation (normal vs. emer- 681 gency), etc. 683 Proposal A proposal is a list, in decreasing order of preference, of the 684 protection suites that a system considers acceptable to protect traffic 685 under a given situation. 687 Payload ISAKMP defines several types of payloads, which are used to trans- 688 fer information such as security association data, or key exchange data, 689 in DOI-defined formats. A payload consists of a generic payload header 690 and a string of octects that is opaque to ISAKMP. ISAKMP uses DOI-specific 691 functionality to synthesize and interpret these payloads. Multiple pay- 692 loads can be sent in a single ISAKMP message. See section 3 for more de- 693 tails on the payload types, and [IPDOI] for the formats of the IETF IP Se- 694 curity DOI payloads. 696 Exchange Type An exchange type is a specification of the number of mes- 697 sages in an ISAKMP exchange, and the payload types that are contained in 698 each of those messages. Each exchange type is designed to provide a par- 699 ticular set of security services, such as anonymity of the participants, 700 perfect forward secrecy of the keying material, authentication of the par- 701 ticipants, etc. Section 4.3 defines the default set of ISAKMP exchange 702 types. Other exchange types can be added to support additional key ex- 703 changes, if required. 705 2.2 ISAKMP Placement 707 Figure 1 is a high level view of the placement of ISAKMP within a system 708 context in a network architecture. An important part of negotiating secu- 709 rity services is to consider the entire ``stack'' of individual SAs as a 710 unit. This is referred to as a ``protection suite''. 712 +------------+ +--------+ +--------------+ 713 ! DOI ! ! ! ! Application ! 714 ! Definition ! <----> ! ISAKMP ! ! Process ! 715 +------------+ ! ! !--------------! 716 +--------+ ! Appl Protocol! 717 ^ +--------------+ 718 ! ^ 719 ! ! 720 v v 721 +---------------------------------------------+ 722 ! Socket Layer ! 723 !---------------------------------------------! 724 ! Transport Protocol (TCP / UDP) ! 725 +----------+ !---------------------------------------------! 726 ! Security ! <----> ! IP ! 727 ! Protocol ! !---------------------------------------------! 728 +----------+ ! Link Layer Protocol ! 729 +---------------------------------------------+ 731 Figure 1: ISAKMP Relationships 733 2.3 Negotiation Phases 735 ISAKMP offers two ``phases'' of negotiation. In the first phase, two en- 736 tities (e.g. ISAKMP servers) agree on how to protect further negotiation 737 traffic between themselves, establishing an ISAKMP SA. This ISAKMP SA is 738 then used to protect the negotiations for the Protocol SA being requested. 739 Two entities (e.g. ISAKMP servers) can negotiate (and have active) multi- 740 ple ISAKMP SAs. 742 The second phase of negotiation is used to establish security associa- 743 tions for other security protocols. This second phase can be used to pro- 744 tect many security associations. The security associations established 745 by ISAKMP during this phase can be used by a security protocol to protect 746 many message/data exchanges. 748 While the two-phased approach has a higher start-up cost for most simple 749 scenarios, there are several reasons that it is beneficial for most cases. 751 First, entities (e.g. ISAKMP servers) can amortize the cost of the first 752 phase across several second phase negotiations. This allows multiple SAs 753 to be established between peers over time without having to start over for 754 each communication. 756 Second, security services negotiated during the first phase provide secu- 757 rity properties for the second phase. For example, after the first phase 758 of negotiation, the encryption provided by the ISAKMP SA can provide iden- 759 tity protection, potentially allowing the use of simpler second-phase ex- 760 changes. On the other hand, if the channel established during the first 761 phase is not adequate to protect identities, then the second phase must 762 negotiate adequate security mechanisms. 764 Third, having an ISAKMP SA in place considerably reduces the cost of 765 ISAKMP management activity - without the ``trusted path'' that an ISAKMP 766 SA gives you, the entities (e.g. ISAKMP servers) would have to go through 767 a complete re-authentication for each error notification or deletion of an 768 SA. 770 Negotiation during each phase is accomplished using ISAKMP-defined ex- 771 changes (see section 4) or exchanges defined for a key exchange within a 772 DOI. 774 Note that security services may be applied differently in each negotiation 775 phase. For example, different parties are being authenticated during each 776 of the phases of negotiation. During the first phase, the parties being 777 authenticated may be the ISAKMP servers/hosts, while during the second 778 phase, users or application level programs are being authenticated. 780 2.4 Identifying Security Associations 782 While bootstrapping secure channels between systems, ISAKMP cannot assume 783 the existence of security services, and must provide some protections for 784 itself. Therefore, ISAKMP considers an ISAKMP Security Association to be 785 different than other types, and manages ISAKMP SAs itself, in their own 786 name space. ISAKMP uses the two cookie fields in the ISAKMP header to 787 identify ISAKMP SAs. The Message ID and SPI fields in the ISAKMP Header 788 are used during SA establishment to identify the SA for other security 789 protocols. The interpretation of these four fields is dependent on the 790 operation taking place. 792 The following table shows the presence or absence of the cookies in the 793 ISAKMP header, the ISAKMP Header Message ID field, and the SPI field in 794 the Proposal payload for various operations. An 'X' in the column means 795 the value MUST be present. An 'NA' in the column means a value in the 796 column is Not Applicable to the operation. 798 __#_____________Operation____________I-Cookie__R-Cookie__Message_ID__SPI_ 799 (1) Start ISAKMP SA negotiation X 0 0 0 800 (2) Respond ISAKMP SA negotiation X X 0 0 801 (3) Init other SA negotiation X X X X 802 (4) Respond other SA negotiation X X X X 803 (5) Other (KE, ID, etc.) X X X/0 NA 804 (6) Security Protocol (ESP, AH) NA NA NA X 806 In the first line (1) of the table, the initiator includes the Initiator 807 Cookie field in the ISAKMP Header, using the procedures outlined in sec- 808 tions 2.5.3 and 3.1. 810 In the second line (2) of the table, the responder includes the Initia- 811 tor and Responder Cookie fields in the ISAKMP Header, using the procedures 812 outlined in sections 2.5.3 and 3.1. Additional messages may be exchanged 813 between ISAKMP peers, depending on the ISAKMP exchange type used during 814 the phase 1 negotiation. Once the phase 1 exchange is completed, the Ini- 815 tiator and Responder cookies are included in the ISAKMP Header of all sub- 816 sequent communications between the ISAKMP peers. 818 During phase 1 negotiations, the initiator and responder cookies deter- 819 mine the ISAKMP SA. Therefore, the SPI field in the Proposal payload is 820 redundant and MAY be set to 0 or it MAY contain the transmitting entity's 821 cookie. 823 In the third line (3) of the table, the initiator associates a Message ID 824 with the Protocols contained in the SA Proposal. This Message ID and the 825 initiator's SPI(s) to be associated with each protocol in the Proposal are 826 sent to the responder. The SPI(s) will be used by the security protocols 827 once the phase 2 negotiation is completed. 829 In the fourth line (4) of the table, the responder includes the same Mes- 830 sage ID and the responder's SPI(s) to be associated with each protocol in 831 the accepted Proposal. This information is returned to the initiator. 833 In the fifth line (5) of the table, the initiator and responder use the 834 Message ID field in the ISAKMP Header to keep track of the in-progress 835 protocol negotiation. This is only applicable for a phase 2 exchange and 836 the value SHOULD be 0 for a phase 1 exchange because the combined cook- 837 ies identify the ISAKMP SA. The SPI field in the Proposal payload is not 838 applicable because the Proposal payload is only used during the SA negoti- 839 ation message exchange (steps 3 and 4). 841 In the sixth line (6) of the table, the phase 2 negotiation is complete. 842 The security protocols use the SPI(s) to determine which security services 843 and mechanisms to apply to the communication between them. The SPI value 844 shown in the sixth line (6) is not the SPI field in the Proposal payload, 845 but the SPI field contained within the security protocol header. 847 During the SA establishment, a SPI MUST be generated. ISAKMP is designed 848 to handle variable sized SPIs. This is accomplished by using the SPI Size 849 field within the Proposal payload during SA establishment. Handling of 850 SPIs will be outlined by the DOI specification (e.g. [IPDOI]). 852 When a security association (SA) is initially established, one side as- 853 sumes the role of initiator and the other the role of responder. Once the 854 SA is established, both the original initiator and responder can initiate 855 a phase 2 negotiation with the peer entity. Thus, ISAKMP SAs are bidirec- 856 tional in nature. 858 Additionally, ISAKMP allows both initiator and responder to have some con- 859 trol during the negotiation process. While ISAKMP is designed to allow an 860 SA negotiation that includes multiple proposals, the initiator can main- 861 tain some control by only making one proposal in accordance with the ini- 862 tiator's local security policy. Once the initiator sends a proposal con- 863 taining more than one proposal (which are sent in decreasing preference 864 order), the initiator relinquishes control to the responder. Once the re- 865 sponder is controlling the SA establishment, the responder can make its 866 policy take precedence over the initiator within the context of the multi- 867 ple options offered by the initiator. This is accomplished by selecting 868 the proposal best suited for the responder's local security policy and re- 869 turning this selection to the initiator. 871 2.5 Miscellaneous 873 2.5.1 Transport Protocol 875 ISAKMP can be implemented over any transport protocol or over IP itself. 876 Implementations MUST include send and receive capability for ISAKMP us- 877 ing the User Datagram Protocol (UDP) on port 500. UDP Port 500 has been 878 assigned to ISAKMP by the Internet Assigned Numbered Authority (IANA). Im- 879 plementations MAY additionally support ISAKMP over other transport proto- 880 cols or over IP itself. 882 2.5.2 RESERVED Fields 884 The existence of RESERVED fields within ISAKMP payloads are used strictly 885 to preserve byte alignment. All RESERVED fields in the ISAKMP protocol 886 MUST be set to zero (0) when a packet is issued. The receiver SHOULD 887 check the RESERVED fields for a zero (0) value and discard the packet if 888 other values are found. 890 2.5.3 Anti-Clogging Token (``Cookie'') Creation 892 The details of cookie generation are implementation dependent, but MUST 893 satisfy these basic requirements (originally stated by Phil Karn in 894 [Karn]): 896 1. The cookie must depend on the specific parties. This prevents 897 an attacker from obtaining a cookie using a real IP address and 898 UDP port, and then using it to swamp the victim with Diffie- 899 Hellman requests from randomly chosen IP addresses or ports. 901 2. It must not be possible for anyone other than the issuing 902 entity to generate cookies that will be accepted by that 903 entity. This implies that the issuing entity must use local 904 secret information in the generation and subsequent 905 verification of a cookie. It must not be possible to deduce 906 this secret information from any particular cookie. 908 3. The cookie generation function must be fast to thwart attacks 909 intended to sabotage CPU resources. 911 Karn's suggested method for creating the cookie is to perform a fast hash 912 (e.g. MD5) over the IP Source and Destination Address, the UDP Source and 913 Destination Ports and a locally generated secret random value. ISAKMP re- 914 quires that the cookie be unique for each SA establishment to help pre- 915 vent replay attacks, therefore, the date and time MUST be added to the in- 916 formation hashed. The generated cookies are placed in the ISAKMP Header 917 (described in section 3.1) Initiator and Responder cookie fields. These 918 fields are 8 octets in length, thus, requiring a generated cookie to be 8 919 octets. Notify and Delete messages (see sections 3.14, 3.15, and 4.8) are 920 uni-directional transmissions and are done under the protection of an ex- 921 isting ISAKMP SA, thus, not requiring the generation of a new cookie. One 922 exception to this is the transmission of a Notify message during a Phase 923 1 exchange, prior to completing the establishment of an SA. Sections 3.14 924 and 4.8 provide additional details. 926 3 ISAKMP Payloads 928 ISAKMP payloads provide modular building blocks for constructing ISAKMP 929 messages. The presence and ordering of payloads in ISAKMP is defined by 930 and dependent upon the Exchange Type Field located in the ISAKMP Header 931 (see Figure 2). The ISAKMP payload types are discussed in sections 3.4 932 through 3.15. The descriptions of the ISAKMP payloads, messages, and ex- 933 changes (see Section 4) are shown using network octet ordering. Addition- 934 ally, all ISAKMP messages MUST be aligned at 4-octet multiples. 936 3.1 ISAKMP Header Format 938 An ISAKMP message has a fixed header format, shown in Figure 2, followed 939 by a variable number of payloads. A fixed header simplifies parsing, pro- 940 viding the benefit of protocol parsing software that is less complex and 941 easier to implement. The fixed header contains the information required 942 by the protocol to maintain state, process payloads and possibly prevent 943 denial of service or replay attacks. 945 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 ! Initiator ! 949 ! Cookie ! 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 ! Responder ! 952 ! Cookie ! 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 ! Message ID ! 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 ! Length ! 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 Figure 2: ISAKMP Header Format 963 The ISAKMP Header fields are defined as follows: 965 o Initiator Cookie (8 octets) - Cookie of entity that initiated SA 966 establishment, SA notification, or SA deletion. 968 o Responder Cookie (8 octets) - Cookie of entity that is responding to 969 an SA establishment request, SA notification, or SA deletion. 971 o Next Payload (1 octet) - Indicates the type of the first payload in 972 the message. The format for each payload is defined in sections 3.4 973 through 3.15. The processing for the payloads is defined in section 974 5. 976 _____Next_Payload_Type_______Value____ 977 NONE 0 978 Security Association (SA) 1 979 Proposal (P) 2 980 Transform (T) 3 981 Key Exchange (KE) 4 982 Identification (ID) 5 983 Certificate (CERT) 6 984 Certificate Request (CR) 7 985 Hash (HASH) 8 986 Signature (SIG) 9 987 Nonce (NONCE) 10 988 Notification (N) 11 989 Delete (D) 12 990 RESERVED 13- 127 991 Private USE 128 - 255 993 o Major Version (4 bits) - indicates the major version of the ISAKMP 994 protocol in use. Implementations based on this version of the ISAKMP 995 Internet-Draft MUST set the Major Version to 1. Implementations 996 based on previous versions of ISAKMP Internet-Drafts MUST set the 997 Major Version to 0. Implementations SHOULD never accept packets with 998 a major version number larger than its own. 1000 o Minor Version (4 bits) - indicates the minor version of the ISAKMP 1001 protocol in use. Implementations based on this version of the ISAKMP 1002 Internet-Draft MUST set the Minor Version to 0. Implementations 1003 based on previous versions of ISAKMP Internet-Drafts MUST set the 1004 Minor Version to 1. Implementations SHOULD never accept packets with 1005 a minor version number larger than its own, given the major version 1006 numbers are identical. 1008 o Exchange Type (1 octet) - indicates the type of exchange being used. 1009 This dictates the message and payload orderings in the ISAKMP 1010 exchanges. 1012 ____Exchange_Type______Value___ 1013 NONE 0 1014 Base 1 1015 Identity Protection 2 1016 Authentication Only 3 1017 Aggressive 4 1018 Informational 5 1019 ISAKMP Future Use 6 - 31 1020 DOI Specific Use 32 - 255 1022 o Flags (1 octet) - indicates specific options that are set for the 1023 ISAKMP exchange. The flags listed below are specified in the Flags 1024 field beginning with the least significant bit, i.e the Encryption 1025 bit is bit 0 of the Flags field, the Commit bit is bit 1 of the Flags 1026 field, etc. 1028 -- E(ncryption Bit) (1 bit) - If set (1), all payloads following the 1029 header are encrypted using the encryption algorithm identified in 1030 the ISAKMP SA. The ISAKMP SA Identifier is the combination of the 1031 initiator and responder cookie. It is RECOMMENDED that 1032 encryption of communications be done as soon as possible between 1033 the peers. For all ISAKMP exchanges described in section 4.3, 1034 the encryption SHOULD begin after both parties have exchanged Key 1035 Exchange payloads. If the E(ncryption Bit) is not set (0), the 1036 payloads are not encrypted. 1038 -- C(ommit Bit) (1 bit) - This bit is used to signal key exchange 1039 synchronization. It is used to ensure that encrypted material is 1040 not received prior to completion of the SA establishment. The 1041 Commit Bit can be set (at anytime) by either party participating 1042 in the SA establishment, and can be used during both phases of an 1043 ISAKMP SA establishment. However, the value MUST be reset after 1044 the Phase 1 negotiation. If set(1), the entity which did not set 1045 the Commit Bit MUST wait for an Informational Exchange containing 1046 a Notify payload (with the CONNECTED Notify Message) from the en- 1047 tity which set the Commit Bit. This indicates that the SA estab- 1048 lishment was successful and either entity can now proceed with en- 1049 crypted traffic communication. In addition to synchronizing key ex- 1050 change, the Commit Bit can be used to protect against loss of trans- 1051 missions over unreliable networks and guard against the need for mul- 1052 tiple retransmissions. 1054 NOTE: It is always possible that the final message of an exchange 1055 can be lost. In this case, the entity expecting to receive the 1056 final message of an exchange would receive the Phase 2 SA negoti- 1057 ation message following a Phase 1 exchange or encrypted traffic 1058 following a Phase 2 exchange. Handling of this situation is not 1059 standardized, but we propose the following possibilities. If the 1060 entity awaiting the Informational Exchange can verify the re- 1061 ceived message (i.e. Phase 2 SA negotiation message or encrypted 1062 traffic), then they MAY consider the SA was established and 1063 continue processing. The other option is to retransmit the last 1064 ISAKMP message to force the other entity to retransmit the final mes- 1065 sage. This suggests that implementations may consider retaining the 1066 last message (locally) until they are sure the SA is established. 1068 o Message ID (4 octets) - Unique Message Identifier used to identify 1069 protocol state during Phase 2 negotiations. This value is randomly 1070 generated by the initiator of the Phase 2 negotiation. During Phase 1071 1 negotiations, the value MUST be set to 0. 1073 o Length (4 octets) - Length of total message (header + payloads) in 1074 octets. Encryption can expand the size of an ISAKMP message. This 1075 issue is addressed in [IPDOI] and [IO-Res]. 1077 3.2 Payload Generic Header 1079 Each ISAKMP payload defined in sections 3.4 through 3.15 begins with a 1080 generic header, shown in Figure 3, which provides a payload "chaining" 1081 capability and clearly defines the boundaries of a payload. 1083 1 2 3 1084 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 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 ! Next Payload ! RESERVED ! Payload Length ! 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 Figure 3: Generic Payload Header 1091 The Generic Payload Header fields are defined as follows: 1093 o Next Payload (1 octet) - Identifier for the payload type of the next 1094 payload in the message. If the current payload is the last in the 1095 message, then this field will be 0. This field provides the 1096 "chaining" capability. 1098 o RESERVED (1 octet) - Unused, set to 0. 1100 o Payload Length (2 octets) - Length in octets of the current payload, 1101 including the generic payload header. 1103 3.3 Data Attributes 1105 There are several instances within ISAKMP where it is necessary to repre- 1106 sent Data Attributes. An example of this is the Security Association (SA) 1107 Attributes contained in the Transform payload (described in section 3.6). 1108 These Data Attributes are not an ISAKMP payload, but are contained within 1109 ISAKMP payloads. The format of the Data Attributes provides the flexi- 1110 bility for representation of many different types of information. There 1111 can be multiple Data Attributes within a payload. This is done using the 1112 Attribute Format bit described below. The length of the Data Attributes 1113 will either be 4 octets or defined by the Attribute Length field. Spe- 1114 cific information about the attributes for each domain will be described 1115 in a DOI document, e.g. IPSEC DOI [IPDOI]. 1117 1 2 3 1118 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 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 !A! Attribute Type ! AF=0 Attribute Length ! 1121 !F! ! AF=1 Attribute Value ! 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 . AF=0 Attribute Value . 1124 . AF=1 Not Transmitted . 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 Figure 4: Data Attributes 1129 The Data Attributes fields are defined as follows: 1131 o Attribute Type (2 octets) - Unique identifier for each type of 1132 attribute. These attributes are defined as part of the DOI-specific 1133 information. 1135 The most significant bit, or Attribute Format (AF), indicates whether 1136 the data attributes follow the Type/Length/Value (TLV) format or a 1137 shortened Type/Value (TV) format. If the AF bit is a zero (0), then 1138 the Data Attributes are of the Type/Length/Value (TLV) form. If the 1139 AF bit is a one (1), then the Data Attributes are of the Type/Value 1140 form. 1142 o Attribute Length (2 octets) - Length in octets of the Attribute 1143 Value. When the AF bit is a one (1), the Attribute Value is only 2 1144 octets and the Attribute Length field is not present. 1146 o Attribute Value (variable length) - Value of the attribute associated 1147 with the DOI-specific Attribute Type. If the AF bit is a zero (0), 1148 this field has a variable length defined by the Attribute Length 1149 field. If the Attribute Value is not aligned at a 4-byte multiple, 1150 the field is right justified and the remaining bits MUST be prepended 1151 with 0 for 4-byte alignment. If the AF bit is a one (1), the 1152 Attribute Value has a length of 2 octets. 1154 3.4 Security Association Payload 1156 The Security Association Payload is used to negotiate security attributes 1157 and to indicate the Domain of Interpretation (DOI) and Situation under 1158 which the negotiation is taking place. Figure 5 shows the format of the 1159 Security Association payload. 1161 1 2 3 1162 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 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 ! Next Payload ! RESERVED ! Payload Length ! 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 ! Domain of Interpretation (DOI) ! 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 ! ! 1169 ~ Situation ~ 1170 ! ! 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 Figure 5: Security Association Payload 1175 The Security Association Payload fields are defined as follows: 1177 o Next Payload (1 octet) - Identifier for the payload type of the next 1178 payload in the message. If the current payload is the last in the 1179 message, then this field will be 0. This field MUST NOT contain the 1180 values for the Proposal or Transform payloads as they are considered 1181 part of the security association negotiation. For example, this 1182 field would contain the value "10" (Nonce payload) in the first 1183 message of a Base Exchange (see Section 4.4) and the value "0" in the 1184 first message of an Identity Protect Exchange (see Section 4.5). 1186 o RESERVED (1 octet) - Unused, set to 0. 1188 o Payload Length (2 octets) - Length in octets of the entire Security 1189 Association payload, including the SA payload, all Proposal payloads, 1190 and all Transform payloads associated with the proposed Security 1191 Association. 1193 o Domain of Interpretation (4 octets) - Identifies the DOI (as 1194 described in Section 2.1) under which this negotiation is taking 1195 place. For the Internet, the DOI is one (1). Other DOI's can be 1196 defined using the description in appendix B. 1198 o Situation (variable length) - A DOI-specific field that identifies 1199 the situation under which this negotiation is taking place. The 1200 Situation is used to make policy decisions regarding the security 1201 attributes being negotiated. Specifics for the IETF IP Security DOI 1202 Situation are detailed in [IPDOI]. 1204 The payload type for the Security Association Payload is one (1). 1206 3.5 Proposal Payload 1208 The Proposal Payload contains information used during Security Associa- 1209 tion negotiation. The proposal consists of security mechanisms, or trans- 1210 forms, to be used to secure the communications channel. Figure 6 shows 1211 the format of the Proposal Payload. A description of its use can be found 1212 in section 4.1. 1214 1 2 3 1215 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 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 ! Next Payload ! RESERVED ! Payload Length ! 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms! 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 ! SPI (variable) ! 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 Figure 6: Proposal Payload Format 1226 The Proposal Payload fields are defined as follows: 1228 o Next Payload (1 octet) - Identifier for the payload type of the next 1229 payload in the message. This field MUST only contain the value "2" 1230 or "0". If there are additional Proposal payloads in the message, 1231 then this field will be 2. If the current Proposal payload is the 1232 last within the security association proposal, then this field will 1233 be 0. 1235 o RESERVED (1 octet) - Unused, set to 0. 1237 o Payload Length (2 octets) - Length in octets of the entire Proposal 1238 payload, including the Proposal payload, and all Transform payloads 1239 associated with this proposal. In the event there are multiple 1240 proposals with the same proposal number (see section 4.1), the 1241 Payload Length field only applies to the current Proposal payload and 1242 not to all Proposal payloads. 1244 o Proposal # (1 octet) - Identifies the Proposal number for the current 1245 payload. A description of the use of this field is found in section 1246 4.1. 1248 o Protocol-Id (1 octet) - Specifies the protocol identifier for the 1249 current negotiation. Examples might include IPSEC ESP, IPSEC AH, 1250 OSPF, TLS, etc. 1252 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 1253 Protocol-Id. 1255 o # of Transforms (1 octet) - Specifies the number of transforms for 1256 the Proposal. Each of these is contained in a Transform payload. 1258 o SPI (variable) - The sending entity's SPI. 1260 The payload type for the Proposal Payload is two (2). 1262 3.6 Transform Payload 1264 The Transform Payload contains information used during Security Associa- 1265 tion negotiation. The Transform payload consists of security mechanisms, 1266 or transforms, to be used to secure the communications channel. The 1267 Transform payload also contains the security association attributes asso- 1268 ciated with the specific transform. These SA attributes are DOI-specific. 1269 Figure 7 shows the format of the Transform Payload. A description of its 1270 use can be found in section 4.1. 1272 1 2 3 1273 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 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 ! Next Payload ! RESERVED ! Payload Length ! 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 ! Transform # ! Transform-Id ! RESERVED2 ! 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 ! ! 1280 ~ SA Attributes ~ 1281 ! ! 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 Figure 7: Transform Payload Format 1286 The Transform Payload fields are defined as follows: 1288 o Next Payload (1 octet) - Identifier for the payload type of the next 1289 payload in the message. This field MUST only contain the value "3" 1290 or "0". If there are additional Transform payloads in the proposal, 1291 then this field will be 3. If the current Transform payload is the 1292 last within the proposal, then this field will be 0. 1294 o RESERVED (1 octet) - Unused, set to 0. 1296 o Payload Length (2 octets) - Length in octets of the current payload, 1297 including the generic payload header, Transform values, and all SA 1298 Attributes. 1300 o Transform # (1 octet) - Identifies the Transform number for the 1301 current payload. If there is more than one transform proposed for a 1302 specific protocol within the Proposal payload, then each Transform 1303 payload has a unique Transform number. A description of the use of 1304 this field is found in section 4.1. 1306 o Transform-Id (1 octet) - Specifies the Transform identifier for the 1307 protocol within the current proposal. These transforms are defined 1308 by the DOI and are dependent on the protocol being negotiated. 1310 o RESERVED2 (2 octets) - Unused, set to 0. 1312 o SA Attributes (variable length) - This field contains the security 1313 association attributes as defined for the transform given in the 1314 Transform-Id field. The SA Attributes SHOULD be represented using 1315 the Data Attributes format described in section 3.3. 1317 The payload type for the Transform Payload is three (3). 1319 3.7 Key Exchange Payload 1321 The Key Exchange Payload supports a variety of key exchange techniques. 1322 Example key exchanges are Oakley [Oakley], Diffie-Hellman, the enhanced 1323 Diffie-Hellman key exchange described in X9.42 [ANSI], and the RSA-based 1324 key exchange used by PGP. Figure 8 shows the format of the Key Exchange 1325 payload. 1327 The Key Exchange Payload fields are defined as follows: 1329 o Next Payload (1 octet) - Identifier for the payload type of the next 1330 payload in the message. If the current payload is the last in the 1331 message, then this field will be 0. 1333 o RESERVED (1 octet) - Unused, set to 0. 1335 1 2 3 1336 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 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 ! Next Payload ! RESERVED ! Payload Length ! 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 ! ! 1341 ~ Key Exchange Data ~ 1342 ! ! 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 Figure 8: Key Exchange Payload Format 1347 o Payload Length (2 octets) - Length in octets of the current payload, 1348 including the generic payload header. 1350 o Key Exchange Data (variable length) - Data required to generate a 1351 session key. The interpretation of this data is specified by the DOI 1352 and the associated Key Exchange algorithm. This field may also 1353 contain pre-placed key indicators. 1355 The payload type for the Key Exchange Payload is four (4). 1357 3.8 Identification Payload 1359 The Identification Payload contains DOI-specific data used to exchange 1360 identification information. This information is used for determining the 1361 identities of communicating peers and may be used for determining authen- 1362 ticity of information. Figure 9 shows the format of the Identification 1363 Payload. 1365 The Identification Payload fields are defined as follows: 1367 o Next Payload (1 octet) - Identifier for the payload type of the next 1368 payload in the message. If the current payload is the last in the 1369 message, then this field will be 0. 1371 o RESERVED (1 octet) - Unused, set to 0. 1373 o Payload Length (2 octets) - Length in octets of the current payload, 1374 including the generic payload header. 1376 o ID Type (1 octet) - Specifies the type of Identification being used. 1377 This field is DOI-dependent. 1379 1 2 3 1380 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 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 ! Next Payload ! RESERVED ! Payload Length ! 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 ! ID Type ! RESERVED2 ! 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 ! ! 1387 ~ Identification Data ~ 1388 ! ! 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 Figure 9: Identification Payload Format 1393 o RESERVED2 (3 octets) - Unused, set to 0. 1395 o Identification Data (variable length) - Contains identity 1396 information. The values for this field are DOI-specific and the 1397 format is specified by the ID Type field. Specific details for the 1398 IETF IP Security DOI Identification Data are detailed in [IPDOI]. 1400 The payload type for the Identification Payload is five (5). 1402 3.9 Certificate Payload 1404 The Certificate Payload provides a means to transport certificates or 1405 other certificate-related information via ISAKMP and can appear in any 1406 ISAKMP message. Certificate payloads SHOULD be included in an exchange 1407 whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is 1408 not available to distribute certificates. The Certificate payload MUST be 1409 accepted at any point during an exchange. Figure 10 shows the format of 1410 the Certificate Payload. 1412 NOTE: Certificate types and formats are not generally bound to a DOI - it 1413 is expected that there will only be a few certificate types, and that most 1414 DOIs will accept all of these types. 1416 The Certificate Payload fields are defined as follows: 1418 o Next Payload (1 octet) - Identifier for the payload type of the next 1419 payload in the message. If the current payload is the last in the 1420 message, then this field will be 0. 1422 o RESERVED (1 octet) - Unused, set to 0. 1424 1 2 3 1425 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 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 ! Next Payload ! RESERVED ! Payload Length ! 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 ! Cert Encoding ! ! 1430 +-+-+-+-+-+-+-+-+ ! 1431 ~ Certificate Data ~ 1432 ! ! 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 Figure 10: Certificate Payload Format 1437 o Payload Length (2 octets) - Length in octets of the current payload, 1438 including the generic payload header. 1440 o Certificate Encoding (1 octet) - This field indicates the type of 1441 certificate or certificate-related information contained in the 1442 Certificate Data field. 1444 __________Certificate_Type___________Value___ 1445 NONE 0 1446 PKCS #7 wrapped X.509 certificate 1 1447 PGP Certificate 2 1448 DNS Signed Key 3 1449 X.509 Certificate - Signature 4 1450 X.509 Certificate - Key Exchange 5 1451 Kerberos Tokens 6 1452 Certificate Revocation List (CRL) 7 1453 Authority Revocation List (ARL) 8 1454 SPKI Certificate 9 1455 RESERVED 10- 255 1457 o Certificate Data (variable length) - Actual encoding of certificate 1458 data. The type of certificate is indicated by the Certificate 1459 Encoding field. 1461 The payload type for the Certificate Payload is six (6). 1463 3.10 Certificate Request Payload 1465 The Certificate Request Payload provides a means to request certificates 1466 via ISAKMP and can appear in any message. Certificate Request payloads 1467 SHOULD be included in an exchange whenever an appropriate directory ser- 1468 vice (e.g. Secure DNS [DNSSEC]) is not available to distribute certifi- 1469 cates. The Certificate Request payloads MUST be accepted at any point 1470 during the exchange. The responder to the Certificate Request payload 1471 MUST send its immediate certificate, if certificates are supported, and 1472 SHOULD send as much of its certificate chain as possible. Figure 11 shows 1473 the format of the Certificate Request Payload. 1475 1 2 3 1476 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 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 ! Next Payload ! RESERVED ! Payload Length ! 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 ! # Cert. Types ! ! 1481 +-+-+-+-+-+-+-+-+ ! 1482 ~ Certificate Types ~ 1483 ! ! 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 ! # Cert. Auths ! ! 1486 +-+-+-+-+-+-+-+-+ ! 1487 ~ Certificate Authorities ~ 1488 ! ! 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 Figure 11: Certificate Request Payload Format 1493 The Certificate Payload fields are defined as follows: 1495 o Next Payload (1 octet) - Identifier for the payload type of the next 1496 payload in the message. If the current payload is the last in the 1497 message, then this field will be 0. 1499 o RESERVED (1 octet) - Unused, set to 0. 1501 o Payload Length (2 octets) - Length in octets of the current payload, 1502 including the generic payload header. 1504 o # Certificate Types (1 octet) - The number of Certificate Types 1505 contained in the Certificate Types field. 1507 o Certificate Types (variable length) - Contains a list of the types of 1508 certificates requested, sorted in order of preference. Each 1509 individual certificate type is 1 octet. This field is NOT required 1510 to end on a 4-octet boundary. It is shown as ending on a 4-octet 1511 boundary in Figure 11 for drawing purposes only. 1513 o # Certificate Authorities (1 octet) - The number of Certificate Au- 1514 thorities contained in the Certificate Authorities field. This field 1515 is NOT required to begin on a 4-octet boundary. It is shown as be- 1516 ginning on a 4-octet boundary in Figure 11 for drawing purposes only. 1518 o Certificate Authorities (variable length) - Contains a list of Data 1519 Attributes (see section 3.3) which indicate the Distinguished Names 1520 of acceptable certificate authorities. See [IPDOI] for the 1521 Distinguished Name Attribute Type value. 1523 The payload type for the Certificate Request Payload is seven (7). 1525 3.11 Hash Payload 1527 The Hash Payload contains data generated by the hash function (selected 1528 during the SA establishment exchange), over some part of the message 1529 and/or ISAKMP state. This payload may be used to verify the integrity of 1530 the data in an ISAKMP message or for authentication of the negotiating en- 1531 tities. Figure 12 shows the format of the Hash Payload. 1533 1 2 3 1534 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 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 ! Next Payload ! RESERVED ! Payload Length ! 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 ! ! 1539 ~ Hash Data ~ 1540 ! ! 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 Figure 12: Hash Payload Format 1545 The Hash Payload fields are defined as follows: 1547 o Next Payload (1 octet) - Identifier for the payload type of the next 1548 payload in the message. If the current payload is the last in the 1549 message, then this field will be 0. 1551 o RESERVED (1 octet) - Unused, set to 0. 1553 o Payload Length (2 octets) - Length in octets of the current payload, 1554 including the generic payload header. 1556 o Hash Data (variable length) - Data that results from applying the 1557 hash routine to the ISAKMP message and/or state. 1559 The payload type for the Hash Payload is eight (8). 1561 3.12 Signature Payload 1563 The Signature Payload contains data generated by the digital signature 1564 function (selected during the SA establishment exchange), over some part 1565 of the message and/or ISAKMP state. This payload is used to verify the 1566 integrity of the data in the ISAKMP message, and may be of use for non- 1567 repudiation services. Figure 13 shows the format of the Signature Pay- 1568 load. 1570 1 2 3 1571 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 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 ! Next Payload ! RESERVED ! Payload Length ! 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 ! ! 1576 ~ Signature Data ~ 1577 ! ! 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 Figure 13: Signature Payload Format 1582 The Signature Payload fields are defined as follows: 1584 o Next Payload (1 octet) - Identifier for the payload type of the next 1585 payload in the message. If the current payload is the last in the 1586 message, then this field will be 0. 1588 o RESERVED (1 octet) - Unused, set to 0. 1590 o Payload Length (2 octets) - Length in octets of the current payload, 1591 including the generic payload header. 1593 o Signature Data (variable length) - Data that results from applying 1594 the digital signature function to the ISAKMP message and/or state. 1596 The payload type for the Signature Payload is nine (9). 1598 3.13 Nonce Payload 1600 The Nonce Payload contains random data used to guarantee liveness dur- 1601 ing an exchange and protect against replay attacks. Figure 14 shows the 1602 format of the Nonce Payload. If nonces are used by a particular key ex- 1603 change, the use of the Nonce payload would be dictated by the key ex- 1604 change. The nonces may be transmitted as part of the key exchange data, 1605 or as a separate payload. However, this is defined by the key exchange, 1606 not by ISAKMP. 1608 1 2 3 1609 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 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 ! Next Payload ! RESERVED ! Payload Length ! 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 ! ! 1614 ~ Nonce Data ~ 1615 ! ! 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 Figure 14: Nonce Payload Format 1620 The Nonce Payload fields are defined as follows: 1622 o Next Payload (1 octet) - Identifier for the payload type of the next 1623 payload in the message. If the current payload is the last in the 1624 message, then this field will be 0. 1626 o RESERVED (1 octet) - Unused, set to 0. 1628 o Payload Length (2 octets) - Length in octets of the current payload, 1629 including the generic payload header. 1631 o Nonce Data (variable length) - Contains the random data generated by 1632 the transmitting entity. 1634 The payload type for the Nonce Payload is ten (10). 1636 3.14 Notification Payload 1638 The Notification Payload can contain both ISAKMP and DOI-specific data and 1639 is used to transmit informational data, such as error conditions, to an 1640 ISAKMP peer. It is possible to send multiple Notification payloads in 1641 a single ISAKMP message. Figure 15 shows the format of the Notification 1642 Payload. 1644 Notification which occurs during, or is concerned with, a Phase 1 nego- 1645 tiation is identified by the Initiator and Responder cookie pair in the 1646 ISAKMP Header. The Protocol Identifier, in this case, is ISAKMP and the 1647 SPI value is 0 because the cookie pair in the ISAKMP Header identifies the 1648 ISAKMP SA. If the notification takes place prior to the completed exchange 1649 of keying information, then the notification will be unprotected. 1651 Notification which occurs during, or is concerned with, a Phase 2 nego- 1652 tiation is identified by the Initiator and Responder cookie pair in the 1653 ISAKMP Header and the Message ID and SPI associated with the current nego- 1654 tiation. One example for this type of notification is to indicate why a 1655 proposal was rejected. 1657 1 2 3 1658 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 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 ! Next Payload ! RESERVED ! Payload Length ! 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 ! Domain of Interpretation (DOI) ! 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 ! Protocol-ID ! SPI Size ! Notify Message Type ! 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 ! ! 1667 ~ Security Parameter Index (SPI) ~ 1668 ! ! 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 ! ! 1671 ~ Notification Data ~ 1672 ! ! 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 Figure 15: Notification Payload Format 1677 The Notification Payload fields are defined as follows: 1679 o Next Payload (1 octet) - Identifier for the payload type of the next 1680 payload in the message. If the current payload is the last in the 1681 message, then this field will be 0. 1683 o RESERVED (1 octet) - Unused, set to 0. 1685 o Payload Length (2 octets) - Length in octets of the current payload, 1686 including the generic payload header. 1688 o Domain of Interpretation (4 octets) - Identifies the DOI (as 1689 described in Section 2.1) under which this notification is taking 1690 place. For the Internet, the DOI is one (1). Other DOI's can be 1691 defined using the description in appendix B. 1693 o Protocol-Id (1 octet) - Specifies the protocol identifier for the 1694 current notification. Examples might include ISAKMP, IPSEC ESP, 1695 IPSEC AH, OSPF, TLS, etc. 1697 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 1698 Protocol-Id. In the case of ISAKMP, the Initiator and Responder 1699 cookie pair is the ISAKMP SPI, therefore, the SPI Size would be 16 1700 octets for the SPI. 1702 o Notify Message Type (2 octets) - Specifies the type of notification 1703 message (see section 3.14.1). Additional text, if specified by the 1704 DOI, is placed in the Notification Data field. 1706 o SPI (variable length) - Security Parameter Index. The receiving 1707 entity's SPI. The use of the SPI field is described in section 2.4. 1708 The length of this field is determined by the SPI Size field. 1710 o Notification Data (variable length) - Informational or error data 1711 transmitted in addition to the Notify Message Type. Values for this 1712 field are DOI-specific. 1714 The payload type for the Notification Payload is eleven (11). 1716 3.14.1 Notify Message Types 1718 Notification information can be error messages specifying why an SA could 1719 not be established. It can also be status data that a process managing 1720 an SA database wishes to communicate with a peer process. For example, 1721 a secure front end or security gateway may use the Notify message to syn- 1722 chronize SA communication. The table below lists the Nofitication mes- 1723 sages and their corresponding values. Values in the Private Use range are 1724 expected to be DOI-specific values. 1726 NOTIFY MESSAGES - ERROR TYPES 1728 __________Errors______________Value_____ 1729 INVALID-PAYLOAD-TYPE 1 1730 DOI-NOT-SUPPORTED 2 1731 SITUATION-NOT-SUPPORTED 3 1732 INVALID-COOKIE 4 1733 INVALID-MAJOR-VERSION 5 1734 INVALID-MINOR-VERSION 6 1735 INVALID-EXCHANGE-TYPE 7 1736 INVALID-FLAGS 8 1737 INVALID-MESSAGE-ID 9 1738 INVALID-PROTOCOL-ID 10 1739 INVALID-SPI 11 1740 INVALID-TRANSFORM-ID 12 1741 ATTRIBUTES-NOT-SUPPORTED 13 1742 NO-PROPOSAL-CHOSEN 14 1743 BAD-PROPOSAL-SYNTAX 15 1744 PAYLOAD-MALFORMED 16 1745 INVALID-KEY-INFORMATION 17 1746 INVALID-ID-INFORMATION 18 1747 INVALID-CERT-ENCODING 19 1748 INVALID-CERTIFICATE 20 1749 BAD-CERT-REQUEST-SYNTAX 21 1750 INVALID-CERT-AUTHORITY 22 1751 INVALID-HASH-INFORMATION 23 1752 AUTHENTICATION-FAILED 24 1753 INVALID-SIGNATURE 25 1754 ADDRESS-NOTIFICATION 26 1755 RESERVED (Future Use) 27-8191 1756 Private Use 8192 - 16383 1758 NOTIFY MESSAGES - STATUS TYPES 1759 ________Status_____________Value______ 1760 CONNECTED 16384 1761 RESERVED (Future Use) 16385- 24575 1762 Private Use 24576 - 32767 1764 3.15 Delete Payload 1766 The Delete Payload contains a protocol-specific security association iden- 1767 tifier that the sender has removed from its security association database 1768 and is, therefore, no longer valid. Figure 16 shows the format of the 1769 Delete Payload. It is possible to send multiple SPIs in a Delete payload, 1770 however, each SPI MUST be for the same protocol. Mixing of Protocol Iden- 1771 tifiers MUST NOT be performed with the Delete payload. 1773 Deletion which is concerned with an ISAKMP SA will contain a Protocol-Id 1774 of ISAKMP and the SPIs are the initiator and responder cookies. Deletion 1775 which is concerned with a Protocol SA, such as ESP or AH, will contain the 1776 Protocol-Id of that protocol (e.g. ESP, AH) and the SPI is the sending 1777 entity's SPI(s). 1779 NOTE: The Delete Payload is not a request for the responder to delete an 1780 SA, but an advisory from the initiator to the responder. If the responder 1781 chooses to ignore the message, the next communication from the responder 1782 to the initiator, using that security association, will fail. A responder 1783 is not expected to acknowledge receipt of a Delete payload. 1785 1 2 3 1786 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 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 ! Next Payload ! RESERVED ! Payload Length ! 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 ! Domain of Interpretation (DOI) ! 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 ! Protocol-Id ! SPI Size ! # of SPIs ! 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 ! ! 1795 ~ Security Parameter Index(es) (SPI) ~ 1796 ! ! 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 Figure 16: Delete Payload Format 1801 The Delete Payload fields are defined as follows: 1803 o Next Payload (1 octet) - Identifier for the payload type of the next 1804 payload in the message. If the current payload is the last in the 1805 message, then this field will be 0. 1807 o RESERVED (1 octet) - Unused, set to 0. 1809 o Payload Length (2 octets) - Length in octets of the current payload, 1810 including the generic payload header. 1812 o Domain of Interpretation (4 octets) - Identifies the DOI (as 1813 described in Section 2.1) under which this deletion is taking place. 1814 For the Internet, the DOI is one (1). Other DOI's can be defined 1815 using the description in appendix B. 1817 o Protocol-Id (1 octet) - ISAKMP can establish security associations 1818 for various protocols, including ISAKMP and IPSEC. This field identi- 1819 fies which security association database to apply the delete request. 1821 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 1822 Protocol-Id. In the case of ISAKMP, the Initiator and Responder 1823 cookie pair is the ISAKMP SPI. In this case, the SPI Size would be 16 1824 octets for each SPI being deleted. 1826 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 1827 payload. The size of each SPI is defined by the SPI Size field. 1829 o Security Parameter Index(es) (variable length) - Identifies the 1830 specific security association(s) to delete. Values for this field 1831 are DOI and protocol specific. The length of this field is 1832 determined by the SPI Size and # of SPIs fields. 1834 The payload type for the Delete Payload is twelve (12). 1836 4 ISAKMP Exchanges 1838 ISAKMP supplies the basic syntax of a message exchange. The basic build- 1839 ing blocks for ISAKMP messages are the payload types described in section 1840 3. This section describes the procedures for SA establishment and SA mod- 1841 ification, followed by a default set of exchanges that MAY be used for 1842 initial interoperability. Other exchanges will be defined depending on 1843 the DOI and key exchange. [IPDOI] and [?] are examples of how this is 1844 achieved. Appendix ?? explains the procedures for accomplishing these 1845 additions. 1847 4.1 Security Association Establishment 1849 The Security Association, Proposal, and Transform payloads are used to 1850 build ISAKMP messages for the negotiation and establishment of SAs. An 1851 SA establishment message consists of a single SA payload followed by at 1852 least one, and possibly many, Proposal payloads and at least one, and pos- 1853 sibly many, Transform payloads associated with each Proposal payload. Be- 1854 cause these payloads are considered together, the SA payload will point to 1855 any following payloads and not to the Proposal payload included with the 1856 SA payload. The SA Payload contains the DOI and Situation for the pro- 1857 posed SA. Each Proposal payload contains a Security Parameter Index (SPI) 1858 and ensures that the SPI is associated with the Protocol-Id in accordance 1859 with the Internet Security Architecture [RFC-1825]. Proposal payloads may 1860 or may not have the same SPI, as this is implementation dependent. Each 1861 Transform Payload contains the specific security mechanisms to be used for 1862 the designated protocol. It is expected that the Proposal and Transform 1863 payloads will be used only during SA establishment negotiation. The cre- 1864 ation of payloads for security association negotiation and establishment 1865 described here in this section are applicable for all ISAKMP exchanges de- 1866 scribed later in sections 4.4 through 4.8. The examples shown in 4.1.1 1867 contain only the SA, Proposal, and Transform payloads and do not contain 1868 other payloads that might exist for a given ISAKMP exchange. 1870 The Proposal payload provides the initiating entity with the capability 1871 to present to the responding entity the security protocols and associated 1872 security mechanisms for use with the security association being negoti- 1873 ated. If the SA establishment negotiation is for a combined protection 1874 suite consisting of multiple protocols, then there MUST be multiple Pro- 1875 posal payloads each with the same Proposal number. These proposals MUST 1876 be considered as a unit and MUST NOT be separated by a proposal with a 1877 different proposal number. The use of the same Proposal number in mul- 1878 tiple Proposal payloads provides a logical AND operation, i.e. Protocol 1879 1 AND Protocol 2. The first example below shows an ESP AND AH protection 1880 suite. If the SA establishment negotiation is for different protection 1881 suites, then there MUST be multiple Proposal payloads each with a monoton- 1882 ically increasing Proposal number. The different proposals MUST be pre- 1883 sented in the initiator's preference order. The use of different Proposal 1884 numbers in multiple Proposal payloads provides a logical OR operation, 1885 i.e. Proposal 1 OR Proposal 2, where each proposal may have more than one 1886 protocol. The second example below shows either an AH AND ESP protection 1887 suite OR just an ESP protection suite. Note that the Next Payload field 1888 of the Proposal payload points to another Proposal payload (if it exists). 1889 The existence of a Proposal payload implies the existence of one or more 1890 Transform payloads. 1892 The Transform payload provides the initiating entity with the capability 1893 to present to the responding entity multiple mechanisms, or transforms, 1894 for a given protocol. The Proposal payload identifies a Protocol for 1895 which services and mechanisms are being negotiated. The Transform pay- 1896 load allows the initiating entity to present several possible supported 1897 transforms for that proposed protocol. There may be several transforms 1898 associated with a specific Proposal payload each identified in a separate 1899 Transform payload. The multiple transforms MUST be presented with mono- 1900 tonically increasing numbers in the initiator's preference order. The 1901 receiving entity MUST select a single transform for each protocol in a 1902 proposal or reject the entire proposal. The use of the Transform num- 1903 ber in multiple Transform payloads provides a second level OR operation, 1904 i.e. Transform 1 OR Transform 2 OR Transform 3. Example 1 below shows 1905 two possible transforms for ESP and a single transform for AH. Example 2 1906 below shows one transform for AH AND one transform for ESP OR two trans- 1907 forms for ESP alone. Note that the Next Payload field of the Transform 1908 payload points to another Transform payload or 0. The Proposal payload 1909 delineates the different proposals. 1911 When responding to a Security Association payload, the responder MUST send 1912 a Security Association payload with the selected proposal, which may con- 1913 sist of multiple Proposal payloads and their associated Transform pay- 1914 loads. Each of the Proposal payloads MUST contain a single Transform 1915 payload associated with the Protocol. The responder SHOULD retain the 1916 Proposal # field in the Proposal payload and the Transform # field in 1917 each Transform payload of the selected Proposal. Retention of Proposal 1918 and Transform numbers should speed the initiator's protocol processing by 1919 negating the need to compare the respondor's selection with every offered 1920 option. These values enable the initiator to perform the comparison di- 1921 rectly and quickly. The initiator MUST verify that the Security Associa- 1922 tion payload received from the responder matches one of the proposals sent 1923 initially. 1925 4.1.1 Security Association Establishment Examples 1927 This example shows a Proposal for a combined protection suite with two 1928 different protocols. The first protocol is presented with two transforms 1929 supported by the proposer. The second protocol is presented with a sin- 1930 gle transform. An example for this proposal might be: Protocol 1 is ESP 1931 with Transform 1 as 3DES and Transform 2 as DES AND Protocol 2 is AH with 1932 Transform 1 as SHA. The responder MUST select from the two transforms pro- 1933 posed for ESP. The resulting protection suite will be either (1) 3DES AND 1934 SHA OR (2) DES AND SHA, depending on which ESP transform was selected by 1935 the responder. Note this example is shown using the Base Exchange. 1937 1 2 3 1938 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 1939 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 / ! NP = Nonce ! RESERVED ! Payload Length ! 1941 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1942 SA Pay ! Domain of Interpretation (DOI) ! 1943 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 \ ! Situation ! 1945 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1946 / ! NP = Proposal ! RESERVED ! Payload Length ! 1947 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans. = 2! 1949 Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1950 \ ! SPI (variable) ! 1951 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 / ! NP = Transform! RESERVED ! Payload Length ! 1953 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 1955 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 \ ! SA Attributes ! 1957 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 / ! NP = 0 ! RESERVED ! Payload Length ! 1959 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! 1961 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 \ ! SA Attributes ! 1963 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 / ! NP = 0 ! RESERVED ! Payload Length ! 1965 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! 1968 Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 \ ! SPI (variable) ! 1970 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 / ! NP = 0 ! RESERVED ! Payload Length ! 1972 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 1974 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 \ ! SA Attributes ! 1976 \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 This second example shows a Proposal for two different protection suites. 1979 The SA Payload was omitted for space reasons. The first protection suite 1980 is presented with one transform for the first protocol and one transform 1981 for the second protocol. The second protection suite is presented with 1982 two transforms for a single protocol. An example for this proposal might 1983 be: Proposal 1 with Protocol 1 as AH with Transform 1 as MD5 AND Protocol 1984 2 as ESP with Transform 1 as 3DES. This is followed by Proposal 2 with 1985 Protocol 1 as ESP with Transform 1 as DES and Transform 2 as 3DES. The 1986 responder MUST select from the two different proposals. If the second 1987 Proposal is selected, the responder MUST select from the two transforms 1988 for ESP. The resulting protection suite will be either (1) MD5 AND 3DES OR 1989 the selection between (2) DES OR (3) 3DES. 1991 1 2 3 1992 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 1993 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 / ! NP = Proposal ! RESERVED ! Payload Length ! 1995 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1996 Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! 1997 Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 \ ! SPI (variable) ! 1999 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 / ! NP = 0 ! RESERVED ! Payload Length ! 2001 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 2003 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 \ ! SA Attributes ! 2005 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 / ! NP = Proposal ! RESERVED ! Payload Length ! 2007 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! 2009 Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 \ ! SPI (variable) ! 2011 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 / ! NP = 0 ! RESERVED ! Payload Length ! 2013 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2014 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 2015 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 \ ! SA Attributes ! 2017 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 / ! NP = 0 ! RESERVED ! Payload Length ! 2019 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 Prop 2 ! Proposal # = 2! Protocol ID ! SPI Size !# of Trans. = 2! 2021 Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 \ ! SPI (variable) ! 2023 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 / ! NP = Transform! RESERVED ! Payload Length ! 2025 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 2027 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2028 \ ! SA Attributes ! 2029 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 / ! NP = 0 ! RESERVED ! Payload Length ! 2031 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! 2033 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 \ ! SA Attributes ! 2035 \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 4.2 Security Association Modification 2039 Security Association modification within ISAKMP is accomplished by cre- 2040 ating a new SA and initiating communications using that new SA. Deletion 2041 of the old SA can be done anytime after the new SA is established. Dele- 2042 tion of the old SA is dependent on local security policy. Modification of 2043 SAs by using a "Create New SA followed by Delete Old SA" method is done to 2044 avoid potential vulnerabilities in synchronizing modification of existing 2045 SA attributes. The procedures for creating new SAs is outlined in section 2046 4.1. The procedures for deleting SAs is outlined in section 5.13. 2048 Modification of an ISAKMP SA (phase 1 negotiation) follows the same proce- 2049 dure as creation of an ISAKMP SA. There is no relationship between the two 2050 SAs and the initiator and responder cookie pairs SHOULD be different, as 2051 outlined in section 2.5.3. 2053 Modification of a Protocol SA (phase 2 negotiation) follows the same pro- 2054 cedure as creation of a Protocol SA. The creation of a new SA is protected 2055 by the existing ISAKMP SA. There is no relationship between the two Proto- 2056 col SAs. A protocol implementation SHOULD begin using the newly created 2057 SA for outbound traffic and SHOULD continue to support incoming traffic on 2058 the old SA until it is deleted. 2060 4.3 ISAKMP Exchange Types 2062 ISAKMP allows the creation of exchanges for the establishment of Security 2063 Associations and keying material. There are currently five default Ex- 2064 change Types defined for ISAKMP. Sections 4.4 through 4.8 describe these 2065 exchanges. Exchanges define the content and ordering of ISAKMP messages 2066 during communications between peers. Most exchanges will include all the 2067 basic payload types - SA, KE, ID, SIG - and may include others. The pri- 2068 mary difference between exchange types is the ordering of the messages 2069 and the payload ordering within each message. Processing of each payload 2070 within an exchange is described in section 5. 2072 Sections 4.4 through 4.8 provide a default set of ISAKMP exchanges. These 2073 exchanges provide different security protection for the exchange itself 2074 and information exchanged. The diagrams in each of the following sections 2075 show the message ordering for each exchange type as well as the payloads 2076 included in each message, and provide basic notes describing what has hap- 2077 pened after each message exchange. None of the examples include any "op- 2078 tional payloads", like certificate and certificate request. Additionally, 2079 none of the examples include an initial exchange of ISAKMP Headers (con- 2080 taining initiator and responder cookies) which would provide protection 2081 against clogging (see section 2.5.3). 2083 The defined exchanges are not meant to satisfy all DOI and key exchange 2084 protocol requirements. If the defined exchanges meet the DOI require- 2085 ments, then they can be used as outlined. If the defined exchanges do 2086 not meet the security requirements defined by the DOI, then the DOI MUST 2087 specify new exchange type(s) and the valid sequences of payloads that make 2088 up a successful exchange, and how to build and interpret those payloads. 2089 All ISAKMP implementations MUST implement the Informational Exchange and 2090 SHOULD implement the other four exchanges. However, this is dependent on 2091 the definition of the DOI and associated key exchange protocols. 2093 As discussed above, these exchange types can be used in either phase of 2094 negotiation. However, they may provide different security properties 2095 in each of the phases. With each of these exchanges, the combination of 2096 cookies and SPI fields identifies whether this exchange is being used in 2097 the first or second phase of a negotiation. 2099 4.3.1 Notation 2101 The following notation is used to describe the ISAKMP exchange types, 2102 shown in the next section, with the message formats and associated pay- 2103 loads: 2105 HDR is an ISAKMP header whose exchange type defines the payload orderings 2106 SA is an SA negotiation payload with one or more Proposal and 2107 Transform payloads. An initiator MAY provide multiple proposals 2108 for negotiation; a responder MUST reply with only one. 2109 KE is the key exchange payload. 2110 IDx is the identity payload for "x". x can be: "ii" or "ir" 2111 for the ISAKMP initiator and responder, respectively, or x can 2112 be: "ui", "ur" (when the ISAKMP daemon is a proxy negotiator), 2113 for the user initiator and responder, respectively. 2114 HASH is the hash payload. 2115 SIG is the signature payload. The data to sign is exchange-specific. 2116 AUTH is a generic authentication mechanism, such as HASH or SIG. 2117 NONCE is the nonce payload. 2118 '*' signifies payload encryption after the ISAKMP header. This 2119 encryption MUST begin immediately after the ISAKMP header and 2120 all payloads following the ISAKMP header MUST be encrypted. 2122 => signifies "initiator to responder" communication 2123 <= signifies "responder to initiator" communication 2125 4.4 Base Exchange 2127 The Base Exchange is designed to allow the Key Exchange and Authentica- 2128 tion related information to be transmitted together. Combining the Key 2129 Exchange and Authentication-related information into one message reduces 2130 the number of round-trips at the expense of not providing identity pro- 2131 tection. Identity protection is not provided because identities are ex- 2132 changed before a common shared secret has been established and, therefore, 2133 encryption of the identities is not possible. The following diagram shows 2134 the messages with the possible payloads sent in each message and notes for 2135 an example of the Base Exchange. 2137 BASE EXCHANGE 2139 _#______Initiator____Direction_____Responder______________________NOTE____________________ 2140 (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation 2142 (2) <= HDR; SA; NONCE 2143 Basic SA agreed upon 2144 (3) HDR; KE; => 2145 IDii; AUTH Key Generated 2146 Initiator Identity Verified by Responder 2147 (4) <= HDR; KE; 2148 IDir; AUTH 2149 Responder Identity Verified by Initiator 2150 Key Generated 2151 SA established 2153 In the first message (1), the initiator generates a proposal it considers 2154 adequate to protect traffic for the given situation. The Security Associ- 2155 ation, Proposal, and Transform payloads are included in the Security Asso- 2156 ciation payload (for notation purposes). Random information which is used 2157 to guarantee liveness and protect against replay attacks is also trans- 2158 mitted. Random information provided by both parties SHOULD be used by the 2159 authentication mechanism to provide shared proof of participation in the 2160 exchange. 2162 In the second message (2), the responder indicates the protection suite it 2163 has accepted with the Security Association, Proposal, and Transform pay- 2164 loads. Again, random information which is used to guarantee liveness and 2165 protect against replay attacks is also transmitted. Random information 2166 provide by both parties SHOULD be used by the authentication mechanism 2167 to provide shared proof of participation in the exchange. Local secu- 2168 rity policy dictates the action of the responder if no proposed protection 2169 suite is accepted. One possible action is the transmission of a Notify 2170 payload as part of an Informational Exchange. 2172 In the third (3) and fourth (4) messages, the initiator and responder, re- 2173 spectively, exchange keying material used to arrive at a common shared 2174 secret and identification information. This information is transmitted 2175 under the protection of the agreed upon authentication function. Local 2176 security policy dictates the action if an error occurs during these mes- 2177 sages. One possible action is the transmission of a Notify payload as 2178 part of an Informational Exchange. 2180 4.5 Identity Protection Exchange 2182 The Identity Protection Exchange is designed to separate the Key Exchange 2183 information from the Identity and Authentication related information. 2184 Separating the Key Exchange from the Identity and Authentication related 2185 information provides protection of the communicating identities at the ex- 2186 pense of an additional message. Identities are exchanged under the pro- 2187 tection of a previously established common shared secret. The following 2188 diagram shows the messages with the possible payloads sent in each message 2189 and notes for an example of the Identity Protection Exchange. 2191 IDENTITY PROTECTION EXCHANGE 2193 _#_______Initiator_____Direction______Responder_____NOTE______________________________________ 2194 (1) HDR; SA => Begin ISAKMP-SA or Proxy negotiation 2195 (2) <= HDR; SA 2196 Basic SA agreed upon 2197 (3) HDR; KE; NONCE => 2198 (4) <= HDR; KE; NONCE 2199 Key Generated 2200 (5) HDR*; IDii; AUTH => 2201 Initiator Identity Verified by Responder 2202 (6) <= HDR*; IDir; AUTH 2203 Responder Identity Verified by Initiator 2204 SA established 2206 In the first message (1), the initiator generates a proposal it consid- 2207 ers adequate to protect traffic for the given situation. The Security As- 2208 sociation, Proposal, and Transform payloads are included in the Security 2209 Association payload (for notation purposes). 2211 In the second message (2), the responder indicates the protection suite it 2212 has accepted with the Security Association, Proposal, and Transform pay- 2213 loads. Local security policy dictates the action of the responder if no 2214 proposed protection suite is accepted. One possible action is the trans- 2215 mission of a Notify payload as part of an Informational Exchange. 2217 In the third (3) and fourth (4) messages, the initiator and responder, re- 2218 spectively, exchange keying material used to arrive at a common shared se- 2219 cret and random information which is used to guarantee liveness and pro- 2220 tect against replay attacks. Random information provided by both parties 2221 SHOULD be used by the authentication mechanism to provide shared proof 2222 of participation in the exchange. Local security policy dictates the ac- 2223 tion if an error occurs during these messages. One possible action is the 2224 transmission of a Notify payload as part of an Informational Exchange. 2226 In the fifth (5) and sixth (6) messages, the initiator and responder, re- 2227 spectively, exchange identification information and the results of the 2228 agreed upon authentication function. This information is transmitted un- 2229 der the protection of the common shared secret. Local security policy 2230 dictates the action if an error occurs during these messages. One pos- 2231 sible action is the transmission of a Notify payload as part of an Infor- 2232 mational Exchange. 2234 4.6 Authentication Only Exchange 2236 The Authentication Only Exchange is designed to allow only Authentication 2237 related information to be transmitted. The benefit of this exchange is 2238 the ability to perform only authentication without the computational ex- 2239 pense of computing keys. Using this exchange during negotiation, none of 2240 the transmitted information will be encrypted. However, the information 2241 may be encrypted in other places. For example, if encryption is negoti- 2242 ated during the first phase of a negotiation and the authentication only 2243 exchange is used in the second phase of a negotiation, then the authenti- 2244 cation only exchange will be encrypted by the ISAKMP SAs negotiated in the 2245 first phase. The following diagram shows the messages with possible pay- 2246 loads sent in each message and notes for an example of the Authentication 2247 Only Exchange. 2249 AUTHENTICATION ONLY EXCHANGE 2251 _#______Initiator_____Direction_____Responder_______________________NOTE____________________ 2252 (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation 2254 (2) <= HDR; SA; NONCE; 2255 IDir; AUTH 2256 Basic SA agreed upon 2257 Responder Identity Verified by Initiator 2258 (3) HDR; IDii; AUTH => 2259 Initiator Identity Verified by Responder 2260 SA established 2262 In the first message (1), the initiator generates a proposal it considers 2263 adequate to protect traffic for the given situation. The Security Associ- 2264 ation, Proposal, and Transform payloads are included in the Security Asso- 2265 ciation payload (for notation purposes). Random information which is used 2266 to guarantee liveness and protect against replay attacks is also trans- 2267 mitted. Random information provided by both parties SHOULD be used by the 2268 authentication mechanism to provide shared proof of participation in the 2269 exchange. 2271 In the second message (2), the responder indicates the protection suite it 2272 has accepted with the Security Association, Proposal, and Transform pay- 2273 loads. Again, random information which is used to guarantee liveness and 2274 protect against replay attacks is also transmitted. Random information 2275 provided by both parties SHOULD be used by the authentication mechanism 2276 to provide shared proof of participation in the exchange. Additionally, 2277 the responder transmits identification information. All of this infor- 2278 mation is transmitted under the protection of the agreed upon authentica- 2279 tion function. Local security policy dictates the action of the responder 2280 if no proposed protection suite is accepted. One possible action is the 2281 transmission of a Notify payload as part of an Informational Exchange. 2283 In the third message (3), the initiator transmits identification informa- 2284 tion. This information is transmitted under the protection of the agreed 2285 upon authentication function. Local security policy dictates the action 2286 if an error occurs during these messages. One possible action is the 2287 transmission of a Notify payload as part of an Informational Exchange. 2289 4.7 Aggressive Exchange 2291 The Aggressive Exchange is designed to allow the Security Association, Key 2292 Exchange and Authentication related payloads to be transmitted together. 2293 Combining the Security Association, Key Exchange, and Authentication- 2294 related information into one message reduces the number of round-trips at 2295 the expense of not providing identity protection. Identity protection is 2296 not provided because identities are exchanged before a common shared se- 2297 cret has been established and, therefore, encryption of the identities is 2298 not possible. Additionally, the Aggressive Exchange is attempting to es- 2299 tablish all security relevant information in a single exchange. The fol- 2300 lowing diagram shows the messages with possible payloads sent in each mes- 2301 sage and notes for an example of the Aggressive Exchange. 2303 AGGRESSIVE EXCHANGE 2305 _#_____Initiator___Direction______Responder________________________NOTE____________________ 2306 (1) HDR; SA; KE; => Begin ISAKMP-SA or Proxy negotiation 2307 NONCE; IDii and Key Exchange 2309 (2) <= HDR; SA; KE; 2310 NONCE; IDir; AUTH 2311 Initiator Identity Verified by Responder 2312 Key Generated 2313 Basic SA agreed upon 2314 (3) HDR*; AUTH => 2315 Responder Identity Verified by Initiator 2316 SA established 2318 In the first message (1), the initiator generates a proposal it consid- 2319 ers adequate to protect traffic for the given situation. The Security 2320 Association, Proposal, and Transform payloads are included in the Secu- 2321 rity Association payload (for notation purposes). Keying material used 2322 to arrive at a common shared secret and random information which is used 2323 to guarantee liveness and protect against replay attacks are also trans- 2324 mitted. Random information provided by both parties SHOULD be used by the 2325 authentication mechanism to provide shared proof of participation in the 2326 exchange. Additionally, the initiator transmits identification informa- 2327 tion. 2329 In the second message (2), the responder indicates the protection suite 2330 it has accepted with the Security Association, Proposal, and Transform 2331 payloads. Keying material used to arrive at a common shared secret and 2332 random information which is used to guarantee liveness and protect against 2333 replay attacks is also transmitted. Random information provided by both 2334 parties SHOULD be used by the authentication mechanism to provide shared 2335 proof of participation in the exchange. Additionally, the responder 2336 transmits identification information. All of this information is trans- 2337 mitted under the protection of the agreed upon authentication function. 2338 Local security policy dictates the action of the responder if no proposed 2339 protection suite is accepted. One possible action is the transmission of 2340 a Notify payload as part of an Informational Exchange. 2342 In the third (3) message, the initiator transmits the results of the 2343 agreed upon authentication function. This information is transmitted un- 2344 der the protection of the common shared secret. Local security policy 2345 dictates the action if an error occurs during these messages. One pos- 2346 sible action is the transmission of a Notify payload as part of an Infor- 2347 mational Exchange. 2349 4.8 Informational Exchange 2351 The Informational Exchange is designed as a one-way transmittal of infor- 2352 mation that can be used for security association management. The follow- 2353 ing diagram shows the messages with possible payloads sent in each message 2354 and notes for an example of the Informational Exchange. 2356 INFORMATIONAL EXCHANGE 2358 __#___Initiator__Direction_Responder_______________NOTE_______________ 2359 (1) HDR*; N/D => Error Notification or Deletion 2361 In the first message (1), the initiator or responder transmits an ISAKMP 2362 Notify or Delete payload. 2364 If the Informational Exchange occurs during an ISAKMP Phase 1 negotiation 2365 there will be no protection provided for the Informational Exchange. Once 2366 keying material has been exchanged or an ISAKMP SA has been established, 2367 the Informational Exchange MUST be transmitted under the protection pro- 2368 vided by the keying material or the ISAKMP SA. 2370 5 ISAKMP Payload Processing 2372 Section 3 describes the ISAKMP payloads. These payloads are used in the 2373 exchanges described in section 4 and can be used in exchanges defined for 2374 a specific DOI. This section describes the processing for each of the 2375 payloads. This section suggests the logging of events to a system au- 2376 dit file. This action is controlled by a system security policy and is, 2377 therefore, only a suggested action. 2379 5.1 General Message Processing 2381 Every ISAKMP message has basic processing applied to insure protocol re- 2382 liability, and to minimize threats, such as denial of service and replay 2383 attacks. 2385 When transmitting an ISAKMP message, the transmitting entity (initiator or 2386 responder) MUST do the following: 2388 1. Set a timer and initialize a retry counter. 2390 2. If the timer expires, the ISAKMP message is resent and the retry 2391 counter is decremented. 2393 3. If the retry counter reaches zero (0), the event, RETRY LIMIT 2394 REACHED, is logged in the appropriate system audit file. 2396 4. The ISAKMP protocol machine clears all states and returns to IDLE. 2398 5.2 ISAKMP Header Processing 2400 When creating an ISAKMP message, the transmitting entity MUST do the fol- 2401 lowing: 2403 1. Create the respective cookie. See section 2.5.3 for details. 2405 2. Determine the relevant security characteristics of the session (i.e. 2406 DOI and situation). 2408 3. Construct an ISAKMP Header with fields as described in section 3.1. 2410 4. Construct other ISAKMP payloads, depending on the exchange type. 2412 5. Transmit the message to the destination host as described in section 2413 5.1. 2415 When an ISAKMP message is received, the receiving entity (initiator or 2416 responder) MUST do the following: 2418 1. Verify the Initiator and Responder ``cookies''. If the cookie 2419 validation fails, the message is discarded and the following actions 2420 are taken: 2422 (a) The event, INVALID COOKIE, is logged in the appropriate system 2423 audit file. 2425 (b) An Informational Exchange with a Notification payload containing 2426 the INVALID-COOKIE message type MAY be sent to the initiating 2427 entity. This action is dictated by a system security policy. 2429 2. Check the Next Payload field to confirm it is valid. If the Next 2430 Payload field validation fails, the message is discarded and the 2431 following actions are taken: 2433 (a) The event, INVALID NEXT PAYLOAD, is logged in the appropriate 2434 system audit file. 2436 (b) An Informational Exchange with a Notification payload containing 2437 the INVALID-PAYLOAD-TYPE message type MAY be sent to the initiat- 2438 ing entity. This action is dictated by a system security policy. 2440 3. Check the Major and Minor Version fields to confirm they are correct. 2441 If the Version field validation fails, the message is discarded and 2442 the following actions are taken: 2444 (a) The event, INVALID ISAKMP VERSION, is logged in the appropriate 2445 system audit file. 2447 (b) An Informational Exchange with a Notification payload containing 2448 the INVALID-MAJOR-VERSION or INVALID-MINOR-VERSION message type 2449 MAY be sent to the initiating entity. This action is dictated by 2450 a system security policy. 2452 4. Check the Exchange Type field to confirm it is valid. If the 2453 Exchange Type field validation fails, the message is discarded and 2454 the following actions are taken: 2456 (a) The event, INVALID EXCHANGE TYPE, is logged in the appropriate 2457 system audit file. 2459 (b) An Informational Exchange with a Notification payload containing 2460 the INVALID-EXCHANGE-TYPE message type MAY be sent to the 2461 initiating entity. This action is dictated by a system security 2462 policy. 2464 5. Check the Flags field to ensure it contains correct values. If the 2465 Flags field validation fails, the message is discarded and the 2466 following actions are taken: 2468 (a) The event, INVALID FLAGS, is logged in the appropriate system 2469 audit file. 2471 (b) An Informational Exchange with a Notification payload containing 2472 the INVALID-FLAGS message type MAY be sent to the initiating 2473 entity. This action is dictated by a system security policy. 2475 6. Check the Message ID field to ensure it contains correct values. If 2476 the Message ID validation fails, the message is discarded and the 2477 following actions are taken: 2479 (a) The event, INVALID MESSAGE ID, is logged in the appropriate 2480 system audit file. 2482 (b) An Informational Exchange with a Notification payload containing 2483 the INVALID-MESSAGE-ID message type MAY be sent to the initiating 2484 entity. This action is dictated by a system security policy. 2486 7. Processing of the ISAKMP message continues using the value in the 2487 Next Payload field. 2489 5.3 Generic Payload Header Processing 2491 When creating any of the ISAKMP Payloads described in sections 5.4 through 2492 5.13 a Generic Payload Header is placed at the beginning of these pay- 2493 loads. When creating the Generic Payload Header, the transmitting entity 2494 MUST do the following: 2496 1. Place the value of the Next Payload in the Next Payload field. These 2497 values are described in section 3.1. 2499 2. Place the value zero (0) in the RESERVED field. 2501 3. Place the length (in octets) of the payload in the Payload Length 2502 field. 2504 4. Construct the payloads as defined in the remainder of this section. 2506 When any of the ISAKMP Payloads are received, the receiving entity (ini- 2507 tiator or responder) MUST do the following: 2509 1. Check the Next Payload field to confirm it is valid. If the Next 2510 Payload field validation fails, the message is discarded and the 2511 following actions are taken: 2513 (a) The event, INVALID NEXT PAYLOAD, is logged in the appropriate 2514 system audit file. 2516 (b) An Informational Exchange with a Notification payload containing 2517 the INVALID-PAYLOAD-TYPE message type MAY be sent to the initiat- 2518 ing entity. This action is dictated by a system security policy. 2520 2. Verify the RESERVED field contains the value zero. If the value in 2521 the RESERVED field is not zero, the message is discarded and the 2522 following actions are taken: 2524 (a) The event, INVALID RESERVED FIELD, is logged in the appropriate 2525 system audit file. 2527 (b) An Informational Exchange with a Notification payload containing 2528 the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be 2529 sent to the initiating entity. This action is dictated by a 2530 system security policy. 2532 3. Process the remaining payloads as defined by the Next Payload field. 2534 5.4 Security Association Payload Processing 2536 When creating a Security Association Payload, the transmitting entity MUST 2537 do the following: 2539 1. Determine the Domain of Interpretation for which this negotiation is 2540 being performed. 2542 2. Determine the situation within the determined DOI for which this 2543 negotiation is being performed. 2545 3. Determine the proposal(s) and transform(s) within the situation. 2546 These are described, respectively, in sections 3.5, 5.4.1, 3.6, and 2547 5.4.2. 2549 4. Construct a Security Association payload. 2551 5. Transmit the message to the receiving entity as described in section 2552 5.1. 2554 When a Security Association payload is received, the receiving entity 2555 (initiator or responder) MUST do the following: 2557 1. Determine if the Domain of Interpretation (DOI) is supported. If the 2558 DOI determination fails, the message is discarded and the following 2559 actions are taken: 2561 (a) The event, INVALID DOI, is logged in the appropriate system audit 2562 file. 2564 (b) An Informational Exchange with a Notification payload containing 2565 the DOI-NOT-SUPPORTED message type MAY be sent to the initiating 2566 entity. This action is dictated by a system security policy. 2568 2. Determine if the given situation can be protected. If the Situation 2569 determination fails, the message is discarded and the following 2570 actions are taken: 2572 (a) The event, INVALID SITUATION, is logged in the appropriate system 2573 audit file. 2575 (b) An Informational Exchange with a Notification payload containing 2576 the SITUATION-NOT-SUPPORTED message type MAY be sent to the 2577 initiating entity. This action is dictated by a system security 2578 policy. 2580 3. Process the remaining payloads (i.e. Proposal, Transform) of the 2581 Security Association Payload. If the Security Association Proposal 2582 (as described in sections 5.4.1 and 5.4.2) is not accepted, then the 2583 following actions are taken: 2585 (a) The event, INVALID PROPOSAL, is logged in the appropriate system 2586 audit file. 2588 (b) An Informational Exchange with a Notification payload containing 2589 the NO-PROPOSAL-CHOSEN message type MAY be sent to the initiating 2590 entity. This action is dictated by a system security policy. 2592 5.4.1 Proposal Payload Processing 2594 When creating a Proposal Payload, the transmitting entity MUST do the fol- 2595 lowing: 2597 1. Determine the Protocol for this proposal. 2599 2. Determine the number of proposals to be offered for this protocol and 2600 the number of transforms for each proposal. Transforms are described 2601 in sections 3.6 and 5.4.2. 2603 3. Generate a unique pseudo-random SPI. 2605 4. Construct a Proposal payload. 2607 When a Proposal payload is received, the receiving entity (initiator or 2608 responder) MUST do the following: 2610 1. Determine if the Protocol is supported. If the Protocol-ID field is 2611 invalid, the message is discarded and the following actions are 2612 taken: 2614 (a) The event, INVALID PROTOCOL, is logged in the appropriate system 2615 audit file. 2617 (b) An Informational Exchange with a Notification payload containing 2618 the INVALID-PROTOCOL-ID message type MAY be sent to the initiat- 2619 ing entity. This action is dictated by a system security policy. 2621 2. Determine if the SPI is valid. If the SPI is invalid, the message is 2622 discarded and the following actions are taken: 2624 (a) The event, INVALID SPI, is logged in the appropriate system audit 2625 file. 2627 (b) An Informational Exchange with a Notification payload containing 2628 the INVALID-SPI message type MAY be sent to the initiating 2629 entity. This action is dictated by a system security policy. 2631 3. Ensure the Proposals are presented according to the details given in 2632 section 3.5 and 4.1. If the proposals are not formed correctly, the 2633 following actions are taken: 2635 (a) Possible events, BAD PROPOSAL SYNTAX, INVALID PROPOSAL, are 2636 logged in the appropriate system audit file. 2638 (b) An Informational Exchange with a Notification payload containing 2639 the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be 2640 sent to the initiating entity. This action is dictated by a 2641 system security policy. 2643 4. Process the Proposal and Transform payloads as defined by the Next 2644 Payload field. Examples of processing these payloads is given in 2645 section 4.1.1. 2647 5.4.2 Transform Payload Processing 2649 When creating a Transform Payload, the transmitting entity MUST do the 2650 following: 2652 1. Determine the Transform # for this transform. 2654 2. Determine the number of transforms to be offered for this proposal. 2655 Transforms are described in sections 3.6. 2657 3. Construct a Transform payload. 2659 When a Transform payload is received, the receiving entity (initiator or 2660 responder) MUST do the following: 2662 1. Determine if the Transform is supported. If the Transform-ID field 2663 is invalid, the message is discarded and the following actions are 2664 taken: 2666 (a) The event, INVALID TRANSFORM, is logged in the appropriate system 2667 audit file. 2669 (b) An Informational Exchange with a Notification payload containing 2670 the INVALID-TRANSFORM-ID message type MAY be sent to the initiat- 2671 ing entity. This action is dictated by a system security policy. 2673 2. Ensure the Transforms are presented according to the details given in 2674 section 3.6 and 4.1. If the transforms are not formed correctly, the 2675 following actions are taken: 2677 (a) Possible events, BAD PROPOSAL SYNTAX, INVALID TRANSFORM, INVALID 2678 ATTRIBUTES, are logged in the appropriate system audit file. 2680 (b) An Informational Exchange with a Notification payload containing 2681 the BAD-PROPOSAL-SYNTAX, PAYLOAD-MALFORMED or ATTRIBUTES-NOT- 2682 SUPPORTED message type MAY be sent to the initiating entity. 2683 This action is dictated by a system security policy. 2685 3. Process the subsequent Transform and Proposal payloads as defined by 2686 the Next Payload field. Examples of processing these payloads is 2687 given in section 4.1.1. 2689 5.5 Key Exchange Payload Processing 2691 When creating a Key Exchange Payload, the transmitting entity MUST do the 2692 following: 2694 1. Determine the Key Exchange to be used as defined by the DOI. 2696 2. Determine the usage of the Key Exchange Data field as defined by the 2697 DOI. 2699 3. Construct a Key Exchange payload. 2701 4. Transmit the message to the receiving entity as described in section 2702 5.1. 2704 When a Key Exchange payload is received, the receiving entity (initiator 2705 or responder) MUST do the following: 2707 1. Determine if the Key Exchange is supported. If the Key Exchange 2708 determination fails, the message is discarded and the following 2709 actions are taken: 2711 (a) The event, INVALID KEY INFORMATION, is logged in the appropriate 2712 system audit file. 2714 (b) An Informational Exchange with a Notification payload containing 2715 the INVALID-KEY-INFORMATION message type MAY be sent to the 2716 initiating entity. This action is dictated by a system security 2717 policy. 2719 5.6 Identification Payload Processing 2721 When creating an Identification Payload, the transmitting entity MUST do 2722 the following: 2724 1. Determine the Identification information to be used as defined by the 2725 DOI (and possibly the situation). 2727 2. Determine the usage of the Identification Data field as defined by 2728 the DOI. 2730 3. Construct an Identification payload. 2732 4. Transmit the message to the receiving entity as described in section 2733 5.1. 2735 When an Identification payload is received, the receiving entity (initia- 2736 tor or responder) MUST do the following: 2738 1. Determine if the Identification Type is supported. This may be based 2739 on the DOI and Situation. If the Identification determination fails, 2740 the message is discarded and the following actions are taken: 2742 (a) The event, INVALID ID INFORMATION, is logged in the appropriate 2743 system audit file. 2745 (b) An Informational Exchange with a Notification payload containing 2746 the INVALID-ID-INFORMATION message type MAY be sent to the 2747 initiating entity. This action is dictated by a system security 2748 policy. 2750 5.7 Certificate Payload Processing 2752 When creating a Certificate Payload, the transmitting entity MUST do the 2753 following: 2755 1. Determine the Certificate Encoding to be used. This may be specified 2756 by the DOI. 2758 2. Ensure the existence of a certificate formatted as defined by the 2759 Certificate Encoding. 2761 3. Construct a Certificate payload. 2763 4. Transmit the message to the receiving entity as described in section 2764 5.1. 2766 When a Certificate payload is received, the receiving entity (initiator or 2767 responder) MUST do the following: 2769 1. Determine if the Certificate Encoding is supported. If the 2770 Certificate Encoding is not supported, the message is discarded and 2771 the following actions are taken: 2773 (a) The event, INVALID CERTIFICATE TYPE, is logged in the appropriate 2774 system audit file. 2776 (b) An Informational Exchange with a Notification payload containing 2777 the INVALID-CERT-ENCODING message type MAY be sent to the 2778 initiating entity. This action is dictated by a system security 2779 policy. 2781 2. Process the Certificate Data field. If the Certificate Data is 2782 invalid or improperly formatted, the message is discarded and the 2783 following actions are taken: 2785 (a) The event, INVALID CERTIFICATE, is logged in the appropriate 2786 system audit file. 2788 (b) An Informational Exchange with a Notification payload containing 2789 the INVALID-CERTIFICATE message type MAY be sent to the initiat- 2790 ing entity. This action is dictated by a system security policy. 2792 5.8 Certificate Request Payload Processing 2794 When creating a Certificate Request Payload, the transmitting entity MUST 2795 do the following: 2797 1. Determine the number and types of acceptable Certificate Encodings to 2798 be requested. This may be specified by the DOI. 2800 2. Determine the number and names of Certificate Authorities which are 2801 acceptable and are to be requested. 2803 3. Construct a Certificate Request payload. 2805 4. Transmit the message to the receiving entity as described in section 2806 5.1. 2808 When a Certificate Request payload is received, the receiving entity (ini- 2809 tiator or responder) MUST do the following: 2811 1. Ensure that the # of Certificate Types and the actual values 2812 contained in the Certificate Types field are equivalent. If not, 2813 then the following actions are taken: 2815 (a) The event, BAD CERTIFICATE REQUEST SYNTAX, is logged in the 2816 appropriate system audit file. 2818 (b) An Informational Exchange with a Notification payload containing 2819 the BAD-CERT-REQUEST-SYNTAX message type MAY be sent to the 2820 initiating entity. This action is dictated by a system security 2821 policy. 2823 2. Determine if the Certificate Types are supported. If any of the 2824 Certificate Types are not supported, the message is discarded and the 2825 following actions are taken: 2827 (a) The event, INVALID CERTIFICATE TYPE, is logged in the appropriate 2828 system audit file. 2830 (b) An Informational Exchange with a Notification payload containing 2831 the INVALID-CERT-ENCODING message type MAY be sent to the 2832 initiating entity. This action is dictated by a system security 2833 policy. 2835 3. Ensure that the # of Certificate Authorities and the actual values 2836 contained in the Certificate Authorities field are equivalent. If 2837 not, then the following actions are taken: 2839 (a) The event, BAD CERTIFICATE REQUEST SYNTAX, is logged in the 2840 appropriate system audit file. 2842 (b) An Informational Exchange with a Notification payload containing 2843 the BAD-CERT-REQUEST-SYNTAX message type MAY be sent to the 2844 initiating entity. This action is dictated by a system security 2845 policy. 2847 4. Process the Certificate Authorities field. If the Certificate 2848 Authorities are invalid or improperly formatted, the message is 2849 discarded and the following actions are taken: 2851 (a) The event, INVALID CERTIFICATE AUTHORITIES, is logged in the 2852 appropriate system audit file. 2854 (b) An Informational Exchange with a Notification payload containing 2855 the INVALID-CERT-AUTHORITY message type MAY be sent to the 2856 initiating entity. This action is dictated by a system security 2857 policy. 2859 5.9 Hash Payload Processing 2861 When creating a Hash Payload, the transmitting entity MUST do the follow- 2862 ing: 2864 1. Determine the Hash function to be used as defined by the SA 2865 negotiation. 2867 2. Determine the usage of the Hash Data field as defined by the DOI. 2869 3. Construct a Hash payload. 2871 4. Transmit the message to the receiving entity as described in section 2872 5.1. 2874 When a Hash payload is received, the receiving entity (initiator or re- 2875 sponder) MUST do the following: 2877 1. Determine if the Hash is supported. If the Hash determination fails, 2878 the message is discarded and the following actions are taken: 2880 (a) The event, INVALID HASH INFORMATION, is logged in the appropriate 2881 system audit file. 2883 (b) An Informational Exchange with a Notification payload containing 2884 the INVALID-HASH-INFORMATION message type MAY be sent to the 2885 initiating entity. This action is dictated by a system security 2886 policy. 2888 2. Perform the Hash function as outlined in the DOI and/or Key Exchange 2889 protocol documents. If the Hash function fails, the message is 2890 discarded and the following actions are taken: 2892 (a) The event, INVALID HASH VALUE, is logged in the appropriate 2893 system audit file. 2895 (b) An Informational Exchange with a Notification payload containing 2896 the AUTHENTICATION-FAILED message type MAY be sent to the 2897 initiating entity. This action is dictated by a system security 2898 policy. 2900 5.10 Signature Payload Processing 2902 When creating a Signature Payload, the transmitting entity MUST do the 2903 following: 2905 1. Determine the Signature function to be used as defined by the SA 2906 negotiation. 2908 2. Determine the usage of the Signature Data field as defined by the 2909 DOI. 2911 3. Construct a Signature payload. 2913 4. Transmit the message to the receiving entity as described in section 2914 5.1. 2916 When a Signature payload is received, the receiving entity (initiator or 2917 responder) MUST do the following: 2919 1. Determine if the Signature is supported. If the Signature 2920 determination fails, the message is discarded and the following 2921 actions are taken: 2923 (a) The event, INVALID SIGNATURE INFORMATION, is logged in the 2924 appropriate system audit file. 2926 (b) An Informational Exchange with a Notification payload containing 2927 the INVALID-SIGNATURE message type MAY be sent to the initiating 2928 entity. This action is dictated by a system security policy. 2930 2. Perform the Signature function as outlined in the DOI and/or Key 2931 Exchange protocol documents. If the Signature function fails, the 2932 message is discarded and the following actions are taken: 2934 (a) The event, INVALID SIGNATURE VALUE, is logged in the appropriate 2935 system audit file. 2937 (b) An Informational Exchange with a Notification payload containing 2938 the AUTHENTICATION-FAILED message type MAY be sent to the 2939 initiating entity. This action is dictated by a system security 2940 policy. 2942 5.11 Nonce Payload Processing 2944 When creating a Nonce Payload, the transmitting entity MUST do the follow- 2945 ing: 2947 1. Create a unique random value to be used as a nonce. 2949 2. Construct a Nonce payload. 2951 3. Transmit the message to the receiving entity as described in section 2952 5.1. 2954 When a Nonce payload is received, the receiving entity (initiator or re- 2955 sponder) MUST do the following: 2957 1. There are no specific procedures for handling Nonce payloads. The 2958 procedures are defined by the exchange types (and possibly the DOI 2959 and Key Exchange descriptions). 2961 5.12 Notification Payload Processing 2963 During communications it is possible that errors may occur. The Infor- 2964 mational Exchange with a Notify Payload provides a controlled method of 2965 informing a peer entity that errors have occurred during protocol process- 2966 ing. 2968 When creating a Notification Payload, the transmitting entity MUST do the 2969 following: 2971 1. Determine the DOI for this Notification. 2973 2. Determine the Protocol-ID for this Notification. 2975 3. Determine the SPI size based on the Protocol-ID field. This field is 2976 necessary because different security protocols have different SPI 2977 sizes. For example, ISAKMP combines the Initiator and Responder 2978 cookie pair (16 octets) as a SPI, while ESP and AH have 8 octet SPIs. 2980 4. Determine the Notify Message Type based on the error or status 2981 message desired. 2983 5. Determine the SPI which is associated with this notification. 2985 6. Determine if additional Notification Data is to be included. This is 2986 additional information specified by the DOI. 2988 7. Construct a Notification payload. 2990 8. Transmit the message to the receiving entity as described in section 2991 5.1. 2993 Because the Informational Exchange with a Notification payload is a uni- 2994 directional message a retransmission will not be performed. The local 2995 security policy will dictate the procedures for continuing. However, we 2996 RECOMMEND that a NOTIFICATION PAYLOAD ERROR event be logged in the appro- 2997 priate system audit file by the receiving entity. 2999 If the Informational Exchange occurs prior to the exchange of keying ma- 3000 terial during an ISAKMP Phase 1 negotiation there will be no protection 3001 provided for the Informational Exchange. Once the keying material has 3002 been exchanged or the ISAKMP SA has been established, the Informational 3003 Exchange MUST be transmitted under the protection provided by the keying 3004 material or the ISAKMP SA. 3006 When a Notification payload is received, the receiving entity (initiator 3007 or responder) MUST do the following: 3009 1. Determine if the Informational Exchange has any protection applied to 3010 it by checking the Encryption Bit in the ISAKMP Header. If the 3011 Informational Exchange is not encrypted the payload processing can 3012 continue as described below. If the Informational Exchange is 3013 encrypted, then the message MUST be decrypted using the (in-progress 3014 or completed) ISAKMP SA. Once the decryption is complete the 3015 processing can continue as described below. 3017 2. Determine if the Domain of Interpretation (DOI) is supported. If the 3018 DOI determination fails, the message is discarded and the following 3019 action is taken: 3021 (a) The event, INVALID DOI, is logged in the appropriate system audit 3022 file. 3024 3. Determine if the Protocol-Id is supported. If the Protocol-Id 3025 determination fails, the message is discarded and the following 3026 action is taken: 3028 (a) The event, INVALID PROTOCOL-ID, is logged in the appropriate 3029 system audit file. 3031 4. Determine if the SPI is valid. If the SPI is invalid, the message is 3032 discarded and the following action is taken: 3034 (a) The event, INVALID SPI, is logged in the appropriate system audit 3035 file. 3037 5. Determine if the Notify Message Type is valid. If the Notify Message 3038 Type is invalid, the message is discarded and the following action is 3039 taken: 3041 (a) The event, INVALID MESSAGE TYPE, is logged in the appropriate 3042 system audit file. 3044 6. Process the Notification payload, including additional Notification 3045 Data, and take appropriate action, according to local security 3046 policy. 3048 5.13 Delete Payload Processing 3050 During communications it is possible that hosts may be compromised or that 3051 information may be intercepted during transmission. Determining whether 3052 this has occurred is not an easy task and is outside the scope of this 3053 Internet-Draft. However, if it is discovered that transmissions are being 3054 compromised, then it is necessary to establish a new SA and delete the 3055 current SA. 3057 The Informational Exchange with a Delete Payload provides a controlled 3058 method of informing a peer entity that the initiating entity has deleted 3059 the SA(s). Deletion of Security Associations MUST always be performed 3060 under the protection of an ISAKMP SA. The receiving entity SHOULD clean up 3061 its local SA database. However, upon receipt of a Delete message the SAs 3062 listed in the Security Parameter Index (SPI) field of the Delete payload 3063 cannot be used with the initiating entity. The SA Establishment procedure 3064 must be invoked to re-establish secure communications. 3066 When creating a Delete Payload, the transmitting entity MUST do the fol- 3067 lowing: 3069 1. Determine the DOI for this Deletion. 3071 2. Determine the Protocol-ID for this Deletion. 3073 3. Determine the SPI size based on the Protocol-ID field. This field is 3074 necessary because different security protocols have different SPI 3075 sizes. For example, ISAKMP combines the Initiator and Responder 3076 cookie pair (16 octets) as a SPI, while ESP and AH have 8 octet SPIs. 3078 4. Determine the # of SPIs to be deleted for this protocol. 3080 5. Determine the SPI(s) which is (are) associated with this deletion. 3082 6. Construct a Delete payload. 3084 7. Transmit the message to the receiving entity as described in section 3085 5.1. 3087 Because the Informational Exchange with a Delete payload is a unidirec- 3088 tional message a retransmission will not be performed. The local security 3089 policy will dictate the procedures for continuing. However, we RECOMMEND 3090 that a DELETE PAYLOAD ERROR event be logged in the appropriate system au- 3091 dit file by the receiving entity. 3093 As described above, the Informational Exchange with a Delete payload MUST 3094 be transmitted under the protection provided by an ISAKMP SA. 3096 When a Delete payload is received, the receiving entity (initiator or re- 3097 sponder) MUST do the following: 3099 1. Because the Informational Exchange is encrypted, then the message 3100 MUST be decrypted using the ISAKMP SA. Once the decryption is 3101 complete the processing can continue as described below. Any errors 3102 that occur during the decryption process will be evident when 3103 checking information in the Delete payload. The local security 3104 policy SHOULD dictate any action to be taken as a result of 3105 decryption errors. 3107 2. Determine if the Domain of Interpretation (DOI) is supported. If the 3108 DOI determination fails, the message is discarded and the following 3109 action is taken: 3111 (a) The event, INVALID DOI, is logged in the appropriate system audit 3112 file. 3114 3. Determine if the Protocol-Id is supported. If the Protocol-Id 3115 determination fails, the message is discarded and the following 3116 action is taken: 3118 (a) The event, INVALID PROTOCOL-ID, is logged in the appropriate 3119 system audit file. 3121 4. Determine if the SPI is valid for each SPI included in the Delete 3122 payload. For each SPI that is invalid, the following action is 3123 taken: 3125 (a) The event, INVALID SPI, is logged in the appropriate system audit 3126 file. 3128 5. Process the Delete payload and take appropriate action, according to 3129 local security policy. As described above, one appropriate action 3130 SHOULD include cleaning up the local SA database. 3132 6 Conclusions 3134 The Internet Security Association and Key Management Protocol (ISAKMP) is 3135 a well designed protocol aimed at the Internet of the future. The mas- 3136 sive growth of the Internet will lead to great diversity in network uti- 3137 lization, communications, security requirements, and security mechanisms. 3138 ISAKMP contains all the features that will be needed for this dynamic and 3139 expanding communications environment. 3141 ISAKMP's Security Association (SA) feature coupled with authentication 3142 and key establishment provides the security and flexibility that will be 3143 needed for future growth and diversity. This security diversity of multi- 3144 ple key exchange techniques, encryption algorithms, authentication mecha- 3145 nisms, security services, and security attributes will allow users to se- 3146 lect the appropriate security for their network, communications, and secu- 3147 rity needs. The SA feature allows users to specify and negotiate security 3148 requirements with other users. An additional benefit of supporting multi- 3149 ple techniques in a single protocol is that as new techniques are devel- 3150 oped they can easily be added to the protocol. This provides a path for 3151 the growth of Internet security services. ISAKMP supports both publicly 3152 or privately defined SAs, making it ideal for government, commercial, and 3153 private communications. 3155 ISAKMP provides the ability to establish SAs for multiple security proto- 3156 cols and applications. These protocols and applications may be session- 3157 oriented or sessionless. Having one SA establishment protocol that sup- 3158 ports multiple security protocols eliminates the need for multiple, nearly 3159 identical authentication, key exchange and SA establishment protocols when 3160 more than one security protocol is in use or desired. Just as IP has pro- 3161 vided the common networking layer for the Internet, a common security es- 3162 tablishment protocol is needed if security is to become a reality on the 3163 Internet. ISAKMP provides the common base that allows all other security 3164 protocols to interoperate. 3166 ISAKMP follows good security design principles. It is not coupled to 3167 other insecure transport protocols, therefore it is not vulnerable or 3168 weakened by attacks on other protocols. Also, when more secure transport 3169 protocols are developed, ISAKMP can be easily migrated to them. ISAKMP 3170 also provides protection against protocol related attacks. This protec- 3171 tion provides the assurance that the SAs and keys established are with the 3172 desired party and not with an attacker. 3174 ISAKMP also follows good protocol design principles. Protocol specific 3175 information only is in the protocol header, following the design prin- 3176 ciples of IPv6. The data transported by the protocol is separated into 3177 functional payloads. As the Internet grows and evolves, new payloads to 3178 support new security functionality can be added without modifying the en- 3179 tire protocol. 3181 A ISAKMP Security Association Attributes 3183 A.1 Background/Rationale 3185 As detailed in previous sections, ISAKMP is designed to provide a flexible 3186 and extensible framework for establishing and managing Security Associa- 3187 tions and cryptographic keys. The framework provided by ISAKMP consists 3188 of header and payload definitions, exchange types for guiding message and 3189 payload exchanges, and general processing guidelines. ISAKMP does not 3190 define the mechanisms that will be used to establish and manage Security 3191 Associations and cryptographic keys in an authenticated and confidential 3192 manner. The definition of mechanisms and their application is the purview 3193 of individual Domains of Interpretation (DOIs). 3195 This section describes the ISAKMP values for the Internet IP Security DOI. 3196 The Internet IP Security DOI is MANDATORY to implement for IP Security. 3197 [Oakley] and [IO-Res] describe, in detail, the mechanisms and their ap- 3198 plication for establishing and managing Security Associations and crypto- 3199 graphic keys for IP Security. 3201 A.2 Assigned Values for the Internet IP Security DOI 3203 A.2.1 Internet IP Security DOI Assigned Value 3205 As described in [IPDOI], the Internet IP Security DOI Assigned Number is 3206 one (1). 3208 A.2.2 Supported Security Protocols 3210 Values for supported security protocols are specified in the most recent 3211 ``Assigned Numbers'' RFC [STD-2]. Presented in the following table are 3212 the values for the security protocols supported by ISAKMP for the Internet 3213 IP Security DOI. 3215 _Protocol_Assigned_Value__ 3216 RESERVED 0 3217 ISAKMP 1 3219 All DOIs MUST reserve ISAKMP with a Protocol-ID of 1. All other security 3220 protocols within that DOI will be numbered accordingly. 3222 Security protocol values 2-1023 are reserved for IANA use. Values 1024- 3223 15359 are reserved for future use. Values 15360-16383 are reserved for 3224 private use. 3226 B Defining a new Domain of Interpretation 3228 The Internet DOI may be sufficient to meet the security requirements of 3229 a large portion of the internet community. However, some groups may have 3230 a need to customize some aspect of a DOI, perhaps to add a different set 3231 of cryptographic algorithms, or perhaps because they want to make their 3232 security-relevant decisions based on something other than a host id or 3233 user id. Also, a particular group may have a need for a new exchange 3234 type, for example to support key management for multicast groups. 3236 This section discusses guidelines for defining a new DOI. The full speci- 3237 fication for the Internet DOI can be found in [IPDOI]. 3239 Defining a new DOI is likely to be a time-consuming process. If at all 3240 possible, it is recommended that the designer begin with an existing DOI 3241 and customize only the parts that are unacceptable. 3243 If a designer chooses to start from scratch, the following MUST be de- 3244 fined: 3246 o A ``situation'': the set of information that will be used to 3247 determine the required security services. 3249 o The set of security policies that must be supported. 3251 o A scheme for naming security-relevant information, including 3252 encryption algorithms, key exchange algorithms, etc. 3254 o A syntax for the specification of proposed security services, 3255 attributes, and certificate authorities. 3257 o The specific formats of the various payload contents. 3259 o Additional exchange types, if required. 3261 B.1 Situation 3263 The situation is the basis for deciding how to protect a communications 3264 channel. It must contain all of the data that will be used to determine 3265 the types and strengths of protections applied in an SA. For example, a 3266 US Department of Defense DOI would probably use unpublished algorithms 3267 and have additional special attributes to negotiate. These additional 3268 security attributes would be included in the situation. 3270 B.2 Security Policies 3272 Security policies define how various types of information must be cate- 3273 gorized and protected. The DOI must define the set of security policies 3274 supported, because both parties in a negotiation must trust that the other 3275 party understands a situation, and will protect information appropriately, 3276 both in transit and in storage. In a corporate setting, for example, both 3277 parties in a negotiation must agree to the meaning of the term ``propri- 3278 etary information'' before they can negotiate how to protect it. 3280 Note that including the required security policies in the DOI only speci- 3281 fies that the participating hosts understand and implement those policies 3282 in a full system context. 3284 B.3 Naming Schemes 3286 Any DOI must define a consistent way to name cryptographic algorithms, 3287 certificate authorities, etc. This can usually be done by using IANA nam- 3288 ing conventions, perhaps with some private extensions. 3290 B.4 Syntax for Specifying Security Services 3292 In addition to simply specifying how to name entities, the DOI must also 3293 specify the format for complete proposals of how to protect traffic under 3294 a given situation. 3296 B.5 Payload Specification 3298 The DOI must specify the format of each of the payload types. For several 3299 of the payload types, ISAKMP has included fields that would have to be 3300 present across all DOI (such as a certificate authority in the certificate 3301 payload, or a key exchange identifier in the key exchange payload). 3303 B.6 Defining new Exchange Types 3305 If the basic exchange types are inadequate to meet the requirements within 3306 a DOI, a designer can define up to thirteen extra exchange types per DOI. 3307 The designer creates a new exchange type by choosing an unused exchange 3308 type value, and defining a sequence of messages composed of strings of the 3309 ISAKMP payload types. 3311 Note that any new exchange types must be rigorously analyzed for vulner- 3312 abilities. Since this is an expensive and imprecise undertaking, a new 3313 exchange type should only be created when absolutely necessary. 3315 Security Considerations 3317 Cryptographic analysis techniques are improving at a steady pace. The 3318 continuing improvement in processing power makes once computationally pro- 3319 hibitive cryptographic attacks more realistic. New cryptographic algo- 3320 rithms and public key generation techniques are also being developed at a 3321 steady pace. New security services and mechanisms are being developed at 3322 an accelerated pace. A consistent method of choosing from a variety of 3323 security services and mechanisms and to exchange attributes required by 3324 the mechanisms is important to security in the complex structure of the 3325 Internet. However, a system that locks itself into a single cryptographic 3326 algorithm, key exchange technique, or security mechanism will become in- 3327 creasingly vulnerable as time passes. 3329 UDP is an unreliable datagram protocol and therefore its use in ISAKMP in- 3330 troduces a number of security considerations. Since UDP is unreliable, 3331 but a key management protocol must be reliable, the reliability is built 3332 into ISAKMP. While ISAKMP utilizes UDP as its transport mechanism, it 3333 doesn't rely on any UDP information (e.g. checksum, length) for its pro- 3334 cessing. 3336 Another issue that must be considered in the development of ISAKMP is the 3337 effect of firewalls on the protocol. Many firewalls filter out all UDP 3338 packets, making reliance on UDP questionable in certain environments. 3340 A number of very important security considerations are presented in 3341 [RFC-1825]. One bears repeating. Once a private session key is created, 3342 it must be safely stored. Failure to properly protect the private key 3343 from access both internal and external to the system completely nullifies 3344 any protection provided by the IP Security services. 3346 Acknowledgements 3348 Dan Harkins, Dave Carrel, and Derrell Piper of Cisco Systems provided de- 3349 sign assistance with the protocol and coordination for the [IO-Res] and 3350 [IPDOI] documents. 3352 Hilarie Orman, via the Oakley key exchange protocol, has significantly 3353 influenced the design of ISAKMP. 3355 Marsha Gross, Bill Kutz, Mike Oehler, Pete Sell, and Ruth Taylor provided 3356 significant input and review to this document. 3358 Scott Carlson ported the TIS DNSSEC prototype to FreeBSD for use with the 3359 ISAKMP prototype. 3361 Jeff Turner and Steve Smalley contributed to the prototype development and 3362 integration with ESP and AH. 3364 Mike Oehler and Pete Sell performed interoperability testing with other 3365 ISAKMP implementors. 3367 Thanks to Carl Muckenhirn of SPARTA, Inc. for his assistance with LaTeX. 3369 References 3371 [ANSI] ANSI, X9.42: Public Key Cryptography for the Financial Services 3372 Industry -- Establishment of Symmetric Algorithm Keys Using 3373 Diffie-Hellman, Working Draft, April 19, 1996. 3375 [RFC-1825] Randall Atkinson, Security Architecture for the Internet 3376 Protocol, RFC-1825, August, 1995. 3378 [BC] Ballardie, A. and J. Crowcroft, Multicast-specific Security Threats 3379 and Countermeasures, Proceedings of 1995 ISOC Symposium on Networks 3380 & Distributed Systems Security, pp. 17-30, Internet Society, San 3381 Diego, CA, February 1995. 3383 [RFC-1949] A. Ballardie, Scalable Multicast Key Distribution, RFC-1949, 3384 May, 1996. 3386 [Berge] Berge, N.H., UNINETT PCA Policy Statements, Internet-Draft, work 3387 in progress, November, 1995. 3389 [CW87] Clark, D.D. and D.R. Wilson, A Comparison of Commercial and 3390 Military Computer Security Policies, Proceedings of the IEEE 3391 Symposium on Security & Privacy, Oakland, CA, 1987, pp 184-193. 3393 [DOW92] Diffie, W., M.Wiener, P. Van Oorschot, Authentication and 3394 Authenticated Key Exchanges, Designs, Codes, and Cryptography, 2, 3395 107-125, Kluwer Academic Publishers, 1992. 3397 [DNSSEC] D. Eastlake III, Domain Name System Protocol Security 3398 Extensions, Internet-Draft: draft-ietf-dnssec-secext2-00.txt, Work 3399 in Progress, July 1997. 3401 [Karn] Karn, P. and B. Simpson, The Photuris Session Key Management 3402 Protocol, Internet-Draft: draft-simpson-photuris-15.txt, Work in 3403 Progress, July 1997. 3405 [RFC-1422] Steve Kent, Privacy Enhancement for Internet Electronic Mail: 3406 Part II: Certificate-Based Key Management, RFC-1422, February 1993. 3408 [Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August 10, 3409 1994. 3411 [Oakley] H. K. Orman, The Oakley Key Determination Protocol, Internet- 3412 Draft: draft-ietf-ipsec-oakley-02.txt, Work in Progress, July 1997. 3414 [IO-Res] Harkins, D. and D. Carrel, The Resolution of ISAKMP with Oakley, 3415 Internet-Draft: draft-ietf-ipsec-isakmp-oakley-04.txt, Work in 3416 Progress, July 1997. 3418 [IPDOI] Derrell Piper, The Internet IP Security Domain of Interpretation 3419 for ISAKMP, Internet-Draft: draft-ietf-ipsec-ipsec-doi-03.txt, Work 3420 in Progress, July 1997. 3422 [STD-2] Reynolds, J. and J. Postel, Assigned Numbers, STD 2, October, 3423 1994. 3425 [Schneier] Bruce Schneier, Applied Cryptography - Protocols, Algorithms, 3426 and Source Code in C (Second Edition), John Wiley & Sons, Inc., 3427 1996. 3429 [RFC-2094] Harney, H. and C. Muckenhirn, Group Key Management Protocol 3430 (GKMP) Architecture, SPARTA, Inc., RFC-2094, July 1997. 3432 [RFC-2093] Harney, H. and C. Muckenhirn, Group Key Management Protocol 3433 (GKMP) Specification, SPARTA, Inc., RFC-2093, July 1997. 3435 Addresses of Authors 3437 The authors can be contacted at: 3439 Douglas Maughan 3440 Phone: 301-688-0847 3441 E-mail:wdmaugh@tycho.ncsc.mil 3443 Mark Schneider 3444 Phone: 301-688-0851 3445 E-mail:mss@tycho.ncsc.mil 3447 Jeff Turner 3448 Phone: 301-688-0849 3449 E-mail:sjt@epoch.ncsc.mil 3451 National Security Agency 3452 ATTN: R23 3453 9800 Savage Road 3454 Ft. Meade, MD. 20755-6000 3456 Mark Schertler 3457 Terisa Systems, Inc. 3458 4984 El Camino Real 3459 Los Altos, CA. 94022 3460 Phone: 415-919-1773 3461 E-mail:mjs@terisa.com