idnits 2.17.00 (12 Aug 2021) /tmp/idnits29994/draft-ietf-ipsec-isakmp-07.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 (2022-05-20) 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) 2022 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-07.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-ipsec-isakmp-07.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-ipsec-isakmp-07.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-07.txt,', but the file name used is 'draft-ietf-ipsec-isakmp-07' == 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 733 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 228: '... - MUST...' RFC 2119 keyword, line 233: '... - MUST NOT...' RFC 2119 keyword, line 238: '... - SHOULD...' RFC 2119 keyword, line 246: '... - MAY...' RFC 2119 keyword, line 257: '...to-implement, or MUST, items MUST be f...' (123 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 (February 21, 1997) is 9219 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 3216, but no explicit reference was found in the text == Unused Reference: 'Kent94' is defined on line 3234, 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'DNSSEC' == Outdated reference: draft-simpson-photuris has been published as RFC 2522 ** 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' == Outdated reference: draft-ietf-ipsec-oakley has been published as RFC 2412 ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-oakley (ref. 'Oakley') == Outdated reference: draft-ietf-ipsec-isakmp-oakley has been published as RFC 2409 == Outdated reference: draft-ietf-ipsec-ipsec-doi has been published as RFC 2407 -- Possible downref: Non-RFC (?) normative reference: ref. 'STD-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' == Outdated reference: draft-harney-gkmp-arch has been published as RFC 2094 ** Downref: Normative reference to an Experimental draft: draft-harney-gkmp-arch (ref. 'Spar96a') == Outdated reference: draft-harney-gkmp-spec has been published as RFC 2093 ** Downref: Normative reference to an Experimental draft: draft-harney-gkmp-spec (ref. 'Spar96b') Summary: 20 errors (**), 1 flaw (~~), 11 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-07.txt, .ps February 21, 1997 5 Expire in six months 7 Internet Security Association and Key Management Protocol (ISAKMP) 9 Abstract 11 This memo describes a protocol utilizing security concepts 12 necessary for establishing Security Associations (SA) and crypto- 13 graphic keys in an Internet environment. A Security Association 14 protocol that negotiates, establishes, modifies and deletes 15 Security Associations and their attributes is required for an 16 evolving Internet, where there will be numerous security mecha- 17 nisms and several options for each security mechanism. The key 18 management protocol must be robust in order to handle public key 19 generation for the Internet community at large and private key 20 requirements for those private networks with that requirement. 21 The Internet Security Association and Key Management Protocol 22 (ISAKMP) defines the procedures for authenticating a communicat- 23 ing peer, creation and management of Security Associations, key 24 generation techniques, and threat mitigation (e.g. denial of 25 service and replay attacks). All of these are necessary to es- 26 tablish and maintain secure communications (via IP Security Ser- 27 vice or any other security protocol) in an Internet environment. 29 Status of this memo 31 This document is being submitted to the IETF Internet Protocol Security 32 (IPSEC) Working Group for consideration as a method for the establishment 33 and management of security associations and their appropriate security at- 34 tributes. Additionally, this document proposes a method for key manage- 35 ment to support IPSEC and IPv6. It is intended that a future version of 36 this draft be submitted to the IESG for publication as a Draft Standard 37 RFC. Comments are solicited and should be addressed to the authors and/or 38 the IPSEC working group mailing list at ipsec@tis.com. 40 This document is an Internet Draft. Internet Drafts are working documents 41 of the Internet Engineering Task Force (IETF), its Areas, and its Working 42 Groups. Note that other groups may also distribute working documents as 43 Internet Drafts. 45 Internet Drafts are draft documents valid for a maximum of six months. 46 Internet Drafts may be updated, replaced, or obsoleted by other documents 47 at any time. It is not appropriate to use Internet Drafts as reference 48 material or to cite them other than as ``working draft'' or ``work in 49 progress.'' 51 To learn the current status of any Internet-Draft, please check the ``1id- 52 abstracts.txt'' listing contained in the Internet- Drafts Shadow Di- 53 rectories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 54 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 56 Distribution of this document is unlimited. 58 Contents 60 1 Introduction 6 61 1.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . . 7 62 1.2 The Need for Negotiation . . . . . . . . . . . . . . . . . . . . 8 63 1.3 What can be Negotiated? . . . . . . . . . . . . . . . . . . . . . 8 64 1.4 Security Associations and Management . . . . . . . . . . . . . . 9 65 1.4.1Security Associations and Registration . . . . . . . . . . . . 9 66 1.4.2ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 10 67 1.5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 1.5.1Certificate Authorities . . . . . . . . . . . . . . . . . . . 11 69 1.5.2Entity Naming . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1.5.3ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 11 71 1.6 Public Key Cryptography . . . . . . . . . . . . . . . . . . . . . 12 72 1.6.1Key Exchange Properties . . . . . . . . . . . . . . . . . . . 13 73 1.6.2ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 14 74 1.7 ISAKMP Protection . . . . . . . . . . . . . . . . . . . . . . . . 14 75 1.7.1Anti-Clogging (Denial of Service) . . . . . . . . . . . . . . 14 76 1.7.2Connection Hijacking . . . . . . . . . . . . . . . . . . . . . 14 77 1.7.3Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . 15 78 1.8 Multicast Communications . . . . . . . . . . . . . . . . . . . . 15 80 2 Terminology and Concepts 15 81 2.1 ISAKMP Terminology . . . . . . . . . . . . . . . . . . . . . . . 15 82 2.2 ISAKMP Placement . . . . . . . . . . . . . . . . . . . . . . . . 17 83 2.3 Negotiation Phases . . . . . . . . . . . . . . . . . . . . . . . 17 84 2.4 Identifying Security Associations . . . . . . . . . . . . . . . . 19 85 2.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 2.5.1Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 21 87 2.5.2RESERVED Fields . . . . . . . . . . . . . . . . . . . . . . . 21 88 2.5.3Anti-Clogging Token (``Cookie'') Creation . . . . . . . . . . 21 89 3 ISAKMP Payloads 22 90 3.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 22 91 3.2 Payload Generic Header . . . . . . . . . . . . . . . . . . . . . 25 92 3.3 Data Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 3.4 Security Association Payload . . . . . . . . . . . . . . . . . . 26 94 3.5 Proposal Payload . . . . . . . . . . . . . . . . . . . . . . . . 27 95 3.6 Transform Payload . . . . . . . . . . . . . . . . . . . . . . . . 29 96 3.7 Key Exchange Payload . . . . . . . . . . . . . . . . . . . . . . 30 97 3.8 Identification Payload . . . . . . . . . . . . . . . . . . . . . 31 98 3.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . 32 99 3.10Certificate Request Payload . . . . . . . . . . . . . . . . . . . 33 100 3.11Hash Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 34 101 3.12Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . 35 102 3.13Nonce Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 36 103 3.14Notification Payload . . . . . . . . . . . . . . . . . . . . . . 37 104 3.14.1Notify Message Types . . . . . . . . . . . . . . . . . . . . . 39 105 3.15Delete Payload . . . . . . . . . . . . . . . . . . . . . . . . . 40 107 4 ISAKMP Exchanges 41 108 4.1 Security Association Establishment . . . . . . . . . . . . . . . 41 109 4.1.1Security Association Establishment Examples . . . . . . . . . 43 110 4.2 Security Association Modification . . . . . . . . . . . . . . . . 45 111 4.3 ISAKMP Exchange Types . . . . . . . . . . . . . . . . . . . . . . 46 112 4.3.1Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 113 4.4 Base Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . 47 114 4.5 Identity Protection Exchange . . . . . . . . . . . . . . . . . . 48 115 4.6 Authentication Only Exchange . . . . . . . . . . . . . . . . . . 50 116 4.7 Aggressive Exchange . . . . . . . . . . . . . . . . . . . . . . . 51 117 4.8 Informational Exchange . . . . . . . . . . . . . . . . . . . . . 52 119 5 ISAKMP Payload Processing 53 120 5.1 General Message Processing . . . . . . . . . . . . . . . . . . . 53 121 5.2 ISAKMP Header Processing . . . . . . . . . . . . . . . . . . . . 53 122 5.3 Generic Payload Header Processing . . . . . . . . . . . . . . . . 55 123 5.4 Security Association Payload Processing . . . . . . . . . . . . . 56 124 5.4.1Proposal Payload Processing . . . . . . . . . . . . . . . . . 58 125 5.4.2Transform Payload Processing . . . . . . . . . . . . . . . . . 59 126 5.5 Key Exchange Payload Processing . . . . . . . . . . . . . . . . . 60 127 5.6 Identification Payload Processing . . . . . . . . . . . . . . . . 61 128 5.7 Certificate Payload Processing . . . . . . . . . . . . . . . . . 62 129 5.8 Certificate Request Payload Processing . . . . . . . . . . . . . 63 130 5.9 Hash Payload Processing . . . . . . . . . . . . . . . . . . . . . 64 131 5.10Signature Payload Processing . . . . . . . . . . . . . . . . . . 65 132 5.11Nonce Payload Processing . . . . . . . . . . . . . . . . . . . . 66 133 5.12Notification Payload Processing . . . . . . . . . . . . . . . . . 67 134 5.13Delete Payload Processing . . . . . . . . . . . . . . . . . . . . 67 135 6 Conclusions 69 137 A ISAKMP Security Association Attributes 70 138 A.1 Background/Rationale . . . . . . . . . . . . . . . . . . . . . . 70 139 A.2 Assigned Values for the Internet IP Security DOI . . . . . . . . 70 140 A.2.1Internet IP Security DOI Assigned Value . . . . . . . . . . . 70 141 A.2.2Supported Security Protocols . . . . . . . . . . . . . . . . . 70 142 B Defining a new Domain of Interpretation 72 143 B.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 144 B.2 Security Policies . . . . . . . . . . . . . . . . . . . . . . . . 73 145 B.3 Naming Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 73 146 B.4 Syntax for Specifying Security Services . . . . . . . . . . . . . 73 147 B.5 Payload Specification . . . . . . . . . . . . . . . . . . . . . . 73 148 B.6 Defining new Exchange Types . . . . . . . . . . . . . . . . . . . 73 150 List of Figures 152 1 ISAKMP Relationships . . . . . . . . . . . . . . . . . . . . . . 18 153 2 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 22 154 3 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . 25 155 4 Data Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 26 156 5 Security Association Payload . . . . . . . . . . . . . . . . . . 27 157 6 Proposal Payload Format . . . . . . . . . . . . . . . . . . . . . 28 158 7 Transform Payload Format . . . . . . . . . . . . . . . . . . . . 29 159 8 Key Exchange Payload Format . . . . . . . . . . . . . . . . . . . 30 160 9 Identification Payload Format . . . . . . . . . . . . . . . . . . 31 161 10 Certificate Payload Format . . . . . . . . . . . . . . . . . . . 32 162 11 Certificate Request Payload Format . . . . . . . . . . . . . . . 34 163 12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . . . . 35 164 13 Signature Payload Format . . . . . . . . . . . . . . . . . . . . 36 165 14 Nonce Payload Format . . . . . . . . . . . . . . . . . . . . . . 37 166 15 Notification Payload Format . . . . . . . . . . . . . . . . . . . 38 167 16 Delete Payload Format . . . . . . . . . . . . . . . . . . . . . . 40 169 1 Introduction 171 This document describes an Internet Security Association and Key Manage- 172 ment Protocol (ISAKMP). ISAKMP combines the security concepts of authen- 173 tication, key management, and security associations to establish the re- 174 quired security for government, commercial, and private communications on 175 the Internet. 177 The Internet Security Association and Key Management Protocol (ISAKMP) de- 178 fines procedures and packet formats to establish, negotiate, modify and 179 delete Security Associations (SA). SAs contain all the information re- 180 quired for execution of various network security services, such as the 181 IP layer services (such as header authentication and payload encapsula- 182 tion), transport or application layer services, or self-protection of ne- 183 gotiation traffic. ISAKMP defines payloads for exchanging key generation 184 and authentication data. These formats provide a consistent framework for 185 transferring key and authentication data which is independent of the key 186 generation technique, encryption algorithm and authentication mechanism. 188 ISAKMP is distinct from key exchange protocols in order to cleanly sepa- 189 rate the details of security association management (and key management) 190 from the details of key exchange. There may be many different key ex- 191 change protocols, each with different security properties. However, a 192 common framework is required for agreeing to the format of SA attributes, 193 and for negotiating, modifying, and deleting SAs. ISAKMP serves as this 194 common framework. 196 Separating the functionality into three parts adds complexity to the se- 197 curity analysis of a complete ISAKMP implementation. However, the sep- 198 aration is critical for interoperability between systems with differing 199 security requirements, and should also simplify the analysis of further 200 evolution of a ISAKMP server. 202 ISAKMP is intended to support the negotiation of SAs for security proto- 203 cols at all layers of the network stack (e.g., IPSEC, TLS, TLSP, OSPF, 204 etc.). By centralizing the management of the security associations, 205 ISAKMP reduces the amount of duplicated functionality within each security 206 protocol. ISAKMP can also reduce connection setup time, by negotiating a 207 whole stack of services at once. 209 The remainder of section 1 establishes the motivation for security nego- 210 tiation and outlines the major components of ISAKMP, i.e. Security As- 211 sociations and Management, Authentication, Public Key Cryptography, and 212 Miscellaneous items. Section 2 presents the terminology and concepts as- 213 sociated with ISAKMP. Section 3 describes the different ISAKMP payload 214 formats. Section 4 describes how the payloads of ISAKMP are composed to- 215 gether as exchange types to establish security associations and perform 216 key exchanges in an authenticated manner. Additionally, security as- 217 sociation modification, deletion, and error notification are discussed. 218 Section 5 describes the processing of each payload within the context of 219 ISAKMP exchanges, including error handling and associated actions. The 220 appendices provide the attribute values necessary for ISAKMP and require- 221 ment for defining a new Domain of Interpretation (DOI) within ISAKMP. 223 1.1 Requirements Terminology 225 In this document, the words that are used to define the significance of 226 each particular requirement are usually capitalised. These words are: 228 - MUST 230 This word or the adjective "REQUIRED" means that implementation of 231 the item is an absolute requirement of the specification. 233 - MUST NOT 235 This phrase means that the definition is an absolute prohibition 236 of the specification. 238 - SHOULD 240 This word or the adjective "RECOMMENDED" means that there might 241 exist valid reasons in particular circumstances to not implement 242 this item, but the full implications should be understood and the 243 case carefully weighed before not implementing this or not 244 implementing in a conforming manner. 246 - MAY 248 This word or the adjective "OPTIONAL" means that implementation of 249 this item is truly optional. One vendor might choose to include 250 the item because particular buyers require it or it enhances the 251 product, while another vendor may omit the same item. 253 - CONFORMANCE and COMPLIANCE 255 Conformance to this specification has the same meaning as 256 compliance to this specification. In either case, the 257 mandatory-to-implement, or MUST, items MUST be fully implemented 258 as specified here. If any mandatory item is not implemented as 259 specified here, that implementation is not conforming and not 260 compliant with this specification. 262 1.2 The Need for Negotiation 264 ISAKMP extends the assertion in [DOW92] that authentication and key ex- 265 changes must be combined for better security to include security associa- 266 tion exchanges. The security services required for communications depends 267 on the individual network configurations and environments. Organizations 268 are setting up Virtual Private Networks (VPN), also known as Intranets, 269 that will require one set of security functions for communications within 270 the VPN and possibly many different security functions for communications 271 outside the VPN to support geographically separate organizational compo- 272 nents, customers, suppliers, sub-contractors (with their own VPNs), gov- 273 ernment, and others. Departments within large organizations may require a 274 number of security associations to separate and protect data (e.g. per- 275 sonnel data, company proprietary data, medical) on internal networks and 276 other security associations to communicate within the same department. 277 Nomadic users wanting to ``phone home'' represent another set of secu- 278 rity requirements. These requirements must be tempered with bandwidth 279 challenges. Smaller groups of people may meet their security require- 280 ments by setting up ``Webs of Trust''. ISAKMP exchanges provide these 281 assorted networking communities the ability to present peers with the se- 282 curity functionality that the user supports in an authenticated and pro- 283 tected manner for agreement upon a common set of security attributes, i.e. 284 an interoperable security association. 286 1.3 What can be Negotiated? 288 Security associations must support different encryption algorithms, au- 289 thentication mechanisms, and key establishment algorithms for other secu- 290 rity protocols, as well as IP Security. Security associations must also 291 support host-oriented certificates for lower layer protocols and user- 292 oriented certificates for higher level protocols. Algorithm and mecha- 293 nism independence is required in applications such as e-mail, remote lo- 294 gin, and file transfer, as well as in session oriented protocols, routing 295 protocols, and link layer protocols. ISAKMP provides a common security 296 association and key establishment protocol for this wide range of security 297 protocols, applications, security requirements, and network environments. 299 ISAKMP is not bound to any specific cryptographic algorithm, key gener- 300 ation technique, or security mechanism. This flexibility is beneficial 301 for a number of reasons. First, it supports the dynamic communications 302 environment described above. Second, the independence from specific secu- 303 rity mechanisms and algorithms provides a forward migration path to better 304 mechanisms and algorithms. When improved security mechanisms are devel- 305 oped or new attacks against current encryption algorithms, authentica- 306 tion mechanisms and key exchanges are discovered, ISAKMP will allow the 307 updating of the algorithms and mechanisms without having to develop a com- 308 pletely new KMP or patch the current one. 310 ISAKMP has basic requirements for its authentication and key exchange com- 311 ponents. These requirements guard against denial of service, replay / re- 312 flection, man-in-the-middle, and connection hijacking attacks. This is 313 important because these are the types of attacks that are targeted against 314 protocols. Complete Security Association (SA) support, which provides 315 mechanism and algorithm independence, and protection from protocol threats 316 are the strengths of ISAKMP. 318 1.4 Security Associations and Management 320 A Security Association (SA) is a relationship between two or more entities 321 that describes how the entities will utilize security services to communi- 322 cate securely. This relationship is represented by a set of information 323 that can be considered a contract between the entities. The information 324 must be agreed upon and shared between all the entities. Sometimes the 325 information alone is referred to as an SA, but this is just a physical in- 326 stantiation of the existing relationship. The existence of this relation- 327 ship, represented by the information, is what provides the agreed upon se- 328 curity information needed by entities to securely interoperate. All enti- 329 ties must adhere to the SA for secure communications to be possible. When 330 accessing SA attributes, entities use a pointer or identifier refered to 331 as the Security Parameter Index (SPI). [RFC-1825] provides details on IP 332 Security Associations (SA) and Security Parameter Index (SPI) definitions. 334 1.4.1 Security Associations and Registration 336 The SA attributes required and recommended for the IP Security (AH, ESP) 337 are defined in [RFC-1825]. The attributes specified for an IP Security SA 338 include, but are not limited to, authentication mechanism, cryptographic 339 algorithm, algorithm mode, key length, and Initialization Vector (IV). 340 Other protocols that provide algorithm and mechanism independent secu- 341 rity MUST define their requirements for SA attributes. The separation of 342 ISAKMP from a specific SA definition is important to ensure ISAKMP can es- 343 tablish SAs for all possible security protocols and applications. 345 NOTE: See [IPDOI] for a discussion of SA attributes that should be consid- 346 ered when defining a security protocol or application. 348 In order to facilitate easy identification of specific attributes (e.g. 349 a specific encryption algorithm) among different network entites the at- 350 tributes must be assigned identifiers and these identifiers must be reg- 351 istered by a central authority. The Internet Assigned Numbers Authority 352 (IANA) provides this function for the Internet. 354 1.4.2 ISAKMP Requirements 356 Security Association (SA) establishment MUST be part of the key manage- 357 ment protocol defined for IP based networks. The SA concept is required 358 to support security protocols in a diverse and dynamic networking envi- 359 ronment. Just as authentication and key exchange must be linked to pro- 360 vide assurance that the key is established with the authenticated party 361 [DOW92], SA establishment must be linked with the authentication and the 362 key exchange protocol. 364 ISAKMP provides the protocol exchanges to establish a security association 365 between negotiating entities followed by the establishment of a security 366 association by these negotiated entities in behalf of some protocol (e.g. 367 ESP/AH). First, an initial protocol exchange allows a basic set of secu- 368 rity attributes to be agreed upon. This basic set provides protection for 369 subsequent ISAKMP exchanges. It also indicates the authentication method 370 and key exchange that will be performed as part of the ISAKMP protocol. 371 If a basic set of security attributes is already in place between the ne- 372 gotiating server entities, the initial ISAKMP exchange may be skipped and 373 the establishment of a security association can be done directly. After 374 the basic set of security attributes has been agreed upon, initial iden- 375 tity authenticated, and required keys generated, the established SA can 376 be used for subsequent communications by the entity that invoked ISAKMP. 377 The basic set of SA attributes that MUST be implemented to provide ISAKMP 378 interoperability are defined in Appendix A. 380 1.5 Authentication 382 A very important step in establishing secure network communications is au- 383 thentication of the entity at the other end of the communication. Many 384 authentication mechanisms are available. Authentication mechanisms fall 385 into two catagories of strength - weak and strong. Passwords are an ex- 386 ample of a mechanism that provides weak authentication. The reason pass- 387 words are considered weak is the fact that most users pick passwords that 388 are easy to guess and when used over an unprotected network are easily 389 read by network sniffers. Digital signatures, such as the Digital Sig- 390 nature Standard (DSS) and the Rivest-Shamir-Adleman (RSA) signature, are 391 public key based strong authentication mechanisms. When using public 392 key digital signatures each entity requires a public key and a private 393 key. Certificates are an essential part of a digital signature authen- 394 tication mechanism. Certificates bind a specific entity's identity (be 395 it host, network, user, or application) to its public keys and possi- 396 bly other security-related information such as privileges, clearances, 397 and compartments. Authentication based on digital signatures requires a 398 trusted third party or certificate authority to create, sign and properly 399 distribute certificates. For more detailed information on digital signa- 400 tures, such as DSS and RSA, and certificates see [Schneier]. 402 1.5.1 Certificate Authorities 404 Certificates require an infrastructure for generation, verification, re- 405 vocation, management and distribution. The Internet Policy Registration 406 Authority (IPRA) [RFC-1422] has been established to direct this infras- 407 tructure for the IETF. The IPRA certifies Policy Certification Authori- 408 ties (PCA). PCAs control Certificate Authorities (CA) which certify users 409 and subordinate entities. Current certificate related work includes the 410 Domain Name System (DNS) Security Extensions [DNSSEC] which will provide 411 signed entity keys in the DNS. The Public Key Infrastucture (PKIX) working 412 group is specifying an Internet profile for X.509 certificates. There is 413 also work going on in industry to develop X.500 Directory Services which 414 would provide X.509 certificates to users. The U.S. Post Office is devel- 415 oping a (CA) hierarchy. The NIST Public Key Infrastructure Working Group 416 has also been doing work in this area. The DOD Multi Level Information 417 System Security Initiative (MISSI) program has begun deploying a certifi- 418 cate infrastructure for the U.S. Government. Alternatively, if no infras- 419 tructure exists, the PGP Web of Trust certificates can be used to provide 420 user authentication and privacy in a community of users who know and trust 421 each other. 423 1.5.2 Entity Naming 425 An entity's name is its identity and is bound to its public keys in cer- 426 tificates. The CA MUST define the naming semantics for the certificates 427 it issues. See the UNINETT PCA Policy Statements [Berge] for an example 428 of how a CA defines its naming policy. When the certificate is verified, 429 the name is verified and that name will have meaning within the realm of 430 that CA. An example is the DNS security extensions which make DNS servers 431 CAs for the zones and nodes they serve. Resource records are provided for 432 public keys and signatures on those keys. The names associatied with the 433 keys are IP addresses and domain names which have meaning to entities ac- 434 cessing the DNS for this information. A Web of Trust is another example. 435 When webs of trust are set up, names are bound with the public keys. In 436 PGP the name is usually the entities e-mail address which has meaning to 437 those, and only those, who understand e-mail. Another web of trust could 438 use an entirely different naming scheme. 440 1.5.3 ISAKMP Requirements 442 Strong authentication MUST be provided on ISAKMP exchanges. Without being 443 able to authenticate the entity at the other end, the Security Association 444 (SA) and session key established are suspect. Without authentication you 445 are unable to trust an entity's identification, this makes access control 446 questionable. While encryption (e.g. ESP) and integrity (e.g. AH) will 447 protect subsequent communications from passive eavesdroppers, without au- 448 thentication it is possible that the SA and key may have been established 449 with an adversary who performed an active man-in-the-middle attack and is 450 now stealing all your personal data. 452 A digital signature algorithm MUST be used within ISAKMP's authentication 453 component. However, ISAKMP does not mandate a specific signature algo- 454 rithm or certificate authority (CA). ISAKMP allows an entity initiating 455 communications to indicate which CAs it supports. After selection of a 456 CA, the protocol provides the messages required to support the actual au- 457 thentication exchange. The protocol provides a facility for identifica- 458 tion of different certificate authorities, certificate types (e.g. X.509, 459 PKCS #7, PGP, DNS SIG and KEY records), and the exchange of the certifi- 460 cates identified. 462 ISAKMP utilizes digital signatures, based on public cryptography, for au- 463 thentication. There are other strong authentication systems available, 464 which could be specified as additional optional authentication mechanisms 465 for ISAKMP. Some of these authentication systems rely on a trusted third 466 party called a key distribution center (KDC) to distribute secret session 467 keys. An example is Kerberos, where the trusted third party is the Ker- 468 beros server, which holds secret keys for all clients and servers within 469 its network domain. A client's proof that it holds its secret key pro- 470 vides authenticaton to a server. 472 The ISAKMP specification does not specify the protocol for communicating 473 with the trusted third parties (TTP) or certificate directory services. 474 These protocols are defined by the TTP and directory service themselves 475 and are outside the scope of this specification. The use of these addi- 476 tional services and protocols will be described in a Key Exchange specific 477 document. 479 1.6 Public Key Cryptography 481 Public key cryptography is the most flexible, scalable, and efficient way 482 for users to obtain the shared secrets and session keys needed to support 483 the large number of ways Internet users will interoperate. Many key gen- 484 eration algorithms, that have different properties, are available to users 485 (see [DOW92], [ANSI], and [Oakley]). Properties of key exchange protocols 486 include the key establishment method, authentication, symmetry, perfect 487 forward secrecy, and back traffic protection. 489 NOTE: Cryptographic keys can protect information for a considerable length 490 of time. However, this is based on the assumption that keys used for pro- 491 tection of communications are destroyed after use and not kept for any 492 reaso 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 authentication without key exchange. 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 other then the intended party. 594 Messages may be redirected to a different destination or modified but this 595 will be detected and an SA will not be established. The ISAKMP specifica- 596 tion defines where abnormal processing has occurred and recommends notify- 597 ing 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, [Spar96a] and 608 [Spar96b], 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. Depending on the DOI, additional information (e.g. host address) may 643 be necessary to identify an SA. 645 Domain of Interpretation A Domain of Interpretation (DOI) defines payload 646 formats, exchange types, and conventions for naming security-relevant in- 647 formation such as security policies or cryptographic algorithms and modes. 648 A Domain of Interpretation (DOI) identifier is used to interpret the pay- 649 loads of ISAKMP payloads. A system SHOULD support multiple Domains of In- 650 terpretation simultaneously. The concept of a DOI is based on previous 651 work by the TSIG CIPSO Working Group, but extends beyond security label 652 interpretation to include naming and interpretation of security services. 653 A DOI defines: 655 o A ``situation'': the set of information that will be used to 656 determine the required security services. 658 o The set of security policies that must, and may, be supported. 660 o A syntax for the specification of proposed security services. 662 o A scheme for naming security-relevant information, including 663 encryption algorithms, key exchange algorithms, security policy 664 attributes, and certificate authorities. 666 o The specific formats of the various payload contents. 668 o Additional exchange types, if required. 670 The rules for the IETF IP Security DOI are presented in [IPDOI]. Speci- 671 fications of the rules for customized DOIs will be presented in separate 672 documents. 674 Situation A situation contains all of the security-relevant information 675 that a system considers necessary to decide the security services required 676 to protect the session being negotiated. The situation may include ad- 677 dresses, security classifications, modes of operation (normal vs. emer- 678 gency), etc. 680 Proposal A proposal is a list, in decreasing order of preference, of the 681 protection suites that a system considers acceptable to protect traffic 682 under a given situation. 684 Payload ISAKMP defines several types of payloads, which are used to trans- 685 fer information such as security association data, or key exchange data, 686 in DOI-defined formats. A payload consists of a generic payload header 687 and a string of octects that is opaque to ISAKMP. ISAKMP uses DOI-specific 688 functionality to synthesize and interpret these payloads. Multiple pay- 689 loads can be sent in a single ISAKMP message. See section 3 for more de- 690 tails on the payload types, and [IPDOI] for the formats of the IETF IP Se- 691 curity DOI payloads. 693 Exchange Type An exchange type is a specification of the number of mes- 694 sages in an ISAKMP exchange, and the payload types that are contained in 695 each of those messages. Each exchange type is designed to provide a par- 696 ticular set of security services, such as anonymity of the participants, 697 perfect forward secrecy of the keying material, authentication of the par- 698 ticipants, etc. Section 4.3 defines the default set of ISAKMP exchange 699 types. Other exchange types can be added to support additional key ex- 700 changes, if required. 702 2.2 ISAKMP Placement 704 Figure 1 is a high level view of the placement of ISAKMP within a system 705 context in a network architecture. An important part of negotiating secu- 706 rity services is to consider the entire ``stack'' of individual SAs as a 707 unit. This is referred to as a ``protection suite''. 709 2.3 Negotiation Phases 711 ISAKMP offers two ``phases'' of negotiation. In the first phase, two 712 ISAKMP servers agree on how to protect further negotiation traffic between 713 +------------+ +--------+ +--------------+ 714 ! DOI ! ! ! ! Application ! 715 ! Definition ! <----> ! ISAKMP ! ! Process ! 716 +------------+ ! ! !--------------! 717 +--------+ ! Appl Protocol! 718 ^ +--------------+ 719 ! ^ 720 ! ! 721 v v 722 +---------------------------------------------+ 723 ! Socket Layer ! 724 !---------------------------------------------! 725 ! Transport Protocol (TCP / UDP) ! 726 +----------+ !---------------------------------------------! 727 ! Security ! <----> ! IP ! 728 ! Protocol ! !---------------------------------------------! 729 +----------+ ! Link Layer Protocol ! 730 +---------------------------------------------+ 732 Figure 1: ISAKMP Relationships 734 themselves, establishing an ISAKMP SA. This ISAKMP SA is then used to pro- 735 tect the negotiations for the Protocol SA being requested. Two ISAKMP 736 servers can negotiate (and have active) multiple ISAKMP SAs. 738 The second phase of negotiation is used to establish security associa- 739 tions for other security protocols. This second phase can be used to pro- 740 tect many security associations. The security associations established 741 by ISAKMP during this phase can be used by a security protocol to protect 742 many message/data exchanges. 744 While the two-phased approach has a higher start-up cost for most simple 745 scenarios, there are several reasons that it is beneficial for most cases. 747 First, ISAKMP servers can amortize the cost of the first phase across sev- 748 eral second phase negotiations. This allows multiple SAs to be estab- 749 lished between peers over time without having to start over for each com- 750 munication. 752 Second, security services negotiated during the first phase provide secu- 753 rity properties for the second phase. For example, after the first phase 754 of negotiation, the encryption provided by the ISAKMP SA can provide iden- 755 tity protection, potentially allowing the use of simpler second-phase ex- 756 changes. On the other hand, if the channel established during the first 757 phase is not adequate to protect identities, then the second phase must 758 negotiate adequate security mechanisms. 760 Third, having an ISAKMP SA in place considerably reduces the cost of 761 ISAKMP management activity - without the ``trusted path'' that an ISAKMP 762 SA gives you, the ISAKMP servers would have to go through a complete re- 763 authentication for each error notification or deletion of an SA. 765 Negotiation during each phase is accomplished using ISAKMP-defined ex- 766 changes (see section 4) or exchanges defined for a key exchange within a 767 DOI. 769 Note that security services may be applied differently in each negotiation 770 phase. For example, different parties are being authenticated during each 771 of the phases of negotiation. During the first phase, the parties being 772 authenticated are the ISAKMP servers/hosts, while during the second phase, 773 users or application level programs are being authenticated. 775 2.4 Identifying Security Associations 777 While bootstrapping secure channels between systems, ISAKMP cannot assume 778 the existence of security services, and must provide some protections for 779 itself. Therefore, ISAKMP considers an ISAKMP Security Association to be 780 different than other types, and manages ISAKMP SAs itself, in their own 781 name space. ISAKMP uses the two cookie fields in the ISAKMP header to 782 identify ISAKMP SAs. The Message ID and SPI fields in the ISAKMP Header 783 are used during SA establishment to identify the SA for other security 784 protocols. The interpretation of these four fields is dependent on the 785 operation taking place. 787 The following table shows the presence or absence of the cookies in the 788 ISAKMP header, the ISAKMP Header Message ID field, and the SPI field in 789 the Proposal payload for various operations. An 'X' in the column means 790 the value MUST be present. An 'NA' in the column means a value in the 791 column is Not Applicable to the operation. 793 __#_____________Operation____________I-Cookie__R-Cookie__Message_ID__SPI_ 794 (1) Start ISAKMP SA negotiation X 0 0 0 795 (2) Respond ISAKMP SA negotiation X X 0 0 796 (3) Init other SA negotiation X X X X 797 (4) Respond other SA negotiation X X X X 798 (5) Other (KE, ID, etc.) X X X/0 NA 799 (6) Security Protocol (ESP, AH) NA NA NA X 801 In the first line (1) of the table, the initiator includes the Initiator 802 Cookie field in the ISAKMP Header, using the procedures outlined in sec- 803 tions 2.5.3 and 3.1. 805 In the second line (2) of the table, the responder includes the Initia- 806 tor and Responder Cookie fields in the ISAKMP Header, using the procedures 807 outlined in sections 2.5.3 and 3.1. Additional messages may be exchanged 808 between ISAKMP peers, depending on the ISAKMP exchange type used during 809 the phase 1 negotiation. Once the phase 1 exchange is completed, the Ini- 810 tiator and Responder cookies are included in the ISAKMP Header of all sub- 811 sequent communications between the ISAKMP peers. 813 During phase 1 negotiations, the initiator and responder cookies deter- 814 mine the ISAKMP SA. Therefore, the SPI field in the Proposal payload is 815 redundant and MAY be set to 0 or it MAY contain the transmitting entity's 816 cookie. 818 In the third line (3) of the table, the initiator associates a Message ID 819 with the Protocols contained in the SA Proposal. This Message ID and the 820 initiator's SPI(s) to be associated with each protocol in the Proposal are 821 sent to the responder. The SPI(s) will be used by the security protocols 822 once the phase 2 negotiation is completed. 824 In the fourth line (4) of the table, the responder includes the same Mes- 825 sage ID and the responder's SPI(s) to be associated with each protocol in 826 the accepted Proposal. This information is returned to the initiator. 828 In the fifth line (5) of the table, the initiator and responder use the 829 Message ID field in the ISAKMP Header to keep track of the in-progress 830 protocol negotiation. This is only applicable for a phase 2 exchange and 831 the value SHOULD be 0 for a phase 1 exchange because the combined cook- 832 ies identify the ISAKMP SA. The SPI field in the Proposal payload is not 833 applicable because the Proposal payload is only used during the SA negoti- 834 ation message. 836 In the sixth line (6) of the table, the phase 2 negotiation is complete. 837 The security protocols use the SPI to determine which security services 838 and mechanisms to apply to the communication between them. The SPI value 839 shown in the sixth line (6) is not the SPI field in the Proposal payload, 840 but the SPI field contained within the security protocol header. 842 For uniformity, all SPIs are 8 octets long. When negotiating security 843 associations for security protocols that use 4-octet SPIs, the first four 844 octets will be used, and the last four will be zero. 846 When a security association (SA) is initially established, one side as- 847 sumes the role of initiator and the other the role of responder. Once the 848 SA is established, both the original initiator and responder can initiate 849 a phase 2 negotiation with the peer entity. Thus, ISAKMP SAs are bidirec- 850 tional in nature. 852 2.5 Miscellaneous 854 2.5.1 Transport Protocol 856 ISAKMP can be implemented over any transport protocol or over IP itself. 857 Implementations MUST include support for ISAKMP using the User Datagram 858 Protocol (UDP) on port 500. UDP Port 500 has been assigned to ISAKMP by 859 the Internet Assigned Numbered Authority (IANA). Implementations MAY addi- 860 tionally support ISAKMP over other transport protocols or over IP itself. 862 2.5.2 RESERVED Fields 864 The existence of RESERVED fields within ISAKMP payloads are used strictly 865 to preserve byte alignment. All RESERVED fields in the ISAKMP protocol 866 MUST be set to zero (0) when a packet is issued. The receiver SHOULD 867 check the RESERVED fields for a zero (0) value and discard the packet if 868 other values are found. 870 2.5.3 Anti-Clogging Token (``Cookie'') Creation 872 The details of cookie generation are implementation dependent, but MUST 873 satisfy these basic requirements (originally stated by Phil Karn in 874 [Karn]): 876 1. The cookie must depend on the specific parties. This prevents 877 an attacker from obtaining a cookie using a real IP address and 878 UDP port, and then using it to swamp the victim with Diffie- 879 Hellman requests from randomly chosen IP addresses or ports. 881 2. It must not be possible for anyone other than the issuing 882 entity to generate cookies that will be accepted by that 883 entity. This implies that the issuing entity must use local 884 secret information in the generation and subsequent 885 verification of a cookie. It must not be possible to deduce 886 this secret information from any particular cookie. 888 3. The cookie generation function must be fast to thwart attacks 889 intended to sabotage CPU resources. 891 Karn's suggested method for creating the cookie is to perform a fast hash 892 (e.g. MD5) over the IP Source and Destination Address, the UDP Source 893 and Destination Ports and a locally generated secret random value. ISAKMP 894 requires that the cookie be unique for each SA establishment, SA Notify, 895 and SA Delete to help prevent replay attacks, therefore, the date and time 896 MUST be added to the information hashed. The generated cookies are placed 897 in the ISAKMP Header (described in section 3.1) Initiator and Responder 898 cookie fields. These fields are 8 octets in length, thus, requiring a 899 generated cookie to be 8 octets. 901 3 ISAKMP Payloads 903 ISAKMP payloads provide modular building blocks for constructing ISAKMP 904 messages. The presence and ordering of payloads in ISAKMP is defined by 905 and dependent upon the Exchange Type Field located in the ISAKMP Header 906 (see Figure 2). The ISAKMP payload types are discussed in sections 3.4 907 through 3.15. The descriptions of the ISAKMP payloads, messages, and ex- 908 changes (see Section 4) are shown using network byte ordering. Addition- 909 ally, all ISAKMP payloads MUST be aligned at 4-byte multiples. 911 3.1 ISAKMP Header Format 913 An ISAKMP message has a fixed header format, shown in Figure 2, followed 914 by a variable number of payloads. A fixed header simplifies parsing, pro- 915 viding the benefit of protocol parsing software that is less complex and 916 easier to implement. The fixed header contains the information required 917 by the protocol to maintain state, process payloads and possibly prevent 918 denial of service or replay attacks. 920 1 2 3 921 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 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 ! Initiator ! 924 ! Cookie ! 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 ! Responder ! 927 ! Cookie ! 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 ! Message ID ! 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 ! Length ! 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 Figure 2: ISAKMP Header Format 938 The ISAKMP Header fields are defined as follows: 940 o Initiator Cookie (8 octets) - Cookie of entity that initiated SA 941 establishment, SA notification, or SA deletion. 943 o Responder Cookie (8 octets) - Cookie of entity that is responding to 944 an SA establishment request, SA notification, or SA deletion. 946 o Next Payload (1 octet) - Indicates the type of the first payload in 947 the message. The format for each payload is defined in sections 3.4 948 through 3.15. The processing for the payloads is defined in section 949 5. 951 _____Next_Payload_Type_______Value____ 952 NONE 0 953 Security Association (SA) 1 954 Proposal (P) 2 955 Transform (T) 3 956 Key Exchange (KE) 4 957 Identification (ID) 5 958 Certificate (CERT) 6 959 Certificate Request (CR) 7 960 Hash (HASH) 8 961 Signature (SIG) 9 962 Nonce (NONCE) 10 963 Notification (N) 11 964 Delete (D) 12 965 RESERVED 13- 127 966 Private USE 128 - 255 968 o Major Version (4 bits) - indicates the major version of the ISAKMP 969 protocol in use. Implementations based on this version of the ISAKMP 970 Internet-Draft MUST set the Major Version to 1. Implementations 971 based on previous versions of ISAKMP Internet-Drafts MUST set the 972 Major Version to 0. Implementations SHOULD never accept packets with 973 a major version number larger than its own. 975 o Minor Version (4 bits) - indicates the minor version of the ISAKMP 976 protocol in use. Implementations based on this version of the ISAKMP 977 Internet-Draft MUST set the Minor Version to 0. Implementations 978 based on previous versions of ISAKMP Internet-Drafts MUST set the 979 Minor Version to 1. Implementations SHOULD never accept packets with 980 a minor version number larger than its own, given the major version 981 numbers are identical. 983 o Exchange Type (1 octet) - indicates the type of exchange being used. 984 This dictates the message and payload orderings in the ISAKMP 985 exchanges. 987 ____Exchange_Type______Value___ 988 NONE 0 989 Base 1 990 Identity Protection 2 991 Authentication Only 3 992 Aggressive 4 993 Informational 5 994 ISAKMP Future Use 6 - 31 995 DOI Specific Use 32 - 255 997 o Flags (1 octet) - indicates specific options that are set for the 998 ISAKMP exchange. The flags listed below are specified in the Flags 999 field beginning with the least significant bit, i.e the Encryption 1000 bit is bit 0 of the Flags field, the Commit bit is bit 1 of the Flags 1001 field, etc. 1003 -- E(ncryption Bit) (1 bit) - If set (1), all payloads following the 1004 header are encrypted using the encryption algorithm identified in 1005 the ISAKMP SA. The ISAKMP SA Identifier is the combination of the 1006 initiator and responder cookie. If the E(ncryption Bit) is not 1007 set (0), the payloads are not encrypted. 1009 -- C(ommit Bit) (1 bit) - This bit is used to signal possible key 1010 exchange synchronization. It is used to ensure that encrypted 1011 material is not received prior to completion of the SA 1012 establishment. If set (1), the entity which did not set the 1013 Commit Bit MUST wait for an Informational Exchange that the SA 1014 establishment was successful before proceeding with encrypted 1015 traffic communication. 1017 o Message ID (4 octets) - Unique Message Identifier used to identify 1018 protocol state during Phase 2 negotiations. This value is randomly 1019 generated by the initiator of the Phase 2 negotiation. During Phase 1020 1 negotiations, the value MUST be set to 0. 1022 o Length (4 octets) - Length of total message (header + payloads) in 1023 octets. Encryption can expand the size of an ISAKMP message. This 1024 issue is addressed in [IPDOI] and [IO-Res]. 1026 3.2 Payload Generic Header 1028 Each ISAKMP payload defined in sections 3.4 through 3.15 begins with a 1029 generic header, shown in Figure 3.2, which provides a payload "chaining" 1030 capability and clearly defines the boundaries of a payload. 1032 1 2 3 1033 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 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 ! Next Payload ! RESERVED ! Payload Length ! 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 Figure 3: Generic Payload Header 1040 The Generic Payload Header fields are defined as follows: 1042 o Next Payload (1 octet) - Identifier for the payload type of the next 1043 payload in the message. If the current payload is the last in the 1044 message, then this field will be 0. This field provides the 1045 "chaining" capability. 1047 o RESERVED (1 octet) - Unused, set to 0. 1049 o Payload Length (2 octets) - Length in octets of the current payload, 1050 including the generic payload header. 1052 3.3 Data Attributes 1054 There are several instances within ISAKMP where it is necessary to repre- 1055 sent Data Attributes. An example of this is the Security Association (SA) 1056 Attributes contained in the Transform payload (described in section 3.6). 1057 These Data Attributes are not an ISAKMP payload, but are contained within 1058 ISAKMP payloads. The format of the Data Attributes provides the flexi- 1059 bility for representation of many different types of information. There 1060 can be multiple Data Attributes within a payload. This is done using the 1061 Attribute Format bit described below. The length of the Data Attributes 1062 will either be 4 octets or defined by the Attribute Length field. 1064 The Data Attributes fields are defined as follows: 1066 o Attribute Type (2 octets) - Unique identifier for each type of 1067 attribute. These attributes are defined as part of the DOI-specific 1068 information. 1070 1 2 3 1071 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 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 !A! Attribute Type ! AF=0 Attribute Length ! 1074 !F! ! AF=1 Attribute Value ! 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 . AF=0 Attribute Value . 1077 . AF=1 Not Transmitted . 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 Figure 4: Data Attributes 1082 The most significant bit, or Attribute Format (AF), indicates whether 1083 the data attributes follow the Type/Length/Value (TLV) format or a 1084 shortened Type/Value (TV) format. If the AF bit is a zero (0), then 1085 the Data Attributes are of the Type/Length/Value (TLV) form. If the 1086 AF bit is a one (1), then the Data Attributes are of the Type/Value 1087 form. 1089 o Attribute Length (2 octets) - Length in octets of the Attribute 1090 Value. When the AF bit is a one (1), the Attribute Value is only 2 1091 octets and the Attribute Length field is not present. 1093 o Attribute Value (variable length) - Value of the attribute associated 1094 with the DOI-specific Attribute Type. If the AF bit is a zero (0), 1095 this field has a variable length defined by the Attribute Length 1096 field. If the Attribute Value is not aligned at a 4-byte multiple, 1097 the field is right justified and the remaining bits MUST be prepended 1098 with 0 for 4-byte alignment. If the AF bit is a one (1), the 1099 Attribute Value has a length of 2 octets. 1101 3.4 Security Association Payload 1103 The Security Association Payload is used to negotiate security attributes 1104 and to indicate the Domain of Interpretation (DOI) and Situation under 1105 which the negotiation is taking place. Figure 5 shows the format of the 1106 Security Association payload. 1108 The Security Association Payload fields are defined as follows: 1110 o Next Payload (1 octet) - Identifier for the payload type of the next 1111 payload in the message. If the current payload is the last in the 1112 message, then this field will be 0. This field MUST NOT contain the 1113 values for the Proposal or Transform payloads as they are considered 1114 part of the security association negotiation. For example, this 1115 1 2 3 1116 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 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 ! Next Payload ! RESERVED ! Payload Length ! 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 ! Domain of Interpretation (DOI) ! 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 ! ! 1123 ~ Situation ~ 1124 ! ! 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 Figure 5: Security Association Payload 1129 field would contain the value "10" (Nonce payload) in the first 1130 message of a Base Exchange (see Section 4.4) and the value "0" in the 1131 first message of an Identity Protect Exchange (see Section 4.5). 1133 o RESERVED (1 octet) - Unused, set to 0. 1135 o Payload Length (2 octets) - Length in octets of the entire Security 1136 Association payload, including the SA payload, all Proposal payloads, 1137 and all Transform payloads associated with the proposed Security 1138 Association. 1140 o Domain of Interpretation (4 octets) - Identifies the DOI (as 1141 described in Section 2.1) under which this negotiation is taking 1142 place. For the Internet, the DOI is one (1). Other DOI's can be 1143 defined using the description in appendix B. 1145 o Situation (variable length) - A DOI-specific field that identifies 1146 the situation under which this negotiation is taking place. The 1147 Situation is used to make policy decisions regarding the security 1148 attributes being negotiated. Specifics for the IETF IP Security DOI 1149 Situation are detailed in [IPDOI]. 1151 The payload type for the Security Association Payload is one (1). 1153 3.5 Proposal Payload 1155 The Proposal Payload contains information used during Security Associa- 1156 tion negotiation. The proposal consists of security mechanisms, or trans- 1157 forms, to be used to secure the communications channel. Figure 6 shows 1158 the format of the Proposal Payload. A description of its use can be found 1159 1 2 3 1160 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 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 ! Next Payload ! RESERVED ! Payload Length ! 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms! 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 ! SPI (variable) ! 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 Figure 6: Proposal Payload Format 1171 in section 4.1. 1173 The Proposal Payload fields are defined as follows: 1175 o Next Payload (1 octet) - Identifier for the payload type of the next 1176 payload in the message. This field MUST only contain the value "2" 1177 or "0". If there are additional Proposal payloads in the message, 1178 then this field will be 2. If the current Proposal payload is the 1179 last within the security association proposal, then this field will 1180 be 0. 1182 o RESERVED (1 octet) - Unused, set to 0. 1184 o Payload Length (2 octets) - Length in octets of the entire Proposal 1185 payload, including the Proposal payload, and all Transform payloads 1186 associated with this proposal. In the event there are multiple 1187 proposals with the same proposal number (see section 4.1), the 1188 Payload Length field only applies to the current Proposal payload and 1189 not to all Proposal payloads. 1191 o Proposal # (1 octet) - Identifies the Proposal number for the current 1192 payload. A description of the use of this field is found in section 1193 4.1. 1195 o Protocol-Id (1 octet) - Specifies the protocol identifier for the 1196 current negotiation. Examples might include IPSEC ESP, IPSEC AH, 1197 OSPF, TLS, etc. 1199 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 1200 Protocol-Id. 1202 o # of Transforms (1 octet) - Specifies the number of transforms for 1203 the Proposal. Each of these is contained in a Transform payload. 1205 o SPI (variable) - The sending entity's SPI. 1207 The payload type for the Proposal Payload is two (2). 1209 3.6 Transform Payload 1211 The Transform Payload contains information used during Security Associa- 1212 tion negotiation. The Transform payload consists of security mechanisms, 1213 or transforms, to be used to secure the communications channel. The 1214 Transform payload also contains the security association attributes asso- 1215 ciated with the specific transform. These SA attributes are DOI-specific. 1216 Figure 7 shows the format of the Transform Payload. A description of its 1217 use can be found in section 4.1. 1219 1 2 3 1220 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 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 ! Next Payload ! RESERVED ! Payload Length ! 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 ! Transform # ! Transform-Id ! RESERVED2 ! 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 ! ! 1227 ~ SA Attributes ~ 1228 ! ! 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 Figure 7: Transform Payload Format 1233 The Transform Payload fields are defined as follows: 1235 o Next Payload (1 octet) - Identifier for the payload type of the next 1236 payload in the message. This field MUST only contain the value "3" 1237 or "0". If there are additional Transform payloads in the message, 1238 then this field will be 3. If the current Transform payload is the 1239 last within the proposal, then this field will be 0. 1241 o RESERVED (1 octet) - Unused, set to 0. 1243 o Payload Length (2 octets) - Length in octets of the current payload, 1244 including the generic payload header, Transform values, and all SA 1245 Attributes. 1247 o Transform # (1 octet) - Identifies the Transform number for the 1248 current payload. If there is more than one transform proposed for a 1249 specific protocol within the Proposal payload, then each Transform 1250 payload has a unique Transform number. A description of the use of 1251 this field is found in section 4.1. 1253 o Transform-Id (1 octet) - Specifies the Transform identifier for the 1254 protocol within the current proposal. These transforms are defined 1255 by the DOI and are dependent on the protocol being negotiated. 1257 o RESERVED2 (2 octets) - Unused, set to 0. 1259 o SA Attributes (variable length) - This field contains the security 1260 association attributes as defined for the transform given in the 1261 Transform-Id field. The SA Attributes SHOULD be represented using 1262 the Data Attributes format described in section 3.3. 1264 The payload type for the Transform Payload is three (3). 1266 3.7 Key Exchange Payload 1268 The Key Exchange Payload supports a variety of key exchange techniques. 1269 Example key exchanges are Oakley [Oakley], Diffie-Hellman, the enhanced 1270 Diffie-Hellman key exchange described in X9.42 [ANSI], and the RSA-based 1271 key exchange used by PGP. Figure 8 shows the format of the Key Exchange 1272 payload. 1274 1 2 3 1275 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 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 ! Next Payload ! RESERVED ! Payload Length ! 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 ! ! 1280 ~ Key Exchange Data ~ 1281 ! ! 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 Figure 8: Key Exchange Payload Format 1286 The Key Exchange 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. If the current payload is the last in the 1290 message, then this field will be 0. 1292 o RESERVED (1 octet) - Unused, set to 0. 1294 o Payload Length (2 octets) - Length in octets of the current payload, 1295 including the generic payload header. 1297 o Key Exchange Data (variable length) - Data required to generate a 1298 session key. The interpretation of this data is specified by the DOI 1299 and the associated Key Exchange algorithm. This field may also 1300 contain pre-placed key indicators. 1302 The payload type for the Key Exchange Payload is four (4). 1304 3.8 Identification Payload 1306 The Identification Payload contains DOI-specific data used to exchange 1307 identification information. This information is used for determining the 1308 identities of communicating peers and may be used for determining authen- 1309 ticity of information. Figure 9 shows the format of the Identification 1310 Payload. 1312 1 2 3 1313 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 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 ! Next Payload ! RESERVED ! Payload Length ! 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 ! ID Type ! RESERVED2 ! 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 ! ! 1320 ~ Identification Data ~ 1321 ! ! 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 Figure 9: Identification Payload Format 1326 The Identification Payload fields are defined as follows: 1328 o Next Payload (1 octet) - Identifier for the payload type of the next 1329 payload in the message. If the current payload is the last in the 1330 message, then this field will be 0. 1332 o RESERVED (1 octet) - Unused, set to 0. 1334 o Payload Length (2 octets) - Length in octets of the current payload, 1335 including the generic payload header. 1337 o ID Type (1 octet) - Specifies the type of Identification being used. 1338 This field is DOI-dependent. 1340 o RESERVED2 (3 octets) - Unused, set to 0. 1342 o Identification Data (variable length) - Contains identity 1343 information. The values for this field are DOI-specific and the 1344 format is specified by the ID Type field. 1346 The payload type for the Identification Payload is five (5). 1348 3.9 Certificate Payload 1350 The Certificate Payload provides a means to transport certificates or 1351 other certificate-related information via ISAKMP and can appear in any 1352 ISAKMP message. Certificate payloads SHOULD be included in an exchange 1353 whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is 1354 not available to distribute certificates. The Certificate payload MUST be 1355 accepted at any point during an exchange. Figure 10 shows the format of 1356 the Certificate Payload. 1358 NOTE: Certificate types and formats are not generally bound to a DOI - it 1359 is expected that there will only be a few certificate types, and that most 1360 DOIs will accept all of these types. 1362 1 2 3 1363 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 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 ! Next Payload ! RESERVED ! Payload Length ! 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 ! Cert Encoding ! ! 1368 +-+-+-+-+-+-+-+-+ ! 1369 ~ Certificate Data ~ 1370 ! ! 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 Figure 10: Certificate Payload Format 1375 The Certificate Payload fields are defined as follows: 1377 o Next Payload (1 octet) - Identifier for the payload type of the next 1378 payload in the message. If the current payload is the last in the 1379 message, then this field will be 0. 1381 o RESERVED (1 octet) - Unused, set to 0. 1383 o Payload Length (2 octets) - Length in octets of the current payload, 1384 including the generic payload header. 1386 o Certificate Encoding (1 octet) - This field indicates the type of 1387 certificate or certificate-related information contained in the 1388 Certificate Data field. 1390 _________Certificate_Type___________Value___ 1391 NONE 0 1392 PKCS #7 wrapped X.509 certificate 1 1393 PGP Certificate 2 1394 DNS Signed Key 3 1395 X.509 Certificate - Signature 4 1396 X.509 Certificate - Key Exchange 5 1397 Kerberos Tokens 6 1398 Certificate Revocation List (CRL) 7 1399 Authority Revocation List (ARL) 8 1400 RESERVED 9- 255 1402 o Certificate Data (variable length) - Actual encoding of certificate 1403 data. The type of certificate is indicated by the Certificate 1404 Encoding field. 1406 The payload type for the Certificate Payload is six (6). 1408 3.10 Certificate Request Payload 1410 The Certificate Request Payload provides a means to request certificates 1411 via ISAKMP and can appear in any message. Certificate Request payloads 1412 SHOULD be included in an exchange whenever an appropriate directory ser- 1413 vice (e.g. Secure DNS [DNSSEC]) is not available to distribute certifi- 1414 cates. The Certificate Request payloads MUST be accepted at any point 1415 during the exchange. The responder to the Certificate Request payload 1416 MUST send its immediate certificate, if certificates are supported, and 1417 SHOULD send as much of its certificate chain as possible. Figure 11 shows 1418 the format of the Certificate Request Payload. 1420 The Certificate Payload fields are defined as follows: 1422 o Next Payload (1 octet) - Identifier for the payload type of the next 1423 payload in the message. If the current payload is the last in the 1424 message, then this field will be 0. 1426 o RESERVED (1 octet) - Unused, set to 0. 1428 1 2 3 1429 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 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 ! Next Payload ! RESERVED ! Payload Length ! 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 ! # Cert. Types ! ! 1434 +-+-+-+-+-+-+-+-+ ! 1435 ~ Certificate Types ~ 1436 ! ! 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 ! # Cert. Auths ! ! 1439 +-+-+-+-+-+-+-+-+ ! 1440 ~ Certificate Authorities ~ 1441 ! ! 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 Figure 11: Certificate Request Payload Format 1446 o Payload Length (2 octets) - Length in octets of the current payload, 1447 including the generic payload header. 1449 o # Certificate Types (1 octet) - The number of Certificate Types 1450 contained in the Certificate Type field. 1452 o Certificate Types (variable length) - Contains a list of the types of 1453 certificates requested, sorted in order of preference. Each 1454 individual certificate type is 1 octet. 1456 o # Certificate Authorities (1 octet) - The number of Certificate 1457 Authorities contained in the Certificate Authorities field. 1459 o Certificate Authorities (variable length) - Contains a list of Data 1460 Attributes (see section 3.3) which indicate the Distinguished Names 1461 of acceptable certificate authorities. See [IPDOI] for the 1462 Distinguished Name Attribute Type value. 1464 The payload type for the Certificate Request Payload is seven (7). 1466 3.11 Hash Payload 1468 The Hash Payload contains data generated by the hash function (selected 1469 during the SA establishment exchange), over some part of the message 1470 and/or ISAKMP state. This payload may be used to verify the integrity of 1471 the data in an ISAKMP message or for authentication of the negotiating en- 1472 1 2 3 1473 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 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 ! Next Payload ! RESERVED ! Payload Length ! 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 ! ! 1478 ~ Hash Data ~ 1479 ! ! 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 Figure 12: Hash Payload Format 1484 tities. Figure 12 shows the format of the Hash Payload. 1486 The Hash Payload fields are defined as follows: 1488 o Next Payload (1 octet) - Identifier for the payload type of the next 1489 payload in the message. If the current payload is the last in the 1490 message, then this field will be 0. 1492 o RESERVED (1 octet) - Unused, set to 0. 1494 o Payload Length (2 octets) - Length in octets of the current payload, 1495 including the generic payload header. 1497 o Hash Data (variable length) - Data that results from applying the 1498 hash routine to the ISAKMP message and/or state. 1500 The payload type for the Hash Payload is eight (8). 1502 3.12 Signature Payload 1504 The Signature Payload contains data generated by the digital signature 1505 function (selected during the SA establishment exchange), over some part 1506 of the message and/or ISAKMP state. This payload is used to verify the 1507 integrity of the data in the ISAKMP message, and may be of use for non- 1508 repudiation services. Figure 13 shows the format of the Signature Pay- 1509 load. 1511 The Signature Payload fields are defined as follows: 1513 o Next Payload (1 octet) - Identifier for the payload type of the next 1514 payload in the message. If the current payload is the last in the 1515 1 2 3 1516 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 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 ! Next Payload ! RESERVED ! Payload Length ! 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 ! ! 1521 ~ Signature Data ~ 1522 ! ! 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 Figure 13: Signature Payload Format 1527 message, then this field will be 0. 1529 o RESERVED (1 octet) - Unused, set to 0. 1531 o Payload Length (2 octets) - Length in octets of the current payload, 1532 including the generic payload header. 1534 o Signature Data (variable length) - Data that results from applying 1535 the digital signature function to the ISAKMP message and/or state. 1537 The payload type for the Signature Payload is nine (9). 1539 3.13 Nonce Payload 1541 The Nonce Payload contains random data used to guarantee liveness dur- 1542 ing an exchange and protect against replay attacks. Figure 14 shows the 1543 format of the Nonce Payload. If nonces are used by a particular key ex- 1544 change, the use of the Nonce payload would be dictated by the key ex- 1545 change. The nonces may be transmitted as part of the key exchange data, 1546 or as a separate payload. However, this is defined by the key exchange, 1547 not by ISAKMP. 1549 The Nonce Payload fields are defined as follows: 1551 o Next Payload (1 octet) - Identifier for the payload type of the next 1552 payload in the message. If the current payload is the last in the 1553 message, then this field will be 0. 1555 o RESERVED (1 octet) - Unused, set to 0. 1557 o Payload Length (2 octets) - Length in octets of the current payload, 1558 including the generic payload header. 1560 1 2 3 1561 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 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 ! Next Payload ! RESERVED ! Payload Length ! 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 ! ! 1566 ~ Nonce Data ~ 1567 ! ! 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 Figure 14: Nonce Payload Format 1572 o Nonce Data (variable length) - Contains the random data generated by 1573 the transmitting entity. 1575 The payload type for the Nonce Payload is ten (10). 1577 3.14 Notification Payload 1579 The Notification Payload contains both ISAKMP and DOI-specific data used 1580 to transmit informational data, such as error conditions, to an ISAKMP 1581 peer. It is possible to send multiple Notification payloads in a single 1582 ISAKMP message. Figure 15 shows the format of the Notification Payload. 1584 Notification which occurs during, or is concerned with, a Phase 1 nego- 1585 tiation is identified by the Initiator and Responder cookie pair in the 1586 ISAKMP Header. The Protocol Identifier, in this case, is ISAKMP and the 1587 SPI value is 0 because the cookie pair in the ISAKMP Header identifies the 1588 ISAKMP SA. 1590 Notification which occurs during, or is concerned with, a Phase 2 nego- 1591 tiation is identified by the Initiator and Responder cookie pair in the 1592 ISAKMP Header and the Message ID and SPI associated with the current nego- 1593 tiation. One example for this type of notification is to indicate why a 1594 proposal was rejected. 1596 The Notification Payload fields are defined as follows: 1598 o Next Payload (1 octet) - Identifier for the payload type of the next 1599 payload in the message. If the current payload is the last in the 1600 message, then this field will be 0. 1602 o RESERVED (1 octet) - Unused, set to 0. 1604 1 2 3 1605 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 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 ! Next Payload ! RESERVED ! Payload Length ! 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 ! Domain of Interpretation (DOI) ! 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 ! Protocol-ID ! SPI Size ! Notify Message Type ! 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 ! ! 1614 ~ Security Parameter Index (SPI) ~ 1615 ! ! 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 ! ! 1618 ~ Notification Data ~ 1619 ! ! 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 Figure 15: Notification Payload Format 1624 o Payload Length (2 octets) - Length in octets of the current payload, 1625 including the generic payload header. 1627 o Domain of Interpretation (4 octets) - Identifies the DOI (as 1628 described in Section 2.1) under which this notification is taking 1629 place. For the Internet, the DOI is one (1). Other DOI's can be 1630 defined using the description in appendix B. 1632 o Protocol-Id (1 octet) - Specifies the protocol identifier for the 1633 current notification. Examples might include ISAKMP, IPSEC ESP, 1634 IPSEC AH, OSPF, TLS, etc. 1636 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 1637 Protocol-Id. In the case of ISAKMP, the Initiator and Responder 1638 cookie pair is the ISAKMP SPI. In this case, the SPI Size would be 16 1639 octets for each SPI being deleted. 1641 o Notify Message Type (2 octets) - Specifies the type of notification 1642 message (see section 3.14.1). Additional text, if specified by the 1643 DOI, is placed in the Notification Data field. 1645 o SPI (variable length) - Security Parameter Index. The receiving 1646 entity's SPI. The use of the SPI field is described in section 2.4. 1647 The length of this field is determined by the SPI Size field. 1649 o Notification Data (variable length) - Informational or error data 1650 transmitted in addition to the Notify Message Type. Values for this 1651 field are DOI-specific. 1653 The payload type for the Notification Payload is eleven (11). 1655 3.14.1 Notify Message Types 1657 Notification information can be error messages specifying why an SA could 1658 not be established. It can also be status data that a process managing 1659 an SA database wishes to communicate with a peer process. For example, 1660 a secure front end or security gateway may use the Notify message to syn- 1661 chronize SA communication. The table below lists the Nofitication mes- 1662 sages and their corresponding values. Values in the Private Use range are 1663 expected to be DOI-specific values. 1665 NOTIFY MESSAGES - ERROR TYPES 1667 __________Errors______________Value_____ 1668 INVALID-PAYLOAD-TYPE 1 1669 DOI-NOT-SUPPORTED 2 1670 SITUATION-NOT-SUPPORTED 3 1671 INVALID-COOKIE 4 1672 INVALID-MAJOR-VERSION 5 1673 INVALID-MINOR-VERSION 6 1674 INVALID-EXCHANGE-TYPE 7 1675 INVALID-FLAGS 8 1676 INVALID-MESSAGE-ID 9 1677 INVALID-PROTOCOL-ID 10 1678 INVALID-SPI 11 1679 INVALID-TRANSFORM-ID 12 1680 ATTRIBUTES-NOT-SUPPORTED 13 1681 NO-PROPOSAL-CHOSEN 14 1682 BAD-PROPOSAL-SYNTAX 15 1683 PAYLOAD-MALFORMED 16 1684 INVALID-KEY-INFORMATION 17 1685 INVALID-ID-INFORMATION 18 1686 INVALID-CERT-ENCODING 19 1687 INVALID-CERTIFICATE 20 1688 BAD-CERT-REQUEST-SYNTAX 21 1689 INVALID-CERT-AUTHORITY 22 1690 INVALID-HASH-INFORMATION 23 1691 AUTHENTICATION-FAILED 24 1692 INVALID-SIGNATURE 25 1693 ADDRESS-NOTIFICATION 26 1694 RESERVED (Future Use) 27- 8192 1695 Private Use 8193 - 16383 1696 NOTIFY MESSAGES - STATUS TYPES 1697 ________Status_____________Value______ 1698 CONNECTED 16384 1699 RESERVED (Future Use) 16385- 24576 1700 Private Use 24577 - 32767 1702 3.15 Delete Payload 1704 The Delete Payload contains a protocol-specific security association iden- 1705 tifier that the sender has removed from its security association database 1706 and is, therefore, no longer valid. Figure 16 shows the format of the 1707 Delete Payload. It is possible to send multiple SPIs in a Delete payload, 1708 however, each SPI MUST be for the same protocol. Mixing of Protocol Iden- 1709 tifiers MUST NOT be performed with the Delete payload. 1711 Deletion which is concerned with an ISAKMP SA will contain a Protocol-Id 1712 of ISAKMP and the SPIs are the initiator and responder cookies. Deletion 1713 which is concerned with a Protocol SA, such as ESP and/or AH, will con- 1714 tain the Protocol-Id of that protocol (e.g. ESP, AH) and the SPI is the 1715 sending entity's SPI(s). 1717 NOTE: The Delete Payload is not a request for the responder to delete an 1718 SA, but an advisory from the initiator to the responder. If the responder 1719 chooses to ignore the message, the next communication from the responder 1720 to the initiator, using that security association, will fail. A responder 1721 is not expected to acknowledge receipt of a Delete payload. 1723 1 2 3 1724 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 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 ! Next Payload ! RESERVED ! Payload Length ! 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 ! Domain of Interpretation (DOI) ! 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 ! Protocol-Id ! SPI Size ! # of SPIs ! 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 ! ! 1733 ~ Security Parameter Index(es) (SPI) ~ 1734 ! ! 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 Figure 16: Delete Payload Format 1739 The Delete Payload fields are defined as follows: 1741 o Next Payload (1 octet) - Identifier for the payload type of the next 1742 payload in the message. If the current payload is the last in the 1743 message, then this field will be 0. 1745 o RESERVED (1 octet) - Unused, set to 0. 1747 o Payload Length (2 octets) - Length in octets of the current payload, 1748 including the generic payload header. 1750 o Domain of Interpretation (4 octets) - Identifies the DOI (as 1751 described in Section 2.1) under which this deletion is taking place. 1752 For the Internet, the DOI is one (1). Other DOI's can be defined 1753 using the description in appendix B. 1755 o Protocol-Id (1 octet) - ISAKMP can establish security associations 1756 for various protocols, including ISAKMP and IPSEC. This field identi- 1757 fies which security association database to apply the delete request. 1759 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 1760 Protocol-Id. In the case of ISAKMP, the Initiator and Responder 1761 cookie pair is the ISAKMP SPI. In this case, the SPI Size would be 16 1762 octets for each SPI being deleted. 1764 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 1765 payload. The size of each SPI is defined by the SPI Size field. 1767 o Security Parameter Index(es) (variable length) - Identifies the 1768 specific security association(s) to delete. Values for this field 1769 are DOI and protocol specific. The length of this field is 1770 determined by the SPI Size and # of SPIs fields. 1772 The payload type for the Delete Payload is twelve (12). 1774 4 ISAKMP Exchanges 1776 ISAKMP supplies the basic syntax of a message exchange. The basic build- 1777 ing blocks for ISAKMP messages are the payload types described in section 1778 3. This section describes the procedures for SA establishment and SA mod- 1779 ification, followed by a default set of exchanges that MAY be used for 1780 initial interoperability. 1782 4.1 Security Association Establishment 1784 The Security Association, Proposal, and Transform payloads are used to 1785 build ISAKMP messages for the negotiation and establishment of SAs. An 1786 SA establishment message consists of a single SA payload followed by at 1787 least one, and possibly many, Proposal and Transform payloads. The SA 1788 Payload contains the DOI and Situation for the proposed SA. Each Proposal 1789 payload contains a Security Parameter Index (SPI) and ensures that the SPI 1790 is associated with the Protocol-Id in accordance with the Internet Secu- 1791 rity Architecture [RFC-1825]. Each Transform Payload contains the spe- 1792 cific security mechanisms to be used for the designated protocol. It is 1793 expected that the Proposal and Transform payloads will be used only dur- 1794 ing SA establishment negotiation. The creation of payloads for security 1795 association negotiation and establishment described here in this section 1796 are applicable for all ISAKMP exchanges described later in sections 4.4 1797 through 4.8. 1799 The Proposal payload provides the initiating entity with the capability 1800 to present to the responding entity the security protocols and associated 1801 security mechanisms for use with the security association being negoti- 1802 ated. If the SA establishment negotiation is for a combined protection 1803 suite consisting of multiple protocols, then there MUST be multiple Pro- 1804 posal payloads each with the same Proposal number. These proposals MUST 1805 be considered as a unit and MUST NOT be separated by a proposal with a 1806 different proposal number. The use of the same Proposal number in mul- 1807 tiple Proposal payloads provides a logical AND operation, i.e. Protocol 1808 1 AND Protocol 2. The first example below shows an ESP AND AH protection 1809 suite. If the SA establishment negotiation is for different protection 1810 suites, then there MUST be multiple Proposal payloads each with a monoton- 1811 ically increasing Proposal number. The different proposals MUST be pre- 1812 sented in the initiator's preference order. The use of different Proposal 1813 numbers in multiple Proposal payloads provides a logical OR operation, 1814 i.e. Proposal 1 OR Proposal 2, where each proposal may have more than one 1815 protocol. The second example below shows either an AH AND ESP protection 1816 suite OR just an ESP protection suite. Note that the Next Payload field 1817 of the Proposal payload points to another Proposal payload (if it exists). 1818 The existence of a Proposal payload implies the existence of one or more 1819 Transform payloads. 1821 The Transform payload provides the initiating entity with the capability 1822 to present to the responding entity multiple mechanisms, or transforms, 1823 for a given protocol. The Proposal payload identifies a Protocol for 1824 which services and mechanisms are being negotiated. The Transform pay- 1825 load allows the initiating entity to present several possible supported 1826 transforms for that proposed protocol. There may be several transforms 1827 associated with a specific Proposal payload each identified in a separate 1828 Transform payload. The multiple transforms MUST be presented with mono- 1829 tonically increasing numbers in the initiator's preference order. The 1830 receiving entity MUST select a single transform for each protocol in a 1831 proposal or reject the entire proposal. The use of the Transform number 1832 in multiple Transform payload provides a second level OR operation, i.e. 1833 Transform 1 OR Transform 2 OR Transform 3. Example 1 below shows three 1834 possible transforms for ESP and a single transform for AH. Example 2 below 1835 shows two transforms for AH AND two transforms for ESP OR two transform 1836 for ESP alone. Note that the Next Payload field of the Transform payload 1837 points to another Transform payload or 0. The Proposal payload delineates 1838 the different proposals. 1840 When responding to a Security Association payload, the responder MUST send 1841 a Security Association payload with the selected proposal, which may con- 1842 sist of multiple Proposal payloads and their associated Transform pay- 1843 loads. Each of the Proposal payloads MUST contain a single Transform 1844 payload associated with the Protocol. The responder SHOULD retain the 1845 Proposal # field in the Proposal payload and the Transform # field in 1846 each Transform payload of the selected Proposal. Retention of Proposal 1847 and Transform numbers should speed the initiator's protocol processing by 1848 negating the need to compare the respondor's selection with every offered 1849 option. These values enable the initiator to perform the comparison di- 1850 rectly and quickly. The initiator MUST verify that the Security Associa- 1851 tion payload received from the responder matches one of the proposals sent 1852 initially. 1854 4.1.1 Security Association Establishment Examples 1856 This example shows a Proposal for a combined protection suite with two 1857 different protocols. The first protocol is presented with two transforms 1858 supported by the proposer. The second protocol is presented with a sin- 1859 gle transform. An example for this proposal might be: Protocol 1 is ESP 1860 with Transform 1 as 3DES and Transform 2 as DES AND Protocol 2 is AH with 1861 Transform 1 as SHA. The responder MUST select from the two transforms pro- 1862 posed for ESP. The resulting protection suite will be either (1) 3DES AND 1863 SHA OR (2) DES AND SHA, depending on which ESP transform was selected by 1864 the responder. Note this example is shown using the Base Exchange. 1866 1 2 3 1867 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 1868 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 / ! NP = Nonce ! RESERVED ! Payload Length ! 1870 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 SA Pay ! Domain of Interpretation (DOI) ! 1872 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 \ ! Situation ! 1874 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 / ! NP = Proposal ! RESERVED ! Payload Length ! 1876 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 Prop 1 ! Proposal # = 1! Protocol-Id ! # of Transforms ! 1878 Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 \ ! SPI (8 octets) ! 1880 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 / ! NP = Transform! RESERVED ! Payload Length ! 1882 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 Tran 1 ! Transform # ! Transform ID ! RESERVED2 ! 1884 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 \ ! SA Attributes ! 1886 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 / ! NP = 0 ! RESERVED ! Payload Length ! 1888 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1889 Tran 2 ! Transform # ! Transform ID ! RESERVED2 ! 1890 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 \ ! SA Attributes ! 1892 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 / ! NP = 0 ! RESERVED ! Payload Length ! 1894 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 Prop 1 ! Proposal # = 1! Protocol ID ! # of Transforms ! 1896 Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 \ ! SPI (8 octets) ! 1898 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 / ! NP = 0 ! RESERVED ! Payload Length ! 1900 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 Tran 1 ! Transform # ! Transform ID ! RESERVED2 ! 1902 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 \ ! SA Attributes ! 1904 \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 This second example shows a Proposal for two different protection suites. 1907 The SA Payload was omitted for space reasons. The first protection suite 1908 is presented with one transform for the first protocol and one transform 1909 for the second protocol. The second protection suite is presented with 1910 two transforms for a single protocol. An example for this proposal might 1911 be: Proposal 1 with Protocol 1 as AH with Transform 1 as MD5 AND Protocol 1912 2 as ESP with Transform 1 as 3DES. This is followed by Proposal 2 with 1913 Protocol 1 as ESP with Transform 1 as DES and Transform 2 as 3DES. The 1914 responder MUST select from the two different proposals. If the second 1915 Proposal is selected, the responder MUST select from the two transforms 1916 for ESP. The resulting protection suite will be either (1) MD5 AND 3DES OR 1917 the selection between (2) DES OR (3) 3DES. 1919 1 2 3 1920 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 1921 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 / ! NP = Proposal ! RESERVED ! Payload Length ! 1923 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 Prop 1 ! Proposal # = 1! Protocol ID ! # of Transforms ! 1925 Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 \ ! SPI (8 octets) ! 1927 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 / ! NP = 0 ! RESERVED ! Payload Length ! 1929 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 Tran 1 ! Transform # ! Transform ID ! RESERVED2 ! 1931 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 \ ! SA Attributes ! 1933 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 / ! NP = Proposal ! RESERVED ! Payload Length ! 1936 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 Prop 1 ! Proposal # = 1! Protocol ID ! # of Transforms ! 1938 Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 \ ! SPI (8 octets) ! 1940 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1941 / ! NP = 0 ! RESERVED ! Payload Length ! 1942 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1943 Tran 1 ! Transform # ! Transform ID ! RESERVED2 ! 1944 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1945 \ ! SA Attributes ! 1946 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 / ! NP = 0 ! RESERVED ! Payload Length ! 1948 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 Prop 2 ! Proposal # = 2! Protocol ID ! # of Transforms ! 1950 Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 \ ! SPI (8 octets) ! 1952 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 / ! NP = Transform! RESERVED ! Payload Length ! 1954 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 Tran 1 ! Transform # ! Transform ID ! RESERVED2 ! 1956 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 \ ! SA Attributes ! 1958 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 / ! NP = 0 ! RESERVED ! Payload Length ! 1960 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 Tran 2 ! Transform # ! Transform ID ! RESERVED2 ! 1962 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 \ ! SA Attributes ! 1964 \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 4.2 Security Association Modification 1968 Security Association modification within ISAKMP is accomplished by cre- 1969 ating a new SA and initiating communications using that new SA. Deletion 1970 of the old SA can be done anytime after the new SA is established. Dele- 1971 tion of the old SA is dependent on local security policy. Modification of 1972 SAs by using a "Create New SA followed by Delete Old SA" method is done to 1973 avoid potential vulnerabilities in synchronizing modification of existing 1974 SA attributes. The procedures for creating new SAs is outlined in section 1975 4.1. The procedures for deleting SAs is outlined in section 5.13. 1977 Modification of an ISAKMP SA (phase 1 negotiation) follows the same pro- 1978 cedure as creation of an ISAKMP SA. There is no relationship between the 1979 two SAs and the initiator and responder cookie pairs MUST be different, as 1980 outlined in section 2.5.3. 1982 Modification of a Protocol SA (phase 2 negotiation) follows the same pro- 1983 cedure as creation of a Protocol SA. The creation of a new SA is protected 1984 by the existing ISAKMP SA. There is no relationship between the two Proto- 1985 col SAs. A protocol implementation SHOULD begin using the newly created 1986 SA for outbound traffic and SHOULD continue to support incoming traffic on 1987 the old SA until it is deleted. 1989 4.3 ISAKMP Exchange Types 1991 ISAKMP allows the creation of exchanges for the establishment of Security 1992 Associations and keying material. There are currently five default Ex- 1993 change Types defined for ISAKMP. Sections 4.4 through 4.8 describe these 1994 exchanges. Exchanges define the content and ordering of ISAKMP messages 1995 during communications between peers. Most exchanges will include all the 1996 basic payload types - SA, KE, ID, SIG - and may include others. The pri- 1997 mary difference between exchange types is the ordering of the messages and 1998 the payload ordering within each message. 2000 Sections 4.4 through 4.8 provide a default set of ISAKMP exchanges. These 2001 exchanges provide different security protection for the exchange itself 2002 and information exchanged. The diagrams in each of the following sections 2003 show the message ordering for each exchange type as well as the payloads 2004 included in each message, and provide basic notes describing what has hap- 2005 pened after each message exchange. None of the examples include any "op- 2006 tional payloads", like certificate and certificate request. 2008 The defined exchanges are not meant to satisfy all DOI and key exchange 2009 protocol requirements. If the defined exchanges meet the DOI require- 2010 ments, then they can be used as outlined. If the defined exchanges do 2011 not meet the security requirements defined by the DOI, then it is up to 2012 the DOI to specify a new exchange type and the valid sequences of payloads 2013 that make up a successful exchange, and how to build and interpret those 2014 payloads. All ISAKMP implementations MUST implement the Informational Ex- 2015 change and SHOULD implement the other five exchanges. However, this is 2016 dependent on the definition of the DOI and associated key exchange proto- 2017 cols. 2019 As discussed above, these exchange types can be used in either phase of 2020 negotiation. However, they may provide different security properties 2021 in each of the phases. With each of these exchanges, the combination of 2022 cookies and SPI fields identifies whether this exchange is being used in 2023 the first or second phase of a negotiation. 2025 4.3.1 Notation 2027 The following notation is used to describe the ISAKMP exchange types, 2028 shown in the next section, with the message formats and associated pay- 2029 loads: 2031 HDR is an ISAKMP header whose exchange type defines the payload orderings 2032 SA is an SA negotiation payload with one or more Proposal and 2033 Transform payloads. An initiator MAY provide multiple proposals 2034 for negotiation; a responder MUST reply with only one. 2035 KE is the key exchange payload. 2036 IDx is the identity payload for "x". x can be: "ii" or "ir" 2037 for the ISAKMP initiator and responder, respectively, or x can 2038 be: "ui", "ur" (when the ISAKMP daemon is a proxy negotiator), 2039 for the user initiator and responder, respectively. 2040 HASH is the hash payload. 2041 SIG is the signature payload. The data to sign is exchange-specific. 2042 AUTH is a generic authentication mechanism, such as HASH or SIG. 2043 NONCE is the nonce payload. 2044 '*' signifies payload encryption after the ISAKMP header. This 2045 encryption MUST begin immediately after the ISAKMP header and 2046 all payloads following the ISAKMP header MUST be encrypted. 2048 => signifies "initiator to responder" communication 2049 <= signifies "responder to initiator" communication 2051 4.4 Base Exchange 2053 The Base Exchange is designed to allow the Key Exchange and Authentica- 2054 tion related information to be transmitted together. Combining the Key 2055 Exchange and Authentication-related information into one message reduces 2056 the number of round-trips at the expense of not providing identity pro- 2057 tection. Identity protection is not provided because identities are ex- 2058 changed before a common shared secret has been established and, therefore, 2059 encryption of the identities is not possible. The following diagram shows 2060 the messages with the possible payloads sent in each message and notes for 2061 an example of the Base Exchange. 2063 BASE EXCHANGE 2065 _#______Initiator____Direction_____Responder______________________NOTE____________________ 2066 (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation 2068 (2) <= HDR; SA; NONCE 2069 Basic SA agreed upon 2070 (3) HDR; KE; => 2071 IDii; AUTH 2072 Initiator Identity Verified by Responder 2073 (4) <= HDR; KE; 2074 IDir; AUTH 2075 Responder Identity Verified by Initiator 2076 Key Generated 2077 SA established 2079 In the first message (1), the initiator generates a proposal it considers 2080 adequate to protect traffic for the given situation. The Security Associ- 2081 ation, Proposal, and Transform payloads are included in the Security Asso- 2082 ciation payload (for notation purposes). Random information which is used 2083 to guarantee liveness and protect against replay attacks is also trans- 2084 mitted. Random information provided by both parties SHOULD be used by the 2085 authentication mechanism to provide shared proof of participation in the 2086 exchange. 2088 In the second message (2), the responder indicates the protection suite it 2089 has accepted with the Security Association, Proposal, and Transform pay- 2090 loads. Again, random information which is used to guarantee liveness and 2091 protect against replay attacks is also transmitted. Random information 2092 provide by both parties SHOULD be used by the authentication mechanism 2093 to provide shared proof of participation in the exchange. Local secu- 2094 rity policy dictates the action of the responder if no proposed protection 2095 suite is accepted. One possible action is the transmission of a Notify 2096 payload as part of an Informational Exchange. 2098 In the third (3) and fourth (4) messages, the initiator and responder, re- 2099 spectively, exchange keying material used to arrive at a common shared 2100 secret and identification information. This information is transmitted 2101 under the protection of the agreed upon authentication function. Local 2102 security policy dictates the action if an error occurs during these mes- 2103 sages. One possible action is the transmission of a Notify payload as 2104 part of an Informational Exchange. 2106 4.5 Identity Protection Exchange 2108 The Identity Protection Exchange is designed to separate the Key Exchange 2109 information from the Identity and Authentication related information. 2111 Separating the Key Exchange from the Identity and Authentication related 2112 information provides protection of the communicating identities at the ex- 2113 pense of an additional message. Identities are exchanged under the pro- 2114 tection of a previously established common shared secret. The following 2115 diagram shows the messages with the possible payloads sent in each message 2116 and notes for an example of the Identity Protection Exchange. 2118 IDENTITY PROTECTION EXCHANGE 2120 _#_______Initiator_____Direction______Responder_____NOTE______________________________________ 2121 (1) HDR; SA => Begin ISAKMP-SA or Proxy negotiation 2122 (2) <= HDR; SA 2123 Basic SA agreed upon 2124 (3) HDR; KE; NONCE => 2125 (4) <= HDR; KE; NONCE 2126 Key Generated 2127 (5) HDR*; IDii; AUTH => 2128 Initiator Identity Verified by Responder 2129 (6) <= HDR*; IDir; AUTH 2130 Responder Identity Verified by Initiator 2131 SA established 2133 In the first message (1), the initiator generates a proposal it consid- 2134 ers adequate to protect traffic for the given situation. The Security As- 2135 sociation, Proposal, and Transform payloads are included in the Security 2136 Association payload (for notation purposes). 2138 In the second message (2), the responder indicates the protection suite it 2139 has accepted with the Security Association, Proposal, and Transform pay- 2140 loads. Local security policy dictates the action of the responder if no 2141 proposed protection suite is accepted. One possible action is the trans- 2142 mission of a Notify payload as part of an Informational Exchange. 2144 In the third (3) and fourth (4) messages, the initiator and responder, re- 2145 spectively, exchange keying material used to arrive at a common shared se- 2146 cret and random information which is used to guarantee liveness and pro- 2147 tect against replay attacks. Random information provided by both parties 2148 SHOULD be used by the authentication mechanism to provide shared proof 2149 of participation in the exchange. Local security policy dictates the ac- 2150 tion if an error occurs during these messages. One possible action is the 2151 transmission of a Notify payload as part of an Informational Exchange. 2153 In the fifth (5) and sixth (6) messages, the initiator and responder, re- 2154 spectively, exchange identification information and the results of the 2155 agreed upon authentication function. This information is transmitted un- 2156 der the protection of the common shared secret. Local security policy 2157 dictates the action if an error occurs during these messages. One pos- 2158 sible action is the transmission of a Notify payload as part of an Infor- 2159 mational Exchange. 2161 4.6 Authentication Only Exchange 2163 The Authentication Only Exchange is designed to allow only Authentication 2164 related information to be transmitted. The benefit of this exchange is 2165 the ability to perform only authentication without the computational ex- 2166 pense of computing keys. Using this exchange during negotiation, none of 2167 the transmitted information will be encrypted. However, the information 2168 may be encrypted in other places. For example, if encryption is negoti- 2169 ated during the first phase of a negotiation and the authentication only 2170 exchange is used in the second phase of a negotiation, then the authenti- 2171 cation only exchange will be encrypted by the ISAKMP SAs negotiated in the 2172 first phase. The following diagram shows the messages with possible pay- 2173 loads sent in each message and notes for an example of the Authentication 2174 Only Exchange. 2176 AUTHENTICATION ONLY EXCHANGE 2178 _#______Initiator_____Direction_____Responder_______________________NOTE____________________ 2179 (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation 2181 (2) <= HDR; SA; NONCE; 2182 IDir; AUTH 2183 Basic SA agreed upon 2184 Responder Identity Verified by Initiator 2185 (3) HDR; IDii; AUTH => 2186 Initiator Identity Verified by Responder 2187 SA established 2189 In the first message (1), the initiator generates a proposal it considers 2190 adequate to protect traffic for the given situation. The Security Associ- 2191 ation, Proposal, and Transform payloads are included in the Security Asso- 2192 ciation payload (for notation purposes). Random information which is used 2193 to guarantee liveness and protect against replay attacks is also trans- 2194 mitted. Random information provided by both parties SHOULD be used by the 2195 authentication mechanism to provide shared proof of participation in the 2196 exchange. 2198 In the second message (2), the responder indicates the protection suite it 2199 has accepted with the Security Association, Proposal, and Transform pay- 2200 loads. Again, random information which is used to guarantee liveness and 2201 protect against replay attacks is also transmitted. Random information 2202 provided by both parties SHOULD be used by the authentication mechanism 2203 to provide shared proof of participation in the exchange. Additionally, 2204 the responder transmits identification information. All of this infor- 2205 mation is transmitted under the protection of the agreed upon authentica- 2206 tion function. Local security policy dictates the action of the responder 2207 if no proposed protection suite is accepted. One possible action is the 2208 transmission of a Notify payload as part of an Informational Exchange. 2210 In the third message (3), the initiator transmits identification informa- 2211 tion. This information is transmitted under the protection of the agreed 2212 upon authentication function. Local security policy dictates the action 2213 if an error occurs during these messages. One possible action is the 2214 transmission of a Notify payload as part of an Informational Exchange. 2216 4.7 Aggressive Exchange 2218 The Aggressive Exchange is designed to allow the Security Association, Key 2219 Exchange and Authentication related payloads to be transmitted together. 2220 Combining the Security Association, Key Exchange, and Authentication- 2221 related information into one message reduces the number of round-trips at 2222 the expense of not providing identity protection. Identity protection is 2223 not provided because identities are exchanged before a common shared se- 2224 cret has been established and, therefore, encryption of the identities is 2225 not possible. Additionally, the Aggressive Exchange is attempting to es- 2226 tablish all security relevant information in a single exchange. The fol- 2227 lowing diagram shows the messages with possible payloads sent in each mes- 2228 sage and notes for an example of the Aggressive Exchange. 2230 AGGRESSIVE EXCHANGE 2232 _#_____Initiator___Direction______Responder________________________NOTE____________________ 2233 (1) HDR; SA; KE; => Begin ISAKMP-SA or Proxy negotiation 2234 NONCE; IDii and Key Exchange 2236 (2) <= HDR; SA; KE; 2237 NONCE; IDir; AUTH 2238 Initiator Identity Verified by Responder 2239 Key Generated 2240 Basic SA agreed upon 2241 (3) HDR*; AUTH => 2242 Responder Identity Verified by Initiator 2243 SA established 2245 In the first message (1), the initiator generates a proposal it consid- 2246 ers adequate to protect traffic for the given situation. The Security 2247 Association, Proposal, and Transform payloads are included in the Secu- 2248 rity Association payload (for notation purposes). Keying material used 2249 to arrive at a common shared secret and random information which is used 2250 to guarantee liveness and protect against replay attacks are also trans- 2251 mitted. Random information provided by both parties SHOULD be used by the 2252 authentication mechanism to provide shared proof of participation in the 2253 exchange. Additionally, the initiator transmits identification informa- 2254 tion. 2256 In the second message (2), the responder indicates the protection suite 2257 it has accepted with the Security Association, Proposal, and Transform 2258 payloads. Keying material used to arrive at a common shared secret and 2259 random information which is used to guarantee liveness and protect against 2260 replay attacks is also transmitted. Random information provided by both 2261 parties SHOULD be used by the authentication mechanism to provide shared 2262 proof of participation in the exchange. Additionally, the responder 2263 transmits identification information. All of this information is trans- 2264 mitted under the protection of the agreed upon authentication function. 2265 Local security policy dictates the action of the responder if no proposed 2266 protection suite is accepted. One possible action is the transmission of 2267 a Notify payload as part of an Informational Exchange. 2269 In the third (3) message, the initiator transmits the results of the 2270 agreed upon authentication function. This information is transmitted un- 2271 der the protection of the common shared secret. Local security policy 2272 dictates the action if an error occurs during these messages. One pos- 2273 sible action is the transmission of a Notify payload as part of an Infor- 2274 mational Exchange. 2276 4.8 Informational Exchange 2278 The Informational Exchange is designed as a one-way transmittal of infor- 2279 mation that can be used for security association management. The follow- 2280 ing diagram shows the messages with possible payloads sent in each message 2281 and notes for an example of the Informational Exchange. 2283 INFORMATIONAL EXCHANGE 2285 __#___Initiator__Direction_Responder_______________NOTE_______________ 2286 (1) HDR; N/D => Error Notification or Deletion 2288 In the first message (1), the initiator or responder transmits an ISAKMP 2289 Notify or Delete payload. 2291 If the Informational Exchange occurs during an ISAKMP Phase 1 negotia- 2292 tion there will be no protection provided for the Informational Exchange. 2293 Once an ISAKMP SA has been established, the Informational Exchange MUST be 2294 transmitted under the protection provided by the ISAKMP SA. 2296 5 ISAKMP Payload Processing 2298 Section 3 describes the ISAKMP payloads. These payloads are used in the 2299 exchanges described in section 4 and can be used in exchanges defined for 2300 a specific DOI. This section describes the processing for each of the 2301 payloads. This section suggests the logging of events to a system au- 2302 dit file. This action is controlled by a system security policy and is, 2303 therefore, only a suggested action. 2305 5.1 General Message Processing 2307 Every ISAKMP message has basic processing applied to insure protocol re- 2308 liability, and to minimize threats, such as denial of service and replay 2309 attacks. 2311 When transmitting an ISAKMP message, the transmitting entity (initiator or 2312 responder) MUST do the following: 2314 1. Set a timer and initialize a retry counter. 2316 2. If the timer expires, the ISAKMP message is resent and the retry 2317 counter is decremented. 2319 3. If the retry counter reaches zero (0), the event, RETRY LIMIT 2320 REACHED, is logged in the appropriate system audit file. 2322 4. The ISAKMP protocol machine clears all states and returns to IDLE. 2324 5.2 ISAKMP Header Processing 2326 When creating an ISAKMP message, the transmitting entity MUST do the fol- 2327 lowing: 2329 1. Create the respective cookie. See section 2.5.3 for details. 2331 2. Determine the relevant security characteristics of the session (i.e. 2332 DOI and situation). 2334 3. Construct an ISAKMP Header with fields as described in section 3.1. 2336 4. Construct other ISAKMP payloads, depending on the exchange type. 2338 5. Transmit the message to the destination host as described in section 2339 5.1. 2341 When an ISAKMP message is received, the receiving entity (initiator or 2342 responder) MUST do the following: 2344 1. Verify the Initiator and Responder ``cookies''. If the cookie 2345 validation fails, the message is discarded and the following actions 2346 are taken: 2348 (a) The event, INVALID COOKIE, is logged in the appropriate system 2349 audit file. 2351 (b) An Informational Exchange with a Notification payload containing 2352 the INVALID-COOKIE message type MAY be sent to the initiating 2353 entity. This action is dictated by a system security policy. 2355 2. Check the Next Payload field to confirm it is valid. If the Next 2356 Payload field validation fails, the message is discarded and the 2357 following actions are taken: 2359 (a) The event, INVALID NEXT PAYLOAD, is logged in the appropriate 2360 system audit file. 2362 (b) An Informational Exchange with a Notification payload containing 2363 the INVALID-PAYLOAD-TYPE message type MAY be sent to the initiat- 2364 ing entity. This action is dictated by a system security policy. 2366 3. Check the Major and Minor Version fields to confirm they are correct. 2367 If the Version field validation fails, the message is discarded and 2368 the following actions are taken: 2370 (a) The event, INVALID ISAKMP VERSION, is logged in the appropriate 2371 system audit file. 2373 (b) An Informational Exchange with a Notification payload containing 2374 the INVALID-MAJOR-VERSION or INVALID-MINOR-VERSION message type 2375 MAY be sent to the initiating entity. This action is dictated by 2376 a system security policy. 2378 4. Check the Exchange Type field to confirm it is valid. If the 2379 Exchange Type field validation fails, the message is discarded and 2380 the following actions are taken: 2382 (a) The event, INVALID EXCHANGE TYPE, is logged in the appropriate 2383 system audit file. 2385 (b) An Informational Exchange with a Notification payload containing 2386 the INVALID-EXCHANGE-TYPE message type MAY be sent to the 2387 initiating entity. This action is dictated by a system security 2388 policy. 2390 5. Check the Flags field to ensure it contains correct values. If the 2391 Flags field validation fails, the message is discarded and the 2392 following actions are taken: 2394 (a) The event, INVALID FLAGS, is logged in the appropriate system 2395 audit file. 2397 (b) An Informational Exchange with a Notification payload containing 2398 the INVALID-FLAGS message type MAY be sent to the initiating 2399 entity. This action is dictated by a system security policy. 2401 6. Check the Message ID field to ensure it contains correct values. If 2402 the Message ID validation fails, the message is discarded and the 2403 following actions are taken: 2405 (a) The event, INVALID MESSAGE ID, is logged in the appropriate 2406 system audit file. 2408 (b) An Informational Exchange with a Notification payload containing 2409 the INVALID-MESSAGE-ID message type MAY be sent to the initiating 2410 entity. This action is dictated by a system security policy. 2412 7. Processing of the ISAKMP message continues using the value in the 2413 Next Payload field. 2415 5.3 Generic Payload Header Processing 2417 When creating any of the ISAKMP Payloads described in sections 5.4 through 2418 5.13 a Generic Payload Header is placed at the beginning of these pay- 2419 loads. When creating the Generic Payload Header, the transmitting entity 2420 MUST do the following: 2422 1. Place the value of the Next Payload in the Next Payload field. These 2423 values are described in section 3.1. 2425 2. Place the value zero (0) in the RESERVED field. 2427 3. Place the length (in octets) of the payload in the Payload Length 2428 field. 2430 4. Construct the payloads as defined in the remainder of this section. 2432 When any of the ISAKMP Payloads are received, the receiving entity (ini- 2433 tiator or responder) MUST do the following: 2435 1. Check the Next Payload field to confirm it is valid. If the Next 2436 Payload field validation fails, the message is discarded and the 2437 following actions are taken: 2439 (a) The event, INVALID NEXT PAYLOAD, is logged in the appropriate 2440 system audit file. 2442 (b) An Informational Exchange with a Notification payload containing 2443 the INVALID-PAYLOAD-TYPE message type MAY be sent to the initiat- 2444 ing entity. This action is dictated by a system security policy. 2446 2. Verify the RESERVED field contains the value zero. If the value in 2447 the RESERVED field is not zero, the message is discarded and the 2448 following actions are taken: 2450 (a) The event, INVALID RESERVED FIELD, is logged in the appropriate 2451 system audit file. 2453 (b) An Informational Exchange with a Notification payload containing 2454 the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be 2455 sent to the initiating entity. This action is dictated by a 2456 system security policy. 2458 3. Process the remaining payloads as defined by the Next Payload field. 2460 5.4 Security Association Payload Processing 2462 When creating a Security Association Payload, the transmitting entity MUST 2463 do the following: 2465 1. Determine the Domain of Interpretation for which this negotiation is 2466 being performed. 2468 2. Determine the situation within the determined DOI for which this 2469 negotiation is being performed. 2471 3. Determine the proposal(s) and transform(s) within the situation. 2472 These are described, respectively, in sections 3.5, 5.4.1, 3.6, and 2473 5.4.2. 2475 4. Construct a Security Association payload. 2477 5. Transmit the message to the initiating host as described in section 2478 5.1. 2480 When a Security Association payload is received, the receiving entity 2481 (initiator or responder) MUST do the following: 2483 1. Determine if the Domain of Interpretation (DOI) is supported. If the 2484 DOI determination fails, the message is discarded and the following 2485 actions are taken: 2487 (a) The event, INVALID DOI, is logged in the appropriate system audit 2488 file. 2490 (b) An Informational Exchange with a Notification payload containing 2491 the DOI-NOT-SUPPORTED message type MAY be sent to the initiating 2492 entity. This action is dictated by a system security policy. 2494 2. Determine if the given situation can be protected. If the Situation 2495 determination fails, the message is discarded and the following 2496 actions are taken: 2498 (a) The event, INVALID SITUATION, is logged in the appropriate system 2499 audit file. 2501 (b) An Informational Exchange with a Notification payload containing 2502 the SITUATION-NOT-SUPPORTED message type MAY be sent to the 2503 initiating entity. This action is dictated by a system security 2504 policy. 2506 3. Process the remaining payloads (i.e. Proposal, Transform) of the 2507 Security Association Payload. If the Security Association Proposal 2508 (as described in sections 5.4.1 and 5.4.2) is not accepted, then the 2509 following actions are taken: 2511 (a) The event, INVALID PROPOSAL, is logged in the appropriate system 2512 audit file. 2514 (b) An Informational Exchange with a Notification payload containing 2515 the NO-PROPOSAL-CHOSEN message type MAY be sent to the initiating 2516 entity. This action is dictated by a system security policy. 2518 5.4.1 Proposal Payload Processing 2520 When creating a Proposal Payload, the transmitting entity MUST do the fol- 2521 lowing: 2523 1. Determine the Protocol for this proposal. 2525 2. Determine the number of proposals to be offered for this protocol and 2526 the number of transforms for each proposal. Transforms are described 2527 in sections 3.6 and 5.4.2. 2529 3. Generate a unique pseudo-random SPI. 2531 4. Construct a Proposal payload. 2533 When a Proposal payload is received, the receiving entity (initiator or 2534 responder) MUST do the following: 2536 1. Determine if the Protocol is supported. If the Protocol-ID field is 2537 invalid, the message is discarded and the following actions are 2538 taken: 2540 (a) The event, INVALID PROTOCOL, is logged in the appropriate system 2541 audit file. 2543 (b) An Informational Exchange with a Notification payload containing 2544 the INVALID-PROTOCOL-ID message type MAY be sent to the initiat- 2545 ing entity. This action is dictated by a system security policy. 2547 2. Determine if the SPI is valid. If the SPI is invalid, the message is 2548 discarded and the following actions are taken: 2550 (a) The event, INVALID SPI, is logged in the appropriate system audit 2551 file. 2553 (b) An Informational Exchange with a Notification payload containing 2554 the INVALID-SPI message type MAY be sent to the initiating 2555 entity. This action is dictated by a system security policy. 2557 3. Ensure the Proposals are presented according to the details given in 2558 section 3.5 and 4.1. If the proposals are not formed correctly, the 2559 following actions are taken: 2561 (a) Possible events, BAD PROPOSAL SYNTAX, INVALID PROPOSAL, are 2562 logged in the appropriate system audit file. 2564 (b) An Informational Exchange with a Notification payload containing 2565 the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be 2566 sent to the initiating entity. This action is dictated by a 2567 system security policy. 2569 4. Process the Proposal and Transform payloads as defined by the Next 2570 Payload field. Examples of processing these payloads is given in 2571 section 4.1.1. 2573 5.4.2 Transform Payload Processing 2575 When creating a Transform Payload, the transmitting entity MUST do the 2576 following: 2578 1. Determine the Transform # for this transform. 2580 2. Determine the number of transforms to be offered for this proposal. 2581 Transforms are described in sections 3.6. 2583 3. Construct a Transform payload. 2585 When a Transform payload is received, the receiving entity (initiator or 2586 responder) MUST do the following: 2588 1. Determine if the Transform is supported. If the Transform-ID field 2589 is invalid, the message is discarded and the following actions are 2590 taken: 2592 (a) The event, INVALID TRANSFORM, is logged in the appropriate system 2593 audit file. 2595 (b) An Informational Exchange with a Notification payload containing 2596 the INVALID-TRANSFORM-ID message type MAY be sent to the initiat- 2597 ing entity. This action is dictated by a system security policy. 2599 2. Ensure the Transforms are presented according to the details given in 2600 section 3.6 and 4.1. If the transforms are not formed correctly, the 2601 following actions are taken: 2603 (a) Possible events, BAD PROPOSAL SYNTAX, INVALID TRANSFORM, INVALID 2604 ATTRIBUTES, are logged in the appropriate system audit file. 2606 (b) An Informational Exchange with a Notification payload containing 2607 the BAD-PROPOSAL-SYNTAX, PAYLOAD-MALFORMED or ATTRIBUTES-NOT- 2608 SUPPORTED message type MAY be sent to the initiating entity. 2609 This action is dictated by a system security policy. 2611 3. Process the subsequent Transform and Proposal payloads as defined by 2612 the Next Payload field. Examples of processing these payloads is 2613 given in section 4.1.1. 2615 5.5 Key Exchange Payload Processing 2617 When creating a Key Exchange Payload, the transmitting entity MUST do the 2618 following: 2620 1. Determine the Key Exchange to be used as defined by the DOI. 2622 2. Determine the usage of the Key Exchange Data field as defined by the 2623 DOI. 2625 3. Construct a Key Exchange payload. 2627 4. Transmit the message to the initiating host as described in section 2628 5.1. 2630 When a Key Exchange payload is received, the receiving entity (initiator 2631 or responder) MUST do the following: 2633 1. Determine if the Key Exchange is supported. If the Key Exchange 2634 determination fails, the message is discarded and the following 2635 actions are taken: 2637 (a) The event, INVALID KEY INFORMATION, is logged in the appropriate 2638 system audit file. 2640 (b) An Informational Exchange with a Notification payload containing 2641 the INVALID-KEY-INFORMATION message type MAY be sent to the 2642 initiating entity. This action is dictated by a system security 2643 policy. 2645 5.6 Identification Payload Processing 2647 When creating an Identification Payload, the transmitting entity MUST do 2648 the following: 2650 1. Determine the Identification information to be used as defined by the 2651 DOI (and possibly the situation). 2653 2. Determine the usage of the Identification Data field as defined by 2654 the DOI. 2656 3. Construct an Identification payload. 2658 4. Transmit the message to the initiating host as described in section 2659 5.1. 2661 When an Identification payload is received, the receiving entity (initia- 2662 tor or responder) MUST do the following: 2664 1. Determine if the Identification Type is supported. This may be based 2665 on the DOI and Situation. If the Identification determination fails, 2666 the message is discarded and the following actions are taken: 2668 (a) The event, INVALID ID INFORMATION, is logged in the appropriate 2669 system audit file. 2671 (b) An Informational Exchange with a Notification payload containing 2672 the INVALID-ID-INFORMATION message type MAY be sent to the 2673 initiating entity. This action is dictated by a system security 2674 policy. 2676 5.7 Certificate Payload Processing 2678 When creating a Certificate Payload, the transmitting entity MUST do the 2679 following: 2681 1. Determine the Certificate Encoding to be used. This may be specified 2682 by the DOI. 2684 2. Ensure the existence of a certificate formatted as defined by the 2685 Certificate Encoding. 2687 3. Construct a Certificate payload. 2689 4. Transmit the message to the initiating host as described in section 2690 5.1. 2692 When a Certificate payload is received, the receiving entity (initiator or 2693 responder) MUST do the following: 2695 1. Determine if the Certificate Encoding is supported. If the 2696 Certificate Encoding is not supported, the message is discarded and 2697 the following actions are taken: 2699 (a) The event, INVALID CERTIFICATE TYPE, is logged in the appropriate 2700 system audit file. 2702 (b) An Informational Exchange with a Notification payload containing 2703 the INVALID-CERT-ENCODING message type MAY be sent to the 2704 initiating entity. This action is dictated by a system security 2705 policy. 2707 2. Process the Certificate Data field. If the Certificate Data is 2708 invalid or improperly formatted, the message is discarded and the 2709 following actions are taken: 2711 (a) The event, INVALID CERTIFICATE, is logged in the appropriate 2712 system audit file. 2714 (b) An Informational Exchange with a Notification payload containing 2715 the INVALID-CERTIFICATE message type MAY be sent to the initiat- 2716 ing entity. This action is dictated by a system security policy. 2718 5.8 Certificate Request Payload Processing 2720 When creating a Certificate Request Payload, the transmitting entity MUST 2721 do the following: 2723 1. Determine the number and types of acceptable Certificate Encodings to 2724 be requested. This may be specified by the DOI. 2726 2. Determine the number and names of Certificate Authorities which are 2727 acceptable and are to be requested. 2729 3. Construct a Certificate Request payload. 2731 4. Transmit the message to the initiating host as described in section 2732 5.1. 2734 When a Certificate Request payload is received, the receiving entity (ini- 2735 tiator or responder) MUST do the following: 2737 1. Ensure that the # of Certificate Types and the actual values 2738 contained in the Certificate Types field are equivalent. If not, 2739 then the following actions are taken: 2741 (a) The event, BAD CERTIFICATE REQUEST SYNTAX, is logged in the 2742 appropriate system audit file. 2744 (b) An Informational Exchange with a Notification payload containing 2745 the BAD-CERT-REQUEST-SYNTAX message type MAY be sent to the 2746 initiating entity. This action is dictated by a system security 2747 policy. 2749 2. Determine if the Certificate Types are supported. If any of the 2750 Certificate Types are not supported, the message is discarded and the 2751 following actions are taken: 2753 (a) The event, INVALID CERTIFICATE TYPE, is logged in the appropriate 2754 system audit file. 2756 (b) An Informational Exchange with a Notification payload containing 2757 the INVALID-CERT-ENCODING message type MAY be sent to the 2758 initiating entity. This action is dictated by a system security 2759 policy. 2761 3. Ensure that the # of Certificate Authorities and the actual values 2762 contained in the Certificate Authorities field are equivalent. If 2763 not, then the following actions are taken: 2765 (a) The event, BAD CERTIFICATE REQUEST SYNTAX, is logged in the 2766 appropriate system audit file. 2768 (b) An Informational Exchange with a Notification payload containing 2769 the BAD-CERT-REQUEST-SYNTAX message type MAY be sent to the 2770 initiating entity. This action is dictated by a system security 2771 policy. 2773 4. Process the Certificate Authorities field. If the Certificate 2774 Authorities are invalid or improperly formatted, the message is 2775 discarded and the following actions are taken: 2777 (a) The event, INVALID CERTIFICATE AUTHORITIES, is logged in the 2778 appropriate system audit file. 2780 (b) An Informational Exchange with a Notification payload containing 2781 the INVALID-CERT-AUTHORITY message type MAY be sent to the 2782 initiating entity. This action is dictated by a system security 2783 policy. 2785 5.9 Hash Payload Processing 2787 When creating a Hash Payload, the transmitting entity MUST do the follow- 2788 ing: 2790 1. Determine the Hash function to be used as defined by the SA 2791 negotiation. 2793 2. Determine the usage of the Hash Data field as defined by the DOI. 2795 3. Construct a Hash payload. 2797 4. Transmit the message to the initiating host as described in section 2798 5.1. 2800 When a Hash payload is received, the receiving entity (initiator or re- 2801 sponder) MUST do the following: 2803 1. Determine if the Hash is supported. If the Hash determination fails, 2804 the message is discarded and the following actions are taken: 2806 (a) The event, INVALID HASH INFORMATION, is logged in the appropriate 2807 system audit file. 2809 (b) An Informational Exchange with a Notification payload containing 2810 the INVALID-HASH-INFORMATION message type MAY be sent to the 2811 initiating entity. This action is dictated by a system security 2812 policy. 2814 2. Perform the Hash function as outlined in the DOI and/or Key Exchange 2815 protocol documents. If the Hash function fails, the message is 2816 discarded and the following actions are taken: 2818 (a) The event, INVALID HASH VALUE, is logged in the appropriate 2819 system audit file. 2821 (b) An Informational Exchange with a Notification payload containing 2822 the AUTHENTICATION-FAILED message type MAY be sent to the 2823 initiating entity. This action is dictated by a system security 2824 policy. 2826 5.10 Signature Payload Processing 2828 When creating a Signature Payload, the transmitting entity MUST do the 2829 following: 2831 1. Determine the Signature function to be used as defined by the SA 2832 negotiation. 2834 2. Determine the usage of the Signature Data field as defined by the 2835 DOI. 2837 3. Construct a Signature payload. 2839 4. Transmit the message to the initiating host as described in section 2840 5.1. 2842 When a Signature payload is received, the receiving entity (initiator or 2843 responder) MUST do the following: 2845 1. Determine if the Signature is supported. If the Signature 2846 determination fails, the message is discarded and the following 2847 actions are taken: 2849 (a) The event, INVALID SIGNATURE INFORMATION, is logged in the 2850 appropriate system audit file. 2852 (b) An Informational Exchange with a Notification payload containing 2853 the INVALID-SIGNATURE message type MAY be sent to the initiating 2854 entity. This action is dictated by a system security policy. 2856 2. Perform the Signature function as outlined in the DOI and/or Key 2857 Exchange protocol documents. If the Signature function fails, the 2858 message is discarded and the following actions are taken: 2860 (a) The event, INVALID SIGNATURE VALUE, is logged in the appropriate 2861 system audit file. 2863 (b) An Informational Exchange with a Notification payload containing 2864 the AUTHENTICATION-FAILED message type MAY be sent to the 2865 initiating entity. This action is dictated by a system security 2866 policy. 2868 5.11 Nonce Payload Processing 2870 When creating a Nonce Payload, the transmitting entity MUST do the follow- 2871 ing: 2873 1. Create a unique random value to be used as a nonce. 2875 2. Construct a Nonce payload. 2877 3. Transmit the message to the initiating host as described in section 2878 5.1. 2880 When a Nonce payload is received, the receiving entity (initiator or re- 2881 sponder) MUST do the following: 2883 1. There are no specific procedures for handling Nonce payloads. The 2884 procedures are defined by the exchange types (and possibly the DOI 2885 and Key Exchange descriptions). 2887 5.12 Notification Payload Processing 2889 When creating a Notification Payload, the transmitting entity MUST do the 2890 following: 2892 1. Determine the DOI for this Notification. 2894 2. Determine the Protocol-ID for this Notification. 2896 3. Determine the SPI size based on the Protocol-ID field. This field is 2897 necessary because different security protocols have different SPI 2898 sizes. For example, ISAKMP combines the Initiator and Responder 2899 cookie pair (16 octets) as a SPI, while ESP and AH have 8 octet SPIs. 2901 4. Determine the Notify Message Type based on the error or status 2902 message desired. 2904 5. Determine the SPI which is associated with this notification. 2906 6. Determine if addition Notification Data is to be included. This is 2907 additional information specified by the DOI. 2909 7. Construct a Notification payload. 2911 Because the Informational Exchange with a Notification payload is a uni- 2912 directional message a retransmission will not be performed. The local 2913 security policy will dictate the procedures for continuing. However, we 2914 RECOMMEND that a NOTIFICATION PAYLOAD ERROR event be logged in the appro- 2915 priate system audit file. 2917 5.13 Delete Payload Processing 2919 During communications it is possible that hosts may be compromised or that 2920 information may be intercepted during transmission. Determining whether 2921 this has occurred is not an easy task and is outside the scope of this 2922 Internet-Draft. However, if it is discovered that transmissions are being 2923 compromised, then it is necessary to establish a new SA and delete the 2924 current SA. 2926 The Informational Exchange with a Delete Payload provides a controlled 2927 method of informing a peer entity that the initiating entity has deleted 2928 the SA(s). Deletion of Security Associations MUST always be performed 2929 under the protection of an ISAKMP SA. The receiving entity SHOULD clean up 2930 its local SA database. However, upon receipt of a Delete message the SAs 2931 listed in the Security Parameter Index (SPI) field of the Delete payload 2932 cannot be used with the initiating entity. The SA Establishment procedure 2933 must be invoked to re-establish secure communications. 2935 When creating a Delete Payload, the transmitting entity MUST do the fol- 2936 lowing: 2938 1. Determine the DOI for this Deletion. 2940 2. Determine the Protocol-ID for this Deletion. 2942 3. Determine the SPI size based on the Protocol-ID field. This field is 2943 necessary because different security protocols have different SPI 2944 sizes. For example, ISAKMP combines the Initiator and Responder 2945 cookie pair (16 octets) as a SPI, while ESP and AH have 8 octet SPIs. 2947 4. Determine the # of SPIs to be deleted for this protocol. 2949 5. Determine the SPI(s) which is (are) associated with this deletion. 2951 6. Construct a Delete payload. 2953 Because the Informational Exchange with a Delete payload is a unidirec- 2954 tional message a retransmission will not be performed. The local security 2955 policy will dictate the procedures for continuing. However, we RECOMMEND 2956 that a DELETE PAYLOAD ERROR event be logged in the appropriate system au- 2957 dit file. 2959 6 Conclusions 2961 The Internet Security Association and Key Management Protocol (ISAKMP) is 2962 a well designed protocol aimed at the Internet of the future. The mas- 2963 sive growth of the Internet will lead to great diversity in network uti- 2964 lization, communications, security requirements, and security mechanisms. 2965 ISAKMP contains all the features that will be needed for this dynamic and 2966 expanding communications environment. 2968 ISAKMP's Security Association (SA) feature coupled with authentication 2969 and key establishment provides the security and flexibility that will be 2970 needed for future growth and diversity. This security diversity of multi- 2971 ple key exchange techniques, encryption algorithms, authentication mecha- 2972 nisms, security services, and security attributes will allow users to se- 2973 lect the appropriate security for their network, communications, and secu- 2974 rity needs. The SA feature allows users to specify and negotiate security 2975 requirements with other users. An additional benefit of supporting multi- 2976 ple techniques in a single protocol is that as new techniques are devel- 2977 oped they can easily be added to the protocol. This provides a path for 2978 the growth of Internet security services. ISAKMP supports both publicly 2979 or privately defined SAs, making it ideal for government, commercial, and 2980 private communications. 2982 ISAKMP provides the ability to establish SAs for multiple security proto- 2983 cols and applications. These protocols and applications may be session- 2984 oriented or sessionless. Having one SA establishment protocol that sup- 2985 ports multiple security protocols eliminates the need for multiple, nearly 2986 identical authentication, key exchange and SA establishment protocols when 2987 more than one security protocol is in use or desired. Just as IP has pro- 2988 vided the common networking layer for the Internet, a common security es- 2989 tablishment protocol is needed if security is to become a reality on the 2990 Internet. ISAKMP provides the common base that allows all other security 2991 protocols to interoperate. 2993 ISAKMP follows good security design principles. It is not coupled to 2994 other insecure transport protocols, therefore it is not vulnerable or 2995 weakened by attacks on other protocols. Also, when more secure transport 2996 protocols are developed, ISAKMP can be easily migrated to them. ISAKMP 2997 also provides protection against protocol related attacks. This protec- 2998 tion provides the assurance that the SAs and keys established are with the 2999 desired party and not with an attacker. 3001 ISAKMP also follows good protocol design principles. Protocol specific 3002 information only is in the protocol header, following the design prin- 3003 ciples of IPv6. The data transported by the protocol is separated into 3004 functional payloads. As the Internet grows and evolves, new payloads to 3005 support new security functionality can be added without modifying the en- 3006 tire protocol. 3008 A ISAKMP Security Association Attributes 3010 A.1 Background/Rationale 3012 As detailed in previous sections, ISAKMP is designed to provide a flexible 3013 and extensible framework for establishing and managing Security Associa- 3014 tions and cryptographic keys. The framework provided by ISAKMP consists 3015 of header and payload definitions, exchange types for guiding message and 3016 payload exchanges, and general processing guidelines. ISAKMP does not 3017 define the mechanisms that will be used to establish and manage Security 3018 Associations and cryptographic keys in an authenticated and confidential 3019 manner. The definition of mechanisms and their application is the purview 3020 of individual Domains of Interpretation (DOIs). 3022 This section describes the ISAKMP values for the Internet IP Security DOI. 3023 The Internet IP Security DOI is MANDATORY to implement for IP Security. 3024 [Oakley] and [IO-Res] describe, in detail, the mechanisms and their ap- 3025 plication for establishing and managing Security Associations and crypto- 3026 graphic keys for IP Security. 3028 A.2 Assigned Values for the Internet IP Security DOI 3030 A.2.1 Internet IP Security DOI Assigned Value 3032 As described in [IPDOI], the Internet IP Security DOI Assigned Number is 3033 one (1). 3035 A.2.2 Supported Security Protocols 3037 Values for supported security protocols are specified in the most recent 3038 ``Assigned Numbers'' RFC [STD-2]. Presented in the following table are 3039 the values for the security protocols supported by ISAKMP for the Internet 3040 IP Security DOI. 3042 _Protocol_Assigned_Value__ 3043 RESERVED 0 3044 ISAKMP 1 3046 All DOIs MUST reserve ISAKMP with a Protocol-ID of 1. All other security 3047 protocols within that DOI will be numbered accordingly. 3049 Security protocol values 2-1024 are reserved for IANA use. Values 1025- 3050 15360 are reserved for future use. Values 15361-16383 are reserved for 3051 private use. 3053 B Defining a new Domain of Interpretation 3055 The Internet DOI may be sufficient to meet the security requirements of 3056 a large portion of the internet community. However, some groups may have 3057 a need to customize some aspect of a DOI, perhaps to add a different set 3058 of cryptographic algorithms, or perhaps because they want to make their 3059 security-relevant decisions based on something other than a host id or 3060 user id. Also, a particular group may have a need for a new exchange 3061 type, for example to support key management for multicast groups. 3063 This section discusses guidelines for defining a new DOI. The full speci- 3064 fication for the internet DOI can be found in [IPDOI]. 3066 Defining a new DOI is likely to be a time-consuming process. If at all 3067 possible, it is recommended that the designer begin with an existing DOI 3068 and customize only the parts that are unacceptable. 3070 If a designer chooses to start from scratch, the following MUST be de- 3071 fined: 3073 o A ``situation'': the set of information that will be used to 3074 determine the required security services. 3076 o The set of security policies that must be supported. 3078 o A scheme for naming security-relevant information, including 3079 encryption algorithms, key exchange algorithms, etc. 3081 o A syntax for the specification of proposed security services, 3082 attributes, and certificate authorities. 3084 o The specific formats of the various payload contents. 3086 o Additional exchange types, if required. 3088 B.1 Situation 3090 The situation is the basis for deciding how to protect a communications 3091 channel. It must contain all of the data that will be used to determine 3092 the types and strengths of protections applied in an SA. For example, a 3093 US Department of Defense DOI would probably use unpublished algorithms 3094 and have additional special attributes to negotiate. These additional 3095 security attributes would be included in the situation. 3097 B.2 Security Policies 3099 Security policies define how various types of information must be cate- 3100 gorized and protected. The DOI must define the set of security policies 3101 supported, because both parties in a negotiation must trust that the other 3102 party understands a situation, and will protect information appropriately, 3103 both in transit and in storage. In a corporate setting, for example, both 3104 parties in a negotiation must agree to the meaning of the term ``propri- 3105 etary information'' before they can negotiate how to protect it. 3107 Note that including the required security policies in the DOI only speci- 3108 fies that the participating hosts understand and implement those policies 3109 in a full system context. 3111 B.3 Naming Schemes 3113 Any DOI must define a consistent way to name cryptographic algorithms, 3114 certificate authorities, etc. This can usually be done by using IANA nam- 3115 ing conventions, perhaps with some private extensions. 3117 B.4 Syntax for Specifying Security Services 3119 In addition to simply specifying how to name entities, the DOI must also 3120 specify the format for complete proposals of how to protect traffic under 3121 a given situation. 3123 B.5 Payload Specification 3125 The DOI must specify the format of each of the payload types. For several 3126 of the payload types, ISAKMP has included fields that would have to be 3127 present across all DOI (such as a certificate authority in the certificate 3128 payload, or a key exchange identifier in the key exchange payload). 3130 B.6 Defining new Exchange Types 3132 If the basic exchange types are inadequate to meet the requirements within 3133 a DOI, a designer can define up to thirteen extra exchange types per DOI. 3134 The designer creates a new exchange type by choosing an unused exchange 3135 type value, and defining a sequence of messages composed of strings of the 3136 ISAKMP payload types. 3138 Note that any new exchange types must be rigorously analyzed for vulner- 3139 abilities. Since this is an expensive and imprecise undertaking, a new 3140 exchange type should only be created when absolutely necessary. 3142 Security Considerations 3144 Cryptographic analysis techniques are improving at a steady pace. The 3145 continuing improvement in processing power makes once computationally pro- 3146 hibitive cryptographic attacks more realistic. New cryptographic algo- 3147 rithms and public key generation techniques are also being developed at a 3148 steady pace. New security services and mechanisms are being developed at 3149 an accelerated pace. A consistent method of choosing from a variety of 3150 security services and mechanisms and to exchange attributes required by 3151 the mechanisms is important to security in the complex structure of the 3152 Internet. However, a system that locks itself into a single cryptographic 3153 algorithm, key exchange technique, or security mechanism will become in- 3154 creasingly vulnerable as time passes. 3156 UDP is an unreliable datagram protocol and therefore its use in ISAKMP in- 3157 troduces a number of security considerations. Since UDP is unreliable, 3158 but a key management protocol must be reliable, the reliability is built 3159 into ISAKMP. While ISAKMP utilizes UDP as its transport mechanism, it 3160 doesn't rely on any UDP information (e.g. checksum, length) for its pro- 3161 cessing. 3163 Another issue that must be considered in the development of ISAKMP is the 3164 effect of firewalls on the protocol. Many firewalls filter out all UDP 3165 packets, making reliance on UDP questionable in certain environments. 3167 A number of very important security considerations are presented in 3168 [RFC-1825]. One bears repeating. Once a private session key is created, 3169 it must be safely stored. Failure to properly protect the private key 3170 from access both internal and external to the system completely nullifies 3171 any protection provided by the IP Security services. 3173 Acknowledgements 3175 Dan Harkins, Dave Carrel, and Derrell Piper of Cisco Systems provided de- 3176 sign assistance with the protocol and coordination for the [IO-Res] and 3177 [IPDOI] documents. 3179 Hilarie Orman, via the Oakley key exchange protocol, has significantly 3180 influenced the design of ISAKMP. 3182 Marsha Gross, Bill Kutz, Mike Oehler, and Pete Sell provided significant 3183 input and review to this document. 3185 Scott Carlson ported the TIS DNSSEC prototype to FreeBSD for use with the 3186 ISAKMP prototype. 3188 Jeff Turner and Steve Smalley contributed to the prototype development and 3189 integration with ESP and AH. 3191 Mike Oehler and Pete Sell performed interoperability testing with other 3192 ISAKMP implementors. 3194 Thanks to Carl Muckenhirn of SPARTA, Inc. for his assistance with LaTeX. 3196 References 3198 [ANSI] ANSI, X9.42: Public Key Cryptography for the Financial Services 3199 Industry -- Establishment of Symmetric Algorithm Keys Using 3200 Diffie-Hellman, Working Draft, April 19, 1996. 3202 [RFC-1825] Randall Atkinson, Security Architecture for the Internet 3203 Protocol, RFC-1825, August, 1995. 3205 [BC] Ballardie, A. and J. Crowcroft, Multicast-specific Security Threats 3206 and Countermeasures, Proceedings of 1995 ISOC Symposium on Networks 3207 & Distributed Systems Security, pp. 17-30, Internet Society, San 3208 Diego, CA, February 1995. 3210 [RFC-1949] A. Ballardie, Scalable Multicast Key Distribution, RFC-1949, 3211 May, 1996. 3213 [Berge] Berge, N.H., UNINETT PCA Policy Statements, Internet-Draft, work 3214 in progress, November, 1995. 3216 [CW87] Clark, D.D. and D.R. Wilson, A Comparison of Commercial and 3217 Military Computer Security Policies, Proceedings of the IEEE 3218 Symposium on Security & Privacy, Oakland, CA, 1987, pp 184-193. 3220 [DOW92] Diffie, W., M.Wiener, P. Van Oorschot, Authentication and 3221 Authenticated Key Exchanges, Designs, Codes, and Cryptography, 2, 3222 107-125, Kluwer Academic Publishers, 1992. 3224 [DNSSEC] Eastlake III, D. and C. Kaufman, Domain Name System Protocol 3225 Security Extensions, Internet-Draft, work in progress, Feb, 1996. 3227 [Karn] Karn, P. and B. Simpson, The Photuris Session Key Management 3228 Protocol, Internet-Draft: draft-simpson-photuris-11.txt, Work in 3229 Progress, June, 1996. 3231 [RFC-1422] Steve Kent, Privacy Enhancement for Internet Electronic Mail: 3232 Part II: Certificate-Based Key Management, RFC-1422, February 1993. 3234 [Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August 10, 3235 1994. 3237 [Oakley] H. K. Orman, The Oakley Key Determination Protocol, Internet- 3238 Draft: draft-ietf-ipsec-oakley-01.txt, Work in Progress, May 1996. 3240 [IO-Res] Harkins, D. and D. Carrel, The Resolution of ISAKMP with Oakley, 3241 Internet-Draft: draft-ietf-ipsec-isakmp-oakley-02.txt, Work in 3242 Progress, November, 1996. 3244 [IPDOI] Derrell Piper, The Internet IP Security Domain of Interpretation 3245 for ISAKMP, Internet-Draft: draft-ietf-ipsec-ipsec-doi-01.txt, Work 3246 in Progress, November, 1996. 3248 [STD-2] Reynolds, J. and J. Postel, Assigned Numbers, STD 2, October, 3249 1994. 3251 [Schneier] Bruce Schneier, Applied Cryptography - Protocols, Algorithms, 3252 and Source Code in C (Second Edition), John Wiley & Sons, Inc., 3253 1996. 3255 [Spar96a] Harney, H. and C. Muckenhirn, Group Key Management Protocol 3256 (GKMP) Architecture, SPARTA, Inc., Internet-Draft: 3257 draft-harney-gkmp-arch-01.txt, Work in Progress, August, 1996. 3259 [Spar96b] Harney, H. and C. Muckenhirn, Group Key Management Protocol 3260 (GKMP) Specification, SPARTA, Inc., Internet-Draft: 3261 draft-harney-gkmp-spec-01.txt, Work in Progress, August, 1996. 3263 Addresses of Authors 3265 The authors can be contacted at: 3267 Douglas Maughan 3268 Phone: 301-688-0847 3269 E-mail:wdmaugh@tycho.ncsc.mil 3271 Mark Schneider 3272 Phone: 301-688-0851 3273 E-mail:mss@tycho.ncsc.mil 3275 Jeff Turner 3276 Phone: 301-688-0849 3277 E-mail:sjt@epoch.ncsc.mil 3279 National Security Agency 3280 ATTN: R23 3281 9800 Savage Road 3282 Ft. Meade, MD. 20755-6000 3284 Mark Schertler 3285 Terisa Systems, Inc. 3286 4984 El Camino Real 3287 Los Altos, CA. 94022 3288 Phone: 415-919-1773 3289 E-mail:mjs@terisa.com