idnits 2.17.1 draft-ietf-ipsec-isakmp-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-ipsec-isakmp-09.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-ipsec-isakmp-09.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-ipsec-isakmp-09.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-09.txt,', but the file name used is 'draft-ietf-ipsec-isakmp-09' == 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 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 837 instances of too long lines in the document, the longest one being 24 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Certificate Authority (variable length) - Contains an encoding of an acceptable certificate authority for the type of certificate requested. As an example, for an X.509 certificate this field would contain the Distinguished Name encoding of the Issuer Name of an X.509 certificate authority acceptable to the sender of this payload. This would be included to assist the responder in determining how much of the certificate chain would need to be sent in response to this request. If there is no specific certificate authority requested, this field SHOULD not be included. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Vendor ID payload is not an announcement from the sender that it will send private payload types. A vendor sending the Vendor ID MUST not make any assumptions about private payloads that it may send unless a Vendor ID is received as well. Multiple Vendor ID payloads MAY be sent. An imple-mentation is NOT REQUIRED to understand any Vendor ID payloads. An imple-mentation is NOT REQUIRED to send any Vendor ID payload at all. If a pri-vate payload was sent without prior agreement to send it, a compliant im-plementation may reject a proposal with a notify message of type INVALID-PAYLOAD-TYPE. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If a Vendor ID payload is sent, it MUST be sent during the Phase 1 negoti-ation. Reception of a familiar Vendor ID payload in the Phase 1 negotia-tion allows an implementation to make use of Private USE payload numbers (128-255), described in section 3.1 for vendor specific extensions during Phase 2 negotiations. The definition of "familiar" is left to implementa-tions to determine. Some vendors may wish to implement another vendor's extension prior to standardization. However, this practice SHOULD not be widespread and vendors should work towards standardization instead. == 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 (March 10, 1998) is 9545 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 3572, but no explicit reference was found in the text == Unused Reference: 'Kent94' is defined on line 3600, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ANSI' -- Possible downref: Non-RFC (?) normative reference: ref. 'BC' -- Possible downref: Non-RFC (?) normative reference: ref. 'Berge' -- Possible downref: Non-RFC (?) normative reference: ref. 'CW87' == Outdated reference: A later version (-07) exists of draft-ietf-dnssec-secext2-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'DOW92' ** Downref: Normative reference to an Informational draft: draft-iab-secwks-report (ref. 'IAB') == Outdated reference: A later version (-07) exists of draft-ietf-ipsec-isakmp-oakley-06 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'IKE') == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-ipsec-doi-07 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-ipsec-doi (ref. 'IPDOI') == Outdated reference: A later version (-18) exists of draft-simpson-photuris-15 ** Downref: Normative reference to an Experimental draft: draft-simpson-photuris (ref. 'Karn') -- Possible downref: Non-RFC (?) normative reference: ref. 'Kent94' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-oakley is -01, but you're referring to -02. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-oakley (ref. 'Oakley') ** Downref: Normative reference to an Historic RFC: RFC 1422 ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Downref: Normative reference to an Experimental RFC: RFC 1949 ** Downref: Normative reference to an Experimental RFC: RFC 2093 ** Downref: Normative reference to an Experimental RFC: RFC 2094 -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' -- Possible downref: Non-RFC (?) normative reference: ref. 'STD-2' Summary: 21 errors (**), 1 flaw (~~), 13 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSEC Working Group Douglas Maughan, Mark Schertler 2 INTERNET-DRAFT Mark Schneider, Jeff Turner 3 draft-ietf-ipsec-isakmp-09.txt, .ps March 10, 1998 5 Internet Security Association and Key Management Protocol (ISAKMP) 7 Abstract 9 This memo describes a protocol utilizing security concepts 10 necessary for establishing Security Associations (SA) and crypto- 11 graphic keys in an Internet environment. A Security Association 12 protocol that negotiates, establishes, modifies and deletes 13 Security Associations and their attributes is required for an 14 evolving Internet, where there will be numerous security mecha- 15 nisms and several options for each security mechanism. The key 16 management protocol must be robust in order to handle public key 17 generation for the Internet community at large and private key 18 requirements for those private networks with that requirement. 19 The Internet Security Association and Key Management Protocol 20 (ISAKMP) defines the procedures for authenticating a communicat- 21 ing peer, creation and management of Security Associations, key 22 generation techniques, and threat mitigation (e.g. denial of 23 service and replay attacks). All of these are necessary to es- 24 tablish and maintain secure communications (via IP Security Ser- 25 vice or any other security protocol) in an Internet environment. 27 Status of this memo 29 This document is being submitted to the IETF Internet Protocol Security 30 (IPSEC) Working Group for consideration as a method for the establishment 31 and management of security associations and their appropriate security at- 32 tributes. Additionally, this document proposes a method for key manage- 33 ment to support IPSEC and IPv6. It is intended that a future version of 34 this draft be submitted to the IESG for publication as a Draft Standard 35 RFC. Comments are solicited and should be addressed to the authors and/or 36 the IPSEC working group mailing list at ipsec@tis.com. 38 This document is an Internet Draft. Internet Drafts are working documents 39 of the Internet Engineering Task Force (IETF), its Areas, and its Working 40 Groups. Note that other groups may also distribute working documents as 41 Internet Drafts. 43 Internet Drafts are draft documents valid for a maximum of six months. 44 Internet Drafts may be updated, replaced, or obsoleted by other documents 45 at any time. It is not appropriate to use Internet Drafts as reference 46 material or to cite them other than as ``working draft'' or ``work in 47 progress.'' 49 To learn the current status of any Internet-Draft, please check the ``1id- 50 abstracts.txt'' listing contained in the Internet- Drafts Shadow Di- 51 rectories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 52 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 54 Distribution of this document is unlimited. 56 Contents 58 1 Introduction 6 59 1.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . . 7 60 1.2 The Need for Negotiation . . . . . . . . . . . . . . . . . . . . 7 61 1.3 What can be Negotiated? . . . . . . . . . . . . . . . . . . . . . 7 62 1.4 Security Associations and Management . . . . . . . . . . . . . . 8 63 1.4.1Security Associations and Registration . . . . . . . . . . . . 8 64 1.4.2ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 9 65 1.5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 1.5.1Certificate Authorities . . . . . . . . . . . . . . . . . . . 10 67 1.5.2Entity Naming . . . . . . . . . . . . . . . . . . . . . . . . 10 68 1.5.3ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 11 69 1.6 Public Key Cryptography . . . . . . . . . . . . . . . . . . . . . 12 70 1.6.1Key Exchange Properties . . . . . . . . . . . . . . . . . . . 12 71 1.6.2ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 13 72 1.7 ISAKMP Protection . . . . . . . . . . . . . . . . . . . . . . . . 13 73 1.7.1Anti-Clogging (Denial of Service) . . . . . . . . . . . . . . 13 74 1.7.2Connection Hijacking . . . . . . . . . . . . . . . . . . . . . 14 75 1.7.3Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . 14 76 1.8 Multicast Communications . . . . . . . . . . . . . . . . . . . . 14 78 2 Terminology and Concepts 15 79 2.1 ISAKMP Terminology . . . . . . . . . . . . . . . . . . . . . . . 15 80 2.2 ISAKMP Placement . . . . . . . . . . . . . . . . . . . . . . . . 17 81 2.3 Negotiation Phases . . . . . . . . . . . . . . . . . . . . . . . 18 82 2.4 Identifying Security Associations . . . . . . . . . . . . . . . . 19 83 2.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 2.5.1Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 21 85 2.5.2RESERVED Fields . . . . . . . . . . . . . . . . . . . . . . . 21 86 2.5.3Anti-Clogging Token (``Cookie'') Creation . . . . . . . . . . 21 87 3 ISAKMP Payloads 22 88 3.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 22 89 3.2 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . 26 90 3.3 Data Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 3.4 Security Association Payload . . . . . . . . . . . . . . . . . . 27 92 3.5 Proposal Payload . . . . . . . . . . . . . . . . . . . . . . . . 29 93 3.6 Transform Payload . . . . . . . . . . . . . . . . . . . . . . . . 30 94 3.7 Key Exchange Payload . . . . . . . . . . . . . . . . . . . . . . 31 95 3.8 Identification Payload . . . . . . . . . . . . . . . . . . . . . 32 96 3.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . 33 97 3.10Certificate Request Payload . . . . . . . . . . . . . . . . . . . 35 98 3.11Hash Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 36 99 3.12Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . 37 100 3.13Nonce Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 37 101 3.14Notification Payload . . . . . . . . . . . . . . . . . . . . . . 38 102 3.14.1Notify Message Types . . . . . . . . . . . . . . . . . . . . . 40 103 3.15Delete Payload . . . . . . . . . . . . . . . . . . . . . . . . . 41 104 3.16Vendor ID Payload . . . . . . . . . . . . . . . . . . . . . . . . 43 106 4 ISAKMP Exchanges 45 107 4.1 ISAKMP Exchange Types . . . . . . . . . . . . . . . . . . . . . . 45 108 4.1.1Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 109 4.2 Security Association Establishment . . . . . . . . . . . . . . . 46 110 4.2.1Security Association Establishment Examples . . . . . . . . . 48 111 4.3 Security Association Modification . . . . . . . . . . . . . . . . 50 112 4.4 Base Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . 51 113 4.5 Identity Protection Exchange . . . . . . . . . . . . . . . . . . 52 114 4.6 Authentication Only Exchange . . . . . . . . . . . . . . . . . . 53 115 4.7 Aggressive Exchange . . . . . . . . . . . . . . . . . . . . . . . 54 116 4.8 Informational Exchange . . . . . . . . . . . . . . . . . . . . . 56 118 5 ISAKMP Payload Processing 56 119 5.1 General Message Processing . . . . . . . . . . . . . . . . . . . 57 120 5.2 ISAKMP Header Processing . . . . . . . . . . . . . . . . . . . . 57 121 5.3 Generic Payload Header Processing . . . . . . . . . . . . . . . . 59 122 5.4 Security Association Payload Processing . . . . . . . . . . . . . 60 123 5.5 Proposal Payload Processing . . . . . . . . . . . . . . . . . . . 62 124 5.6 Transform Payload Processing . . . . . . . . . . . . . . . . . . 63 125 5.7 Key Exchange Payload Processing . . . . . . . . . . . . . . . . . 64 126 5.8 Identification Payload Processing . . . . . . . . . . . . . . . . 65 127 5.9 Certificate Payload Processing . . . . . . . . . . . . . . . . . 66 128 5.10Certificate Request Payload Processing . . . . . . . . . . . . . 67 129 5.11Hash Payload Processing . . . . . . . . . . . . . . . . . . . . . 68 130 5.12Signature Payload Processing . . . . . . . . . . . . . . . . . . 69 131 5.13Nonce Payload Processing . . . . . . . . . . . . . . . . . . . . 70 132 5.14Notification Payload Processing . . . . . . . . . . . . . . . . . 71 133 5.15Delete Payload Processing . . . . . . . . . . . . . . . . . . . . 73 134 6 Conclusions 75 136 A ISAKMP Security Association Attributes 76 137 A.1 Background/Rationale . . . . . . . . . . . . . . . . . . . . . . 76 138 A.2 Internet IP Security DOI Assigned Value . . . . . . . . . . . . . 76 139 A.3 Supported Security Protocols . . . . . . . . . . . . . . . . . . 76 140 A.4 ISAKMP Identification Type Values . . . . . . . . . . . . . . . . 77 141 A.4.1ID_IPV4_ADDR . . . . . . . . . . . . . . . . . . . . . . . . . 77 142 A.4.2ID_IPV4_ADDR_SUBNET . . . . . . . . . . . . . . . . . . . . . . 77 143 A.4.3ID_IPV6_ADDR . . . . . . . . . . . . . . . . . . . . . . . . . 77 144 A.4.4ID_IPV6_ADDR_SUBNET . . . . . . . . . . . . . . . . . . . . . . 77 145 B Defining a new Domain of Interpretation 78 146 B.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 147 B.2 Security Policies . . . . . . . . . . . . . . . . . . . . . . . . 79 148 B.3 Naming Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 79 149 B.4 Syntax for Specifying Security Services . . . . . . . . . . . . . 79 150 B.5 Payload Specification . . . . . . . . . . . . . . . . . . . . . . 79 151 B.6 Defining new Exchange Types . . . . . . . . . . . . . . . . . . . 79 153 List of Figures 155 1 ISAKMP Relationships . . . . . . . . . . . . . . . . . . . . . . 17 156 2 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 23 157 3 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . 26 158 4 Data Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 27 159 5 Security Association Payload . . . . . . . . . . . . . . . . . . 28 160 6 Proposal Payload Format . . . . . . . . . . . . . . . . . . . . . 29 161 7 Transform Payload Format . . . . . . . . . . . . . . . . . . . . 30 162 8 Key Exchange Payload Format . . . . . . . . . . . . . . . . . . . 32 163 9 Identification Payload Format . . . . . . . . . . . . . . . . . . 33 164 10 Certificate Payload Format . . . . . . . . . . . . . . . . . . . 34 165 11 Certificate Request Payload Format . . . . . . . . . . . . . . . 35 166 12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . . . . 36 167 13 Signature Payload Format . . . . . . . . . . . . . . . . . . . . 37 168 14 Nonce Payload Format . . . . . . . . . . . . . . . . . . . . . . 38 169 15 Notification Payload Format . . . . . . . . . . . . . . . . . . . 39 170 16 Delete Payload Format . . . . . . . . . . . . . . . . . . . . . . 42 171 17 Vendor ID Payload Format . . . . . . . . . . . . . . . . . . . . 44 173 1 Introduction 175 This document describes an Internet Security Association and Key Manage- 176 ment Protocol (ISAKMP). ISAKMP combines the security concepts of authen- 177 tication, key management, and security associations to establish the re- 178 quired security for government, commercial, and private communications on 179 the Internet. 181 The Internet Security Association and Key Management Protocol (ISAKMP) de- 182 fines procedures and packet formats to establish, negotiate, modify and 183 delete Security Associations (SA). SAs contain all the information re- 184 quired for execution of various network security services, such as the 185 IP layer services (such as header authentication and payload encapsula- 186 tion), transport or application layer services, or self-protection of ne- 187 gotiation traffic. ISAKMP defines payloads for exchanging key generation 188 and authentication data. These formats provide a consistent framework for 189 transferring key and authentication data which is independent of the key 190 generation technique, encryption algorithm and authentication mechanism. 192 ISAKMP is distinct from key exchange protocols in order to cleanly sepa- 193 rate the details of security association management (and key management) 194 from the details of key exchange. There may be many different key ex- 195 change protocols, each with different security properties. However, a 196 common framework is required for agreeing to the format of SA attributes, 197 and for negotiating, modifying, and deleting SAs. ISAKMP serves as this 198 common framework. 200 Separating the functionality into three parts adds complexity to the se- 201 curity analysis of a complete ISAKMP implementation. However, the sep- 202 aration is critical for interoperability between systems with differing 203 security requirements, and should also simplify the analysis of further 204 evolution of a ISAKMP server. 206 ISAKMP is intended to support the negotiation of SAs for security proto- 207 cols at all layers of the network stack (e.g., IPSEC, TLS, TLSP, OSPF, 208 etc.). By centralizing the management of the security associations, 209 ISAKMP reduces the amount of duplicated functionality within each security 210 protocol. ISAKMP can also reduce connection setup time, by negotiating a 211 whole stack of services at once. 213 The remainder of section 1 establishes the motivation for security nego- 214 tiation and outlines the major components of ISAKMP, i.e. Security As- 215 sociations and Management, Authentication, Public Key Cryptography, and 216 Miscellaneous items. Section 2 presents the terminology and concepts as- 217 sociated with ISAKMP. Section 3 describes the different ISAKMP payload 218 formats. Section 4 describes how the payloads of ISAKMP are composed to- 219 gether as exchange types to establish security associations and perform 220 key exchanges in an authenticated manner. Additionally, security as- 221 sociation modification, deletion, and error notification are discussed. 222 Section 5 describes the processing of each payload within the context of 223 ISAKMP exchanges, including error handling and associated actions. The 224 appendices provide the attribute values necessary for ISAKMP and require- 225 ment for defining a new Domain of Interpretation (DOI) within ISAKMP. 227 1.1 Requirements Terminology 229 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 230 NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, 231 are to be interpreted as described in [RFC-2119]. 233 1.2 The Need for Negotiation 235 ISAKMP extends the assertion in [DOW92] that authentication and key ex- 236 changes must be combined for better security to include security associa- 237 tion exchanges. The security services required for communications depends 238 on the individual network configurations and environments. Organizations 239 are setting up Virtual Private Networks (VPN), also known as Intranets, 240 that will require one set of security functions for communications within 241 the VPN and possibly many different security functions for communications 242 outside the VPN to support geographically separate organizational compo- 243 nents, customers, suppliers, sub-contractors (with their own VPNs), gov- 244 ernment, and others. Departments within large organizations may require a 245 number of security associations to separate and protect data (e.g. per- 246 sonnel data, company proprietary data, medical) on internal networks and 247 other security associations to communicate within the same department. 248 Nomadic users wanting to ``phone home'' represent another set of secu- 249 rity requirements. These requirements must be tempered with bandwidth 250 challenges. Smaller groups of people may meet their security require- 251 ments by setting up ``Webs of Trust''. ISAKMP exchanges provide these 252 assorted networking communities the ability to present peers with the se- 253 curity functionality that the user supports in an authenticated and pro- 254 tected manner for agreement upon a common set of security attributes, i.e. 255 an interoperable security association. 257 1.3 What can be Negotiated? 259 Security associations must support different encryption algorithms, au- 260 thentication mechanisms, and key establishment algorithms for other secu- 261 rity protocols, as well as IP Security. Security associations must also 262 support host-oriented certificates for lower layer protocols and user- 263 oriented certificates for higher level protocols. Algorithm and mecha- 264 nism independence is required in applications such as e-mail, remote lo- 265 gin, and file transfer, as well as in session oriented protocols, routing 266 protocols, and link layer protocols. ISAKMP provides a common security 267 association and key establishment protocol for this wide range of security 268 protocols, applications, security requirements, and network environments. 270 ISAKMP is not bound to any specific cryptographic algorithm, key gener- 271 ation technique, or security mechanism. This flexibility is beneficial 272 for a number of reasons. First, it supports the dynamic communications 273 environment described above. Second, the independence from specific secu- 274 rity mechanisms and algorithms provides a forward migration path to better 275 mechanisms and algorithms. When improved security mechanisms are devel- 276 oped or new attacks against current encryption algorithms, authentica- 277 tion mechanisms and key exchanges are discovered, ISAKMP will allow the 278 updating of the algorithms and mechanisms without having to develop a com- 279 pletely new KMP or patch the current one. 281 ISAKMP has basic requirements for its authentication and key exchange com- 282 ponents. These requirements guard against denial of service, replay / re- 283 flection, man-in-the-middle, and connection hijacking attacks. This is 284 important because these are the types of attacks that are targeted against 285 protocols. Complete Security Association (SA) support, which provides 286 mechanism and algorithm independence, and protection from protocol threats 287 are the strengths of ISAKMP. 289 1.4 Security Associations and Management 291 A Security Association (SA) is a relationship between two or more entities 292 that describes how the entities will utilize security services to communi- 293 cate securely. This relationship is represented by a set of information 294 that can be considered a contract between the entities. The information 295 must be agreed upon and shared between all the entities. Sometimes the 296 information alone is referred to as an SA, but this is just a physical in- 297 stantiation of the existing relationship. The existence of this relation- 298 ship, represented by the information, is what provides the agreed upon se- 299 curity information needed by entities to securely interoperate. All enti- 300 ties must adhere to the SA for secure communications to be possible. When 301 accessing SA attributes, entities use a pointer or identifier refered to 302 as the Security Parameter Index (SPI). [RFC-1825] provides details on IP 303 Security Associations (SA) and Security Parameter Index (SPI) definitions. 305 1.4.1 Security Associations and Registration 307 The SA attributes required and recommended for the IP Security (AH, ESP) 308 are defined in [RFC-1825]. The attributes specified for an IP Security SA 309 include, but are not limited to, authentication mechanism, cryptographic 310 algorithm, algorithm mode, key length, and Initialization Vector (IV). 311 Other protocols that provide algorithm and mechanism independent secu- 312 rity MUST define their requirements for SA attributes. The separation of 313 ISAKMP from a specific SA definition is important to ensure ISAKMP can es- 314 tablish SAs for all possible security protocols and applications. 316 NOTE: See [IPDOI] for a discussion of SA attributes that should be consid- 317 ered when defining a security protocol or application. 319 In order to facilitate easy identification of specific attributes (e.g. 320 a specific encryption algorithm) among different network entites the at- 321 tributes must be assigned identifiers and these identifiers must be reg- 322 istered by a central authority. The Internet Assigned Numbers Authority 323 (IANA) provides this function for the Internet. 325 1.4.2 ISAKMP Requirements 327 Security Association (SA) establishment MUST be part of the key manage- 328 ment protocol defined for IP based networks. The SA concept is required 329 to support security protocols in a diverse and dynamic networking envi- 330 ronment. Just as authentication and key exchange must be linked to pro- 331 vide assurance that the key is established with the authenticated party 332 [DOW92], SA establishment must be linked with the authentication and the 333 key exchange protocol. 335 ISAKMP provides the protocol exchanges to establish a security association 336 between negotiating entities followed by the establishment of a security 337 association by these negotiating entities in behalf of some protocol (e.g. 338 ESP/AH). First, an initial protocol exchange allows a basic set of secu- 339 rity attributes to be agreed upon. This basic set provides protection for 340 subsequent ISAKMP exchanges. It also indicates the authentication method 341 and key exchange that will be performed as part of the ISAKMP protocol. 342 If a basic set of security attributes is already in place between the ne- 343 gotiating server entities, the initial ISAKMP exchange may be skipped and 344 the establishment of a security association can be done directly. After 345 the basic set of security attributes has been agreed upon, initial iden- 346 tity authenticated, and required keys generated, the established SA can 347 be used for subsequent communications by the entity that invoked ISAKMP. 348 The basic set of SA attributes that MUST be implemented to provide ISAKMP 349 interoperability are defined in Appendix A. 351 1.5 Authentication 353 A very important step in establishing secure network communications is au- 354 thentication of the entity at the other end of the communication. Many 355 authentication mechanisms are available. Authentication mechanisms fall 356 into two catagories of strength - weak and strong. Sending cleartext keys 357 or other unprotected authenticating information over a network is weak, 358 due to the threat of reading them with a network sniffer. Additionally, 359 sending one-way hashed poorly-chosen keys with low entropy is also weak, 360 due to the threat of brute-force guessing attacks on the sniffed mes- 361 sages. While passwords can be used for establishing identity, they are 362 not considered in this context because of recent statements from the In- 363 ternet Architecture Board [IAB]. Digital signatures, such as the Digital 364 Signature Standard (DSS) and the Rivest-Shamir-Adleman (RSA) signature, 365 are public key based strong authentication mechanisms. When using pub- 366 lic key digital signatures each entity requires a public key and a pri- 367 vate key. Certificates are an essential part of a digital signature au- 368 thentication mechanism. Certificates bind a specific entity's identity 369 (be it host, network, user, or application) to its public keys and pos- 370 sibly other security-related information such as privileges, clearances, 371 and compartments. Authentication based on digital signatures requires a 372 trusted third party or certificate authority to create, sign and properly 373 distribute certificates. For more detailed information on digital signa- 374 tures, such as DSS and RSA, and certificates see [Schneier]. 376 1.5.1 Certificate Authorities 378 Certificates require an infrastructure for generation, verification, re- 379 vocation, management and distribution. The Internet Policy Registration 380 Authority (IPRA) [RFC-1422] has been established to direct this infras- 381 tructure for the IETF. The IPRA certifies Policy Certification Authori- 382 ties (PCA). PCAs control Certificate Authorities (CA) which certify users 383 and subordinate entities. Current certificate related work includes the 384 Domain Name System (DNS) Security Extensions [DNSSEC] which will provide 385 signed entity keys in the DNS. The Public Key Infrastucture (PKIX) working 386 group is specifying an Internet profile for X.509 certificates. There is 387 also work going on in industry to develop X.500 Directory Services which 388 would provide X.509 certificates to users. The U.S. Post Office is devel- 389 oping a (CA) hierarchy. The NIST Public Key Infrastructure Working Group 390 has also been doing work in this area. The DOD Multi Level Information 391 System Security Initiative (MISSI) program has begun deploying a certifi- 392 cate infrastructure for the U.S. Government. Alternatively, if no infras- 393 tructure exists, the PGP Web of Trust certificates can be used to provide 394 user authentication and privacy in a community of users who know and trust 395 each other. 397 1.5.2 Entity Naming 399 An entity's name is its identity and is bound to its public keys in cer- 400 tificates. The CA MUST define the naming semantics for the certificates 401 it issues. See the UNINETT PCA Policy Statements [Berge] for an example 402 of how a CA defines its naming policy. When the certificate is verified, 403 the name is verified and that name will have meaning within the realm of 404 that CA. An example is the DNS security extensions which make DNS servers 405 CAs for the zones and nodes they serve. Resource records are provided for 406 public keys and signatures on those keys. The names associated with the 407 keys are IP addresses and domain names which have meaning to entities ac- 408 cessing the DNS for this information. A Web of Trust is another example. 409 When webs of trust are set up, names are bound with the public keys. In 410 PGP the name is usually the entity's e-mail address which has meaning to 411 those, and only those, who understand e-mail. Another web of trust could 412 use an entirely different naming scheme. 414 1.5.3 ISAKMP Requirements 416 Strong authentication MUST be provided on ISAKMP exchanges. Without being 417 able to authenticate the entity at the other end, the Security Association 418 (SA) and session key established are suspect. Without authentication you 419 are unable to trust an entity's identification, which makes access control 420 questionable. While encryption (e.g. ESP) and integrity (e.g. AH) will 421 protect subsequent communications from passive eavesdroppers, without au- 422 thentication it is possible that the SA and key may have been established 423 with an adversary who performed an active man-in-the-middle attack and is 424 now stealing all your personal data. 426 A digital signature algorithm MUST be used within ISAKMP's authentication 427 component. However, ISAKMP does not mandate a specific signature algo- 428 rithm or certificate authority (CA). ISAKMP allows an entity initiating 429 communications to indicate which CAs it supports. After selection of a 430 CA, the protocol provides the messages required to support the actual au- 431 thentication exchange. The protocol provides a facility for identifica- 432 tion of different certificate authorities, certificate types (e.g. X.509, 433 PKCS #7, PGP, DNS SIG and KEY records), and the exchange of the certifi- 434 cates identified. 436 ISAKMP utilizes digital signatures, based on public key cryptography, for 437 authentication. There are other strong authentication systems available, 438 which could be specified as additional optional authentication mechanisms 439 for ISAKMP. Some of these authentication systems rely on a trusted third 440 party called a key distribution center (KDC) to distribute secret session 441 keys. An example is Kerberos, where the trusted third party is the Ker- 442 beros server, which holds secret keys for all clients and servers within 443 its network domain. A client's proof that it holds its secret key pro- 444 vides authenticaton to a server. 446 The ISAKMP specification does not specify the protocol for communicating 447 with the trusted third parties (TTP) or certificate directory services. 448 These protocols are defined by the TTP and directory service themselves 449 and are outside the scope of this specification. The use of these addi- 450 tional services and protocols will be described in a Key Exchange specific 451 document. 453 1.6 Public Key Cryptography 455 Public key cryptography is the most flexible, scalable, and efficient way 456 for users to obtain the shared secrets and session keys needed to support 457 the large number of ways Internet users will interoperate. Many key gen- 458 eration algorithms, that have different properties, are available to users 459 (see [DOW92], [ANSI], and [Oakley]). Properties of key exchange protocols 460 include the key establishment method, authentication, symmetry, perfect 461 forward secrecy, and back traffic protection. 463 NOTE: Cryptographic keys can protect information for a considerable length 464 of time. However, this is based on the assumption that keys used for pro- 465 tection of communications are destroyed after use and not kept for any 466 reason. 468 1.6.1 Key Exchange Properties 470 Key Establishment (Key Generation / Key Transport): The two common methods 471 of using public key cryptography for key establishment are key transport 472 and key generation. An example of key transport is the use of the RSA al- 473 gorithm to encrypt a randomly generated session key (for encrypting subse- 474 quent communications) with the recipient's public key. The encrypted ran- 475 dom key is then sent to the recipient, who decrypts it using his private 476 key. At this point both sides have the same session key, however it was 477 created based on input from only one side of the communications. The ben- 478 efit of the key transport method is that it has less computational over- 479 head than the following method. The Diffie-Hellman (D-H) algorithm il- 480 lustrates key generation using public key cryptography. The D-H algorithm 481 is begun by two users exchanging public information. Each user then math- 482 ematically combines the other's public information along with their own 483 secret information to compute a shared secret value. This secret value 484 can be used as a session key or as a key encryption key for encrypting a 485 randomly generated session key. This method generates a session key based 486 on public and secret information held by both users. The benefit of the 487 D-H algorithm is that the key used for encrypting messages is based on 488 information held by both users and the independence of keys from one key 489 exchange to another provides perfect forward secrecy. Detailed descrip- 490 tions of these algorithms can be found in [Schneier]. There are a number 491 of variations on these two key generation schemes and these variations do 492 not necessarily interoperate. 494 Key Exchange Authentication: Key exchanges may be authenticated during the 495 protocol or after protocol completion. Authentication of the key exchange 496 during the protocol is provided when each party provides proof it has the 497 secret session key before the end of the protocol. Proof can be provided 498 by encrypting known data in the secret session key during the protocol ex- 499 change. Authentication after the protocol must occur in subsequent commu- 500 nications. Authentication during the protocol is preferred so subsequent 501 communications are not initiated if the secret session key is not estab- 502 lished with the desired party. 504 Key Exchange Symmetry: A key exchange provides symmetry if either party 505 can initiate the exchange and exchanged messages can cross in transit 506 without affecting the key that is generated. This is desirable so that 507 computation of the keys does not require either party to know who initi- 508 ated the exchange. While key exchange symmetry is desirable, symmetry in 509 the entire key management protocol may provide a vulnerablity to reflec- 510 tion attacks. 512 Perfect Forward Secrecy: As described in [DOW92], an authenticated key ex- 513 change protocol provides perfect forward secrecy if disclosure of long- 514 term secret keying material does not compromise the secrecy of the ex- 515 changed keys from previous communications. The property of perfect for- 516 ward secrecy does not apply to key exchange without authentication. 518 1.6.2 ISAKMP Requirements 520 An authenticated key exchange MUST be supported by ISAKMP. Users SHOULD 521 choose additional key establishment algorithms based on their require- 522 ments. ISAKMP does not specify a specific key exchange. However, [IKE] 523 describes a proposal for using the Oakley key exchange [Oakley] in con- 524 junction with ISAKMP. Requirements that should be evaluated when choosing 525 a key establishment algorithm include establishment method (generation vs. 526 transport), perfect forward secrecy, computational overhead, key escrow, 527 and key strength. Based on user requirements, ISAKMP allows an entity 528 initiating communications to indicate which key exchanges it supports. 529 After selection of a key exchange, the protocol provides the messages re- 530 quired to support the actual key establishment. 532 1.7 ISAKMP Protection 534 1.7.1 Anti-Clogging (Denial of Service) 536 Of the numerous security services available, protection against denial 537 of service always seems to be one of the most difficult to address. A 538 ``cookie'' or anti-clogging token (ACT) is aimed at protecting the com- 539 puting resources from attack without spending excessive CPU resources to 540 determine its authenticity. An exchange prior to CPU-intensive public key 541 operations can thwart some denial of service attempts (e.g. simple flood- 542 ing with bogus IP source addresses). Absolute protection against denial 543 of service is impossible, but this anti-clogging token provides a tech- 544 nique for making it easier to handle. The use of an anti-clogging token 545 was introduced by Karn and Simpson in [Karn]. 547 It should be noted that in the exchanges shown in section 4, the anti- 548 clogging mechanism should be used in conjuction with a garbage-state col- 549 lection mechanism; an attacker can still flood a server using packets with 550 bogus IP addresses and cause state to be created. Such aggressive memory 551 management techniques SHOULD be employed by protocols using ISAKMP that 552 do not go through an initial, anti-clogging only phase, as was done in 553 [Karn]. 555 1.7.2 Connection Hijacking 557 ISAKMP prevents connection hijacking by linking the authentication, key 558 exchange and security association exchanges. This linking prevents an 559 attacker from allowing the authentication to complete and then jumping 560 in and impersonating one entity to the other during the key and security 561 association exchanges. 563 1.7.3 Man-in-the-Middle Attacks 565 Man-in-the-Middle attacks include interception, insertion, deletion, and 566 modification of messages, reflecting messages back at the sender, re- 567 playing old messages and redirecting messages. ISAKMP features prevent 568 these types of attacks from being successful. The linking of the ISAKMP 569 exchanges prevents the insertion of messages in the protocol exchange. 570 The ISAKMP protocol state machine is defined so deleted messages will not 571 cause a partial SA to be created, the state machine will clear all state 572 and return to idle. The state machine also prevents reflection of a mes- 573 sage from causing harm. The requirement for a new cookie with time vari- 574 ant material for each new SA establishment prevents attacks that involve 575 replaying old messages. The ISAKMP strong authentication requirement pre- 576 vents an SA from being established with anyone other than the intended 577 party. Messages may be redirected to a different destination or modified 578 but this will be detected and an SA will not be established. The ISAKMP 579 specification defines where abnormal processing has occurred and recom- 580 mends notifying the appropriate party of this abnormality. 582 1.8 Multicast Communications 584 It is expected that multicast communications will require the same secu- 585 rity services as unicast communications and may introduce the need for 586 additional security services. The issues of distributing SPIs for mul- 587 ticast traffic are presented in [RFC-1825]. Multicast security issues are 588 also discussed in [RFC-1949] and [BC]. A future extension to ISAKMP will 589 support multicast key distribution. For an introduction to the issues re- 590 lated to multicast security, consult the Internet Drafts, [RFC-2094] and 591 [RFC-2093], describing Sparta's research in this area. 593 2 Terminology and Concepts 595 2.1 ISAKMP Terminology 597 Security Protocol: A Security Protocol consists of an entity at a single 598 point in the network stack, performing a security service for network com- 599 munication. For example, IPSEC ESP and IPSEC AH are two different secu- 600 rity protocols. TLS is another example. Security Protocols may perform 601 more than one service, for example providing integrity and confidentiality 602 in one module. 604 Protection Suite: A protection suite is a list of the security services 605 that must be applied by various security protocols. For example, a pro- 606 tection suite may consist of DES encryption in IP ESP, and keyed MD5 in IP 607 AH. All of the protections in a suite must be treated as a single unit. 608 This is necessary because security services in different security pro- 609 tocols can have subtle interactions, and the effects of a suite must be 610 analyzed and verified as a whole. 612 Security Association (SA): A Security Association is a security-protocol- 613 specific set of parameters that completely defines the services and mech- 614 anisms necessary to protect traffic at that security protocol location. 615 These parameters can include algorithm identifiers, modes, cryptographic 616 keys, etc. The SA is referred to by its associated security protocol (for 617 example, ``ISAKMP SA'', ``ESP SA'', ``TLS SA''). 619 ISAKMP SA: An SA used by the ISAKMP servers to protect their own traffic. 620 Sections 2.3 and 2.4 provide more details about ISAKMP SAs. 622 Security Parameter Index (SPI): An identifier for a Security Assocation, 623 relative to some security protocol. Each security protocol has its own 624 ``SPI-space''. A (security protocol, SPI) pair may uniquely identify an 625 SA. The uniqueness of the SPI is implementation dependent, but could be 626 based per system, per protocol, or other options. Depending on the DOI, 627 additional information (e.g. host address) may be necessary to identify 628 an SA. The DOI will also determine which SPIs (i.e. initiator's or re- 629 sponder's) are sent during communication. 631 Domain of Interpretation: A Domain of Interpretation (DOI) defines payload 632 formats, exchange types, and conventions for naming security-relevant in- 633 formation such as security policies or cryptographic algorithms and modes. 634 A Domain of Interpretation (DOI) identifier is used to interpret the pay- 635 loads of ISAKMP payloads. A system SHOULD support multiple Domains of In- 636 terpretation simultaneously. The concept of a DOI is based on previous 637 work by the TSIG CIPSO Working Group, but extends beyond security label 638 interpretation to include naming and interpretation of security services. 639 A DOI defines: 641 o A ``situation'': the set of information that will be used to 642 determine the required security services. 644 o The set of security policies that must, and may, be supported. 646 o A syntax for the specification of proposed security services. 648 o A scheme for naming security-relevant information, including 649 encryption algorithms, key exchange algorithms, security policy 650 attributes, and certificate authorities. 652 o The specific formats of the various payload contents. 654 o Additional exchange types, if required. 656 The rules for the IETF IP Security DOI are presented in [IPDOI]. Speci- 657 fications of the rules for customized DOIs will be presented in separate 658 documents. 660 Situation: A situation contains all of the security-relevant information 661 that a system considers necessary to decide the security services required 662 to protect the session being negotiated. The situation may include ad- 663 dresses, security classifications, modes of operation (normal vs. emer- 664 gency), etc. 666 Proposal: A proposal is a list, in decreasing order of preference, of the 667 protection suites that a system considers acceptable to protect traffic 668 under a given situation. 670 Payload: ISAKMP defines several types of payloads, which are used to 671 transfer information such as security association data, or key exchange 672 data, in DOI-defined formats. A payload consists of a generic payload 673 header and a string of octects that is opaque to ISAKMP. ISAKMP uses DOI- 674 specific functionality to synthesize and interpret these payloads. Mul- 675 tiple payloads can be sent in a single ISAKMP message. See section 3 for 676 more details on the payload types, and [IPDOI] for the formats of the IETF 677 IP Security DOI payloads. 679 Exchange Type: An exchange type is a specification of the number of mes- 680 sages in an ISAKMP exchange, and the payload types that are contained in 681 each of those messages. Each exchange type is designed to provide a par- 682 ticular set of security services, such as anonymity of the participants, 683 perfect forward secrecy of the keying material, authentication of the par- 684 ticipants, etc. Section 4.1 defines the default set of ISAKMP exchange 685 types. Other exchange types can be added to support additional key ex- 686 changes, if required. 688 2.2 ISAKMP Placement 690 Figure 1 is a high level view of the placement of ISAKMP within a system 691 context in a network architecture. An important part of negotiating secu- 692 rity services is to consider the entire ``stack'' of individual SAs as a 693 unit. This is referred to as a ``protection suite''. 695 +------------+ +--------+ +--------------+ 696 ! DOI ! ! ! ! Application ! 697 ! Definition ! <----> ! ISAKMP ! ! Process ! 698 +------------+ --> ! ! !--------------! 699 +--------------+ ! +--------+ ! Appl Protocol! 700 ! Key Exchange ! ! ^ ^ +--------------+ 701 ! Definition !<-- ! ! ^ 702 +--------------+ ! ! ! 703 ! ! ! 704 !----------------! ! ! 705 v ! ! 706 +-------+ v v 707 ! API ! +---------------------------------------------+ 708 +-------+ ! Socket Layer ! 709 ! !---------------------------------------------! 710 v ! Transport Protocol (TCP / UDP) ! 711 +----------+ !---------------------------------------------! 712 ! Security ! <----> ! IP ! 713 ! Protocol ! !---------------------------------------------! 714 +----------+ ! Link Layer Protocol ! 715 +---------------------------------------------+ 717 Figure 1: ISAKMP Relationships 719 2.3 Negotiation Phases 721 ISAKMP offers two ``phases'' of negotiation. In the first phase, two en- 722 tities (e.g. ISAKMP servers) agree on how to protect further negotiation 723 traffic between themselves, establishing an ISAKMP SA. This ISAKMP SA is 724 then used to protect the negotiations for the Protocol SA being requested. 725 Two entities (e.g. ISAKMP servers) can negotiate (and have active) multi- 726 ple ISAKMP SAs. 728 The second phase of negotiation is used to establish security associations 729 for other security protocols. This second phase can be used to estab- 730 lish many security associations. The security associations established 731 by ISAKMP during this phase can be used by a security protocol to protect 732 many message/data exchanges. 734 While the two-phased approach has a higher start-up cost for most simple 735 scenarios, there are several reasons that it is beneficial for most cases. 737 First, entities (e.g. ISAKMP servers) can amortize the cost of the first 738 phase across several second phase negotiations. This allows multiple SAs 739 to be established between peers over time without having to start over for 740 each communication. 742 Second, security services negotiated during the first phase provide secu- 743 rity properties for the second phase. For example, after the first phase 744 of negotiation, the encryption provided by the ISAKMP SA can provide iden- 745 tity protection, potentially allowing the use of simpler second-phase ex- 746 changes. On the other hand, if the channel established during the first 747 phase is not adequate to protect identities, then the second phase must 748 negotiate adequate security mechanisms. 750 Third, having an ISAKMP SA in place considerably reduces the cost of 751 ISAKMP management activity - without the ``trusted path'' that an ISAKMP 752 SA gives you, the entities (e.g. ISAKMP servers) would have to go through 753 a complete re-authentication for each error notification or deletion of an 754 SA. 756 Negotiation during each phase is accomplished using ISAKMP-defined ex- 757 changes (see section 4) or exchanges defined for a key exchange within a 758 DOI. 760 Note that security services may be applied differently in each negotiation 761 phase. For example, different parties are being authenticated during each 762 of the phases of negotiation. During the first phase, the parties being 763 authenticated may be the ISAKMP servers/hosts, while during the second 764 phase, users or application level programs are being authenticated. 766 2.4 Identifying Security Associations 768 While bootstrapping secure channels between systems, ISAKMP cannot assume 769 the existence of security services, and must provide some protections for 770 itself. Therefore, ISAKMP considers an ISAKMP Security Association to 771 be different than other types, and manages ISAKMP SAs itself, in their 772 own name space. ISAKMP uses the two cookie fields in the ISAKMP header 773 to identify ISAKMP SAs. The Message ID in the ISAKMP Header and the SPI 774 field in the Proposal payload are used during SA establishment to identify 775 the SA for other security protocols. The interpretation of these four 776 fields is dependent on the operation taking place. 778 The following table shows the presence or absence of several fields during 779 SA establishment. The following fields are necessary for various opera- 780 tions associated with SA establishment: cookies in the ISAKMP header, the 781 ISAKMP Header Message ID field, and the SPI field in the Proposal payload. 782 An 'X' in the column means the value MUST be present. An 'NA' in the col- 783 umn means a value in the column is Not Applicable to the operation. 785 __#_____________Operation____________I-Cookie__R-Cookie__Message_ID__SPI_ 786 (1) Start ISAKMP SA negotiation X 0 0 0 787 (2) Respond ISAKMP SA negotiation X X 0 0 788 (3) Init other SA negotiation X X X X 789 (4) Respond other SA negotiation X X X X 790 (5) Other (KE, ID, etc.) X X X/0 NA 791 (6) Security Protocol (ESP, AH) NA NA NA X 793 In the first line (1) of the table, the initiator includes the Initiator 794 Cookie field in the ISAKMP Header, using the procedures outlined in sec- 795 tions 2.5.3 and 3.1. 797 In the second line (2) of the table, the responder includes the Initia- 798 tor and Responder Cookie fields in the ISAKMP Header, using the procedures 799 outlined in sections 2.5.3 and 3.1. Additional messages may be exchanged 800 between ISAKMP peers, depending on the ISAKMP exchange type used during 801 the phase 1 negotiation. Once the phase 1 exchange is completed, the Ini- 802 tiator and Responder cookies are included in the ISAKMP Header of all sub- 803 sequent communications between the ISAKMP peers. 805 During phase 1 negotiations, the initiator and responder cookies deter- 806 mine the ISAKMP SA. Therefore, the SPI field in the Proposal payload is 807 redundant and MAY be set to 0 or it MAY contain the transmitting entity's 808 cookie. 810 In the third line (3) of the table, the initiator associates a Message ID 811 with the Protocols contained in the SA Proposal. This Message ID and the 812 initiator's SPI(s) to be associated with each protocol in the Proposal are 813 sent to the responder. The SPI(s) will be used by the security protocols 814 once the phase 2 negotiation is completed. 816 In the fourth line (4) of the table, the responder includes the same Mes- 817 sage ID and the responder's SPI(s) to be associated with each protocol in 818 the accepted Proposal. This information is returned to the initiator. 820 In the fifth line (5) of the table, the initiator and responder use the 821 Message ID field in the ISAKMP Header to keep track of the in-progress 822 protocol negotiation. This is only applicable for a phase 2 exchange and 823 the value SHOULD be 0 for a phase 1 exchange because the combined cook- 824 ies identify the ISAKMP SA. The SPI field in the Proposal payload is not 825 applicable because the Proposal payload is only used during the SA negoti- 826 ation message exchange (steps 3 and 4). 828 In the sixth line (6) of the table, the phase 2 negotiation is complete. 829 The security protocols use the SPI(s) to determine which security services 830 and mechanisms to apply to the communication between them. The SPI value 831 shown in the sixth line (6) is not the SPI field in the Proposal payload, 832 but the SPI field contained within the security protocol header. 834 During the SA establishment, a SPI MUST be generated. ISAKMP is designed 835 to handle variable sized SPIs. This is accomplished by using the SPI Size 836 field within the Proposal payload during SA establishment. Handling of 837 SPIs will be outlined by the DOI specification (e.g. [IPDOI]). 839 When a security association (SA) is initially established, one side as- 840 sumes the role of initiator and the other the role of responder. Once the 841 SA is established, both the original initiator and responder can initiate 842 a phase 2 negotiation with the peer entity. Thus, ISAKMP SAs are bidirec- 843 tional in nature. 845 Additionally, ISAKMP allows both initiator and responder to have some con- 846 trol during the negotiation process. While ISAKMP is designed to allow an 847 SA negotiation that includes multiple proposals, the initiator can main- 848 tain some control by only making one proposal in accordance with the ini- 849 tiator's local security policy. Once the initiator sends a proposal con- 850 taining more than one proposal (which are sent in decreasing preference 851 order), the initiator relinquishes control to the responder. Once the re- 852 sponder is controlling the SA establishment, the responder can make its 853 policy take precedence over the initiator within the context of the multi- 854 ple options offered by the initiator. This is accomplished by selecting 855 the proposal best suited for the responder's local security policy and re- 856 turning this selection to the initiator. 858 2.5 Miscellaneous 860 2.5.1 Transport Protocol 862 ISAKMP can be implemented over any transport protocol or over IP itself. 863 Implementations MUST include send and receive capability for ISAKMP us- 864 ing the User Datagram Protocol (UDP) on port 500. UDP Port 500 has been 865 assigned to ISAKMP by the Internet Assigned Numbered Authority (IANA). Im- 866 plementations MAY additionally support ISAKMP over other transport proto- 867 cols or over IP itself. 869 2.5.2 RESERVED Fields 871 The existence of RESERVED fields within ISAKMP payloads are used strictly 872 to preserve byte alignment. All RESERVED fields in the ISAKMP protocol 873 MUST be set to zero (0) when a packet is issued. The receiver SHOULD 874 check the RESERVED fields for a zero (0) value and discard the packet if 875 other values are found. 877 2.5.3 Anti-Clogging Token (``Cookie'') Creation 879 The details of cookie generation are implementation dependent, but MUST 880 satisfy these basic requirements (originally stated by Phil Karn in 881 [Karn]): 883 1. The cookie must depend on the specific parties. This prevents 884 an attacker from obtaining a cookie using a real IP address and 885 UDP port, and then using it to swamp the victim with Diffie- 886 Hellman requests from randomly chosen IP addresses or ports. 888 2. It must not be possible for anyone other than the issuing 889 entity to generate cookies that will be accepted by that 890 entity. This implies that the issuing entity must use local 891 secret information in the generation and subsequent 892 verification of a cookie. It must not be possible to deduce 893 this secret information from any particular cookie. 895 3. The cookie generation function must be fast to thwart attacks 896 intended to sabotage CPU resources. 898 Karn's suggested method for creating the cookie is to perform a fast hash 899 (e.g. MD5) over the IP Source and Destination Address, the UDP Source and 900 Destination Ports and a locally generated secret random value. ISAKMP re- 901 quires that the cookie be unique for each SA establishment to help pre- 902 vent replay attacks, therefore, the date and time MUST be added to the in- 903 formation hashed. The generated cookies are placed in the ISAKMP Header 904 (described in section 3.1) Initiator and Responder cookie fields. These 905 fields are 8 octets in length, thus, requiring a generated cookie to be 8 906 octets. Notify and Delete messages (see sections 3.14, 3.15, and 4.8) are 907 uni-directional transmissions and are done under the protection of an ex- 908 isting ISAKMP SA, thus, not requiring the generation of a new cookie. One 909 exception to this is the transmission of a Notify message during a Phase 910 1 exchange, prior to completing the establishment of an SA. Sections 3.14 911 and 4.8 provide additional details. 913 3 ISAKMP Payloads 915 ISAKMP payloads provide modular building blocks for constructing ISAKMP 916 messages. The presence and ordering of payloads in ISAKMP is defined by 917 and dependent upon the Exchange Type Field located in the ISAKMP Header 918 (see Figure 2). The ISAKMP payload types are discussed in sections 3.4 919 through 3.15. The descriptions of the ISAKMP payloads, messages, and ex- 920 changes (see Section 4) are shown using network octet ordering. Addition- 921 ally, all ISAKMP messages MUST be aligned at 4-octet multiples. 923 3.1 ISAKMP Header Format 925 An ISAKMP message has a fixed header format, shown in Figure 2, followed 926 by a variable number of payloads. A fixed header simplifies parsing, pro- 927 viding the benefit of protocol parsing software that is less complex and 928 easier to implement. The fixed header contains the information required 929 by the protocol to maintain state, process payloads and possibly prevent 930 denial of service or replay attacks. 932 The ISAKMP Header fields are defined as follows: 934 o Initiator Cookie (8 octets) - Cookie of entity that initiated SA 935 establishment, SA notification, or SA deletion. 937 o Responder Cookie (8 octets) - Cookie of entity that is responding to 938 1 2 3 939 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 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 ! Initiator ! 942 ! Cookie ! 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 ! Responder ! 945 ! Cookie ! 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 ! Message ID ! 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 ! Length ! 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 Figure 2: ISAKMP Header Format 956 an SA establishment request, SA notification, or SA deletion. 958 o Next Payload (1 octet) - Indicates the type of the first payload in 959 the message. The format for each payload is defined in sections 3.4 960 through 3.16. The processing for the payloads is defined in section 961 5. 963 _____Next_Payload_Type_______Value____ 964 NONE 0 965 Security Association (SA) 1 966 Proposal (P) 2 967 Transform (T) 3 968 Key Exchange (KE) 4 969 Identification (ID) 5 970 Certificate (CERT) 6 971 Certificate Request (CR) 7 972 Hash (HASH) 8 973 Signature (SIG) 9 974 Nonce (NONCE) 10 975 Notification (N) 11 976 Delete (D) 12 977 Vendor ID (VID) 13 978 RESERVED 14 - 127 979 Private USE 128 - 255 981 o Major Version (4 bits) - indicates the major version of the ISAKMP 982 protocol in use. Implementations based on this version of the ISAKMP 983 Internet-Draft MUST set the Major Version to 1. Implementations 984 based on previous versions of ISAKMP Internet-Drafts MUST set the 985 Major Version to 0. Implementations SHOULD never accept packets with 986 a major version number larger than its own. 988 o Minor Version (4 bits) - indicates the minor version of the ISAKMP 989 protocol in use. Implementations based on this version of the ISAKMP 990 Internet-Draft MUST set the Minor Version to 0. Implementations 991 based on previous versions of ISAKMP Internet-Drafts MUST set the 992 Minor Version to 1. Implementations SHOULD never accept packets with 993 a minor version number larger than its own, given the major version 994 numbers are identical. 996 o Exchange Type (1 octet) - indicates the type of exchange being used. 997 This dictates the message and payload orderings in the ISAKMP 998 exchanges. 1000 ____Exchange_Type______Value___ 1001 NONE 0 1002 Base 1 1003 Identity Protection 2 1004 Authentication Only 3 1005 Aggressive 4 1006 Informational 5 1007 ISAKMP Future Use 6 - 31 1008 DOI Specific Use 32 - 255 1010 o Flags (1 octet) - indicates specific options that are set for the 1011 ISAKMP exchange. The flags listed below are specified in the Flags 1012 field beginning with the least significant bit, i.e the Encryption 1013 bit is bit 0 of the Flags field, the Commit bit is bit 1 of the Flags 1014 field, and the Authentication Only bit is bit 2 of the Flags field. 1015 The remaining bits of the Flags field MUST be set to 0 prior to 1016 transmission. 1018 -- E(ncryption Bit) (1 bit) - If set (1), all payloads following the 1019 header are encrypted using the encryption algorithm identified in 1020 the ISAKMP SA. The ISAKMP SA Identifier is the combination of the 1021 initiator and responder cookie. It is RECOMMENDED that 1022 encryption of communications be done as soon as possible between 1023 the peers. For all ISAKMP exchanges described in section 4.1, 1024 the encryption SHOULD begin after both parties have exchanged Key 1025 Exchange payloads. If the E(ncryption Bit) is not set (0), the 1026 payloads are not encrypted. 1028 -- C(ommit Bit) (1 bit) - This bit is used to signal key exchange 1029 synchronization. It is used to ensure that encrypted material is 1030 not received prior to completion of the SA establishment. The 1031 Commit Bit can be set (at anytime) by either party participating 1032 in the SA establishment, and can be used during both phases of an 1033 ISAKMP SA establishment. However, the value MUST be reset after 1034 the Phase 1 negotiation. If set(1), the entity which did not set 1035 the Commit Bit MUST wait for an Informational Exchange containing 1036 a Notify payload (with the CONNECTED Notify Message) from the en- 1037 tity which set the Commit Bit. This indicates that the SA estab- 1038 lishment was successful and either entity can now proceed with en- 1039 crypted traffic communication. In addition to synchronizing key ex- 1040 change, the Commit Bit can be used to protect against loss of trans- 1041 missions over unreliable networks and guard against the need for mul- 1042 tiple retransmissions. 1044 NOTE: It is always possible that the final message of an exchange 1045 can be lost. In this case, the entity expecting to receive the 1046 final message of an exchange would receive the Phase 2 SA negoti- 1047 ation message following a Phase 1 exchange or encrypted traffic 1048 following a Phase 2 exchange. Handling of this situation is not 1049 standardized, but we propose the following possibilities. If the 1050 entity awaiting the Informational Exchange can verify the re- 1051 ceived message (i.e. Phase 2 SA negotiation message or encrypted 1052 traffic), then they MAY consider the SA was established and 1053 continue processing. The other option is to retransmit the last 1054 ISAKMP message to force the other entity to retransmit the final mes- 1055 sage. This suggests that implementations may consider retaining the 1056 last message (locally) until they are sure the SA is established. 1058 -- A(uthentication Only Bit) (1 bit) - This bit is intended for use 1059 with the Informational Exchange with a Notify payload and will 1060 allow the transmission of information with integrity checking, 1061 but no encryption (e.g. "emergency mode"). Section 4.8 states 1062 that a Phase 2 Informational Exchange MUST be sent under the 1063 protection of an ISAKMP SA. This is the only exception to that 1064 policy. If the Authentication Only bit is set (1), only 1065 authentication security services will be applied to the entire 1066 Notify payload of the Informational Exchange and the payload will 1067 not be encrypted. 1069 o Message ID (4 octets) - Unique Message Identifier used to identify 1070 protocol state during Phase 2 negotiations. This value is randomly 1071 generated by the initiator of the Phase 2 negotiation. In the event 1072 of simultaneous SA establishments (i.e. collisions), the value of 1073 this field will likely be different because they are independently 1074 generated and, thus, two security associations will progress toward 1075 establishment. However, it is unlikely there will be absolute 1076 simultaneous establishments. During Phase 1 negotiations, the value 1077 MUST be set to 0. 1079 o Length (4 octets) - Length of total message (header + payloads) in 1080 octets. Encryption can expand the size of an ISAKMP message. 1082 3.2 Generic Payload Header 1084 Each ISAKMP payload defined in sections 3.4 through 3.16 begins with a 1085 generic header, shown in Figure 3, which provides a payload "chaining" 1086 capability and clearly defines the boundaries of a payload. 1088 1 2 3 1089 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 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 ! Next Payload ! RESERVED ! Payload Length ! 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 Figure 3: Generic Payload Header 1096 The Generic Payload Header fields are defined as follows: 1098 o Next Payload (1 octet) - Identifier for the payload type of the next 1099 payload in the message. If the current payload is the last in the 1100 message, then this field will be 0. This field provides the 1101 "chaining" capability. 1103 o RESERVED (1 octet) - Unused, set to 0. 1105 o Payload Length (2 octets) - Length in octets of the current payload, 1106 including the generic payload header. 1108 3.3 Data Attributes 1110 There are several instances within ISAKMP where it is necessary to repre- 1111 sent Data Attributes. An example of this is the Security Association (SA) 1112 Attributes contained in the Transform payload (described in section 3.6). 1113 These Data Attributes are not an ISAKMP payload, but are contained within 1114 ISAKMP payloads. The format of the Data Attributes provides the flexibil- 1115 ity for representation of many different types of information. There can 1116 be multiple Data Attributes within a payload. The length of the Data At- 1117 tributes will either be 4 octets or defined by the Attribute Length field. 1118 This is done using the Attribute Format bit described below. Specific in- 1119 formation about the attributes for each domain will be described in a DOI 1120 document, e.g. IPSEC DOI [IPDOI]. 1122 The Data Attributes fields are defined as follows: 1124 o Attribute Type (2 octets) - Unique identifier for each type of 1125 attribute. These attributes are defined as part of the DOI-specific 1126 1 2 3 1127 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 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 !A! Attribute Type ! AF=0 Attribute Length ! 1130 !F! ! AF=1 Attribute Value ! 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 . AF=0 Attribute Value . 1133 . AF=1 Not Transmitted . 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 Figure 4: Data Attributes 1138 information. 1140 The most significant bit, or Attribute Format (AF), indicates whether 1141 the data attributes follow the Type/Length/Value (TLV) format or a 1142 shortened Type/Value (TV) format. If the AF bit is a zero (0), then 1143 the Data Attributes are of the Type/Length/Value (TLV) form. If the 1144 AF bit is a one (1), then the Data Attributes are of the Type/Value 1145 form. 1147 o Attribute Length (2 octets) - Length in octets of the Attribute 1148 Value. When the AF bit is a one (1), the Attribute Value is only 2 1149 octets and the Attribute Length field is not present. 1151 o Attribute Value (variable length) - Value of the attribute associated 1152 with the DOI-specific Attribute Type. If the AF bit is a zero (0), 1153 this field has a variable length defined by the Attribute Length 1154 field. If the AF bit is a one (1), the Attribute Value has a length 1155 of 2 octets. 1157 3.4 Security Association Payload 1159 The Security Association Payload is used to negotiate security attributes 1160 and to indicate the Domain of Interpretation (DOI) and Situation under 1161 which the negotiation is taking place. Figure 5 shows the format of the 1162 Security Association payload. 1164 The Security Association Payload fields are defined as follows: 1166 o Next Payload (1 octet) - Identifier for the payload type of the next 1167 payload in the message. If the current payload is the last in the 1168 message, then this field will be 0. This field MUST NOT contain the 1169 values for the Proposal or Transform payloads as they are considered 1170 part of the security association negotiation. For example, this 1171 1 2 3 1172 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 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 ! Next Payload ! RESERVED ! Payload Length ! 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 ! Domain of Interpretation (DOI) ! 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 ! ! 1179 ~ Situation ~ 1180 ! ! 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 Figure 5: Security Association Payload 1185 field would contain the value "10" (Nonce payload) in the first 1186 message of a Base Exchange (see Section 4.4) and the value "0" in the 1187 first message of an Identity Protect Exchange (see Section 4.5). 1189 o RESERVED (1 octet) - Unused, set to 0. 1191 o Payload Length (2 octets) - Length in octets of the entire Security 1192 Association payload, including the SA payload, all Proposal payloads, 1193 and all Transform payloads associated with the proposed Security 1194 Association. 1196 o Domain of Interpretation (4 octets) - Identifies the DOI (as 1197 described in Section 2.1) under which this negotiation is taking 1198 place. The DOI is a 32-bit unsigned integer. A DOI value of 0 1199 during a Phase 1 exchange specifies a Generic ISAKMP SA which can be 1200 used for any protocol during the Phase 2 exchange. The necessary SA 1201 Attributes are defined in A.4. A DOI value of 1 is assigned to the 1202 IPsec DOI [IPDOI]. All other DOI values are reserved to IANA for 1203 future use. IANA will not normally assign a DOI value without 1204 referencing some public specification, such as an Internet RFC. Other 1205 DOI's can be defined using the description in appendix B. This field 1206 MUST be present within the Security Association payload. 1208 o Situation (variable length) - A DOI-specific field that identifies 1209 the situation under which this negotiation is taking place. The 1210 Situation is used to make policy decisions regarding the security 1211 attributes being negotiated. Specifics for the IETF IP Security DOI 1212 Situation are detailed in [IPDOI]. This field MUST be present within 1213 the Security Association payload. 1215 The payload type for the Security Association Payload is one (1). 1217 3.5 Proposal Payload 1219 The Proposal Payload contains information used during Security Associa- 1220 tion negotiation. The proposal consists of security mechanisms, or trans- 1221 forms, to be used to secure the communications channel. Figure 6 shows 1222 the format of the Proposal Payload. A description of its use can be found 1223 in section 4.2. 1225 1 2 3 1226 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 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 ! Next Payload ! RESERVED ! Payload Length ! 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms! 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 ! SPI (variable) ! 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 Figure 6: Proposal Payload Format 1237 The Proposal Payload fields are defined as follows: 1239 o Next Payload (1 octet) - Identifier for the payload type of the next 1240 payload in the message. This field MUST only contain the value "2" 1241 or "0". If there are additional Proposal payloads in the message, 1242 then this field will be 2. If the current Proposal payload is the 1243 last within the security association proposal, then this field will 1244 be 0. 1246 o RESERVED (1 octet) - Unused, set to 0. 1248 o Payload Length (2 octets) - Length in octets of the entire Proposal 1249 payload, including generic payload header, the Proposal payload, and 1250 all Transform payloads associated with this proposal. In the event 1251 there are multiple proposals with the same proposal number (see 1252 section 4.2), the Payload Length field only applies to the current 1253 Proposal payload and not to all Proposal payloads. 1255 o Proposal # (1 octet) - Identifies the Proposal number for the current 1256 payload. A description of the use of this field is found in section 1257 4.2. 1259 o Protocol-Id (1 octet) - Specifies the protocol identifier for the 1260 current negotiation. Examples might include IPSEC ESP, IPSEC AH, 1261 OSPF, TLS, etc. 1263 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 1264 Protocol-Id. In the case of ISAKMP, the Initiator and Responder 1265 cookie pair from the ISAKMP Header is the ISAKMP SPI, therefore, the 1266 SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). If 1267 the SPI Size is non-zero, the content of the SPI field MUST be 1268 ignored. If the SPI Size is not a multiple of 4 octets it will have 1269 some impact on the SPI field and the alignment of all payloads in the 1270 message. The Domain of Interpretation (DOI) will dictate the SPI 1271 Size for other protocols. 1273 o # of Transforms (1 octet) - Specifies the number of transforms for 1274 the Proposal. Each of these is contained in a Transform payload. 1276 o SPI (variable) - The sending entity's SPI. In the event the SPI Size 1277 is not a multiple of 4 octets, there is no padding applied to the 1278 payload, however, it can be applied at the end of the message. 1280 The payload type for the Proposal Payload is two (2). 1282 3.6 Transform Payload 1284 The Transform Payload contains information used during Security Associa- 1285 tion negotiation. The Transform payload consists of a specific security 1286 mechanism, or transforms, to be used to secure the communications chan- 1287 nel. The Transform payload also contains the security association at- 1288 tributes associated with the specific transform. These SA attributes are 1289 DOI-specific. Figure 7 shows the format of the Transform Payload. A de- 1290 scription of its use can be found in section 4.2. 1292 1 2 3 1293 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 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 ! Next Payload ! RESERVED ! Payload Length ! 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 ! Transform # ! Transform-Id ! RESERVED2 ! 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 ! ! 1300 ~ SA Attributes ~ 1301 ! ! 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 Figure 7: Transform Payload Format 1306 The Transform Payload fields are defined as follows: 1308 o Next Payload (1 octet) - Identifier for the payload type of the next 1309 payload in the message. This field MUST only contain the value "3" 1310 or "0". If there are additional Transform payloads in the proposal, 1311 then this field will be 3. If the current Transform payload is the 1312 last within the proposal, then this field will be 0. 1314 o RESERVED (1 octet) - Unused, set to 0. 1316 o Payload Length (2 octets) - Length in octets of the current payload, 1317 including the generic payload header, Transform values, and all SA 1318 Attributes. 1320 o Transform # (1 octet) - Identifies the Transform number for the 1321 current payload. If there is more than one transform proposed for a 1322 specific protocol within the Proposal payload, then each Transform 1323 payload has a unique Transform number. A description of the use of 1324 this field is found in section 4.2. 1326 o Transform-Id (1 octet) - Specifies the Transform identifier for the 1327 protocol within the current proposal. These transforms are defined 1328 by the DOI and are dependent on the protocol being negotiated. 1330 o RESERVED2 (2 octets) - Unused, set to 0. 1332 o SA Attributes (variable length) - This field contains the security 1333 association attributes as defined for the transform given in the 1334 Transform-Id field. The SA Attributes SHOULD be represented using 1335 the Data Attributes format described in section 3.3. If the SA 1336 Attributes are not aligned on 4-byte boundaries, then subsequent 1337 payloads will not be aligned and any padding will be added at the end 1338 of the message to make the message 4-octet aligned. 1340 The payload type for the Transform Payload is three (3). 1342 3.7 Key Exchange Payload 1344 The Key Exchange Payload supports a variety of key exchange techniques. 1345 Example key exchanges are Oakley [Oakley], Diffie-Hellman, the enhanced 1346 Diffie-Hellman key exchange described in X9.42 [ANSI], and the RSA-based 1347 key exchange used by PGP. Figure 8 shows the format of the Key Exchange 1348 payload. 1350 The Key Exchange Payload fields are defined as follows: 1352 o Next Payload (1 octet) - Identifier for the payload type of the next 1353 payload in the message. If the current payload is the last in the 1354 message, then this field will be 0. 1356 1 2 3 1357 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 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 ! Next Payload ! RESERVED ! Payload Length ! 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 ! ! 1362 ~ Key Exchange Data ~ 1363 ! ! 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 Figure 8: Key Exchange Payload Format 1368 o RESERVED (1 octet) - Unused, set to 0. 1370 o Payload Length (2 octets) - Length in octets of the current payload, 1371 including the generic payload header. 1373 o Key Exchange Data (variable length) - Data required to generate a 1374 session key. The interpretation of this data is specified by the DOI 1375 and the associated Key Exchange algorithm. This field may also 1376 contain pre-placed key indicators. 1378 The payload type for the Key Exchange Payload is four (4). 1380 3.8 Identification Payload 1382 The Identification Payload contains DOI-specific data used to exchange 1383 identification information. This information is used for determining the 1384 identities of communicating peers and may be used for determining authen- 1385 ticity of information. Figure 9 shows the format of the Identification 1386 Payload. 1388 The Identification Payload fields are defined as follows: 1390 o Next Payload (1 octet) - Identifier for the payload type of the next 1391 payload in the message. If the current payload is the last in the 1392 message, then this field will be 0. 1394 o RESERVED (1 octet) - Unused, set to 0. 1396 o Payload Length (2 octets) - Length in octets of the current payload, 1397 including the generic payload header. 1399 o ID Type (1 octet) - Specifies the type of Identification being used. 1401 1 2 3 1402 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 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 ! Next Payload ! RESERVED ! Payload Length ! 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 ! ID Type ! DOI Specific ID Data ! 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 ! ! 1409 ~ Identification Data ~ 1410 ! ! 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 Figure 9: Identification Payload Format 1415 This field is DOI-dependent. 1417 o DOI Specific ID Data (3 octets) - Contains DOI specific 1418 Identification data. If unused, then this field MUST be set to 0. 1420 o Identification Data (variable length) - Contains identity 1421 information. The values for this field are DOI-specific and the 1422 format is specified by the ID Type field. Specific details for the 1423 IETF IP Security DOI Identification Data are detailed in [IPDOI]. 1425 The payload type for the Identification Payload is five (5). 1427 3.9 Certificate Payload 1429 The Certificate Payload provides a means to transport certificates or 1430 other certificate-related information via ISAKMP and can appear in any 1431 ISAKMP message. Certificate payloads SHOULD be included in an exchange 1432 whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is 1433 not available to distribute certificates. The Certificate payload MUST be 1434 accepted at any point during an exchange. Figure 10 shows the format of 1435 the Certificate Payload. 1437 NOTE: Certificate types and formats are not generally bound to a DOI - it 1438 is expected that there will only be a few certificate types, and that most 1439 DOIs will accept all of these types. 1441 The Certificate Payload fields are defined as follows: 1443 o Next Payload (1 octet) - Identifier for the payload type of the next 1444 payload in the message. If the current payload is the last in the 1445 1 2 3 1446 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 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 ! Next Payload ! RESERVED ! Payload Length ! 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 ! Cert Encoding ! ! 1451 +-+-+-+-+-+-+-+-+ ! 1452 ~ Certificate Data ~ 1453 ! ! 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 Figure 10: Certificate Payload Format 1458 message, then this field will be 0. 1460 o RESERVED (1 octet) - Unused, set to 0. 1462 o Payload Length (2 octets) - Length in octets of the current payload, 1463 including the generic payload header. 1465 o Certificate Encoding (1 octet) - This field indicates the type of 1466 certificate or certificate-related information contained in the 1467 Certificate Data field. 1469 _________Certificate_Type____________Value____ 1470 NONE 0 1471 PKCS #7 wrapped X.509 certificate 1 1472 PGP Certificate 2 1473 DNS Signed Key 3 1474 X.509 Certificate - Signature 4 1475 X.509 Certificate - Key Exchange 5 1476 Kerberos Tokens 6 1477 Certificate Revocation List (CRL) 7 1478 Authority Revocation List (ARL) 8 1479 SPKI Certificate 9 1480 X.509 Certificate - Attribute 10 1481 RESERVED 11 - 255 1483 o Certificate Data (variable length) - Actual encoding of certificate 1484 data. The type of certificate is indicated by the Certificate 1485 Encoding field. 1487 The payload type for the Certificate Payload is six (6). 1489 3.10 Certificate Request Payload 1491 The Certificate Request Payload provides a means to request certificates 1492 via ISAKMP and can appear in any message. Certificate Request payloads 1493 SHOULD be included in an exchange whenever an appropriate directory ser- 1494 vice (e.g. Secure DNS [DNSSEC]) is not available to distribute certifi- 1495 cates. The Certificate Request payload MUST be accepted at any point dur- 1496 ing the exchange. The responder to the Certificate Request payload MUST 1497 send its certificate, if certificates are supported, based on the values 1498 contained in the payload. If multiple certificates are required, then 1499 multiple Certificate Request payloads SHOULD be transmitted. Figure 11 1500 shows the format of the Certificate Request Payload. 1502 1 2 3 1503 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 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 ! Next Payload ! RESERVED ! Payload Length ! 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 ! Cert. Type ! ! 1508 +-+-+-+-+-+-+-+-+ ! 1509 ~ Certificate Authority ~ 1510 ! ! 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 Figure 11: Certificate Request Payload Format 1515 The Certificate Payload fields are defined as follows: 1517 o Next Payload (1 octet) - Identifier for the payload type of the next 1518 payload in the message. If the current payload is the last in the 1519 message, then this field will be 0. 1521 o RESERVED (1 octet) - Unused, set to 0. 1523 o Payload Length (2 octets) - Length in octets of the current payload, 1524 including the generic payload header. 1526 o Certificate Type (1 octet) - Contains an encoding of the type of 1527 certificate requested. Acceptable values are listed in section 3.9. 1529 o Certificate Authority (variable length) - Contains an encoding of an 1530 acceptable certificate authority for the type of certificate 1531 requested. As an example, for an X.509 certificate this field would 1532 contain the Distinguished Name encoding of the Issuer Name of an 1533 X.509 certificate authority acceptable to the sender of this payload. 1534 This would be included to assist the responder in determining how 1535 much of the certificate chain would need to be sent in response to 1536 this request. If there is no specific certificate authority 1537 requested, this field SHOULD not be included. 1539 The payload type for the Certificate Request Payload is seven (7). 1541 3.11 Hash Payload 1543 The Hash Payload contains data generated by the hash function (selected 1544 during the SA establishment exchange), over some part of the message 1545 and/or ISAKMP state. This payload may be used to verify the integrity of 1546 the data in an ISAKMP message or for authentication of the negotiating en- 1547 tities. Figure 12 shows the format of the Hash Payload. 1549 1 2 3 1550 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 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 ! Next Payload ! RESERVED ! Payload Length ! 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 ! ! 1555 ~ Hash Data ~ 1556 ! ! 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 Figure 12: Hash Payload Format 1561 The Hash Payload fields are defined as follows: 1563 o Next Payload (1 octet) - Identifier for the payload type of the next 1564 payload in the message. If the current payload is the last in the 1565 message, then this field will be 0. 1567 o RESERVED (1 octet) - Unused, set to 0. 1569 o Payload Length (2 octets) - Length in octets of the current payload, 1570 including the generic payload header. 1572 o Hash Data (variable length) - Data that results from applying the 1573 hash routine to the ISAKMP message and/or state. 1575 The payload type for the Hash Payload is eight (8). 1577 3.12 Signature Payload 1579 The Signature Payload contains data generated by the digital signature 1580 function (selected during the SA establishment exchange), over some part 1581 of the message and/or ISAKMP state. This payload is used to verify the 1582 integrity of the data in the ISAKMP message, and may be of use for non- 1583 repudiation services. Figure 13 shows the format of the Signature Pay- 1584 load. 1586 1 2 3 1587 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 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 ! Next Payload ! RESERVED ! Payload Length ! 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 ! ! 1592 ~ Signature Data ~ 1593 ! ! 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 Figure 13: Signature Payload Format 1598 The Signature Payload fields are defined as follows: 1600 o Next Payload (1 octet) - Identifier for the payload type of the next 1601 payload in the message. If the current payload is the last in the 1602 message, then this field will be 0. 1604 o RESERVED (1 octet) - Unused, set to 0. 1606 o Payload Length (2 octets) - Length in octets of the current payload, 1607 including the generic payload header. 1609 o Signature Data (variable length) - Data that results from applying 1610 the digital signature function to the ISAKMP message and/or state. 1612 The payload type for the Signature Payload is nine (9). 1614 3.13 Nonce Payload 1616 The Nonce Payload contains random data used to guarantee liveness dur- 1617 ing an exchange and protect against replay attacks. Figure 14 shows the 1618 format of the Nonce Payload. If nonces are used by a particular key ex- 1619 change, the use of the Nonce payload will be dictated by the key exchange. 1620 The nonces may be transmitted as part of the key exchange data, or as a 1621 separate payload. However, this is defined by the key exchange, not by 1622 ISAKMP. 1624 1 2 3 1625 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 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 ! Next Payload ! RESERVED ! Payload Length ! 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 ! ! 1630 ~ Nonce Data ~ 1631 ! ! 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 Figure 14: Nonce Payload Format 1636 The Nonce Payload fields are defined as follows: 1638 o Next Payload (1 octet) - Identifier for the payload type of the next 1639 payload in the message. If the current payload is the last in the 1640 message, then this field will be 0. 1642 o RESERVED (1 octet) - Unused, set to 0. 1644 o Payload Length (2 octets) - Length in octets of the current payload, 1645 including the generic payload header. 1647 o Nonce Data (variable length) - Contains the random data generated by 1648 the transmitting entity. 1650 The payload type for the Nonce Payload is ten (10). 1652 3.14 Notification Payload 1654 The Notification Payload can contain both ISAKMP and DOI-specific data and 1655 is used to transmit informational data, such as error conditions, to an 1656 ISAKMP peer. It is possible to send multiple Notification payloads in 1657 a single ISAKMP message. Figure 15 shows the format of the Notification 1658 Payload. 1660 Notification which occurs during, or is concerned with, a Phase 1 nego- 1661 tiation is identified by the Initiator and Responder cookie pair in the 1662 ISAKMP Header. The Protocol Identifier, in this case, is ISAKMP and the 1663 SPI value is 0 because the cookie pair in the ISAKMP Header identifies the 1664 ISAKMP SA. If the notification takes place prior to the completed exchange 1665 of keying information, then the notification will be unprotected. 1667 Notification which occurs during, or is concerned with, a Phase 2 nego- 1668 tiation is identified by the Initiator and Responder cookie pair in the 1669 ISAKMP Header and the Message ID and SPI associated with the current nego- 1670 tiation. One example for this type of notification is to indicate why a 1671 proposal was rejected. 1673 1 2 3 1674 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 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 ! Next Payload ! RESERVED ! Payload Length ! 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 ! Domain of Interpretation (DOI) ! 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 ! Protocol-ID ! SPI Size ! Notify Message Type ! 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 ! ! 1683 ~ Security Parameter Index (SPI) ~ 1684 ! ! 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 ! ! 1687 ~ Notification Data ~ 1688 ! ! 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 Figure 15: Notification Payload Format 1693 The Notification Payload fields are defined as follows: 1695 o Next Payload (1 octet) - Identifier for the payload type of the next 1696 payload in the message. If the current payload is the last in the 1697 message, then this field will be 0. 1699 o RESERVED (1 octet) - Unused, set to 0. 1701 o Payload Length (2 octets) - Length in octets of the current payload, 1702 including the generic payload header. 1704 o Domain of Interpretation (4 octets) - Identifies the DOI (as 1705 described in Section 2.1) under which this notification is taking 1706 place. For ISAKMP this value is zero (0) and for the IPSEC DOI it is 1707 one (1). Other DOI's can be defined using the description in 1708 appendix B. 1710 o Protocol-Id (1 octet) - Specifies the protocol identifier for the 1711 current notification. Examples might include ISAKMP, IPSEC ESP, 1712 IPSEC AH, OSPF, TLS, etc. 1714 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 1715 Protocol-Id. In the case of ISAKMP, the Initiator and Responder 1716 cookie pair from the ISAKMP Header is the ISAKMP SPI, therefore, the 1717 SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). If 1718 the SPI Size is non-zero, the content of the SPI field MUST be 1719 ignored. The Domain of Interpretation (DOI) will dictate the SPI 1720 Size for other protocols. 1722 o Notify Message Type (2 octets) - Specifies the type of notification 1723 message (see section 3.14.1). Additional text, if specified by the 1724 DOI, is placed in the Notification Data field. 1726 o SPI (variable length) - Security Parameter Index. The receiving 1727 entity's SPI. The use of the SPI field is described in section 2.4. 1728 The length of this field is determined by the SPI Size field and is 1729 not necessarily aligned to a 4 octet boundary. 1731 o Notification Data (variable length) - Informational or error data 1732 transmitted in addition to the Notify Message Type. Values for this 1733 field are DOI-specific. 1735 The payload type for the Notification Payload is eleven (11). 1737 3.14.1 Notify Message Types 1739 Notification information can be error messages specifying why an SA could 1740 not be established. It can also be status data that a process managing 1741 an SA database wishes to communicate with a peer process. For example, 1742 a secure front end or security gateway may use the Notify message to syn- 1743 chronize SA communication. The table below lists the Nofitication mes- 1744 sages and their corresponding values. Values in the Private Use range are 1745 expected to be DOI-specific values. 1747 NOTIFY MESSAGES - ERROR TYPES 1749 __________Errors______________Value_____ 1750 INVALID-PAYLOAD-TYPE 1 1751 DOI-NOT-SUPPORTED 2 1752 SITUATION-NOT-SUPPORTED 3 1753 INVALID-COOKIE 4 1754 INVALID-MAJOR-VERSION 5 1755 INVALID-MINOR-VERSION 6 1756 INVALID-EXCHANGE-TYPE 7 1757 INVALID-FLAGS 8 1758 INVALID-MESSAGE-ID 9 1759 INVALID-PROTOCOL-ID 10 1760 INVALID-SPI 11 1761 INVALID-TRANSFORM-ID 12 1762 ATTRIBUTES-NOT-SUPPORTED 13 1763 NO-PROPOSAL-CHOSEN 14 1764 BAD-PROPOSAL-SYNTAX 15 1765 PAYLOAD-MALFORMED 16 1766 INVALID-KEY-INFORMATION 17 1767 INVALID-ID-INFORMATION 18 1768 INVALID-CERT-ENCODING 19 1769 INVALID-CERTIFICATE 20 1770 CERT-TYPE-UNSUPPORTED 21 1771 INVALID-CERT-AUTHORITY 22 1772 INVALID-HASH-INFORMATION 23 1773 AUTHENTICATION-FAILED 24 1774 INVALID-SIGNATURE 25 1775 ADDRESS-NOTIFICATION 26 1776 NOTIFY-SA-LIFETIME 27 1777 CERTIFICATE-UNAVAILABLE 28 1778 RESERVED (Future Use) 29 - 8191 1779 Private Use 8192 - 16383 1781 NOTIFY MESSAGES - STATUS TYPES 1782 _________Status_____________Value______ 1783 CONNECTED 16384 1784 RESERVED (Future Use) 16385 - 24575 1785 DOI-specific codes 24576 - 32767 1786 Private Use 32768 - 40959 1787 RESERVED (Future Use) 40960 - 65535 1789 3.15 Delete Payload 1791 The Delete Payload contains a protocol-specific security association iden- 1792 tifier that the sender has removed from its security association database 1793 and is, therefore, no longer valid. Figure 16 shows the format of the 1794 Delete Payload. It is possible to send multiple SPIs in a Delete payload, 1795 however, each SPI MUST be for the same protocol. Mixing of Protocol Iden- 1796 tifiers MUST NOT be performed with the Delete payload. 1798 Deletion which is concerned with an ISAKMP SA will contain a Protocol-Id 1799 of ISAKMP and the SPIs are the initiator and responder cookies from the 1800 ISAKMP Header. Deletion which is concerned with a Protocol SA, such as 1801 ESP or AH, will contain the Protocol-Id of that protocol (e.g. ESP, AH) 1802 and the SPI is the sending entity's SPI(s). 1804 NOTE: The Delete Payload is not a request for the responder to delete an 1805 SA, but an advisory from the initiator to the responder. If the responder 1806 chooses to ignore the message, the next communication from the responder 1807 to the initiator, using that security association, will fail. A responder 1808 is not expected to acknowledge receipt of a Delete payload. 1810 1 2 3 1811 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 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 ! Next Payload ! RESERVED ! Payload Length ! 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 ! Domain of Interpretation (DOI) ! 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 ! Protocol-Id ! SPI Size ! # of SPIs ! 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 ! ! 1820 ~ Security Parameter Index(es) (SPI) ~ 1821 ! ! 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 Figure 16: Delete Payload Format 1826 The Delete Payload fields are defined as follows: 1828 o Next Payload (1 octet) - Identifier for the payload type of the next 1829 payload in the message. If the current payload is the last in the 1830 message, then this field will be 0. 1832 o RESERVED (1 octet) - Unused, set to 0. 1834 o Payload Length (2 octets) - Length in octets of the current payload, 1835 including the generic payload header. 1837 o Domain of Interpretation (4 octets) - Identifies the DOI (as 1838 described in Section 2.1) under which this deletion is taking place. 1839 For ISAKMP this value is zero (0) and for the IPSEC DOI it is one 1840 (1). Other DOI's can be defined using the description in appendix B. 1842 o Protocol-Id (1 octet) - ISAKMP can establish security associations 1843 for various protocols, including ISAKMP and IPSEC. This field identi- 1844 fies which security association database to apply the delete request. 1846 o SPI Size (1 octet) - Length in octets of the SPI as defined by the 1847 Protocol-Id. In the case of ISAKMP, the Initiator and Responder 1848 cookie pair is the ISAKMP SPI. In this case, the SPI Size would be 16 1849 octets for each SPI being deleted. 1851 o # of SPIs (2 octets) - The number of SPIs contained in the Delete 1852 payload. The size of each SPI is defined by the SPI Size field. 1854 o Security Parameter Index(es) (variable length) - Identifies the 1855 specific security association(s) to delete. Values for this field 1856 are DOI and protocol specific. The length of this field is 1857 determined by the SPI Size and # of SPIs fields. 1859 The payload type for the Delete Payload is twelve (12). 1861 3.16 Vendor ID Payload 1863 The Vendor ID Payload contains a vendor defined constant. The constant 1864 is used by vendors to identify and recognize remote instances of their 1865 implementations. This mechanism allows a vendor to experiment with new 1866 features while maintaining backwards compatibility. This is not a general 1867 extension facility of ISAKMP. Figure 17 shows the format of the Vendor ID 1868 Payload. 1870 The Vendor ID payload is not an announcement from the sender that it will 1871 send private payload types. A vendor sending the Vendor ID MUST not make 1872 any assumptions about private payloads that it may send unless a Vendor ID 1873 is received as well. Multiple Vendor ID payloads MAY be sent. An imple- 1874 mentation is NOT REQUIRED to understand any Vendor ID payloads. An imple- 1875 mentation is NOT REQUIRED to send any Vendor ID payload at all. If a pri- 1876 vate payload was sent without prior agreement to send it, a compliant im- 1877 plementation may reject a proposal with a notify message of type INVALID- 1878 PAYLOAD-TYPE. 1880 If a Vendor ID payload is sent, it MUST be sent during the Phase 1 negoti- 1881 ation. Reception of a familiar Vendor ID payload in the Phase 1 negotia- 1882 tion allows an implementation to make use of Private USE payload numbers 1883 (128-255), described in section 3.1 for vendor specific extensions during 1884 Phase 2 negotiations. The definition of "familiar" is left to implementa- 1885 tions to determine. Some vendors may wish to implement another vendor's 1886 extension prior to standardization. However, this practice SHOULD not be 1887 widespread and vendors should work towards standardization instead. 1889 The vendor defined constant MUST be unique. The choice of hash and text 1890 to hash is left to the vendor to decide. As an example, vendors could 1891 generate their vendor id by taking a plain (non-keyed) hash of a string 1892 containing the product name, and the version of the product. A hash is 1893 used instead of a vendor registry to avoid local cryptographic policy 1894 problems with having a list of "approved" products, to keep away from 1895 maintaining a list of vendors, and to allow classified products to avoid 1896 having to appear on any list. For instance: 1898 "Example Company IPsec. Version 97.1" 1900 (not including the quotes) has MD5 hash: 1901 48544f9b1fe662af98b9b39e50c01a5a, when using MD5file. Vendors may include 1902 all of the hash, or just a portion of it, as the payload length will bound 1903 the data. There are no security implications of this hash, so its choice 1904 is arbitrary. 1906 1 2 3 1907 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 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 ! Next Payload ! RESERVED ! Payload Length ! 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1911 ! ! 1912 ~ Vendor ID (VID) ~ 1913 ! ! 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 Figure 17: Vendor ID Payload Format 1918 The Vendor ID Payload fields are defined as follows: 1920 o Next Payload (1 octet) - Identifier for the payload type of the next 1921 payload in the message. If the current payload is the last in the 1922 message, then this field will be 0. 1924 o RESERVED (1 octet) - Unused, set to 0. 1926 o Payload Length (2 octets) - Length in octets of the current payload, 1927 including the generic payload header. 1929 o Vendor ID (variable length) - Hash of the vendor string plus version 1930 (as described above). 1932 The payload type for the Vendor ID Payload is thirteen (13). 1934 4 ISAKMP Exchanges 1936 ISAKMP supplies the basic syntax of a message exchange. The basic build- 1937 ing blocks for ISAKMP messages are the payload types described in section 1938 3. This section describes the procedures for SA establishment and SA mod- 1939 ification, followed by a default set of exchanges that MAY be used for 1940 initial interoperability. Other exchanges will be defined depending on 1941 the DOI and key exchange. [IPDOI] and [IKE] are examples of how this is 1942 achieved. Appendix B explains the procedures for accomplishing these ad- 1943 ditions. 1945 4.1 ISAKMP Exchange Types 1947 ISAKMP allows the creation of exchanges for the establishment of Security 1948 Associations and keying material. There are currently five default Ex- 1949 change Types defined for ISAKMP. Sections 4.4 through 4.8 describe these 1950 exchanges. Exchanges define the content and ordering of ISAKMP messages 1951 during communications between peers. Most exchanges will include all the 1952 basic payload types - SA, KE, ID, SIG - and may include others. The pri- 1953 mary difference between exchange types is the ordering of the messages and 1954 the payload ordering within each message. While the ordering of payloads 1955 within messages is not mandated, for processing efficiency it is RECOM- 1956 MENDED that the Security Association payload be the first payload within 1957 an exchange. Processing of each payload within an exchange is described 1958 in section 5. 1960 Sections 4.4 through 4.8 provide a default set of ISAKMP exchanges. These 1961 exchanges provide different security protection for the exchange itself 1962 and information exchanged. The diagrams in each of the following sections 1963 show the message ordering for each exchange type as well as the payloads 1964 included in each message, and provide basic notes describing what has hap- 1965 pened after each message exchange. None of the examples include any "op- 1966 tional payloads", like certificate and certificate request. Additionally, 1967 none of the examples include an initial exchange of ISAKMP Headers (con- 1968 taining initiator and responder cookies) which would provide protection 1969 against clogging (see section 2.5.3). 1971 The defined exchanges are not meant to satisfy all DOI and key exchange 1972 protocol requirements. If the defined exchanges meet the DOI require- 1973 ments, then they can be used as outlined. If the defined exchanges do 1974 not meet the security requirements defined by the DOI, then the DOI MUST 1975 specify new exchange type(s) and the valid sequences of payloads that make 1976 up a successful exchange, and how to build and interpret those payloads. 1977 All ISAKMP implementations MUST implement the Informational Exchange and 1978 SHOULD implement the other four exchanges. However, this is dependent on 1979 the definition of the DOI and associated key exchange protocols. 1981 As discussed above, these exchange types can be used in either phase of 1982 negotiation. However, they may provide different security properties 1983 in each of the phases. With each of these exchanges, the combination of 1984 cookies and SPI fields identifies whether this exchange is being used in 1985 the first or second phase of a negotiation. 1987 4.1.1 Notation 1989 The following notation is used to describe the ISAKMP exchange types, 1990 shown in the next section, with the message formats and associated pay- 1991 loads: 1993 HDR is an ISAKMP header whose exchange type defines the payload orderings 1994 SA is an SA negotiation payload with one or more Proposal and 1995 Transform payloads. An initiator MAY provide multiple proposals 1996 for negotiation; a responder MUST reply with only one. 1997 KE is the key exchange payload. 1998 IDx is the identity payload for "x". x can be: "ii" or "ir" 1999 for the ISAKMP initiator and responder, respectively, or x can 2000 be: "ui", "ur" (when the ISAKMP daemon is a proxy negotiator), 2001 for the user initiator and responder, respectively. 2002 HASH is the hash payload. 2003 SIG is the signature payload. The data to sign is exchange-specific. 2004 AUTH is a generic authentication mechanism, such as HASH or SIG. 2005 NONCE is the nonce payload. 2006 '*' signifies payload encryption after the ISAKMP header. This 2007 encryption MUST begin immediately after the ISAKMP header and 2008 all payloads following the ISAKMP header MUST be encrypted. 2010 => signifies "initiator to responder" communication 2011 <= signifies "responder to initiator" communication 2013 4.2 Security Association Establishment 2015 The Security Association, Proposal, and Transform payloads are used to 2016 build ISAKMP messages for the negotiation and establishment of SAs. An 2017 SA establishment message consists of a single SA payload followed by at 2018 least one, and possibly many, Proposal payloads and at least one, and pos- 2019 sibly many, Transform payloads associated with each Proposal payload. Be- 2020 cause these payloads are considered together, the SA payload will point to 2021 any following payloads and not to the Proposal payload included with the 2022 SA payload. The SA Payload contains the DOI and Situation for the pro- 2023 posed SA. Each Proposal payload contains a Security Parameter Index (SPI) 2024 and ensures that the SPI is associated with the Protocol-Id in accordance 2025 with the Internet Security Architecture [RFC-1825]. Proposal payloads may 2026 or may not have the same SPI, as this is implementation dependent. Each 2027 Transform Payload contains the specific security mechanisms to be used for 2028 the designated protocol. It is expected that the Proposal and Transform 2029 payloads will be used only during SA establishment negotiation. The cre- 2030 ation of payloads for security association negotiation and establishment 2031 described here in this section are applicable for all ISAKMP exchanges de- 2032 scribed later in sections 4.4 through 4.8. The examples shown in 4.2.1 2033 contain only the SA, Proposal, and Transform payloads and do not contain 2034 other payloads that might exist for a given ISAKMP exchange. 2036 The Proposal payload provides the initiating entity with the capability 2037 to present to the responding entity the security protocols and associated 2038 security mechanisms for use with the security association being negoti- 2039 ated. If the SA establishment negotiation is for a combined protection 2040 suite consisting of multiple protocols, then there MUST be multiple Pro- 2041 posal payloads each with the same Proposal number. These proposals MUST 2042 be considered as a unit and MUST NOT be separated by a proposal with a 2043 different proposal number. The use of the same Proposal number in mul- 2044 tiple Proposal payloads provides a logical AND operation, i.e. Protocol 2045 1 AND Protocol 2. The first example below shows an ESP AND AH protection 2046 suite. If the SA establishment negotiation is for different protection 2047 suites, then there MUST be multiple Proposal payloads each with a monoton- 2048 ically increasing Proposal number. The different proposals MUST be pre- 2049 sented in the initiator's preference order. The use of different Proposal 2050 numbers in multiple Proposal payloads provides a logical OR operation, 2051 i.e. Proposal 1 OR Proposal 2, where each proposal may have more than one 2052 protocol. The second example below shows either an AH AND ESP protection 2053 suite OR just an ESP protection suite. Note that the Next Payload field 2054 of the Proposal payload points to another Proposal payload (if it exists). 2055 The existence of a Proposal payload implies the existence of one or more 2056 Transform payloads. 2058 The Transform payload provides the initiating entity with the capability 2059 to present to the responding entity multiple mechanisms, or transforms, 2060 for a given protocol. The Proposal payload identifies a Protocol for 2061 which services and mechanisms are being negotiated. The Transform pay- 2062 load allows the initiating entity to present several possible supported 2063 transforms for that proposed protocol. There may be several transforms 2064 associated with a specific Proposal payload each identified in a separate 2065 Transform payload. The multiple transforms MUST be presented with mono- 2066 tonically increasing numbers in the initiator's preference order. The 2067 receiving entity MUST select a single transform for each protocol in a 2068 proposal or reject the entire proposal. The use of the Transform num- 2069 ber in multiple Transform payloads provides a second level OR operation, 2070 i.e. Transform 1 OR Transform 2 OR Transform 3. Example 1 below shows 2071 two possible transforms for ESP and a single transform for AH. Example 2 2072 below shows one transform for AH AND one transform for ESP OR two trans- 2073 forms for ESP alone. Note that the Next Payload field of the Transform 2074 payload points to another Transform payload or 0. The Proposal payload 2075 delineates the different proposals. 2077 When responding to a Security Association payload, the responder MUST send 2078 a Security Association payload with the selected proposal, which may con- 2079 sist of multiple Proposal payloads and their associated Transform pay- 2080 loads. Each of the Proposal payloads MUST contain a single Transform 2081 payload associated with the Protocol. The responder SHOULD retain the 2082 Proposal # field in the Proposal payload and the Transform # field in 2083 each Transform payload of the selected Proposal. Retention of Proposal 2084 and Transform numbers should speed the initiator's protocol processing by 2085 negating the need to compare the respondor's selection with every offered 2086 option. These values enable the initiator to perform the comparison di- 2087 rectly and quickly. The initiator MUST verify that the Security Associa- 2088 tion payload received from the responder matches one of the proposals sent 2089 initially. 2091 4.2.1 Security Association Establishment Examples 2093 This example shows a Proposal for a combined protection suite with two 2094 different protocols. The first protocol is presented with two transforms 2095 supported by the proposer. The second protocol is presented with a sin- 2096 gle transform. An example for this proposal might be: Protocol 1 is ESP 2097 with Transform 1 as 3DES and Transform 2 as DES AND Protocol 2 is AH with 2098 Transform 1 as SHA. The responder MUST select from the two transforms pro- 2099 posed for ESP. The resulting protection suite will be either (1) 3DES AND 2100 SHA OR (2) DES AND SHA, depending on which ESP transform was selected by 2101 the responder. Note this example is shown using the Base Exchange. 2103 1 2 3 2104 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 2105 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 / ! NP = Nonce ! RESERVED ! Payload Length ! 2107 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 SA Pay ! Domain of Interpretation (DOI) ! 2109 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 \ ! Situation ! 2111 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 / ! NP = Proposal ! RESERVED ! Payload Length ! 2113 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans. = 2! 2115 Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 \ ! SPI (variable) ! 2117 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 / ! NP = Transform! RESERVED ! Payload Length ! 2119 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 2121 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 \ ! SA Attributes ! 2123 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 / ! NP = 0 ! RESERVED ! Payload Length ! 2125 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! 2128 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2129 \ ! SA Attributes ! 2130 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 / ! NP = 0 ! RESERVED ! Payload Length ! 2132 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2133 Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! 2134 Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 \ ! SPI (variable) ! 2136 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 / ! NP = 0 ! RESERVED ! Payload Length ! 2138 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 2140 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 \ ! SA Attributes ! 2142 \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 This second example shows a Proposal for two different protection suites. 2145 The SA Payload was omitted for space reasons. The first protection suite 2146 is presented with one transform for the first protocol and one transform 2147 for the second protocol. The second protection suite is presented with 2148 two transforms for a single protocol. An example for this proposal might 2149 be: Proposal 1 with Protocol 1 as AH with Transform 1 as MD5 AND Protocol 2150 2 as ESP with Transform 1 as 3DES. This is followed by Proposal 2 with 2151 Protocol 1 as ESP with Transform 1 as DES and Transform 2 as 3DES. The 2152 responder MUST select from the two different proposals. If the second 2153 Proposal is selected, the responder MUST select from the two transforms 2154 for ESP. The resulting protection suite will be either (1) MD5 AND 3DES OR 2155 the selection between (2) DES OR (3) 3DES. 2157 1 2 3 2158 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 2159 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 / ! NP = Proposal ! RESERVED ! Payload Length ! 2161 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! 2163 Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 \ ! SPI (variable) ! 2165 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 / ! NP = 0 ! RESERVED ! Payload Length ! 2167 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 2169 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 \ ! SA Attributes ! 2171 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 / ! NP = Proposal ! RESERVED ! Payload Length ! 2173 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! 2175 Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 \ ! SPI (variable) ! 2177 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 / ! NP = 0 ! RESERVED ! Payload Length ! 2179 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 2181 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 \ ! SA Attributes ! 2183 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2184 / ! NP = 0 ! RESERVED ! Payload Length ! 2185 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 Prop 2 ! Proposal # = 2! Protocol ID ! SPI Size !# of Trans. = 2! 2187 Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2188 \ ! SPI (variable) ! 2189 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2190 / ! NP = Transform! RESERVED ! Payload Length ! 2191 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2192 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 2193 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 \ ! SA Attributes ! 2195 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 / ! NP = 0 ! RESERVED ! Payload Length ! 2197 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! 2199 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2200 \ ! SA Attributes ! 2201 \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 4.3 Security Association Modification 2205 Security Association modification within ISAKMP is accomplished by cre- 2206 ating a new SA and initiating communications using that new SA. Deletion 2207 of the old SA can be done anytime after the new SA is established. Dele- 2208 tion of the old SA is dependent on local security policy. Modification of 2209 SAs by using a "Create New SA followed by Delete Old SA" method is done to 2210 avoid potential vulnerabilities in synchronizing modification of existing 2211 SA attributes. The procedure for creating new SAs is outlined in section 2212 4.2. The procedure for deleting SAs is outlined in section 5.15. 2214 Modification of an ISAKMP SA (phase 1 negotiation) follows the same proce- 2215 dure as creation of an ISAKMP SA. There is no relationship between the two 2216 SAs and the initiator and responder cookie pairs SHOULD be different, as 2217 outlined in section 2.5.3. 2219 Modification of a Protocol SA (phase 2 negotiation) follows the same pro- 2220 cedure as creation of a Protocol SA. The creation of a new SA is protected 2221 by the existing ISAKMP SA. There is no relationship between the two Proto- 2222 col SAs. A protocol implementation SHOULD begin using the newly created 2223 SA for outbound traffic and SHOULD continue to support incoming traffic 2224 on the old SA until it is deleted or until traffic is received under the 2225 protection of the newly created SA. As stated previously in this section, 2226 deletion of an old SA is then dependent on local security policy. 2228 4.4 Base Exchange 2230 The Base Exchange is designed to allow the Key Exchange and Authentica- 2231 tion related information to be transmitted together. Combining the Key 2232 Exchange and Authentication-related information into one message reduces 2233 the number of round-trips at the expense of not providing identity pro- 2234 tection. Identity protection is not provided because identities are ex- 2235 changed before a common shared secret has been established and, therefore, 2236 encryption of the identities is not possible. The following diagram shows 2237 the messages with the possible payloads sent in each message and notes for 2238 an example of the Base Exchange. 2240 BASE EXCHANGE 2242 _#______Initiator____Direction_____Responder______________________NOTE____________________ 2243 (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation 2245 (2) <= HDR; SA; NONCE 2246 Basic SA agreed upon 2247 (3) HDR; KE; => 2248 IDii; AUTH Key Generated (by responder) 2249 Initiator Identity Verified by Responder 2250 (4) <= HDR; KE; 2251 IDir; AUTH 2252 Responder Identity Verified by Initiator 2253 Key Generated (by initiator) 2254 SA established 2256 In the first message (1), the initiator generates a proposal it considers 2257 adequate to protect traffic for the given situation. The Security Associ- 2258 ation, Proposal, and Transform payloads are included in the Security Asso- 2259 ciation payload (for notation purposes). Random information which is used 2260 to guarantee liveness and protect against replay attacks is also trans- 2261 mitted. Random information provided by both parties SHOULD be used by the 2262 authentication mechanism to provide shared proof of participation in the 2263 exchange. 2265 In the second message (2), the responder indicates the protection suite it 2266 has accepted with the Security Association, Proposal, and Transform pay- 2267 loads. Again, random information which is used to guarantee liveness and 2268 protect against replay attacks is also transmitted. Random information 2269 provided by both parties SHOULD be used by the authentication mechanism 2270 to provide shared proof of participation in the exchange. Local secu- 2271 rity policy dictates the action of the responder if no proposed protection 2272 suite is accepted. One possible action is the transmission of a Notify 2273 payload as part of an Informational Exchange. 2275 In the third (3) and fourth (4) messages, the initiator and responder, re- 2276 spectively, exchange keying material used to arrive at a common shared 2277 secret and identification information. This information is transmitted 2278 under the protection of the agreed upon authentication function. Local 2279 security policy dictates the action if an error occurs during these mes- 2280 sages. One possible action is the transmission of a Notify payload as 2281 part of an Informational Exchange. 2283 4.5 Identity Protection Exchange 2285 The Identity Protection Exchange is designed to separate the Key Exchange 2286 information from the Identity and Authentication related information. 2287 Separating the Key Exchange from the Identity and Authentication related 2288 information provides protection of the communicating identities at the ex- 2289 pense of two additional messages. Identities are exchanged under the pro- 2290 tection of a previously established common shared secret. The following 2291 diagram shows the messages with the possible payloads sent in each message 2292 and notes for an example of the Identity Protection Exchange. 2294 IDENTITY PROTECTION EXCHANGE 2296 _#_______Initiator_____Direction______Responder_____NOTE________________________________________ 2297 (1) HDR; SA => Begin ISAKMP-SA or Proxy negotiation 2298 (2) <= HDR; SA 2299 Basic SA agreed upon 2300 (3) HDR; KE; NONCE => 2301 (4) <= HDR; KE; NONCE 2302 Key Generated (by Initiator and Responder) 2303 (5) HDR*; IDii; AUTH => 2304 Initiator Identity Verified by Responder 2305 (6) <= HDR*; IDir; AUTH 2306 Responder Identity Verified by Initiator 2307 SA established 2309 In the first message (1), the initiator generates a proposal it consid- 2310 ers adequate to protect traffic for the given situation. The Security As- 2311 sociation, Proposal, and Transform payloads are included in the Security 2312 Association payload (for notation purposes). 2314 In the second message (2), the responder indicates the protection suite it 2315 has accepted with the Security Association, Proposal, and Transform pay- 2316 loads. Local security policy dictates the action of the responder if no 2317 proposed protection suite is accepted. One possible action is the trans- 2318 mission of a Notify payload as part of an Informational Exchange. 2320 In the third (3) and fourth (4) messages, the initiator and responder, re- 2321 spectively, exchange keying material used to arrive at a common shared se- 2322 cret and random information which is used to guarantee liveness and pro- 2323 tect against replay attacks. Random information provided by both parties 2324 SHOULD be used by the authentication mechanism to provide shared proof 2325 of participation in the exchange. Local security policy dictates the ac- 2326 tion if an error occurs during these messages. One possible action is the 2327 transmission of a Notify payload as part of an Informational Exchange. 2329 In the fifth (5) and sixth (6) messages, the initiator and responder, re- 2330 spectively, exchange identification information and the results of the 2331 agreed upon authentication function. This information is transmitted un- 2332 der the protection of the common shared secret. Local security policy 2333 dictates the action if an error occurs during these messages. One pos- 2334 sible action is the transmission of a Notify payload as part of an Infor- 2335 mational Exchange. 2337 4.6 Authentication Only Exchange 2339 The Authentication Only Exchange is designed to allow only Authentication 2340 related information to be transmitted. The benefit of this exchange is 2341 the ability to perform only authentication without the computational ex- 2342 pense of computing keys. Using this exchange during negotiation, none of 2343 the transmitted information will be encrypted. However, the information 2344 may be encrypted in other places. For example, if encryption is negoti- 2345 ated during the first phase of a negotiation and the authentication only 2346 exchange is used in the second phase of a negotiation, then the authenti- 2347 cation only exchange will be encrypted by the ISAKMP SAs negotiated in the 2348 first phase. The following diagram shows the messages with possible pay- 2349 loads sent in each message and notes for an example of the Authentication 2350 Only Exchange. 2352 AUTHENTICATION ONLY EXCHANGE 2354 _#______Initiator_____Direction_____Responder_______________________NOTE____________________ 2355 (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation 2357 (2) <= HDR; SA; NONCE; 2358 IDir; AUTH 2359 Basic SA agreed upon 2360 Responder Identity Verified by Initiator 2361 (3) HDR; IDii; AUTH => 2362 Initiator Identity Verified by Responder 2363 SA established 2365 In the first message (1), the initiator generates a proposal it considers 2366 adequate to protect traffic for the given situation. The Security Associ- 2367 ation, Proposal, and Transform payloads are included in the Security Asso- 2368 ciation payload (for notation purposes). Random information which is used 2369 to guarantee liveness and protect against replay attacks is also trans- 2370 mitted. Random information provided by both parties SHOULD be used by the 2371 authentication mechanism to provide shared proof of participation in the 2372 exchange. 2374 In the second message (2), the responder indicates the protection suite it 2375 has accepted with the Security Association, Proposal, and Transform pay- 2376 loads. Again, random information which is used to guarantee liveness and 2377 protect against replay attacks is also transmitted. Random information 2378 provided by both parties SHOULD be used by the authentication mechanism 2379 to provide shared proof of participation in the exchange. Additionally, 2380 the responder transmits identification information. All of this infor- 2381 mation is transmitted under the protection of the agreed upon authentica- 2382 tion function. Local security policy dictates the action of the responder 2383 if no proposed protection suite is accepted. One possible action is the 2384 transmission of a Notify payload as part of an Informational Exchange. 2386 In the third message (3), the initiator transmits identification informa- 2387 tion. This information is transmitted under the protection of the agreed 2388 upon authentication function. Local security policy dictates the action 2389 if an error occurs during these messages. One possible action is the 2390 transmission of a Notify payload as part of an Informational Exchange. 2392 4.7 Aggressive Exchange 2394 The Aggressive Exchange is designed to allow the Security Association, Key 2395 Exchange and Authentication related payloads to be transmitted together. 2396 Combining the Security Association, Key Exchange, and Authentication- 2397 related information into one message reduces the number of round-trips at 2398 the expense of not providing identity protection. Identity protection is 2399 not provided because identities are exchanged before a common shared se- 2400 cret has been established and, therefore, encryption of the identities is 2401 not possible. Additionally, the Aggressive Exchange is attempting to es- 2402 tablish all security relevant information in a single exchange. The fol- 2403 lowing diagram shows the messages with possible payloads sent in each mes- 2404 sage and notes for an example of the Aggressive Exchange. 2406 AGGRESSIVE EXCHANGE 2408 _#_____Initiator___Direction______Responder________________________NOTE____________________ 2409 (1) HDR; SA; KE; => Begin ISAKMP-SA or Proxy negotiation 2410 NONCE; IDii and Key Exchange 2412 (2) <= HDR; SA; KE; 2413 NONCE; IDir; AUTH 2414 Initiator Identity Verified by Responder 2415 Key Generated 2416 Basic SA agreed upon 2417 (3) HDR*; AUTH => 2418 Responder Identity Verified by Initiator 2419 SA established 2421 In the first message (1), the initiator generates a proposal it considers 2422 adequate to protect traffic for the given situation. The Security Associ- 2423 ation, Proposal, and Transform payloads are included in the Security Asso- 2424 ciation payload (for notation purposes). There can be only one Proposal 2425 and one Transform offered (i.e. no choices) in order for the aggressive 2426 exchange to work. Keying material used to arrive at a common shared se- 2427 cret and random information which is used to guarantee liveness and pro- 2428 tect against replay attacks are also transmitted. Random information pro- 2429 vided by both parties SHOULD be used by the authentication mechanism to 2430 provide shared proof of participation in the exchange. Additionally, the 2431 initiator transmits identification information. 2433 In the second message (2), the responder indicates the protection suite 2434 it has accepted with the Security Association, Proposal, and Transform 2435 payloads. Keying material used to arrive at a common shared secret and 2436 random information which is used to guarantee liveness and protect against 2437 replay attacks is also transmitted. Random information provided by both 2438 parties SHOULD be used by the authentication mechanism to provide shared 2439 proof of participation in the exchange. Additionally, the responder 2440 transmits identification information. All of this information is trans- 2441 mitted under the protection of the agreed upon authentication function. 2442 Local security policy dictates the action of the responder if no proposed 2443 protection suite is accepted. One possible action is the transmission of 2444 a Notify payload as part of an Informational Exchange. 2446 In the third (3) message, the initiator transmits the results of the 2447 agreed upon authentication function. This information is transmitted un- 2448 der the protection of the common shared secret. Local security policy 2449 dictates the action if an error occurs during these messages. One pos- 2450 sible action is the transmission of a Notify payload as part of an Infor- 2451 mational Exchange. 2453 4.8 Informational Exchange 2455 The Informational Exchange is designed as a one-way transmittal of infor- 2456 mation that can be used for security association management. The follow- 2457 ing diagram shows the messages with possible payloads sent in each message 2458 and notes for an example of the Informational Exchange. 2460 INFORMATIONAL EXCHANGE 2462 __#___Initiator__Direction_Responder_______________NOTE_______________ 2463 (1) HDR*; N/D => Error Notification or Deletion 2465 In the first message (1), the initiator or responder transmits an ISAKMP 2466 Notify or Delete payload. 2468 If the Informational Exchange occurs prior to the exchange of keying me- 2469 terial during an ISAKMP Phase 1 negotiation, there will be no protection 2470 provided for the Informational Exchange. Once keying material has been 2471 exchanged or an ISAKMP SA has been established, the Informational Exchange 2472 MUST be transmitted under the protection provided by the keying material 2473 or the ISAKMP SA. 2475 All exchanges are similar in that with the beginning of any exchange cryp- 2476 tographic synchronization MUST occur. The Informational Exchange is an 2477 exchange and not an ISAKMP message. Thus, the generation of an Initial- 2478 ization Vector (IV) for an Informational Exchange SHOULD be independent 2479 of IVs of other on-going communication. This will ensure cryptographic 2480 synchronization is maintained for existing communications and the Informa- 2481 tional Exchange will be processed correctly. 2483 5 ISAKMP Payload Processing 2485 Section 3 describes the ISAKMP payloads. These payloads are used in the 2486 exchanges described in section 4 and can be used in exchanges defined for 2487 a specific DOI. This section describes the processing for each of the 2488 payloads. This section suggests the logging of events to a system au- 2489 dit file. This action is controlled by a system security policy and is, 2490 therefore, only a suggested action. 2492 5.1 General Message Processing 2494 Every ISAKMP message has basic processing applied to insure protocol re- 2495 liability, and to minimize threats, such as denial of service and replay 2496 attacks. All processing SHOULD include packet length checks to insure 2497 the packet received is at least as long as the length given in the ISAKMP 2498 Header. 2500 When transmitting an ISAKMP message, the transmitting entity (initiator or 2501 responder) MUST do the following: 2503 1. Set a timer and initialize a retry counter. 2505 2. If the timer expires, the ISAKMP message is resent and the retry 2506 counter is decremented. 2508 3. If the retry counter reaches zero (0), the event, RETRY LIMIT 2509 REACHED, MAY be logged in the appropriate system audit file. 2511 4. The ISAKMP protocol machine clears all states and returns to IDLE. 2513 5.2 ISAKMP Header Processing 2515 When creating an ISAKMP message, the transmitting entity (initiator or 2516 responder) MUST do the following: 2518 1. Create the respective cookie. See section 2.5.3 for details. 2520 2. Determine the relevant security characteristics of the session (i.e. 2521 DOI and situation). 2523 3. Construct an ISAKMP Header with fields as described in section 3.1. 2525 4. Construct other ISAKMP payloads, depending on the exchange type. 2527 5. Transmit the message to the destination host as described in section 2528 5.1. 2530 When an ISAKMP message is received, the receiving entity (initiator or 2531 responder) MUST do the following: 2533 1. Verify the Initiator and Responder ``cookies''. If the cookie 2534 validation fails, the message is discarded and the following actions 2535 are taken: 2537 (a) The event, INVALID COOKIE, MAY be logged in the appropriate 2538 system audit file. 2540 (b) An Informational Exchange with a Notification payload containing 2541 the INVALID-COOKIE message type MAY be sent to the transmitting 2542 entity. This action is dictated by a system security policy. 2544 2. Check the Next Payload field to confirm it is valid. If the Next 2545 Payload field validation fails, the message is discarded and the 2546 following actions are taken: 2548 (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the appropriate 2549 system audit file. 2551 (b) An Informational Exchange with a Notification payload containing 2552 the INVALID-PAYLOAD-TYPE message type MAY be sent to the 2553 transmitting entity. This action is dictated by a system 2554 security policy. 2556 3. Check the Major and Minor Version fields to confirm they are correct. 2557 If the Version field validation fails, the message is discarded and 2558 the following actions are taken: 2560 (a) The event, INVALID ISAKMP VERSION, MAY be logged in the 2561 appropriate system audit file. 2563 (b) An Informational Exchange with a Notification payload containing 2564 the INVALID-MAJOR-VERSION or INVALID-MINOR-VERSION message type 2565 MAY be sent to the transmitting entity. This action is dictated 2566 by a system security policy. 2568 4. Check the Exchange Type field to confirm it is valid. If the 2569 Exchange Type field validation fails, the message is discarded and 2570 the following actions are taken: 2572 (a) The event, INVALID EXCHANGE TYPE, MAY be logged in the 2573 appropriate system audit file. 2575 (b) An Informational Exchange with a Notification payload containing 2576 the INVALID-EXCHANGE-TYPE message type MAY be sent to the 2577 transmitting entity. This action is dictated by a system 2578 security policy. 2580 5. Check the Flags field to ensure it contains correct values. If the 2581 Flags field validation fails, the message is discarded and the 2582 following actions are taken: 2584 (a) The event, INVALID FLAGS, MAY be logged in the appropriate system 2585 audit file. 2587 (b) An Informational Exchange with a Notification payload containing 2588 the INVALID-FLAGS message type MAY be sent to the transmitting 2589 entity. This action is dictated by a system security policy. 2591 6. Check the Message ID field to ensure it contains correct values. If 2592 the Message ID validation fails, the message is discarded and the 2593 following actions are taken: 2595 (a) The event, INVALID MESSAGE ID, MAY be logged in the appropriate 2596 system audit file. 2598 (b) An Informational Exchange with a Notification payload containing 2599 the INVALID-MESSAGE-ID message type MAY be sent to the 2600 transmitting entity. This action is dictated by a system 2601 security policy. 2603 7. Processing of the ISAKMP message continues using the value in the 2604 Next Payload field. 2606 5.3 Generic Payload Header Processing 2608 When creating any of the ISAKMP Payloads described in sections 3.4 through 2609 3.15 a Generic Payload Header is placed at the beginning of these pay- 2610 loads. When creating the Generic Payload Header, the transmitting entity 2611 (initiator or responder) MUST do the following: 2613 1. Place the value of the Next Payload in the Next Payload field. These 2614 values are described in section 3.1. 2616 2. Place the value zero (0) in the RESERVED field. 2618 3. Place the length (in octets) of the payload in the Payload Length 2619 field. 2621 4. Construct the payloads as defined in the remainder of this section. 2623 When any of the ISAKMP Payloads are received, the receiving entity (ini- 2624 tiator or responder) MUST do the following: 2626 1. Check the Next Payload field to confirm it is valid. If the Next 2627 Payload field validation fails, the message is discarded and the 2628 following actions are taken: 2630 (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the appropriate 2631 system audit file. 2633 (b) An Informational Exchange with a Notification payload containing 2634 the INVALID-PAYLOAD-TYPE message type MAY be sent to the 2635 transmitting entity. This action is dictated by a system 2636 security policy. 2638 2. Verify the RESERVED field contains the value zero. If the value in 2639 the RESERVED field is not zero, the message is discarded and the 2640 following actions are taken: 2642 (a) The event, INVALID RESERVED FIELD, MAY be logged in the 2643 appropriate system audit file. 2645 (b) An Informational Exchange with a Notification payload containing 2646 the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be 2647 sent to the transmitting entity. This action is dictated by a 2648 system security policy. 2650 3. Process the remaining payloads as defined by the Next Payload field. 2652 5.4 Security Association Payload Processing 2654 When creating a Security Association Payload, the transmitting entity 2655 (initiator or responder) MUST do the following: 2657 1. Determine the Domain of Interpretation for which this negotiation is 2658 being performed. 2660 2. Determine the situation within the determined DOI for which this 2661 negotiation is being performed. 2663 3. Determine the proposal(s) and transform(s) within the situation. 2664 These are described, respectively, in sections 3.5 and 3.6. 2666 4. Construct a Security Association payload. 2668 5. Transmit the message to the receiving entity as described in section 2669 5.1. 2671 When a Security Association payload is received, the receiving entity 2672 (initiator or responder) MUST do the following: 2674 1. Determine if the Domain of Interpretation (DOI) is supported. If the 2675 DOI determination fails, the message is discarded and the following 2676 actions are taken: 2678 (a) The event, INVALID DOI, MAY be logged in the appropriate system 2679 audit file. 2681 (b) An Informational Exchange with a Notification payload containing 2682 the DOI-NOT-SUPPORTED message type MAY be sent to the 2683 transmitting entity. This action is dictated by a system 2684 security policy. 2686 2. Determine if the given situation can be protected. If the Situation 2687 determination fails, the message is discarded and the following 2688 actions are taken: 2690 (a) The event, INVALID SITUATION, MAY be logged in the appropriate 2691 system audit file. 2693 (b) An Informational Exchange with a Notification payload containing 2694 the SITUATION-NOT-SUPPORTED message type MAY be sent to the 2695 transmitting entity. This action is dictated by a system 2696 security policy. 2698 3. Process the remaining payloads (i.e. Proposal, Transform) of the 2699 Security Association Payload. If the Security Association Proposal 2700 (as described in sections 5.5 and 5.6) is not accepted, then the 2701 following actions are taken: 2703 (a) The event, INVALID PROPOSAL, MAY be logged in the appropriate 2704 system audit file. 2706 (b) An Informational Exchange with a Notification payload containing 2707 the NO-PROPOSAL-CHOSEN message type MAY be sent to the 2708 transmitting entity. This action is dictated by a system 2709 security policy. 2711 5.5 Proposal Payload Processing 2713 When creating a Proposal Payload, the transmitting entity (initiator or 2714 responder) MUST do the following: 2716 1. Determine the Protocol for this proposal. 2718 2. Determine the number of proposals to be offered for this protocol and 2719 the number of transforms for each proposal. Transforms are described 2720 in section 3.6. 2722 3. Generate a unique pseudo-random SPI. 2724 4. Construct a Proposal payload. 2726 When a Proposal payload is received, the receiving entity (initiator or 2727 responder) MUST do the following: 2729 1. Determine if the Protocol is supported. If the Protocol-ID field is 2730 invalid, the payload is discarded and the following actions are 2731 taken: 2733 (a) The event, INVALID PROTOCOL, MAY be logged in the appropriate 2734 system audit file. 2736 (b) An Informational Exchange with a Notification payload containing 2737 the INVALID-PROTOCOL-ID message type MAY be sent to the 2738 transmitting entity. This action is dictated by a system 2739 security policy. 2741 2. Determine if the SPI is valid. If the SPI is invalid, the payload is 2742 discarded and the following actions are taken: 2744 (a) The event, INVALID SPI, MAY be logged in the appropriate system 2745 audit file. 2747 (b) An Informational Exchange with a Notification payload containing 2748 the INVALID-SPI message type MAY be sent to the transmitting 2749 entity. This action is dictated by a system security policy. 2751 3. Ensure the Proposals are presented according to the details given in 2752 section 3.5 and 4.2. If the proposals are not formed correctly, the 2753 following actions are taken: 2755 (a) Possible events, BAD PROPOSAL SYNTAX, INVALID PROPOSAL, are 2756 logged in the appropriate system audit file. 2758 (b) An Informational Exchange with a Notification payload containing 2759 the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be 2760 sent to the transmitting entity. This action is dictated by a 2761 system security policy. 2763 4. Process the Proposal and Transform payloads as defined by the Next 2764 Payload field. Examples of processing these payloads are given in 2765 section 4.2.1. 2767 5.6 Transform Payload Processing 2769 When creating a Transform Payload, the transmitting entity (initiator or 2770 responder) MUST do the following: 2772 1. Determine the Transform # for this transform. 2774 2. Determine the number of transforms to be offered for this proposal. 2775 Transforms are described in sections 3.6. 2777 3. Construct a Transform payload. 2779 When a Transform payload is received, the receiving entity (initiator or 2780 responder) MUST do the following: 2782 1. Determine if the Transform is supported. If the Transform-ID field 2783 contains an unknown or unsupported value, then that Transform payload 2784 MUST be ignored and MUST NOT cause the generation of an INVALID 2785 TRANSFORM event. If the Transform-ID field is invalid, the payload 2786 is discarded and the following actions are taken: 2788 (a) The event, INVALID TRANSFORM, MAY be logged in the appropriate 2789 system audit file. 2791 (b) An Informational Exchange with a Notification payload containing 2792 the INVALID-TRANSFORM-ID message type MAY be sent to the 2793 transmitting entity. This action is dictated by a system 2794 security policy. 2796 2. Ensure the Transforms are presented according to the details given in 2797 section 3.6 and 4.2. If the transforms are not formed correctly, the 2798 following actions are taken: 2800 (a) Possible events, BAD PROPOSAL SYNTAX, INVALID TRANSFORM, INVALID 2801 ATTRIBUTES, are logged in the appropriate system audit file. 2803 (b) An Informational Exchange with a Notification payload containing 2804 the BAD-PROPOSAL-SYNTAX, PAYLOAD-MALFORMED or ATTRIBUTES-NOT- 2805 SUPPORTED message type MAY be sent to the transmitting entity. 2806 This action is dictated by a system security policy. 2808 3. Process the subsequent Transform and Proposal payloads as defined by 2809 the Next Payload field. Examples of processing these payloads are 2810 given in section 4.2.1. 2812 5.7 Key Exchange Payload Processing 2814 When creating a Key Exchange Payload, the transmitting entity (initiator 2815 or responder) MUST do the following: 2817 1. Determine the Key Exchange to be used as defined by the DOI. 2819 2. Determine the usage of the Key Exchange Data field as defined by the 2820 DOI. 2822 3. Construct a Key Exchange payload. 2824 4. Transmit the message to the receiving entity as described in section 2825 5.1. 2827 When a Key Exchange payload is received, the receiving entity (initiator 2828 or responder) MUST do the following: 2830 1. Determine if the Key Exchange is supported. If the Key Exchange 2831 determination fails, the message is discarded and the following 2832 actions are taken: 2834 (a) The event, INVALID KEY INFORMATION, MAY be logged in the 2835 appropriate system audit file. 2837 (b) An Informational Exchange with a Notification payload containing 2838 the INVALID-KEY-INFORMATION message type MAY be sent to the 2839 transmitting entity. This action is dictated by a system 2840 security policy. 2842 5.8 Identification Payload Processing 2844 When creating an Identification Payload, the transmitting entity (initia- 2845 tor or responder) MUST do the following: 2847 1. Determine the Identification information to be used as defined by the 2848 DOI (and possibly the situation). 2850 2. Determine the usage of the Identification Data field as defined by 2851 the DOI. 2853 3. Construct an Identification payload. 2855 4. Transmit the message to the receiving entity as described in section 2856 5.1. 2858 When an Identification payload is received, the receiving entity (initia- 2859 tor or responder) MUST do the following: 2861 1. Determine if the Identification Type is supported. This may be based 2862 on the DOI and Situation. If the Identification determination fails, 2863 the message is discarded and the following actions are taken: 2865 (a) The event, INVALID ID INFORMATION, MAY be logged in the 2866 appropriate system audit file. 2868 (b) An Informational Exchange with a Notification payload containing 2869 the INVALID-ID-INFORMATION message type MAY be sent to the 2870 transmitting entity. This action is dictated by a system 2871 security policy. 2873 5.9 Certificate Payload Processing 2875 When creating a Certificate Payload, the transmitting entity (initiator or 2876 responder) MUST do the following: 2878 1. Determine the Certificate Encoding to be used. This may be specified 2879 by the DOI. 2881 2. Ensure the existence of a certificate formatted as defined by the 2882 Certificate Encoding. 2884 3. Construct a Certificate payload. 2886 4. Transmit the message to the receiving entity as described in section 2887 5.1. 2889 When a Certificate payload is received, the receiving entity (initiator or 2890 responder) MUST do the following: 2892 1. Determine if the Certificate Encoding is supported. If the 2893 Certificate Encoding is not supported, the payload is discarded and 2894 the following actions are taken: 2896 (a) The event, INVALID CERTIFICATE TYPE, MAY be logged in the 2897 appropriate system audit file. 2899 (b) An Informational Exchange with a Notification payload containing 2900 the INVALID-CERT-ENCODING message type MAY be sent to the 2901 transmitting entity. This action is dictated by a system 2902 security policy. 2904 2. Process the Certificate Data field. If the Certificate Data is 2905 invalid or improperly formatted, the payload is discarded and the 2906 following actions are taken: 2908 (a) The event, INVALID CERTIFICATE, MAY be logged in the appropriate 2909 system audit file. 2911 (b) An Informational Exchange with a Notification payload containing 2912 the INVALID-CERTIFICATE message type MAY be sent to the 2913 transmitting entity. This action is dictated by a system 2914 security policy. 2916 5.10 Certificate Request Payload Processing 2918 When creating a Certificate Request Payload, the transmitting entity (ini- 2919 tiator or responder) MUST do the following: 2921 1. Determine the type of Certificate Encoding to be requested. This may 2922 be specified by the DOI. 2924 2. Determine the name of an acceptable Certificate Authority which is to 2925 be requested (if applicable). 2927 3. Construct a Certificate Request payload. 2929 4. Transmit the message to the receiving entity as described in section 2930 5.1. 2932 When a Certificate Request payload is received, the receiving entity (ini- 2933 tiator or responder) MUST do the following: 2935 1. Determine if the Certificate Encoding is supported. If the 2936 Certificate Encoding is invalid, the payload is discarded and the 2937 following actions are taken: 2939 (a) The event, INVALID CERTIFICATE TYPE, MAY be logged in the 2940 appropriate system audit file. 2942 (b) An Informational Exchange with a Notification payload containing 2943 the INVALID-CERT-ENCODING message type MAY be sent to the 2944 transmitting entity. This action is dictated by a system 2945 security policy. 2947 If the Certificate Encoding is not supported, the payload is 2948 discarded and the following actions are taken: 2950 (a) The event, CERTIFICATE TYPE UNSUPPORTED, MAY be logged in the 2951 appropriate system audit file. 2953 (b) An Informational Exchange with a Notification payload containing 2954 the CERT-TYPE-UNSUPPORTED message type MAY be sent to the 2955 transmitting entity. This action is dictated by a system 2956 security policy. 2958 2. Determine if the Certificate Authority is supported for the specified 2959 Certificate Encoding. If the Certificate Authority is invalid or 2960 improperly formatted, the payload is discarded and the following 2961 actions are taken: 2963 (a) The event, INVALID CERTIFICATE AUTHORITY, MAY be logged in the 2964 appropriate system audit file. 2966 (b) An Informational Exchange with a Notification payload containing 2967 the INVALID-CERT-AUTHORITY message type MAY be sent to the 2968 transmitting entity. This action is dictated by a system 2969 security policy. 2971 3. Process the Certificate Request. If a requested Certificate Type 2972 with the specified Certificate Authority is not available, then the 2973 payload is discarded and the following actions are taken: 2975 (a) The event, CERTIFICATE-UNAVAILABLE, MAY be logged in the 2976 appropriate system audit file. 2978 (b) An Informational Exchange with a Notification payload containing 2979 the CERTIFICATE-UNAVAILABLE message type MAY be sent to the 2980 transmitting entity. This action is dictated by a system 2981 security policy. 2983 5.11 Hash Payload Processing 2985 When creating a Hash Payload, the transmitting entity (initiator or re- 2986 sponder) MUST do the following: 2988 1. Determine the Hash function to be used as defined by the SA 2989 negotiation. 2991 2. Determine the usage of the Hash Data field as defined by the DOI. 2993 3. Construct a Hash payload. 2995 4. Transmit the message to the receiving entity as described in section 2996 5.1. 2998 When a Hash payload is received, the receiving entity (initiator or re- 2999 sponder) MUST do the following: 3001 1. Determine if the Hash is supported. If the Hash determination fails, 3002 the message is discarded and the following actions are taken: 3004 (a) The event, INVALID HASH INFORMATION, MAY be logged in the 3005 appropriate system audit file. 3007 (b) An Informational Exchange with a Notification payload containing 3008 the INVALID-HASH-INFORMATION message type MAY be sent to the 3009 transmitting entity. This action is dictated by a system 3010 security policy. 3012 2. Perform the Hash function as outlined in the DOI and/or Key Exchange 3013 protocol documents. If the Hash function fails, the message is 3014 discarded and the following actions are taken: 3016 (a) The event, INVALID HASH VALUE, MAY be logged in the appropriate 3017 system audit file. 3019 (b) An Informational Exchange with a Notification payload containing 3020 the AUTHENTICATION-FAILED message type MAY be sent to the 3021 transmitting entity. This action is dictated by a system 3022 security policy. 3024 5.12 Signature Payload Processing 3026 When creating a Signature Payload, the transmitting entity (initiator or 3027 responder) MUST do the following: 3029 1. Determine the Signature function to be used as defined by the SA 3030 negotiation. 3032 2. Determine the usage of the Signature Data field as defined by the 3033 DOI. 3035 3. Construct a Signature payload. 3037 4. Transmit the message to the receiving entity as described in section 3038 5.1. 3040 When a Signature payload is received, the receiving entity (initiator or 3041 responder) MUST do the following: 3043 1. Determine if the Signature is supported. If the Signature 3044 determination fails, the message is discarded and the following 3045 actions are taken: 3047 (a) The event, INVALID SIGNATURE INFORMATION, MAY be logged in the 3048 appropriate system audit file. 3050 (b) An Informational Exchange with a Notification payload containing 3051 the INVALID-SIGNATURE message type MAY be sent to the 3052 transmitting entity. This action is dictated by a system 3053 security policy. 3055 2. Perform the Signature function as outlined in the DOI and/or Key 3056 Exchange protocol documents. If the Signature function fails, the 3057 message is discarded and the following actions are taken: 3059 (a) The event, INVALID SIGNATURE VALUE, MAY be logged in the 3060 appropriate system audit file. 3062 (b) An Informational Exchange with a Notification payload containing 3063 the AUTHENTICATION-FAILED message type MAY be sent to the 3064 transmitting entity. This action is dictated by a system 3065 security policy. 3067 5.13 Nonce Payload Processing 3069 When creating a Nonce Payload, the transmitting entity (initiator or re- 3070 sponder) MUST do the following: 3072 1. Create a unique random value to be used as a nonce. 3074 2. Construct a Nonce payload. 3076 3. Transmit the message to the receiving entity as described in section 3077 5.1. 3079 When a Nonce payload is received, the receiving entity (initiator or re- 3080 sponder) MUST do the following: 3082 1. There are no specific procedures for handling Nonce payloads. The 3083 procedures are defined by the exchange types (and possibly the DOI 3084 and Key Exchange descriptions). 3086 5.14 Notification Payload Processing 3088 During communications it is possible that errors may occur. The Infor- 3089 mational Exchange with a Notify Payload provides a controlled method of 3090 informing a peer entity that errors have occurred during protocol process- 3091 ing. It is RECOMMENDED that Notify Payloads be sent in a separate Infor- 3092 mational Exchange rather than appending a Notify Payload to an existing 3093 exchange. 3095 When creating a Notification Payload, the transmitting entity (initiator 3096 or responder) MUST do the following: 3098 1. Determine the DOI for this Notification. 3100 2. Determine the Protocol-ID for this Notification. 3102 3. Determine the SPI size based on the Protocol-ID field. This field is 3103 necessary because different security protocols have different SPI 3104 sizes. For example, ISAKMP combines the Initiator and Responder 3105 cookie pair (16 octets) as a SPI, while ESP and AH have 8 octet SPIs. 3107 4. Determine the Notify Message Type based on the error or status 3108 message desired. 3110 5. Determine the SPI which is associated with this notification. 3112 6. Determine if additional Notification Data is to be included. This is 3113 additional information specified by the DOI. 3115 7. Construct a Notification payload. 3117 8. Transmit the message to the receiving entity as described in section 3118 5.1. 3120 Because the Informational Exchange with a Notification payload is a uni- 3121 directional message a retransmission will not be performed. The local 3122 security policy will dictate the procedures for continuing. However, we 3123 RECOMMEND that a NOTIFICATION PAYLOAD ERROR event be logged in the appro- 3124 priate system audit file by the receiving entity. 3126 If the Informational Exchange occurs prior to the exchange of keying ma- 3127 terial during an ISAKMP Phase 1 negotiation there will be no protection 3128 provided for the Informational Exchange. Once the keying material has 3129 been exchanged or the ISAKMP SA has been established, the Informational 3130 Exchange MUST be transmitted under the protection provided by the keying 3131 material or the ISAKMP SA. 3133 When a Notification payload is received, the receiving entity (initiator 3134 or responder) MUST do the following: 3136 1. Determine if the Informational Exchange has any protection applied to 3137 it by checking the Encryption Bit and the Authentication Only Bit in 3138 the ISAKMP Header. If the Encryption Bit is set, i.e. the Informa- 3139 tional Exchange is encrypted, then the message MUST be decrypted 3140 using the (in-progress or completed) ISAKMP SA. Once the decryption 3141 is complete the processing can continue as described below. If the 3142 Authentication Only Bit is set, then the message MUST be authenti- 3143 cated using the (in-progress or completed) ISAKMP SA. Once the 3144 authentication is completed, the processing can continue as described 3145 below. If the Informational Exchange is not encrypted or authentica- 3146 tion, the payload processing can continue as described below. 3148 2. Determine if the Domain of Interpretation (DOI) is supported. If the 3149 DOI determination fails, the payload is discarded and the following 3150 action is taken: 3152 (a) The event, INVALID DOI, MAY be logged in the appropriate system 3153 audit file. 3155 3. Determine if the Protocol-Id is supported. If the Protocol-Id 3156 determination fails, the payload is discarded and the following 3157 action is taken: 3159 (a) The event, INVALID PROTOCOL-ID, MAY be logged in the appropriate 3160 system audit file. 3162 4. Determine if the SPI is valid. If the SPI is invalid, the payload is 3163 discarded and the following action is taken: 3165 (a) The event, INVALID SPI, MAY be logged in the appropriate system 3166 audit file. 3168 5. Determine if the Notify Message Type is valid. If the Notify Message 3169 Type is invalid, the payload is discarded and the following action is 3170 taken: 3172 (a) The event, INVALID MESSAGE TYPE, MAY be logged in the appropriate 3173 system audit file. 3175 6. Process the Notification payload, including additional Notification 3176 Data, and take appropriate action, according to local security 3177 policy. 3179 5.15 Delete Payload Processing 3181 During communications it is possible that hosts may be compromised or that 3182 information may be intercepted during transmission. Determining whether 3183 this has occurred is not an easy task and is outside the scope of this 3184 Internet-Draft. However, if it is discovered that transmissions are being 3185 compromised, then it is necessary to establish a new SA and delete the 3186 current SA. 3188 The Informational Exchange with a Delete Payload provides a controlled 3189 method of informing a peer entity that the transmitting entity has deleted 3190 the SA(s). Deletion of Security Associations MUST always be performed un- 3191 der the protection of an ISAKMP SA. The receiving entity SHOULD clean up 3192 its local SA database. However, upon receipt of a Delete message the SAs 3193 listed in the Security Parameter Index (SPI) field of the Delete payload 3194 cannot be used with the transmitting entity. The SA Establishment proce- 3195 dure must be invoked to re-establish secure communications. 3197 When creating a Delete Payload, the transmitting entity (initiator or re- 3198 sponder) MUST do the following: 3200 1. Determine the DOI for this Deletion. 3202 2. Determine the Protocol-ID for this Deletion. 3204 3. Determine the SPI size based on the Protocol-ID field. This field is 3205 necessary because different security protocols have different SPI 3206 sizes. For example, ISAKMP combines the Initiator and Responder 3207 cookie pair (16 octets) as a SPI, while ESP and AH have 8 octet SPIs. 3209 4. Determine the # of SPIs to be deleted for this protocol. 3211 5. Determine the SPI(s) which is (are) associated with this deletion. 3213 6. Construct a Delete payload. 3215 7. Transmit the message to the receiving entity as described in section 3216 5.1. 3218 Because the Informational Exchange with a Delete payload is a unidirec- 3219 tional message a retransmission will not be performed. The local security 3220 policy will dictate the procedures for continuing. However, we RECOMMEND 3221 that a DELETE PAYLOAD ERROR event be logged in the appropriate system au- 3222 dit file by the receiving entity. 3224 As described above, the Informational Exchange with a Delete payload MUST 3225 be transmitted under the protection provided by an ISAKMP SA. 3227 When a Delete payload is received, the receiving entity (initiator or re- 3228 sponder) MUST do the following: 3230 1. Because the Informational Exchange is protected by some security 3231 service (e.g. authentication for an Auth-Only SA, encryption for 3232 other exchanges), the message MUST have these security services 3233 applied using the ISAKMP SA. Once the security service processing is 3234 complete the processing can continue as described below. Any errors 3235 that occur during the security service processing will be evident 3236 when checking information in the Delete payload. The local security 3237 policy SHOULD dictate any action to be taken as a result of security 3238 service processing errors. 3240 2. Determine if the Domain of Interpretation (DOI) is supported. If the 3241 DOI determination fails, the payload is discarded and the following 3242 action is taken: 3244 (a) The event, INVALID DOI, MAY be logged in the appropriate system 3245 audit file. 3247 3. Determine if the Protocol-Id is supported. If the Protocol-Id 3248 determination fails, the payload is discarded and the following 3249 action is taken: 3251 (a) The event, INVALID PROTOCOL-ID, MAY be logged in the appropriate 3252 system audit file. 3254 4. Determine if the SPI is valid for each SPI included in the Delete 3255 payload. For each SPI that is invalid, the following action is 3256 taken: 3258 (a) The event, INVALID SPI, MAY be logged in the appropriate system 3259 audit file. 3261 5. Process the Delete payload and take appropriate action, according to 3262 local security policy. As described above, one appropriate action 3263 SHOULD include cleaning up the local SA database. 3265 6 Conclusions 3267 The Internet Security Association and Key Management Protocol (ISAKMP) is 3268 a well designed protocol aimed at the Internet of the future. The mas- 3269 sive growth of the Internet will lead to great diversity in network uti- 3270 lization, communications, security requirements, and security mechanisms. 3271 ISAKMP contains all the features that will be needed for this dynamic and 3272 expanding communications environment. 3274 ISAKMP's Security Association (SA) feature coupled with authentication 3275 and key establishment provides the security and flexibility that will be 3276 needed for future growth and diversity. This security diversity of multi- 3277 ple key exchange techniques, encryption algorithms, authentication mecha- 3278 nisms, security services, and security attributes will allow users to se- 3279 lect the appropriate security for their network, communications, and secu- 3280 rity needs. The SA feature allows users to specify and negotiate security 3281 requirements with other users. An additional benefit of supporting multi- 3282 ple techniques in a single protocol is that as new techniques are devel- 3283 oped they can easily be added to the protocol. This provides a path for 3284 the growth of Internet security services. ISAKMP supports both publicly 3285 or privately defined SAs, making it ideal for government, commercial, and 3286 private communications. 3288 ISAKMP provides the ability to establish SAs for multiple security proto- 3289 cols and applications. These protocols and applications may be session- 3290 oriented or sessionless. Having one SA establishment protocol that sup- 3291 ports multiple security protocols eliminates the need for multiple, nearly 3292 identical authentication, key exchange and SA establishment protocols when 3293 more than one security protocol is in use or desired. Just as IP has pro- 3294 vided the common networking layer for the Internet, a common security es- 3295 tablishment protocol is needed if security is to become a reality on the 3296 Internet. ISAKMP provides the common base that allows all other security 3297 protocols to interoperate. 3299 ISAKMP follows good security design principles. It is not coupled to 3300 other insecure transport protocols, therefore it is not vulnerable or 3301 weakened by attacks on other protocols. Also, when more secure transport 3302 protocols are developed, ISAKMP can be easily migrated to them. ISAKMP 3303 also provides protection against protocol related attacks. This protec- 3304 tion provides the assurance that the SAs and keys established are with the 3305 desired party and not with an attacker. 3307 ISAKMP also follows good protocol design principles. Protocol specific 3308 information only is in the protocol header, following the design prin- 3309 ciples of IPv6. The data transported by the protocol is separated into 3310 functional payloads. As the Internet grows and evolves, new payloads to 3311 support new security functionality can be added without modifying the en- 3312 tire protocol. 3314 A ISAKMP Security Association Attributes 3316 A.1 Background/Rationale 3318 As detailed in previous sections, ISAKMP is designed to provide a flexible 3319 and extensible framework for establishing and managing Security Associa- 3320 tions and cryptographic keys. The framework provided by ISAKMP consists 3321 of header and payload definitions, exchange types for guiding message and 3322 payload exchanges, and general processing guidelines. ISAKMP does not 3323 define the mechanisms that will be used to establish and manage Security 3324 Associations and cryptographic keys in an authenticated and confidential 3325 manner. The definition of mechanisms and their application is the purview 3326 of individual Domains of Interpretation (DOIs). 3328 This section describes the ISAKMP values for the Internet IP Security DOI, 3329 supported security protocols, and identification values for ISAKMP Phase 1 3330 negotiations. The Internet IP Security DOI is MANDATORY to implement for 3331 IP Security. [Oakley] and [IKE] describe, in detail, the mechanisms and 3332 their application for establishing and managing Security Associations and 3333 cryptographic keys for IP Security. 3335 A.2 Internet IP Security DOI Assigned Value 3337 As described in [IPDOI], the Internet IP Security DOI Assigned Number is 3338 one (1). 3340 A.3 Supported Security Protocols 3342 Values for supported security protocols are specified in the most recent 3343 ``Assigned Numbers'' RFC [STD-2]. Presented in the following table are 3344 the values for the security protocols supported by ISAKMP for the Internet 3345 IP Security DOI. 3347 _Protocol_Assigned_Value__ 3348 RESERVED 0 3349 ISAKMP 1 3351 All DOIs MUST reserve ISAKMP with a Protocol-ID of 1. All other security 3352 protocols within that DOI will be numbered accordingly. 3354 Security protocol values 2-15359 are reserved to IANA for future use. 3355 Values 15360-16383 are permanently reserved for private use amongst mu- 3356 tually consenting implementations. Such private use values are unlikely 3357 to be interoperable across different implementations. 3359 A.4 ISAKMP Identification Type Values 3361 The following table lists the assigned values for the Identification Type 3362 field found in the Identification payload during a generic Phase 1 ex- 3363 change, which is not for a specific protocol. 3365 ______ID_Type_______Value_ 3366 ID_IPV4_ADDR 0 3367 ID_IPV4_ADDR_SUBNET 1 3368 ID_IPV6_ADDR 2 3369 ID_IPV6_ADDR_SUBNET 3 3371 A.4.1 ID_IPV4_ADDR 3373 The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. 3375 A.4.2 ID_IPV4_ADDR_SUBNET 3377 The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, repre- 3378 sented by two four (4) octet values. The first value is an IPv4 address. 3379 The second is an IPv4 network mask. Note that ones (1s) in the network 3380 mask indicate that the corresponding bit in the address is fixed, while 3381 zeros (0s) indicate a "wildcard" bit. 3383 A.4.3 ID_IPV6_ADDR 3385 The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 address. 3387 A.4.4 ID_IPV6_ADDR_SUBNET 3389 The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, repre- 3390 sented by two sixteen (16) octet values. The first value is an IPv6 ad- 3391 dress. The second is an IPv6 network mask. Note that ones (1s) in the 3392 network mask indicate that the corresponding bit in the address is fixed, 3393 while zeros (0s) indicate a "wildcard" bit. 3395 B Defining a new Domain of Interpretation 3397 The Internet DOI may be sufficient to meet the security requirements of 3398 a large portion of the internet community. However, some groups may have 3399 a need to customize some aspect of a DOI, perhaps to add a different set 3400 of cryptographic algorithms, or perhaps because they want to make their 3401 security-relevant decisions based on something other than a host id or 3402 user id. Also, a particular group may have a need for a new exchange 3403 type, for example to support key management for multicast groups. 3405 This section discusses guidelines for defining a new DOI. The full speci- 3406 fication for the Internet DOI can be found in [IPDOI]. 3408 Defining a new DOI is likely to be a time-consuming process. If at all 3409 possible, it is recommended that the designer begin with an existing DOI 3410 and customize only the parts that are unacceptable. 3412 If a designer chooses to start from scratch, the following MUST be de- 3413 fined: 3415 o A ``situation'': the set of information that will be used to 3416 determine the required security services. 3418 o The set of security policies that must be supported. 3420 o A scheme for naming security-relevant information, including 3421 encryption algorithms, key exchange algorithms, etc. 3423 o A syntax for the specification of proposed security services, 3424 attributes, and certificate authorities. 3426 o The specific formats of the various payload contents. 3428 o Additional exchange types, if required. 3430 B.1 Situation 3432 The situation is the basis for deciding how to protect a communications 3433 channel. It must contain all of the data that will be used to determine 3434 the types and strengths of protections applied in an SA. For example, a 3435 US Department of Defense DOI would probably use unpublished algorithms 3436 and have additional special attributes to negotiate. These additional 3437 security attributes would be included in the situation. 3439 B.2 Security Policies 3441 Security policies define how various types of information must be cate- 3442 gorized and protected. The DOI must define the set of security policies 3443 supported, because both parties in a negotiation must trust that the other 3444 party understands a situation, and will protect information appropriately, 3445 both in transit and in storage. In a corporate setting, for example, both 3446 parties in a negotiation must agree to the meaning of the term ``propri- 3447 etary information'' before they can negotiate how to protect it. 3449 Note that including the required security policies in the DOI only speci- 3450 fies that the participating hosts understand and implement those policies 3451 in a full system context. 3453 B.3 Naming Schemes 3455 Any DOI must define a consistent way to name cryptographic algorithms, 3456 certificate authorities, etc. This can usually be done by using IANA nam- 3457 ing conventions, perhaps with some private extensions. 3459 B.4 Syntax for Specifying Security Services 3461 In addition to simply specifying how to name entities, the DOI must also 3462 specify the format for complete proposals of how to protect traffic under 3463 a given situation. 3465 B.5 Payload Specification 3467 The DOI must specify the format of each of the payload types. For several 3468 of the payload types, ISAKMP has included fields that would have to be 3469 present across all DOI (such as a certificate authority in the certificate 3470 payload, or a key exchange identifier in the key exchange payload). 3472 B.6 Defining new Exchange Types 3474 If the basic exchange types are inadequate to meet the requirements within 3475 a DOI, a designer can define up to thirteen extra exchange types per DOI. 3476 The designer creates a new exchange type by choosing an unused exchange 3477 type value, and defining a sequence of messages composed of strings of the 3478 ISAKMP payload types. 3480 Note that any new exchange types must be rigorously analyzed for vulner- 3481 abilities. Since this is an expensive and imprecise undertaking, a new 3482 exchange type should only be created when absolutely necessary. 3484 Security Considerations 3486 Cryptographic analysis techniques are improving at a steady pace. The 3487 continuing improvement in processing power makes once computationally pro- 3488 hibitive cryptographic attacks more realistic. New cryptographic algo- 3489 rithms and public key generation techniques are also being developed at a 3490 steady pace. New security services and mechanisms are being developed at 3491 an accelerated pace. A consistent method of choosing from a variety of 3492 security services and mechanisms and to exchange attributes required by 3493 the mechanisms is important to security in the complex structure of the 3494 Internet. However, a system that locks itself into a single cryptographic 3495 algorithm, key exchange technique, or security mechanism will become in- 3496 creasingly vulnerable as time passes. 3498 UDP is an unreliable datagram protocol and therefore its use in ISAKMP in- 3499 troduces a number of security considerations. Since UDP is unreliable, 3500 but a key management protocol must be reliable, the reliability is built 3501 into ISAKMP. While ISAKMP utilizes UDP as its transport mechanism, it 3502 doesn't rely on any UDP information (e.g. checksum, length) for its pro- 3503 cessing. 3505 Another issue that must be considered in the development of ISAKMP is the 3506 effect of firewalls on the protocol. Many firewalls filter out all UDP 3507 packets, making reliance on UDP questionable in certain environments. 3509 A number of very important security considerations are presented in 3510 [RFC-1825]. One bears repeating. Once a private session key is created, 3511 it must be safely stored. Failure to properly protect the private key 3512 from access both internal and external to the system completely nullifies 3513 any protection provided by the IP Security services. 3515 IANA Considerations 3517 This document contains many "magic" numbers to be maintained by the IANA. 3518 This section explains the criteria to be used by the IANA to assign addi- 3519 tional numbers in each of these lists. 3521 Domain of Interpretation 3523 The Domain of Interpretation (DOI) is a 32-bit field which identifies the 3524 domain under which the security association negotiation is taking place. 3525 Requests for assignments of new DOIs must be accompanied by a standards- 3526 track RFC which describes the specific domain. 3528 Supported Security Protocols 3530 ISAKMP is designed to provide security association negotiation and key 3531 management for many security protocols. Requests for identifiers for ad- 3532 ditional security protocols must be accompanied by a standards-track RFC 3533 which describes the security protocol and its relationship to ISAKMP. 3535 Acknowledgements 3537 Dan Harkins, Dave Carrel, and Derrell Piper of Cisco Systems provided 3538 design assistance with the protocol and coordination for the [IKE] and 3539 [IPDOI] documents. 3541 Hilarie Orman, via the Oakley key exchange protocol, has significantly 3542 influenced the design of ISAKMP. 3544 Marsha Gross, Bill Kutz, Mike Oehler, Pete Sell, and Ruth Taylor provided 3545 significant input and review to this document. 3547 Scott Carlson ported the TIS DNSSEC prototype to FreeBSD for use with the 3548 ISAKMP prototype. 3550 Jeff Turner and Steve Smalley contributed to the prototype development and 3551 integration with ESP and AH. 3553 Mike Oehler and Pete Sell performed interoperability testing with other 3554 ISAKMP implementors. 3556 Thanks to Carl Muckenhirn of SPARTA, Inc. for his assistance with LaTeX. 3558 References 3560 [ANSI] ANSI, X9.42: Public Key Cryptography for the Financial Services 3561 Industry -- Establishment of Symmetric Algorithm Keys Using 3562 Diffie-Hellman, Working Draft, April 19, 1996. 3564 [BC] Ballardie, A. and J. Crowcroft, Multicast-specific Security Threats 3565 and Countermeasures, Proceedings of 1995 ISOC Symposium on Networks 3566 & Distributed Systems Security, pp. 17-30, Internet Society, San 3567 Diego, CA, February 1995. 3569 [Berge] Berge, N.H., UNINETT PCA Policy Statements, Internet-Draft, work 3570 in progress, November, 1995. 3572 [CW87] Clark, D.D. and D.R. Wilson, A Comparison of Commercial and 3573 Military Computer Security Policies, Proceedings of the IEEE 3574 Symposium on Security & Privacy, Oakland, CA, 1987, pp. 184-193. 3576 [DNSSEC] D. Eastlake III, Domain Name System Protocol Security 3577 Extensions, Internet-Draft: draft-ietf-dnssec-secext2-03.txt, Work 3578 in Progress, January 1998. 3580 [DOW92] Diffie, W., M.Wiener, P. Van Oorschot, Authentication and 3581 Authenticated Key Exchanges, Designs, Codes, and Cryptography, 2, 3582 107-125, Kluwer Academic Publishers, 1992. 3584 [IAB] Bellovin, S., Report of the IAB Security Architecture Workshop, 3585 Internet-Draft: draft-iab-secwks-report-00.txt, Work in Progress, 3586 November 1997. 3588 [IKE] Harkins, D. and D. Carrel, The Internet Key Exchange (IKE), 3589 Internet-Draft: draft-ietf-ipsec-isakmp-oakley-06.txt, Work in 3590 Progress, February 1998. 3592 [IPDOI] Derrell Piper, The Internet IP Security Domain of Interpretation 3593 for ISAKMP, Internet-Draft: draft-ietf-ipsec-ipsec-doi-07.txt, Work 3594 in Progress, February 1998. 3596 [Karn] Karn, P. and B. Simpson, Photuris: Session Key Management 3597 Protocol, Internet-Draft: draft-simpson-photuris-15.txt, Work in 3598 Progress, July 1997. 3600 [Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August 10, 3601 1994. 3603 [Oakley] H. K. Orman, The Oakley Key Determination Protocol, Internet- 3604 Draft: draft-ietf-ipsec-oakley-02.txt, Work in Progress, July 1997. 3606 [RFC-1422] Steve Kent, Privacy Enhancement for Internet Electronic Mail: 3607 Part II: Certificate-Based Key Management, RFC-1422, February 1993. 3609 [RFC-1825] Randall Atkinson, Security Architecture for the Internet 3610 Protocol, RFC-1825, August, 1995. 3612 [RFC-1949] A. Ballardie, Scalable Multicast Key Distribution, RFC-1949, 3613 May 1996. 3615 [RFC-2093] Harney, H. and C. Muckenhirn, Group Key Management Protocol 3616 (GKMP) Specification, SPARTA, Inc., RFC-2093, July 1997. 3618 [RFC-2094] Harney, H. and C. Muckenhirn, Group Key Management Protocol 3619 (GKMP) Architecture, SPARTA, Inc., RFC-2094, July 1997. 3621 [RFC-2119] S. Bradner, Key Words for use in RFCs to Indicate Requirement 3622 Levels, Harvard University, RFC-2119, March 1997. 3624 [Schneier] Bruce Schneier, Applied Cryptography - Protocols, Algorithms, 3625 and Source Code in C (Second Edition), John Wiley & Sons, Inc., 3626 1996. 3628 [STD-2] Reynolds, J. and J. Postel, Assigned Numbers, STD 2, October, 3629 1994. 3631 Addresses of Authors 3633 The authors can be contacted at: 3635 Douglas Maughan 3636 Phone: 301-688-0847 3637 E-mail:wdm@tycho.ncsc.mil 3639 Mark Schneider 3640 Phone: 301-688-0851 3641 E-mail:mss@tycho.ncsc.mil 3643 National Security Agency 3644 ATTN: R23 3645 9800 Savage Road 3646 Ft. Meade, MD. 20755-6000 3648 Mark Schertler 3649 Terisa Systems, Inc. 3650 4984 El Camino Real 3651 Los Altos, CA. 94022 3652 Phone: 650-919-1773 3653 E-mail:mjs@terisa.com 3655 Jeff Turner 3656 RABA Technologies, Inc. 3657 10500 Little Patuxent Parkway 3658 Columbia, MD. 21044 3659 Phone: 410-715-9399 3660 E-mail:jeff.turner@raba.com