idnits 2.17.1 draft-ietf-ipsec-isakmp-03.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-23) 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-03.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-ipsec-isakmp-03.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-ipsec-isakmp-03.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-03.txt,', but the file name used is 'draft-ietf-ipsec-isakmp-03' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 540 instances of too long lines in the document, the longest one being 16 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 223: '...ficates. The CA MUST define the namin...' RFC 2119 keyword, line 240: '...g authentication MUST be provided on I...' RFC 2119 keyword, line 249: '...nature algorithm MUST be used within I...' RFC 2119 keyword, line 311: '...A) establishment MUST be part of the k...' RFC 2119 keyword, line 331: '...tributes that MUST be implemented to p...' (51 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 21, 1995) is 10381 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC-1155' is defined on line 2296, but no explicit reference was found in the text == Unused Reference: 'RFC-1212' is defined on line 2300, but no explicit reference was found in the text == Unused Reference: 'RFC-1213' is defined on line 2303, but no explicit reference was found in the text == Unused Reference: 'Secu' is defined on line 2313, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ANSI94' -- Possible downref: Non-RFC (?) normative reference: ref. 'DOW92' -- Possible downref: Non-RFC (?) normative reference: ref. 'Berg' -- Possible downref: Non-RFC (?) normative reference: ref. 'EK94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Karn95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kent94' ** Downref: Normative reference to an Historic RFC: RFC 1422 ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) -- Possible downref: Non-RFC (?) normative reference: ref. 'Secu' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schn94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Spar94a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Spar94b' Summary: 16 errors (**), 1 flaw (~~), 8 warnings (==), 12 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 National Security Agency 3 draft-ietf-ipsec-isakmp-03.txt, .ps November 21, 1995 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 establish- 31 ment and management of security associations and their appropriate secu- 32 rity attributes. Additionally, this document proposes a method for key 33 management to support IPSP and IPv6. Publication of this document does 34 not imply acceptance of the concepts discussed by the IPSEC Working Group. 35 Comments are solicited and should be addressed to the authors and/or the 36 working group mailing list at ipsec@ans.net. 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 5 59 1.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 1.1.1Certificate Authorities . . . . . . . . . . . . . . . . . . . 6 61 1.1.2Entity Naming . . . . . . . . . . . . . . . . . . . . . . . . 7 62 1.1.3ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 7 63 1.2 Security Associations and Management . . . . . . . . . . . . . . 8 64 1.2.1Security Associations and Registration . . . . . . . . . . . . 8 65 1.2.2ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 8 66 1.3 Public Key Cryptography . . . . . . . . . . . . . . . . . . . . . 9 67 1.3.1Key Exchange Properties . . . . . . . . . . . . . . . . . . . 9 68 1.3.2ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 11 69 1.4 ISAKMP Protection . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1.4.1Anti-Clogging (Denial of Service) . . . . . . . . . . . . . . 11 71 1.4.2Connection Hijacking . . . . . . . . . . . . . . . . . . . . . 11 72 1.4.3Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . 11 73 1.5 Multicast Communications . . . . . . . . . . . . . . . . . . . . 12 75 2 Description of the Protocol 12 76 2.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 13 77 2.1.1General Message Processing . . . . . . . . . . . . . . . . . . 15 78 2.2 ISAKMP Packet Exchanges . . . . . . . . . . . . . . . . . . . . . 17 79 2.2.1Base Exchange . . . . . . . . . . . . . . . . . . . . . . . . 17 80 2.2.2Identity Protection Exchange . . . . . . . . . . . . . . . . . 17 81 2.2.3Authentication Only Exchange . . . . . . . . . . . . . . . . . 18 82 2.3 ISAKMP Details . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 2.3.1Security Association Attributes . . . . . . . . . . . . . . . 19 84 2.3.2Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 21 85 2.3.3RESERVED Fields . . . . . . . . . . . . . . . . . . . . . . . 21 86 2.3.4Anti-Clogging Token (``Cookie'') Creation . . . . . . . . . . 21 87 2.3.5SA Flags Field . . . . . . . . . . . . . . . . . . . . . . . . 22 88 3 Security Association Establishment 22 89 3.1 Security Association Initialization . . . . . . . . . . . . . . . 22 90 3.1.1SA Initialization Procedures . . . . . . . . . . . . . . . . . 24 91 3.2 Authentication and Key Exchange . . . . . . . . . . . . . . . . . 25 92 3.2.1Authentication Payload Format . . . . . . . . . . . . . . . . 26 93 3.2.2Key Exchange Payload Format . . . . . . . . . . . . . . . . . 28 94 3.2.3Authentication and Key Exchange Procedures . . . . . . . . . . 29 95 3.3 Security Association Negotiation . . . . . . . . . . . . . . . . 30 96 3.3.1SA Negotiation Procedures . . . . . . . . . . . . . . . . . . 31 97 3.4 SA Negotiation Conclusion . . . . . . . . . . . . . . . . . . . . 34 98 3.4.1SA Negotiation Conclusion Procedures . . . . . . . . . . . . . 34 100 4 Security Association Modification 36 101 4.1 Modification Procedures . . . . . . . . . . . . . . . . . . . . . 36 102 5 Security Association Deletion 36 103 5.1 Deletion Procedures . . . . . . . . . . . . . . . . . . . . . . . 37 105 6 Notification Message 39 106 6.1 Notification Procedures . . . . . . . . . . . . . . . . . . . . . 40 108 7 Conclusions 41 110 A ISAKMP Scenarios 43 111 A.1 Initial ISAKMP Daemon Scenerio . . . . . . . . . . . . . . . . . 43 112 A.2 Virtual Private Network Scenario . . . . . . . . . . . . . . . . 44 113 B Security Association Attributes 47 115 C Security Association Examples 51 116 C.1 ISAKMP SA Definition . . . . . . . . . . . . . . . . . . . . . . 51 117 C.1.1ISAKMP SA Examples . . . . . . . . . . . . . . . . . . . . . . 52 118 C.2 ESP SA and AH SA Definitions . . . . . . . . . . . . . . . . . . 53 119 C.2.1ESP and AH SA Examples . . . . . . . . . . . . . . . . . . . . 54 120 C.2.2Fortezza SA Examples . . . . . . . . . . . . . . . . . . . . . 55 122 1 Introduction 124 This document describes an Internet Security Association and Key Manage- 125 ment Protocol (ISAKMP). ISAKMP combines the security concepts of authen- 126 tication, key management, and security associations to establish the re- 127 quired security for government, commercial, and private communications on 128 the Internet. ISAKMP extends the assertion in [DOW92] that authentica- 129 tion and key exchanges must be combined for better security to include se- 130 curity association exchanges. The security required for communications 131 depends on the individual network configurations and environments. Orga- 132 nizations are setting up Virtual Private Networks (VPN) that will require 133 one set of security functions for communications within the VPN and possi- 134 bly many different security functions for communications outside the VPN 135 to support geographically separate organizational components, customers, 136 suppliers, sub-contractors (with their own VPNs), government, and others. 137 Departments within large organizations may require a number of security 138 associations to separate and protect data (e.g. personnel data, company 139 proprietary data, medical) on internal networks and other security associ- 140 ations to communicate inter-department. Nomadic users wanting to ``phone 141 home'' represent another set of security requirements. These requirements 142 must be tempered with bandwidth challenges. Smaller groups of people may 143 meet their security requirements by setting up ``Webs of Trust''. ISAKMP 144 exchanges provide these assorted networking communities the ability to 145 present peers with the security functionality it supports in an authen- 146 ticated and protected manner for agreement upon a common interoperable se- 147 curity association. 149 Security associations must support different encryption algorithms, au- 150 thentication mechanisms, and key establishment algorithms for other secu- 151 rity protocols, as well as IP Security. Security associations must also 152 support host-oriented certificates for lower layer protocols and user- 153 oriented certificates for higher level protocols. Algorithm and mecha- 154 nism independence is required in applications such as e-mail, remote lo- 155 gin, and file transfer, as well as in session oriented protocols, routing 156 protocols, and link layer protocols. ISAKMP provides a common security 157 association and key establishment protocol for this wide range of security 158 protocols, applications, security requirements, and network environments. 160 ISAKMP is not bound to any specific cryptographic algorithm, key gener- 161 ation technique, or security mechanism. This flexibility is beneficial 162 for a number of reasons. First, it supports the dynamic communications 163 environment described above. Second, the independence from specific secu- 164 rity mechanisms and algorithms provides a forward migration path to better 165 mechanisms and algorithms. When improved security mechanisms are devel- 166 oped or new attacks against current encryption algorithms, authentica- 167 tion mechanisms and key exchanges are discovered, ISAKMP will allow the 168 updating of the algorithms and mechanisms without having to develop a com- 169 pletely new KMP or patch the current one. 171 ISAKMP has basic requirements for its authentication and key exchanges 172 components. These requirements guard against denial of service, replay / 173 reflection, man-in-the-middle, and connection hijacking attacks. This is 174 important because these are the types of attacks that are targeted against 175 protocols. Complete Security Association (SA) support, which provides 176 mechanism and algorithm independence, and protection from protocol threats 177 are the strengths of ISAKMP. 179 1.1 Authentication 181 A very important step in establishing secure network communications is au- 182 thentication of the entity at the other end of the communication. Many 183 authentication mechanisms are available. Authentication mechanisms fall 184 into two catagories of strength - weak and strong. Passwords are an exam- 185 ple of a mechanism that provides weak authentication. Reasons for this 186 include the fact that most users pick easy to guess passwords and when 187 used over an unprotected network are easily read by network sniffers. 188 Digital signatures, such as the Digital Signature Standard (DSS) and the 189 Rivest-Shamir-Adleman (RSA) signature, are public key based strong authen- 190 tication mechanisms. When using digital signatures each entity requires a 191 public and a private key. Certificates are an essential part of a digital 192 signature authentication mechanism. Certificates bind a specific enti- 193 ties identity (be it host, network, user, or application) to its public 194 keys and possibly other security-related information such as privileges, 195 clearances, and compartments. Authentication based on digital signatures 196 requires a trusted third party or certificate authority to create, sign 197 and properly distribute certificates. For more detailed information on 198 digital signatures, such as DSS and RSA, and certificates see [Schn94]. 200 1.1.1 Certificate Authorities 202 Certificates require an infrastructure for generation, verification, man- 203 agement and distribution. The Internet Policy Registration Authority 204 (IPRA) [RFC-1422] has been established to direct this infrastructure for 205 the IETF. The IPRA certifies Policy Certification Authorities (PCA). PCAs 206 control Certificate Authorities (CA) which certify users and subordinate 207 entities. Current certificate related work includes the Domain Name Sys- 208 tem (DNS) Security Extensions [EK94] which will provide signed entity keys 209 in the DNS. The Public Key Infrastucture (PKIX) working group is speci- 210 fying an Internet profile for X.509 certificates. There is also work go- 211 ing on in industry to develop X.500 Directory Services which would provide 212 X.509 certificates to users. The U.S. Post Office is developing a (CA) 213 hierarchy. The NIST Public Key Infrastructure Working Group has also been 214 doing work in this area. The DOD Multi Level Information System Security 215 Initiative (MISSI) program has begun deploying a certificate infrastruc- 216 ture for the U.S. Government. Alternatively, if no infrastructure exists, 217 the PGP Web of Trust certificates can be used to provide user authentica- 218 tion and privacy in a community of users who know and trust each other. 220 1.1.2 Entity Naming 222 An entity's name is its identity and is bound to its public keys in cer- 223 tificates. The CA MUST define the naming semantics for the certificates 224 it issues. See the UNINETT PCA Policy Statements [Berg] for an example 225 of how a CA defines its naming policy. When the certificate is verified, 226 the name is verified and that name will have meaning within the realm of 227 that CA. An example is the DNS security extensions which make DNS servers 228 CAs for the zones and nodes they serve. Resource records are provided for 229 public keys and signatures on those keys. The names associatied with the 230 keys are IP addresses and domain names which have meaning to entities ac- 231 cessing the DNS for this information. A Web of Trust is another example. 232 When webs of trust are set up, names are bound with the public keys. In 233 PGP the name is usaully the entities e-mail address which has meaning to 234 those, and only those, who understand e-mail (Do MCI and AOL e-mail ad- 235 dresses tell the casual e-mailer anything about identity?). Another web 236 could use an entirely different naming scheme. 238 1.1.3 ISAKMP Requirements 240 Strong authentication MUST be provided on ISAKMP exchanges. Without being 241 able to authenticate the entity at the other end, the Security Association 242 (SA) and session key established are suspect. Without authentication you 243 are unable to trust an entity's identification, this makes access control 244 questionable. Encryption (e.g. ESP) and integrity (e.g. AH) will pro- 245 tect subsequent communications from passive eavesdroppers, but the SA and 246 key may be established with an adversary who performed an active man-in- 247 the-middle attack and is now stealing all your personnal data. 249 A digital signature algorithm MUST be used within ISAKMP's authentication 250 component. However, ISAKMP does not mandate a specific mechanism. ISAKMP 251 allows an entity initiating communications to indicate which signature al- 252 gorithms it supports. After selection of a common algorithm, the protocol 253 provides the messages required to support the actual authentication ex- 254 change. As an example, if the DSA is selected as the signature algorithm, 255 then the protocol provides a facility for identification of different cer- 256 tificate authorities, certificate types (e.g. X.509v1 certificates, PKCS 257 #7), and the exchange of the certificates identified. 259 ISAKMP utilizes digital signatures, based on public cryptography, for au- 260 thentication. There are other strong authentication systems available, 261 which could be specified as additional optional authentication mechanisms 262 for ISAKMP. Some of these authentication systems rely on a trusted third 263 party called a key distribution center (KDC) to distribute secret session 264 keys. An example is Kerberos, where the trusted third party is the Ker- 265 beros server, which holds secret keys for all clients and servers within 266 it's network domain. A clients proof it holds it's secret key provides 267 its authenticaton to a server. 269 The ISAKMP specification does not specify the protocol for communicating 270 with the trusted third parties (TTP) or certificate directory services. 271 These protocols are defined by the TTP and directory service themselves 272 and are outside the scope of this specification. 274 1.2 Security Associations and Management 276 A Security Association (SA) is a relationship between two or more entities 277 that describes how the entities will utilize security services to communi- 278 cate securely. This relationship is represented by a set of information 279 that can be considered a contract between the entities. The information 280 must be agreed upon and shared between all the entities. Sometimes the 281 information alone is referred to as an SA, but this is just a physical in- 282 stantiation of the existing relationship. The existence of this relation- 283 ship, represented by the information, is what provides the agreed upon se- 284 curity information needed by entities to securely interoperate. All enti- 285 ties must adhere to the SA for secure communications to be possible. When 286 accessing SA attributes, entities use a pointer or identifier refered to 287 as the Security Parameter Index (SPI). 289 1.2.1 Security Associations and Registration 291 The SA attributes required and recommended for the IP Security (AH, ESP) 292 are defined in [RFC-1825]. The attributes specified for an IP Security SA 293 include, but are not limited to, authentication mechanism, cryptographic 294 algorithm, algorithm mode, key length, and Initialization Vector (IV). 295 Other protocols that provide algorithm and mechanism independent security 296 MUST define their SA attributes requirements. The separation of ISAKMP 297 from a specific SA definition is important to ensure ISAKMP can establish 298 SAs for all possible security protocols and applications. 300 NOTE: See Appendix B for a discussion of SA attributes that should be con- 301 sidered when defining a security protocol or application. 303 In order to facilitate easy identification of specific attributes (e.g. 304 a specific encryption algorithm) among different network entites the at- 305 tributes must be assigned identifiers and these identifiers must be reg- 306 istered by a central authority. The Internet Assigned Numbers Authority 307 (IANA) provides this function for the Internet. 309 1.2.2 ISAKMP Requirements 311 Security Association (SA) establishment MUST be part of the key manage- 312 ment protocol defined for IP based networks. The SA concept is required 313 to support security protocols in a diverse and dynamic networking envi- 314 ronment. Just as authentication and key exchange must be linked to pro- 315 vide assurance that the key is established with the authenticated party 316 [DOW92], SA establishment must be linked with the authentication and the 317 key exchange protocol. 319 ISAKMP provides the protocol exchanges to establish a security association 320 between entities. First, an initial protocol exchange allows a basic set 321 of security attributes to be agreed upon. This basic set provides protec- 322 tion for subsequent ISAKMP exchanges. It also indicates the authentica- 323 tion method and key exchange that will be performed as part of the ISAKMP 324 protocol. If a basic set of security attributes is already in place on 325 the communicating entities the initial ISAKMP exchange may be skipped and 326 the key and authentication exchanges issued directly. After the basic set 327 of security attributes has been agreed upon, initial identity authenti- 328 cated, and required keys generated, another security attribute exchange 329 takes place to establish the complete SA which will be used for subsequent 330 communications by the entity that invoked ISAKMP. The basic set of SA at- 331 tributes that MUST be implemented to provide ISAKMP interoperability are 332 defined in Appendix C. *These atributes will be moved to a separate docu- 333 ment to maintain separation of protocol and attributes.* 335 1.3 Public Key Cryptography 337 Public key cryptography is the most flexible, scalable, and efficient way 338 for users to obtain the shared secrets and session keys needed to support 339 the large number of ways Internet users will interoperate. Many key gen- 340 eration algorithms, that have different properties, are available to users 341 (see [DOW92] and [ANSI94]). Properties of key exchange protocols include 342 the key establishment method, authentication, symmetry, perfect forward 343 secrecy, and back traffic protection. 345 1.3.1 Key Exchange Properties 347 Key Establishment (Key Generation / Key Transport) The two common methods 348 of using public key cryptography for key establishment are key transport 349 and key generation. An example of key transport is the use of the RSA al- 350 gorithm to encrypt a randomly generated session key (for encrypting subse- 351 quent communications) with the recipient's public key. The encrypted ran- 352 dom key is then sent to the recipient, who decrypts it using his private 353 key. At this point both sides have the same session key, however it was 354 created based on input from only one side of the communications. The ben- 355 efit of the key transport method is that it has less computational over- 356 head then the following method. The Diffie-Hellman (D-H) algorithm illus- 357 trates key generation using public key cryptography. The D-H algorithm is 358 begun by two users exchanging public information. Each user then mathe- 359 matically combines the other's public information along with their own se- 360 cret information to compute a shared secret value. This secret value can 361 be used as a session key or as a key encryption key for encrypting a ran- 362 domly generated session key. This method generates a session key based on 363 public and secret information held by both users. The benefit of the D-H 364 algorithm is that the key used for encrypting messages is based on infor- 365 mation held by both users. Assuming checks for weak values neither party 366 can force the session key to a predetermined value. Detailed descrip- 367 tions of these algorithms can be found in [Schn94]. There are a number 368 of variations on these two key generation schemes and these variations do 369 not necessarily interoperate. 371 Key Exchange Authentication Key exchanges may be authenticated during the 372 protocol or after protocol completion. Authentication of the key exchange 373 during the protocol is provide when each party provides proof it has the 374 secret session key before the end of the protocol. Proof can be provided 375 by encrypting known data in the secret session key during the protocol ex- 376 change. Authentication after the protocol must occur in subsequent commu- 377 nications. Authentication during the protocol is preferred so subsequent 378 communications are not initiated if the secret session key is not estab- 379 lished with the desired party. 381 Key Exchange Symmetry A key exchange provides symmetry if either party can 382 initiate the exchange and exchanged messages can cross in transit with- 383 out effecting the key that is generated. This is desirable so that com- 384 putation of the keys does not require either party to know who initiated 385 the exchange. While key exchange symmetry is desirable, symmetry in the 386 entire KMP may provide a vulnerablity to reflection attacks. The entire 387 ISAKMP SA establishment is asymetrical. 389 Back Traffic Protection / Perfect Forward Secrecy Perfect forward secrecy 390 is provided by a key exchange protocol if disclosure of long-term cryp- 391 tographic keying material (e.g. public signature keys) does not compro- 392 mise previously generated keys. Back traffic protection is provided by 393 the independent generation of each key such that subsequent keys are not 394 dependent on any previous key. There is a subtle difference. Past ses- 395 sion keys will NOT be obtainable is the long-term key is compromised in 396 perfect forward secrecy; Past session keys will NOT be obtainable if the 397 current session key is compromised in back traffic protecion. 399 The difficulty of numerical factoring of large numbers has proven that 400 cryptographic keys can protect information for a considerable length of 401 time. However, this is based on the assumption that keys used for protec- 402 tion of communications are destroyed after use and not kept for any rea- 403 son. 405 1.3.2 ISAKMP Requirements 407 An authenticate key exchange MUST be supported by ISAKMP. Users SHOULD 408 choose additional key establishment algorithms based on their require- 409 ments. ISAKMP does not specify a specific key exchange. Requirements 410 that should be evaluated when choosing a key establishment algorithm in- 411 clude establishment method (generation vs. transport), perfect forward 412 secrecy, back traffic protection, computational overhead, key escrow, and 413 key strength. Based on user requirements, ISAKMP allows an entity initi- 414 ating communications to indicate which key exchanges it supports. After 415 selection of a key exchange, the protocol provides the messages required 416 to support the actual key establishment. 418 1.4 ISAKMP Protection 420 1.4.1 Anti-Clogging (Denial of Service) 422 Of the numerous security services available, protection against denial 423 of service always seems to be one of the most difficult to address. Phil 424 Karn in his Internet-Draft [Karn95] has introduced a mechanism to provide 425 a measure of denial of service protection through the use of a ``cookie'' 426 exchange. This anti-clogging token (ACT) is aimed at protecting the com- 427 puting resources from attack without spending excessive CPU resources to 428 determine its authenticity. As described in [Karn95], an exchange prior 429 to CPU-intensive public key operations can thwart some denial of service 430 attempts (e.g. simple flooding with bogus IP source addresses). As noted 431 by Karn, absolute protection against denial of service is impossible, but 432 this anti-clogging token provides a technique for making it easier to han- 433 dle. 435 1.4.2 Connection Hijacking 437 ISAKMP prevents connection hijacking by linking the authentication, key 438 exchange and security association exchanges. This linking prevent an at- 439 tacker from allowing the authentication to complete and then jumping in 440 and impersonating one entity to the other during the key and security as- 441 sociation exchanges. 443 1.4.3 Man-in-the-Middle Attacks 445 Man-in-the-Middle attacks include interception, insertion, deletion, and 446 modification of messages, reflecting messages back at the sender, re- 447 playing old messages and redirecting messages. ISAKMP features prevent 448 these types of attacks from being successful. The linking of the ISAKMP 449 exchanges prevents the insertion of messages in the protocol exchange. 450 The ISAKMP protocol state machine is defined so deleted messages will not 451 cause a partial SA to be created, the state machine will clear all state 452 and return to idle. The state machine also prevents reflection of a mes- 453 sage from causing harm. The requirement for a new cookie with time vari- 454 ant material for each new SA establishment prevents attacks that involve 455 replaying old messages. The ISAKMP strong authentication requirement pre- 456 vents an SA from being established with other then the intended party. 457 Messages may be redirected to a different destination or modified but this 458 will be detected and an SA will not be established. The ISAKMP specifica- 459 tion defines where abnormal processing has occurred and recommends notify- 460 ing the appropriate party of this abnormality. 462 1.5 Multicast Communications 464 While future Internet communications will increasingly be of a multicast 465 nature, this document is presenting a security association and key man- 466 agement protocol from the unicast point of view. It is expected that mul- 467 ticast communications will require the same security services as unicast 468 communications and may introduce the need for additional security ser- 469 vices. The issues of distributing SPIs for multicast traffic are pre- 470 sented in [RFC-1825]. Upon agreement and implementation of a security 471 association protocol for the Internet unicast environment, we fully intend 472 to examine any additional security requirements for multicast communica- 473 tions. For an introduction to the issues related to multicast security 474 consult the Internet Drafts, [Spar94a] and [Spar94b], describing Sparta's 475 research in this area. 477 2 Description of the Protocol 479 The Internet Security Association and Key Management Protocol (ISAKMP) de- 480 fines procedures and packet formats to establish, negotiate, modify and 481 delete Security Associations (SA). SAs contain all the information re- 482 quired for execution of IP security services, such as the IP Authentica- 483 tion Header (AH), the IP Encapsulating Security Payload (ESP), and routing 484 protocol authentication mechanisms. ISAKMP includes packet formats for 485 exchanging key generation and authentication data. These formats provide 486 a consistent method of transferring key and authentication data that is 487 independent of the key generation technique, encryption algorithm or au- 488 thentication mechanism. 490 The following sections contain the details of ISAKMP. Sections 2.1 through 491 2.3 cover details that are pertinent to the entire protocol. Sections 3 492 through 6 define the establishment, modification, and deletion services, 493 defined as exchanges, offered by the protocol. The appendices provide 494 examples of SAs and key exchanges. 496 2.1 ISAKMP Header Format 498 ISAKMP has a fixed header format (shown in Figure 1) followed by a vari- 499 able length payload, optional digital signature, and optional padding. A 500 fixed header simplifies parsing, providing the benefit of protocol parsing 501 software that is less complex and easier to implement. The fixed header 502 contains the information required by the protocol to maintain state, pro- 503 cess payloads and prevent attacks (e.g. denial of service and replay). 504 Based on the message type, each header is followed by a payload specific 505 to the message type. The payload for each message is defined in sections 506 3 through 6. Following the payload portion of the ISAKMP packet is a dig- 507 ital signature. This field is dependent on the negotiation of Security 508 Association attributes and may not be present. 510 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 ! Message Type ! Exch ! Vers ! Length ! 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 ! Security Parameter Index (SPI) ! 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 ! ! 518 ~ Initiator-Cookie ~ 519 ! ! 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 ! ! 522 ~ Responder-Cookie ~ 523 ! ! 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 ! ! 526 ~ Payload ~ 527 ! ! 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 ! ! 530 ~ Digital Signature ~ 531 ! ! 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 ! ! 534 ~ Padding ~ 535 ! ! 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Figure 1: ISAKMP Header Format 540 o Message Type (1 octet) - Indicates the type of message. A suffix of 541 REQ denotes a Request message type and an RESP suffix denotes a 542 Response message type. The format and processing for each message is 543 defined in sections 3 through 6. 545 __ISAKMP_Message__Message_Type_ 546 RESERVED 0 547 ISA_INIT_REQ 1 548 ISA_INIT_RESP 2 549 ISA_KE_REQ 3 550 ISA_KE_RESP 4 551 ISA_AUTH_REQ 5 552 ISA_AUTH_RESP 6 553 ISA_AUTH&KE_REQ 7 554 ISA_AUTH&KE_RESP 8 555 ISA_NEG_REQ 9 556 ISA_NEG_RESP 10 557 ISA_MODIFY_REQ 11 558 ISA_MODIFY_RESP 12 559 ISA_NOTIFY 13 560 ISA_DELETE 14 561 ISA_COMMIT 15 562 IANA Use 16-127 563 Future Use 128-255 565 o Exchange (4 bits) - indicates the type of exchange, see section 2.2 566 for a description of the Message Types exchanged in each of these 567 Exchange Types. 569 ___ISAKMP_Exchange___Exchange_Type__ 570 RESERVED 0 571 Base 1 572 Identity Protection 2 573 Authentication Only 3 574 Future Use 4 - 15 576 o Version (4 bits) - indicates the version of the ISAKMP protocol in 577 use. 579 o Length (2 octets) - Length of total message (header + payload) in 580 octets. 582 o SPI (4 octets) - Security Parameter Index. The receiving entity's 583 SPI is always in this field, except for the ISA_INIT packets. The 584 ISA_INIT packets contain the SPI the initiator expects to receive in 585 all subsequent packets. 587 o Initiator Cookie (16 octets) - Cookie of entity that initiated SA 588 establishment, SA modify or SA delete. 590 o Responder Cookie (16 octets) - Cookie of entity that is responding to 591 an SA establishment, SA modify or SA delete request. 593 o Payload (variable) - The format of the payload is based on the 594 message type. These are defined in sections 3 through 6. 596 o Signature - The digital signature of the initiator of the ISAKMP 597 message. This field will not be included on all packets and will be 598 determined by the negotiated SA attributes. 600 o Padding - This is an optional field that may be added depending on 601 the type of encryption algorithm. If the encryption mechanism is 602 based on block encryption, then this field may be necessary to ensure 603 the packet is a specific size. 605 2.1.1 General Message Processing 607 Every ISAKMP message has basic processing applied to insure protocol re- 608 liability, and to minimize threats, such as denial of service and replay 609 attacks. 611 When transmitting an ISAKMP packet, the transmitting entity (initiator or 612 responder) does the following: 614 1. Sets a timer and initializes a retry counter. 616 2. If the timer expires, the ISAKMP packet is resent and the retry 617 counter is decremented. 619 3. If the retry counter reaches zero (0), the event, RETRY LIMIT 620 REACHED, is logged in the appropriate system audit file. 622 4. The ISAKMP protocol machine clears all states and returns to IDLE. 624 When an ISAKMP packet is received, the receiving entity (initiator or re- 625 sponder) does the following: 627 1. Verifies the Initiator and Responder ``cookies''. If the cookie 628 validation fails, the message is discarded and the following actions 629 are taken: 631 (a) The event, INVALID COOKIE, is logged in the appropriate system 632 audit file. 634 (b) No response is sent to the initiating entity. This will cause 635 the transmission timer of the initiating entity to expire and 636 force retransmission of the message. 638 2. Check the Message Type field to confirm it is valid. If the Message 639 Type field validation fails, the message is discarded and the 640 following actions are taken: 642 (a) The event, INVALID MESSAGE TYPE, is logged in the appropriate 643 system audit file. 645 (b) No response is sent to the initiating entity. This will cause 646 the transmission timer of the initiating entity to expire and 647 force retransmission of the message. 649 3. Check the Exchange field to confirm it is valid for the Message Type 650 requested. If the Exchange field validation fails, the message is 651 discarded and the following actions are taken: 653 (a) The event, INVALID EXCHANGE TYPE, is logged in the appropriate 654 system audit file. 656 (b) No response is sent to the initiating entity. This will cause 657 the transmission timer of the initiating entity to expire and 658 force retransmission of the message. 660 4. Check SPI to ensure it is valid for the Message Type and Exchange 661 being performed. If the SPI validation fails, the message is 662 discarded and the following actions are taken: 664 (a) The event, INVALID SPI, is logged in the appropriate system audit 665 file. 667 (b) No response is sent to the initiating entity. This will cause 668 the transmission timer of the initiating entity to expire and 669 force retransmission of the message. 671 5. The message payload is processed. Individual message processing is 672 described in sections 3 through 6. Depending on the Message Type, a 673 valid message results in a response being sent to the transmitting 674 entity (message originator). The procedures for sending these 675 responses are also outline in sections 3 through 6. 677 2.2 ISAKMP Packet Exchanges 679 The Exchange field in the ISAKMP header currently has three values de- 680 fined: the base exchange, the identity protection exchange, and the au- 681 thentication only exchange. These exchanges define the flow of the ISAKMP 682 packets during SA establishment. The diagrams in 2.2.1, 2.2.2, and 2.2.3 683 show the packet exchange ordering for each exchange type and provide basic 684 notes describing what has happened after each packet exchange. 686 2.2.1 Base Exchange 688 Sections 3.1 through 3.3 describe the three basic phases: SA Initial- 689 ization, Key Exchange and Authentication, and SA Negotiation, that com- 690 prise the base exchange. The base exchange contains the minimum number of 691 packet exchanges in order to reduce latency associated with SA establish- 692 ment. 694 Base Exchange 695 ____Initiator____Direction_____Responder____ Note 696 ISA_INIT_REQ => 697 <= ISA_INIT_RESP 698 Basic SA selected 699 ISA_AUTH&KE_REQ => 700 <= ISA_AUTH&KE_RESP 701 Identity Verified 702 Key Generated 703 Encryption Begun 704 ISA_NEG_REQ => 705 <= ISA_NEG_RESP SA Completed 706 (optional) ISA_COMMIT => 708 2.2.2 Identity Protection Exchange 710 The identity protection exchange starts and ends the same as the base ex- 711 change, but separates the key exchange payload and the authentication pay- 712 loads into separate packets. In this exchange, the key exchange is trans- 713 mitted first followed by the strong authentication exchange. The benefit 714 of this exchange is the ability to communicate with a person without dis- 715 closing either party's identity to passive attackers on the network. 717 The ISA_KE_REQ and ISA_KE_RESP packets used for the key exchange portion of 718 this exchange contain an ISAKMP header followed by the key exchange pay- 719 load. The ISA_AUTH_REQ and ISA_AUTH_RESP packet used for the authentication 720 portion of this exchange contain an ISAKMP header followed by the authen- 721 tication payload. 723 Identity Protection Exchange 724 __Initiator___Direction___Responder___ Note 725 ISA_INIT_REQ => 726 <= ISA_INIT_RESP 727 Basic SA selected 728 ISA_KE_REQ => 729 <= ISA_KE_RESP 730 Key Generated 731 Encryption Begun 732 ISA_AUTH_REQ => 733 <= ISA_AUTH_RESP 734 Identity Verified 735 ISA_NEG_REQ => 736 <= ISA_NEG_RESP SA Completed 737 (optional) ISA_COMMIT => 739 2.2.3 Authentication Only Exchange 741 The authentication only exchange starts and ends the same as the base ex- 742 change. In this exchange, the authentication information is the only in- 743 formation transmitted. The benefit of this exchange is the ability to 744 perform only an authentication exchange without the computational expense 745 of computing keys. Using this exchange, none of the transmitted informa- 746 tion will be encrypted. 748 The ISA_AUTH_REQ and ISA_AUTH_RESP packet used for the authentication only 749 exchange contain an ISAKMP header followed by the authentication payload. 751 Identity Protection Exchange 752 __Initiator___Direction___Responder___ Note 753 ISA_INIT_REQ => 754 <= ISA_INIT_RESP 755 Basic SA selected 756 ISA_AUTH_REQ => 757 <= ISA_AUTH_RESP 758 Identity Verified 759 ISA_NEG_REQ => 760 <= ISA_NEG_RESP SA Completed 761 (optional) ISA_COMMIT => 763 2.3 ISAKMP Details 765 2.3.1 Security Association Attributes 767 A Security Association (SA) is a relationship between two entities that 768 describes how they will utilize security services. This relationship is 769 represented by a collection of security related information. The SA At- 770 tributes are the individual elements that comprise all security relevant 771 information necessary to form the SA. 773 The following syntax defines the security attributes to be exchanged by 774 ISAKMP. This syntax is used in the ISA_INIT_REQ, ISA_INIT_RESP, ISA_NEG_REQ, 775 ISA_NEG_RESP, ISA_MOD_REQ, and ISA_MOD_RESP messages. The syntax groups se- 776 curity attributes needed to perform a security function into either an SA 777 set or SA list format. The set format MUST be supported by ISAKMP imple- 778 mentations. The list format is an optional format. 780 Security Associations Sets The set format groups all necessary attributes 781 together. Each set has a unique identifier (Set Number), supported secu- 782 rity service (Supports), such as IP AH, IP ESP, OSPF authentication, and 783 a list of Attribute Classes and Attribute Types. The Attribute Class is 784 the broad category of Attribute Type, such as encryption algorithms. At- 785 tribute Type is a specific attribute identifier. DES is an example of an 786 attribute type for the encryption algorithm attribute class. A set has 787 only one instance of an Attribute Class and one type for that class. This 788 syntax maintains flexibility by allowing many different (and some still 789 undefined) types of SA attributes to be exchanged. 791 Figure 2 depicts the syntax for exchanging security attributes using 792 the set format. It shows a single set from which multiple sets would be 793 grouped for a specific message type. 795 1 2 3 796 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 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 ! Set Number ! Supports ! Num of Attr ! 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 ! Attribute Class ! Attribute Type ! 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 ~ ..... ~ 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 ! Attribute Class ! Attribute Type ! 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 Figure 2: Generic Set Exchange Format 809 o Set number (1 octet) - Unique identifier for each proposed set 811 o Supports (2 octets) - Security service proposed set supports. 812 Examples are IP AH, IP ESP, and OSPF authentication 814 o Number of Attributes (1 octet) - Number of attribute classes 815 contained in the proposed set 817 o Attribute Class (2 octets) - examples are Encryption Algorithms, Key 818 Exchange Algorithms, Authentication Mechanisms 820 o Attribute Type (2 octets) - examples of attribute types for the 821 encryption algorithms attribute class are DES, Triple DES, and IDEA. 823 The size of a set formatted exchange is 4 octets + (Number of Attribute 824 Classes * 4 octets). Computing the size of a particular set allows the 825 determination of the beginning of the next set without completely parsing 826 the current set. This is necessary when it is determined that the current 827 set is not an acceptable SA set. This will improve the performance of SA 828 Attribute determination. 830 Security Association Lists The SA list format presents several attribute 831 types for an attribute class. Each type within the class is then ordered 832 to indicate its precedence. Specifically, the first attribute type is the 833 highest priority type, followed by other choices. Each subsequent choice 834 is listed in descending priority order. An attribute type must be chosen 835 for each attribute class to establish a complete SA. 837 Figure 3 shows the syntax for the optional list exchange format. The num- 838 ber of types is determined by the Count field. The number of Attribute 839 Types within an Attribute Class will depend on what is supported by the 840 local machine. 842 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 ! Attribute Class ! Count ! 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 ! Attribute Type ! Attribute Type ! 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 ~ ~ 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 ! Attribute Type ! Attribute Type ! 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 Figure 3: Generic List Exchange Format 856 o Attribute Class (2 octets) - Examples are Encryption Algorithms, Key 857 Exchange Algorithms 859 o Count - Number of proposed Attribute Types for the given Attribute 860 Class 862 o Attribute Type (2 octets) - Presented in descending priority order 864 Appendix B presents an outline containing a comprehensive listing of SA 865 attributes. This listing of attributes are initial definitions and are 866 presented to stimulate thought and discussion on SAs. The final SA for 867 a protocol SHOULD be defined in that protocol so additions or modifica- 868 tions to the attributes do not require a modification to the Internet Key 869 Management Protocol (IKMP) RFC and vice versa. For example, Appendix C 870 describes the sample security associations for ISAKMP and IPSP ESP and AH. 872 2.3.2 Transport Protocol 874 The User Datagram Protocol (UDP) is the transport protocol for ISAKMP. UDP 875 checksumming discards UDP packets with an incorrect or zero (0) checksum. 876 ISAKMP is unaware of the discard, but will resend the packet when its re- 877 send timer expires. 879 2.3.3 RESERVED Fields 881 The existence of RESERVED fields are strictly used to preserve byte 882 alignement. All RESERVED fields in the ISAKMP protocol MUST be set to 883 zero (0) when a packet is issued. The receiver SHOULD check the RESERVED 884 fields for zero (0) and discard the packet if other values are found. 886 2.3.4 Anti-Clogging Token (``Cookie'') Creation 888 Phil Karn's Internet Draft [Karn95] states that cookie generation is im- 889 plementation dependent, but must satisfy some basic requirements: 891 1. The cookie must depend on the specific parties. This prevents 892 an attacker from obtaining a cookie using a real IP address and 893 UDP port, and then using it to swamp the victim with Diffie- 894 Hellman requests from randomly chosen IP addresses or ports. 896 2. It must not be possible for anyone other than the issuing 897 entity to generate cookies that will be accepted by that 898 entity. This implies that the issuing entity must use local 899 secret information in the generation and subsequent 900 verification of a cookie. It must not be possible to deduce 901 this secret information from any particular cookie. 903 3. The cookie generation function must be fast to thwart attacks 904 intended to sabotage CPU resources. 906 Karn's suggested method for creating the cookie is to perform a fast hash 907 (e.g. MD5) over the IP Source and Destination Address, the UDP Source and 908 Destination Ports and a locally generated secret random value. ISAKMP 909 requires that the cookie be unique for each SA establishment, SA modify 910 and SA delete to help prevent replay attacks, therefore the date and time 911 MUST be added to the information hashed. 913 2.3.5 SA Flags Field 915 The SA Flags field may be set by the entity that initiated the negotia- 916 tion to indicate that the ISA_COMMIT packet will follow the completion of 917 the protocol exchange. The SA Flags field exists only in the ISA_INIT and 918 ISA_NEG packets. If the initiating entity sets the flag, the responding 919 entity cannot reset it. If the initiating entity does not set the flag, 920 the responding entity may set it, thereby, forcing the initiating entity 921 to issue an ISA_COMMIT packet. If neither entity sets the flag, then the 922 ISA_COMMIT packet will not be issued. To set the flag the Least Signifi- 923 cant Bit (LSB) in the SA Flags field is set to one (1) . All other bits 924 in the SA Flags field are zero (0). 926 3 Security Association Establishment 928 Security Association (SA) Establishment is the process of agreeing upon 929 and exchanging all the security information that is required in an SA. The 930 following sections, 3.1 to 3.3, describe the three basic phases that com- 931 prise SA Establishment: SA Initialization, Key and Authentication infor- 932 mation exchange, and SA Negotiation. 934 3.1 Security Association Initialization 936 The initialization exchange of SA establishment is composed of the 937 ISA_INIT_REQ and ISA_INIT_RESP packets shown in figure 4. The ISA_INIT pack- 938 ets exchange ``cookies'', and options for a key generation technique, an 939 encryption algorithm and an authentication mechanism. The ``cookies'' 940 are used to prevent replay and denial of service attacks. Authentication 941 and encryption for the ISAKMP exchanges are provided by the authentication 942 mechanism and encryption algorithm selected. The key generation technique 943 selected creates keys for use by the authentication mechanism and encryp- 944 tion algorithm. The keys may also be used as any of the following: ac- 945 tual session keys, to create the session keys, or to protect the exchange 946 of the actual session keys for the SA. If the key, encryption algorithm, 947 and authentication mechanism are only used to protect ISAKMP exchanges, 948 then new options can be picked during the negotiation phase (described in 949 Section 3.3) for use in protecting the actual data communications. If en- 950 cryption is not required for the SA, the encryption algorithm options are 951 not exchanged. 953 1 2 3 954 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 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 ~ ISAKMP Header ~ 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 ! SA Syntax Type! SA Flags ! # Sets/Lists ! RESERVED ! 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 ~ SA Attribute Set/List #1 ~ 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 ~ SA Attribute Set/List #2 ~ 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 ~ ... ~ 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 ~ SA Attribute Set/List #N ~ 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 Figure 4: ISA_INIT_REQ and ISA_INIT_RESP Packet Format 971 o ISAKMP Header - Described in Section 2.1 973 o SA Syntax Type (1 octet) - Presentation format of SAs 975 _SA_Syntax__SA_Syntax_Type_ 976 RESERVED 0 977 Set 1 978 List 2 980 o SA Flags (1 octet) - Flags specific to an SA service. See section 981 2.3.5 for details. 983 o Number of Sets (1 octet) - Number of SA Attribute Sets being proposed 984 o SA Attributes (variable) - A list of SA Attributes. The SA Attribute 985 specifications are discussed in Section 2.3.1. 987 3.1.1 SA Initialization Procedures 989 When issuing an ISA_INIT_REQ message, the initiating entity does the fol- 990 lowing: 992 1. Create initiator cookie. See Section 2.3.4 for details. 994 2. Generate a unique pseudo-random SPI. See Section 2.1 for details. 996 3. Construct an ISA_INIT_REQ packet. If the initiator will send an 997 ISA_COMMIT message upon completion of the SA establishment, then the 998 SA Flags field MUST be set (see section 2.3.5 and 3.4). 1000 4. Transmit the packet to the destination host as described in Section 1001 2.1.1. 1003 When an ISA_INIT_REQ message is received, the receiving entity does the 1004 following: 1006 1. Check the ISAKMP header as described in Section 2.1.1. 1008 2. Unpack the ISA_INIT_REQ payload and determine the highest priority 1009 attribute set (or attribute list) supported. If the proposed 1010 attribute set (or list) is rejected, then the protocol machine must 1011 clear all state and return to IDLE. 1013 3. Create responder cookie. See Section 2.3.4 for details. 1015 4. Generate a unique pseudo-random SPI. See Section 2.1 for details. 1017 5. Construct an ISA_INIT_RESP packet. If the responder wants to request 1018 that an ISA_COMMIT message be sent upon completion of the SA 1019 establishment, then the SA Flags field MUST be set (see section 2.3.5 1020 and 3.4). 1022 6. Transmit the packet to the initiating host as described in Section 1023 2.1.1. 1025 When an ISA_INIT_RESP message is received, the receiving entity (original 1026 initiator) does the following: 1028 1. Check the ISAKMP header as described in Section 2.1.1. 1030 2. Unpack the ISA_INIT_RESP payload. 1032 3. Determine if the attribute set (or list) selected by the responder is 1033 valid. If the attribute set (or list) is invalid or the responder 1034 rejected all proposed attribute sets (or lists), the receiving entity 1035 does the following: 1037 (a) The event, INVALID ATTRIBUTES, is logged in the appropriate 1038 system audit file. 1040 (b) Clear all state and return to IDLE. Any further communication 1041 must start the SA initialization procedures from the beginning. 1043 If the attribute set (or list) is valid, the receiving entity does 1044 the following: 1046 (a) Configure protocol machine based on attribute set selected. 1048 (b) Transition to Authentication and Key Exchange (see Section 3.2). 1050 3.2 Authentication and Key Exchange 1052 During the authentication and key exchange phase, information required to 1053 confirm the identities of the parties wishing to establish the SA and es- 1054 tablish a session key for use during the SA establishment is exchanged. 1055 Depending on the key exchange algorithm, the original key may be used dur- 1056 ing data communications or a new one may be created and exchanged during 1057 the negotiation phase (described in section 3.3). This original or new 1058 key would be used in protecting the actual data communications. 1060 The packets that carry the authentication and key exchange payloads have 1061 the format shown in Figure 5. When the ISA_AUTH&KE_REQ and ISA_AUTH&KE_RESP 1062 packets are used, the Authentication Payload SHOULD be processed first to 1063 strongly authenticate the packet issuer, followed by the processing of 1064 the Key Exchange Payload. The authentication and key exchange payloads 1065 (shown in Figures 6 and 7) are general formats which support many types 1066 of authentication and key exchange mechanisms. The detailed specification 1067 of these fields will be specified in companion RFCs. These companion RFCs 1068 will define the standard authentication and key exchange mechanisms that 1069 need to be implemented to assure compliance with this specification. 1071 1 2 3 1072 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 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 ~ ISAKMP Header ~ 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 ~ ~ 1077 ! Authentication Payload ! 1078 ~ ~ 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 ~ ~ 1081 ! Key Exchange Payload ! 1082 ~ ~ 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 Figure 5: ISA_AUTH&KE_REQ and ISA_AUTH&KE_RESP Packet Format 1087 3.2.1 Authentication Payload Format 1089 This section specifies the encoding of the authentication payload for the 1090 ISA_AUTH_REQ, ISA_AUTH_RESP, ISA_AUTH&KE_REQ, and ISA_AUTH&KE_RESP messages. 1091 As described in section 2.2.3, when the ISA_AUTH_REQ and ISA_AUTH_RESP pack- 1092 ets are transmitted alone, the key exchange payload is not present. The 1093 format of these messages is shown in Figure 6. 1095 1 2 3 1096 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 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 ! Authentication Authority ! Reserved ! 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 ! Authentication Type ! Length ! 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 ~ ~ 1103 ! Authentication Data ! 1104 ~ ~ 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 Figure 6: Authentication Payload Format 1109 o Authentication Authority (2 octets) - This field identifies the party 1110 that generated the certificates used for authentication. Authorities 1111 must be assigned an identifier by the Internet Assigned Numbers 1112 Authority (IANA). Before being assigned an identifier, an authority 1113 must publish an RFC defining the authority's domain. [RFC-1422] 1114 describes the Internet Policy Registration Authority (IPRA) and the 1115 procedures for achieving this registration. 1117 If PGP certificates, based on the ``web of trust'', are carried in 1118 the authentication payload the Authentication Authority value is one 1119 (1). 1121 Example certificate authorities that would have to register for an 1122 identifier are: 1124 -- RSA Commercial Certificate Authority 1125 (http://www_csc.rsa.com/netsite) 1127 -- Stable Large E-mail Database (SLED) (http://www.four11.com) 1129 -- U.S. Postal Service. 1131 o Authentication Type (2 octets) - This field indicates the 1132 authentication payload format. This field is used by authentication 1133 authorities that support more than one certificate type. The 1134 authentication types supported by an authentication authority must be 1135 defined in the RFC required for authentication authority 1136 registration. Examples are: 1138 -- RSA certificates 1140 -- PGP certificates 1142 -- DSS certificates 1144 -- DNS Signed Keys 1146 -- Kerberos Tokens 1148 -- X.509 certificates 1150 o Length (2 octets) - Length of the Authentication Data field in 1151 octets. 1153 o Authentication Data (variable) - Actual authentication data. The 1154 type of certificate is indicated by the Authentication Type field. 1156 3.2.2 Key Exchange Payload Format 1158 A variety of key exchanges can be supported in the key exchange phase. 1159 Some examples of key exchanges which may be used in this protocol are 1160 Diffie-Hellman, the enhanced Diffie-Hellman key exchange described in 1161 X9.42 [ANSI94], the key exchange on the FORTEZZA card, and the RSA-based 1162 key exchange used by PGP. This protocol will also support key exchanges 1163 that include key escrow or data recovery techniques, but does not mandate 1164 their use. 1166 The encoding of the key exchange payload is dependent on the specific key 1167 exchange and, therefore, is not specified in this Internet draft. Each 1168 key exchange must define the following information: (a) System parame- 1169 ters, (b) Key establishment algorithm, and (c) Key derivation procedure 1170 (dependent on key exchange type). 1172 There can be both public and private key generation techniques. Both 1173 types must register with IANA to obtain a Key Exchange Identifier (KEI). 1174 Before published public key exchanges can obtain a KEI, an RFC defining 1175 the key exchange payload format and key generation procedures MUST be sub- 1176 mitted. Private key exchanges SHOULD be documented in an RFC when regis- 1177 tering for a KEI. 1179 As described in section 2.2.2, when the ISA_KE_REQ and ISA_KE_RESP packets 1180 are transmitted alone, the authentication payload is not present. Once 1181 the key exchange is completed, then the authentication payload is sent 1182 separately using the format described in section 3.2.1 1184 1 2 3 1185 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 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 ! KEI ! Length ! 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 ~ ~ 1190 ! Key Exchange Payload ! 1191 ~ ~ 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 Figure 7: Key Exchange Payload Format 1196 o KEI (2 octets) - Key Exchange Identifier 1198 o Length (2 octets) - Length of payload in octets 1200 o Key Exchange Payload (variable) - Data (i.e. public values) required 1201 to create session key. 1203 3.2.3 Authentication and Key Exchange Procedures 1205 When issuing an ISA_AUTH&KE_REQ packet, the initiating entity will do the 1206 following: 1208 1. Create the ISAKMP Header. 1210 2. Create the authentication payload. 1212 3. Create the key exchange payload based on KEI. 1214 4. Construct an ISA_AUTH&KE_REQ packet. 1216 5. Generate an authentication signature using the authentication 1217 attributes and options selected in the initialization phase. 1219 6. Transmit the packet to the responding host as described in Section 1220 2.1.1. 1222 When an ISA_AUTH&KE_REQ packet is received, the receiving entity will do 1223 the following: 1225 1. Check the ISAKMP header as described in Section 2.1.1. 1227 2. Verify the initiator's signature. The ISA_AUTH&KE_REQ packet is 1228 processed and the calculated signature is compared to the signature 1229 contained in the ISA_AUTH&KE_REQ packet. If these signatures are not 1230 identical, the message is discarded and the following actions are 1231 taken: 1233 (a) The event, INVALID SIGNATURE, is logged in the appropriate system 1234 audit file. 1236 (b) No response is sent to the initiating entity. This will cause 1237 the transmission timer of the initiating entity to expire and 1238 force retransmission of the message. 1240 3. Unpack the ISA_AUTH&KE_REQ packet. 1242 4. Create the ISAKMP Header. 1244 5. Create the authentication payload. 1246 6. Create the key exchange payload based on KEI. 1248 7. Construct an ISA_AUTH&KE_RESP packet. 1250 8. Generate an authentication signature, to authenticate responder to 1251 initiator, using the authentication attributes and options selected. 1253 9. Transmit the packet to the initiating host as described in Section 1254 2.1.1. 1256 10. Begin key calculation in the background, if necessary. 1258 When an ISA_AUTH&KE_RESP message is received, the receiving entity (origi- 1259 nal initiator) will do the following: 1261 1. Check the ISAKMP header as described in Section 2.1.1. 1263 2. Verify the initiator's signature. The ISA_AUTH&KE_RESP packet is 1264 processed and the calculated signature is compared to the signature 1265 contained in the ISA_AUTH&KE_RESP packet. If these signatures are not 1266 identical, the message is discarded and the following actions are 1267 taken: 1269 (a) The event, INVALID SIGNATURE, is logged in the appropriate system 1270 audit file. 1272 (b) No response is sent to the initiating entity. This will cause 1273 the transmission timer of the initiating entity to expire and 1274 force retransmission of the message. 1276 3. Calculate key, if necessary. 1278 4. Transition to Security Association Negotiation. 1280 3.3 Security Association Negotiation 1282 The SA Negotiation phase allows the initiating entity to present SA at- 1283 tributes that it wishes to use for secure communications to a respond- 1284 ing entity. These SA attributes may include additional options for the 1285 attributes agreed upon during the initialization phase, as well as ad- 1286 ditional attributes required for an SA. As an example, the SA parame- 1287 ters for the IP AH and IP ESP security mechanisms are cited in the Secu- 1288 rity Architecture for the Internet Protocol [RFC-1825]. The format for 1289 the ISA_NEG_REQ and ISA_NEG_RESP packets is the same as the ISA_INIT_REQ and 1290 ISA_INIT_RESP shown in Figure 4. All fields shown in Figure 4 exist for 1291 the ISA_NEG_REQ and ISA_NEG_RESP packets. 1293 3.3.1 SA Negotiation Procedures 1295 When issuing an ISA_NEG_REQ packet, the initiating entity does the follow- 1296 ing: 1298 1. Determine SA attributes to be negotiated. This may include changing 1299 some attributes from the original SA initialization. 1301 2. Construct an ISA_NEG_REQ packet. If the initiator will send an 1302 ISA_COMMIT message upon completion of the SA establishment, then the 1303 SA Flags field MUST be set (see section 2.3.5 and 3.4). 1305 3. Depending on the SA Attributes established in the SA initialization 1306 phase, apply the agreed upon security services. 1308 (a) If the SA requires authentication, the ISA_NEG_REQ packet is pro- 1309 cessed (or signed) and the signature placed as noted in Figure 1. 1311 (b) If the SA requires encryption and the encryption algorithm is a 1312 block encryption algorithm, then padding up to the block size 1313 MUST be placed as noted in Figure 1. 1315 (c) If the SA requires encryption, the ISA_NEG_REQ payload and 1316 Signature are encrypted. 1318 4. Transmit the packet to the responding host as described in Section 1319 2.1.1. 1321 When an ISA_NEG_REQ packet is received, the receiving entity does the fol- 1322 lowing: 1324 1. Check the ISAKMP header as described in Section 2.1.1. 1326 2. Depending on the SA Attributes, apply the agreed upon security 1327 services. 1329 (a) If the SA requires encryption, decrypt the ISA_NEG_REQ payload and 1330 Signature. If the decryption fails, the message is discarded and 1331 the following actions are taken: 1333 i. The event, DECRYPTION FAILED, is logged in the appropriate 1334 system audit file. 1336 ii. No response is sent to the initiating entity. This will 1337 cause the transmission timer of the initiating entity to 1338 expire and force retransmission of the message. 1340 (b) If the SA requires authentication, the ISA_NEG_REQ packet is 1341 processed and the calculated signature is compared to the 1342 signature contained in the ISA_NEG_REQ packet. If these signatures 1343 are not identical, the message is discarded and the following 1344 actions are taken: 1346 i. The event, INVALID SIGNATURE, is logged in the appropriate 1347 system audit file. 1349 ii. No response is sent to the initiating entity. This will 1350 cause the transmission timer of the initiating entity to 1351 expire and force retransmission of the message. 1353 3. Unpack the ISA_NEG_REQ packet payload and determine the highest 1354 priority SA attributes supported. If none of the SA attribute 1355 options are supported, the ISA_NEG_RESP packet will have the value zero 1356 (0) in the Number of Sets field and an SA will not be established. 1358 4. If the SA negotiation is requesting a key change or new 1359 authentication mechanism, then generate the appropriate information 1360 and include it as an attribute in the ISA_NEG_RESP payload. 1362 5. Construct an ISA_NEG_RESP packet. If the responder wants to request 1363 that an ISA_COMMIT message be sent upon completion of the SA 1364 establishment, then the SA Flags field MUST be set (see section 2.3.5 1365 and 3.4). 1367 6. Depending on the SA Attributes, apply the agreed upon security 1368 services. 1370 (a) If the SA requires authentication, the ISA_NEG_RESP packet is 1371 processed and the signature placed as noted in Figure 1. 1373 (b) If the SA requires encryption and the encryption algorithm is a 1374 block encryption algorithm, then padding up to the block size 1375 MUST be placed as noted in Figure 1. 1377 (c) If the SA requires encryption, the ISA_NEG_RESP payload and 1378 Signature are encrypted. 1380 7. Transmit the packet to the initiating host as described in Section 1381 2.1.1. 1383 8. If required, begin calculation of the new session key in the 1384 background. 1386 9. Transition to SA Negotation Conclusion (see Section 3.4). 1388 When an ISA_NEG_RESP message is received, the receiving entity (original 1389 initiator) does the following: 1391 1. Check the ISAKMP header as described in Section 2.1.1. 1393 2. Depending on the SA Attributes, apply the agreed upon security 1394 services. 1396 (a) If the SA requires encryption, decrypt the ISA_NEG_RESP payload and 1397 Signature. If the decryption fails, the message is discarded and 1398 the following actions are taken: 1400 i. The event, DECRYPTION FAILED, is logged in the appropriate 1401 system audit file. 1403 ii. No response is sent to the initiating entity. This will 1404 cause the transmission timer of the initiating entity to 1405 expire and force retransmission of the message. 1407 (b) If the SA requires authentication, the ISA_NEG_RESP packet is 1408 processed and the calculated signature is compared to the 1409 signature contained in the ISA_NEG_RESP packet. If these 1410 signatures are not identical, the message is discarded and the 1411 following actions are taken: 1413 i. The event, INVALID SIGNATURE, is logged in the appropriate 1414 system audit file. 1416 ii. No response is sent to the initiating entity. This will 1417 cause the transmission timer of the initiating entity to 1418 expire and force retransmission of the message. 1420 3. Unpack the ISA_NEG_RESP payload and verify the SA attributes selected 1421 by responder are valid. If the attribute sets (or lists) are invalid 1422 or the responder rejected all proposed attribute sets (or lists), the 1423 receiving entity does the following: 1425 (a) The event, INVALID ATTRIBUTES, is logged in the appropriate 1426 system audit file. 1428 (b) Clear all state and return to IDLE. 1430 If the attribute set (or list) is valid, the receiving entity does 1431 the following: 1433 (a) Configure the protocol machine based on the attribute set (or 1434 list) selected. 1436 4. If required, begin calculation of the new session key in the 1437 background. 1439 5. Transition to SA Negotiation Conclusion (see Section 3.4). 1441 3.4 SA Negotiation Conclusion 1443 The SA negotiation concludes with the transmittal of the optional 1444 SA_COMMIT packet. This is determined by the setting of the SA Flags 1445 field. The SA_COMMIT message allows the initiating entity to inform the 1446 responding party that it has completed the processing required to set-up 1447 the SA and therefore, secure communications may begin. If the entity ini- 1448 tiating the SA establishment does not have the ability to queue incoming 1449 data it may receive prior to its completion of SA establishment process- 1450 ing, then it requires the responding entity to wait for an SA_COMMIT mes- 1451 sage before sending data. The transmittal of the ISA_COMMIT packet is op- 1452 tional and determined by the policy of the parties establishing the SA. 1453 All implementations MUST be able to generate, transmit, and receive this 1454 message. 1456 The ISA_COMMIT packet is the ISAKMP header, described in section 2.1, with 1457 no payload. 1459 3.4.1 SA Negotiation Conclusion Procedures 1461 When issuing an ISA_COMMIT packet, the initiating entity does the follow- 1462 ing: 1464 1. Construct an ISA_COMMIT packet (ISAKMP Header). 1466 2. Depending on the SA Attributes established in the SA initialization 1467 phase, apply the agreed upon security services. 1469 (a) If the SA requires authentication, the ISA_COMMIT packet is pro- 1470 cessed (or signed) and the signature placed as noted in Figure 1. 1472 (b) If the SA requires encryption and the encryption algorithm is a 1473 block encryption algorithm, then padding up to the block size 1474 MUST be placed as noted in Figure 1. 1476 (c) If the SA requires encryption, the ISA_COMMIT Signature is 1477 encrypted. 1479 3. Transmit the packet to the responding host as described in Section 1480 2.1.1. 1482 4. Clear all state and return to IDLE. 1484 When an ISA_COMMIT packet is received, the receiving entity does the fol- 1485 lowing: 1487 1. Check the ISAKMP header as described in section 2.1.1. 1489 2. Depending on the SA Attributes, apply the agreed upon security 1490 services. 1492 (a) If the SA requires encryption, decrypt the ISA_COMMIT Signature. 1493 If the decryption fails, the message is discarded and the 1494 following actions are taken: 1496 i. The event, DECRYPTION FAILED, is logged in the appropriate 1497 system audit file. 1499 ii. Because the ISA_COMMIT packet is a unidirectional message a 1500 retransmission will not be performed. Because the SA is 1501 established, we recommend that communications can proceed, 1502 however, the local security policy will dictate the 1503 procedures for continuing. We recommend that an ISA_NOTIFY 1504 packet with an Error Message Type (see Section 6) be sent to 1505 the originator of the ISA_COMMIT packet. 1507 (b) If the SA requires authentication, the ISA_COMMIT packet is 1508 processed and the calculated signature is compared to the 1509 signature contained in the ISA_COMMIT packet. If these signatures 1510 are not identical, the message is discarded and the following 1511 actions are taken: 1513 i. The event, INVALID SIGNATURE, is logged in the appropriate 1514 system audit file. 1516 ii. Because the ISA_COMMIT packet is a unidirectional message a 1517 retransmission will not be performed. Because the SA is 1518 established, we recommend that communications can proceed, 1519 however, the local security policy will dictate the 1520 procedures for continuing. We recommend that an ISA_NOTIFY 1521 packet with an Error Message Type (see Section 6) be sent to 1522 the originator of the ISA_COMMIT packet. 1524 3. Clear all state and return to IDLE. 1526 4 Security Association Modification 1528 Security Association modification provides the ability to update security 1529 association attributes and parameters within an existing SA without having 1530 to establish a new SA. The use of this exchange can provide performance 1531 benefits without sacrificing the security of the existing communication. 1532 The most common use of this exchange will be to re-key an existing SA. 1533 The format for the ISA_MODIFY packet is the same as the ISA_INIT_REQ and 1534 ISA_INIT_RESP shown in Figure 4. All fields shown in Figure 4 exist for 1535 the ISA_MODIFY packets. 1537 4.1 Modification Procedures 1539 The procedure for exchanging information to modify an SA are similiar to 1540 the SA negotiation exchange. The details of SA modification will be de- 1541 scribed in this section as they are solidified during prototype develop- 1542 ment. 1544 5 Security Association Deletion 1546 During communications it is possible that hosts may be compromised or that 1547 information may be intercepted during transmission. Determining whether 1548 this has occurred is not an easy task and is outside the scope of this 1549 Internet-Draft. However, if it is discovered that transmissions are being 1550 compromised, then it is necessary to delete the current SA and establish a 1551 new SA. 1553 The ISA_DELETE packet (shown in Figure 8) provides a controlled method of 1554 informing a peer entity that the initiating entity has deleted an SA(s). 1555 The ISA_DELETE packet allows for the deletion of any number of SAs with 1556 a single message. The receiving entity SHOULD clean up its local SA 1557 database. The receiving entity may be using the SA for secure communi- 1558 cations with more than one party and would not want to actually delete the 1559 SA from its database in this case. However, upon receipt of an ISA_DELETE 1560 packet the SAs listed in the SPIs field of the packet cannot be used with 1561 the initiating entity. The SA Establishment procedure must be invoked to 1562 re-establish secure communications. 1564 1 2 3 1565 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 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 ~ ISAKMP Header ~ 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 ! SPI Count ! Length ! 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 ~ ~ 1572 ! SPIs ! 1573 ~ ~ 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 Figure 8: SA Delete Payload Format 1578 o SPI Count - Number of security associations to be deleted 1580 o Length - length of payload in octets 1582 o SPIs - Initiator's Security Parameter Index(s) to be deleted 1584 5.1 Deletion Procedures 1586 When issuing an ISA_DELETE packet, the issuing entity (initiator or re- 1587 sponder) does the following: 1589 1. Create initiator cookie. See Section 2.3.4 for details. 1591 2. Determine SPI of receiving entity. 1593 3. Construct the ISA_DELETE packet. 1595 4. Depending on the SA Attributes, apply the agreed upon security 1596 services. 1598 (a) If the SA requires authentication, the ISA_DELETE packet is 1599 processed and the signature placed as noted in Figure 1. 1601 (b) If the SA requires encryption, the ISA_DELETE payload and 1602 Signature are encrypted. 1604 5. Transmit the packet to the destination host as described in Section 1605 2.1.1. 1607 6. Update the local SA database to reflect the SPI deletions. 1609 Upon receipt of an ISA_DELETE packet, the receiving entity (initiator or 1610 responder) does the following: 1612 1. Check the ISAKMP header as described in Section 2.1.1. 1614 2. Depending on the SA Attributes, apply the agreed upon security 1615 services in the following order. 1617 (a) If the SA requires encryption, decrypt the ISA_DELETE payload and 1618 Signature. If the decryption fails, the message is discarded and 1619 the following actions are taken: 1621 i. The event is logged in the appropriate system audit file. 1623 ii. Because the ISA_DELETE packet is a unidirectional message a 1624 retransmission will not be performed. The local security 1625 policy will dictate the procedures for continuing. However, 1626 we recommend that the SPIs in the ISA_DELETE packet be checked 1627 to see if the originator was the communicating party. If so, 1628 then these SAs can be deleted from the local SA database. We 1629 also recommend that an ISA_NOTIFY packet with an Error Message 1630 Type (see Section 6) be sent to the originator of the 1631 ISA_DELETE packet. If the SPIs do not match those of the 1632 originator, then no further action should be taken. 1634 (b) If the SA requires authentication, the ISA_DELETE packet is 1635 processed and the calculated signature is compared to the 1636 signature contained in the ISA_DELETE packet. If these signatures 1637 are not identical, the message is discarded and the following 1638 actions are taken: 1640 i. The event is logged in the appropriate system audit file. 1642 ii. Because the ISA_DELETE packet is a unidirectional message a 1643 retransmission will not be performed. The local security 1644 policy will dictate the procedures for continuing. However, 1645 we recommend that the SPIs in the ISA_DELETE packet be checked 1646 to see if the originator was the communicating party. If so, 1647 then these SAs can be deleted from the local SA database. We 1648 also recommend that an ISA_NOTIFY packet with an Error Message 1649 Type (see Section 6) be sent to the originator of the 1650 ISA_DELETE packet. If the SPIs do not match those of the 1651 originator, then no further action should be taken. 1653 3. Unpack the ISA_DELETE payload. 1655 4. Update the local SA database to reflect the SPI deletions. 1657 6 Notification Message 1659 The ISAKMP ISA_NOTIFY packet contains information one party wants to send 1660 to another. Notification information can be error messages specifying 1661 why a SA could not be established. It can also be status data that a 1662 process managing an SA database wishes to communicate with a peer pro- 1663 cess. For example, a secure front end or security gateway may use the 1664 ISA_NOTIFY message to synchronize SA communication (see Appendix A.2). 1665 The ISA_NOTIFY packet is unidirectional. 1667 1 2 3 1668 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 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 ~ ISAKMP Header ~ 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 ! Notify Message Type ! Length ! 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 ~ ~ 1675 ! Notify Payload ! 1676 ~ ~ 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 Figure 9: ISA NOTIFY Payload Format 1681 o Notify Message Type (2 octets) 1683 _Notification__Notify_Message_Type_ 1684 Error 1 1685 Status 2 1687 o Length (2 octets) - length of payload in octets 1689 o Notify Payload (variable) - Value dependent on the Notify Message 1690 Type 1692 6.1 Notification Procedures 1694 When issuing an ISA_NOTIFY message, the issuing entity (initiator or re- 1695 sponder) does the following: 1697 1. Create initiator cookie. See Section 2.3.4 for details. 1699 2. Determine SPI of receiving entity. 1701 3. Construct ISA_NOTIFY packet. 1703 4. Depending on the SA Attributes, apply the agreed upon security 1704 services. 1706 (a) If the SA requires authentication, the ISA_NOTIFY packet is 1707 processed and the signature placed as noted in Figure 1. 1709 (b) If the SA requires encryption, the ISA_NOTIFY payload and 1710 Signature are encrypted. 1712 5. Transmit the packet to the destination host as described in Section 1713 2.1.1. 1715 Upon receipt of an ISA_NOTIFY message, the receiving entity (initiator or 1716 responder) does the following: 1718 1. Check the ISAKMP header as described in Section 2.1.1. 1720 2. Depending on the SA Attributes, apply the agreed upon security 1721 services in the following order. 1723 (a) If the SA requires encryption, decrypt the ISA_NOTIFY payload and 1724 Signature. If the decryption fails, the message is discarded and 1725 the following actions are taken: 1727 i. The event is logged in the appropriate system audit file. 1729 ii. Because the ISA_NOTIFY packet is a unidirectional message a 1730 retransmission will not be performed. The local security 1731 policy will dictate the procedures for continuing. 1733 (b) If the SA requires authentication, the ISA_NOTIFY packet is 1734 processed and the calculated signature is compared to the 1735 signature contained in the ISA_NOTIFY packet. If these signatures 1736 are not identical, the message is discarded and the following 1737 actions are taken: 1739 i. The event is logged in the appropriate system audit file. 1741 ii. Because the ISA_NOTIFY packet is a unidirectional message a 1742 retransmission will not be performed. The local security 1743 policy will dictate the procedures for continuing. 1745 3. Unpack the ISA_NOTIFY payload. 1747 4. Depending on the Notify Message Type, additional processing may be 1748 necessary. 1750 7 Conclusions 1752 The Internet Security Association and Key Management Protocol (ISAKMP) is 1753 a well designed protocol aimed at the Internet of the future. The massive 1754 growth of the Internet will lead to great diversity in network utiliza- 1755 tion, communications, and security requirements. ISAKMP contains all the 1756 features that will be needed for this dynamic and expanding communications 1757 environment. 1759 ISAKMP's Security Association (SA) feature coupled with authentication 1760 and key establishment provides the security and flexibility that will be 1761 needed for future growth and diversity. This security diversity of multi- 1762 ple key exchange techniques, encryption algorithms, authentication mecha- 1763 nisms, security services, and security attributes will allow users to se- 1764 lect the appropriate security for their network, communications, and secu- 1765 rity needs. The SA feature allows users to specify and negotiate security 1766 requirements with other users. An additional benefit of supporting multi- 1767 ple techniques in a single protocol is that as new techniques are devel- 1768 oped they can easily be added to the protocol. This provides a path for 1769 the growth of Internet security services. ISAKMP supports both publicly 1770 or privately defined SAs, making it ideal for government, commercial, and 1771 private communications. 1773 ISAKMP provides the ability to establish SAs for multiple security proto- 1774 cols and applications. These protocols and applications may be session- 1775 oriented or sessionless. Having one SA establishment protocol that sup- 1776 ports multiple security protocols eliminates the need for multiple, nearly 1777 identical authentication, key exchange and SA establishment protocols when 1778 more than one security protocol is in use or desired. Just as IP has pro- 1779 vided the common networking layer for the Internet, a common security es- 1780 tablishment protocol is needed if security is to become a reality on the 1781 Internet. ISAKMP provides the common base that allows all other security 1782 protocols to interoperate. 1784 ISAKMP follows good security design principles. It is not coupled to 1785 other insecure transport protocols, therefore it is not vulnerable or 1786 weakened by attacks on other protocols. Also, when more secure transport 1787 protocols are developed, ISAKMP can be easily migrated to them. ISAKMP 1788 also provides protection against protocol related attacks. This protec- 1789 tion provides the assurance that the SAs and keys established are with the 1790 desired party and not with an attacker. 1792 ISAKMP also follows good protocol design principles. Protocol specific 1793 information only is in the protocol header, following the design prin- 1794 ciples of IPv6. The data transported by the protocol is separated into 1795 functional payloads. As the Internet grows and evolves, new payloads to 1796 support new security functionality can be added without modifying the en- 1797 tire protocol. 1799 A ISAKMP Scenarios 1801 Examples scenerios are are presented to help illustrate the ISAKMP's abil- 1802 ity to support multiple authentication methods and key exchanges. 1804 A.1 Initial ISAKMP Daemon Scenerio 1806 This example steps through two ISAKMP daemons establishing an SA between 1807 themselves. This SA uses DNS Security Extentions [EK94] for authentica- 1808 tion and a Photuris [Karn95] compliant key exchange. Following the SA es- 1809 tablishment between the daemons, SAs are established for ESP and AH commu- 1810 nications between user processes. 1812 1. The initiating daemon sends an ISA_INIT_REQ messages with ISAKMP SA #3, 1813 #2, and #1 (in priority order). These SAs are defined in C.1.1. 1815 2. The responding daemon sends an ISA_INIT_RESP message indicating that 1816 ISAKMP SA #2 was selected, which requires DNS Signature and Key 1817 Records and a Photuris compliant key exchange [DOW92]. 1819 3. The initiating daemon sends an ISA_KE_REQ packet with an index into 1820 well-known table of generator / prime pairs and it's public value. 1822 4. Upon receipt of ISA_KE_REQ packet the responding daemon computes the 1823 shared secret and session key. 1825 5. The responding daemon sends an ISA_KE_RESP packet with an its public 1826 value and both the initiator and responders public values signed 1827 using its Private (Signature) Key and encrypted in the session key 1828 created. 1830 6. Upon receipt of ISA_KE_REQ packet the initiating daemon computes the 1831 shared secret and session key. 1833 7. The initiating daemon sends an ISA_AUTH_REQ packet with both the 1834 initiator and responders public values signed using its Private 1835 (Signature) Key and it's DNS name and Public (Verification) Key 1836 signed by it nameserver. All encrypted in the session key created. 1838 8. The responding daemon sends an ISA_AUTH_RESP packet with it's DNS name 1839 and Public (Verification) signed by it Secure DNS nameserver and 1840 encrypted in the session key created. 1842 9. The initiating daemon sends an ISA_NEG_REQ packet with ESP SA #2, ESP 1843 SA #1, AH SA #1, and AH SA #2. These SAs are defined in C.2.1. 1845 10. The responding daemon sends an ISA_NEG_RESP packet indicating that ESP 1846 SA #2, and AH SA #1 was selected. 1848 A.2 Virtual Private Network Scenario 1850 This scenario show how ISAKMP can be used in a Virtual Public Network 1851 (VPN). The ability to establish SAs for more than just ESP and AH and one 1852 of the uses of the ISA_NOTIFY message are also illustrated. 1854 ___________________________Virtual_Public_Network_Scenario_______________________ 1855 End System#1 SFE#1 INTERNET SFE#2 End System #2 1856 _______ _______ 1857 Establish ES#1 To | | | | 1858 SFE#1 Connection | | | | 1860 SYN | | | | 1861 ===> | | | | 1862 | |Establish Connection Between SFEs | | 1863 | | | | 1864 | | SYN | | 1865 | | ===> | | 1866 | | SYN, ACK | | 1867 | | <======= | | 1868 | | ACK | | 1869 | | ===> | | 1870 | | | | 1871 | | Establish SA Between SFEs | | 1872 | | | | 1873 | | ISA_INIT_REQ | | 1874 | | ============> | | 1875 | | ISA_INIT_RESP | | 1876 | | <============ | | 1877 | | ISA_KE&AUTH_REQ | | 1878 | | ==============> | | 1879 | | ISA_KE&AUTH_RESP | | 1880 | | <=============== | | 1881 | | Secure Connection | |Establish SFE#2 1882 | | Between SFEs | |to ES#2 Connection 1883 | | | | 1884 | | | |SYN 1885 | | | |===> 1886 | | | |SYN, ACK 1887 | | | |<======= 1888 | | | |ACK 1889 | | | |===> 1890 | | ISA_NOTIFY(Status == Connected) | | 1891 SYN, ACK | | <==================== | | 1892 <======= | | | | 1893 ACK | | | | 1894 ===> | | | | 1895 | | | | 1896 | | Protected Traffic | | 1897 | | ES#1 to ES#2 | | 1898 |_______| <==============> |_______| 1900 The diagram shows an End System (ES) using a connection oriented proto- 1901 col (we use TCP as an example) establishing a connection with another ES. 1902 Both ES are behind Secure Front Ends (SFE) (e.g. firewalls). The connec- 1903 tion establishment from End System #1 (ES#1) is intercepted by its Secure 1904 Front End (SFE #1). SFE#1 establishes a connection and then a Security 1905 Association (SA), using normal ISAKMP SA establishment procedures, with 1906 SFE #2. Next SFE #2 establishes a connection with ES #2. Upon successful 1907 completion SFE #2 sends an SA_NOTIFY with Status equal Connected. SFE #1 1908 completes it's connection with ES #1 and normal end to end communications 1909 takes place secured between SFE #1 and SFE #2. If SFE #2 had been unable 1910 to establish a connection with ES #2 it would have returned an SA_NOTIFY 1911 with Status equal Not Connected with an optional reason code. 1913 B Security Association Attributes 1915 This appendix contains a list of security attributes that should be con- 1916 sidered when defining a Security Association (SA) for a security proto- 1917 col or application. As an example, the security attributes culled from 1918 this list and required for an IP Security (AH, ESP) SA are defined in 1919 [RFC-1825]. The separation of ISAKMP from a specific SA definition is im- 1920 portant to ensure ISAKMP can establish SAs for all possible security func- 1921 tionality. Each security function will be required to maintain a database 1922 of current SAs. This list is based upon an e-mail message [Kent94] to the 1923 IPSEC mail list from Steve Kent. 1925 The authors welcome input on what are meaningful security attributes for 1926 an SA. 1928 1. SAID.INBOUND 1930 2. SAID.OUTBOUND 1932 3. ENCAPSULATION 1934 4. INBOUND-CRITERIA 1936 (a) IP-DESTINATION-ADDRESS 1938 (b) IP-SOURCE-ADDRESS 1940 (c) NEXT-PROTOCOL 1942 (d) IP-SECURITY-LABEL 1944 (e) TRANSPORT-DESTINATION-PORT 1946 (f) TRANSPORT-SOURCE-PORT 1948 5. PEER-ADDRESS 1950 6. AUTHENTICATION 1952 (a) ENABLED 1954 (b) MECHANISM 1956 o DIGITAL SIGNATURE 1957 i. KEY.INBOUND (Peer's Public Key) 1959 ii. KEY.OUTBOUND (Initator's Private Key) 1961 7. ENCRYPTION 1963 (a) ENABLED 1965 (b) ALGORTIHM 1967 (c) KEY.INBOUND 1969 (d) KEY.OUTBOUND 1971 (e) IV.INBOUND 1973 (f) IV.OUTBOUND 1975 8. INTEGRITY 1977 (a) ENABLED 1979 (b) PLAINTEXT 1981 (c) DIRECTION.ENABLED 1983 (d) DIRECTION.VALUE 1985 (e) ALGORITHM 1987 (f) KEY.OUTBOUND 1989 (g) KEY.INBOUND 1991 9. COMPRESSION 1993 (a) ENABLED 1995 (b) ALGORITHM 1997 10. REPLAY 1999 (a) ENABLED 2000 (b) SIZE 2002 (c) NUMBER.OUTBOUND 2004 (d) NUMBER.INBOUND 2006 (e) WINDOW.SIZE 2008 (f) WINDOW 2010 11. FRAGMENTATION 2012 (a) INBOUND 2014 (b) OUTBOUND 2016 12. KEY-MANAGEMENT 2018 (a) NEGOTIATED 2020 (b) TECHNIQUE 2022 (c) PARAMETERS 2024 (d) REKEY 2026 o GRACE 2028 o NEXT-SA 2030 o TIME-BASED 2032 i. ENABLE 2034 ii. TRIGGER 2036 o TRAFFIC-BASED 2038 i. ENABLE 2040 ii. PACKET-COUNT.INBOUND 2042 iii. PACKET-COUNT.OUTBOUND 2043 iv. TRIGGER.INBOUND 2045 v. TRIGGER.OUTBOUND 2047 C Security Association Examples 2049 C.1 ISAKMP SA Definition 2051 The ISAKMP SA contains the SA attributes that are exchanged in the 2052 ISA_INIT messages. 2054 ISAKMP Security Association 2055 _______________________SA_Attributes_______________________Requirement__ 2056 Peer ISAKMP Daemon Address REQUIRED 2057 Security Association Lifetime REQUIRED 2058 Certificate Authority REQUIRED 2059 Digital Signature Algorithm REQUIRED 2060 Signature Key(s) REQUIRED 2061 Security Association Lifetime REQUIRED 2062 Key Establishment Algorithm REQUIRED 2063 Cookie Generation Algorithm REQUIRED 2064 Sensitivity Level (e.g. Secret, Unclassified) RECOMMENDED 2065 Encryption Algorithm RECOMMENDED 2066 Encryption Mode RECOMMENDED 2067 Encryption Transform RECOMMENDED 2068 Encryption Key(s) RECOMMENDED 2069 Key Lifetime or Key Rollover RECOMMENDED 2070 Presence / Absence of cryptographic synchronization or IV RECOMMENDED 2071 Size of cryptographic synchronization or IV RECOMMENDED 2073 C.1.1 ISAKMP SA Examples 2075 ISAKMP SA #1 2076 _________________________SA_Class_________________________________SA_Type_________ 2077 Peer ISAKMP Daemon Address N/A 2078 Security Association Lifetime 86400 seconds (1day) 2079 Certificate Authority DMS Root CAW 2080 Certificate Type X.509v1m 2081 Digital Signature Algorithm DSA 2082 Signature Key(s) N/A 2083 Security Association Lifetime 86400 seconds (1day) 2084 Key Establishment Algorithm Fortezza KEA 2085 Cookie Generation Algorithm SHA_1 2086 Sensitivity Level (e.g. Secret, Unclassified) Unclassified 2087 Encryption Algorithm Skipjack 2088 Encryption Mode CDC 2089 Encryption Transform NULL 2090 Encryption Key(s) N/A 2091 Key Lifetime or Key Rollover 3600 seconds (1 hour) 2092 Presence / Absence of cryptographic synchronization or IV Present 2093 Size of cryptographic synchronization or IV 64 bits 2095 ISAKMP SA #2 2096 _________________________SA_Class___________________________________SA_Type__________ 2097 Peer ISAKMP Daemon Address N/A 2098 Security Association Lifetime 86400 seconds (1day) 2099 Certificate Authority DNSSEC janeway.ncsc.mil 2100 Certificate Type RR 2101 Digital Signature Algorithm RSA 2102 Signature Key(s) N/A 2103 Security Association Lifetime 86400 seconds (1day) 2104 Key Establishment Algorithm X9.42_STS 2105 Cookie Generation Algorithm MD5 2106 Sensitivity Level (e.g. Secret, Unclassified) N/A 2107 Encryption Algorithm DES 2108 Encryption Mode CDC 2109 Encryption Transform RFC-1829 2110 Encryption Key(s) N/A 2111 Key Lifetime or Key Rollover 600 seconds (10 minutes) 2112 Presence / Absence of cryptographic synchronization or IV Present 2113 Size of cryptographic synchronization or IV 64 bits 2114 ISAKMP SA #3 2115 _________________________SA_Class___________________________________SA_Type__________ 2116 Peer ISAKMP Daemon Address N/A 2117 Security Association Lifetime 86400 seconds (1day) 2118 Certificate Authority IPRA PCA UNINETT 2119 Certificate Type X.509v1 2120 Digital Signature Algorithm RSA 2121 Signature Key(s) N/A 2122 Security Association Lifetime 86400 seconds (1day) 2123 Key Establishment Algorithm STS 2124 Cookie Generation Algorithm MD5 2125 Sensitivity Level (e.g. Secret, Unclassified) N/A 2126 Encryption Algorithm DES 2127 Encryption Mode CDC 2128 Encryption Transform RFC-1829 2129 Encryption Key(s) N/A 2130 Key Lifetime or Key Rollover 600 seconds (10 minutes) 2131 Presence / Absence of cryptographic synchronization or IV Present 2132 Size of cryptographic synchronization or IV 64 bits 2134 C.2 ESP SA and AH SA Definitions 2136 The following SAs are defined in [RFC-1825] and are presented here for 2137 comparative and completeness purposes. 2139 AH Security Association 2140 __________________SA_Attributes__________________Requirement_ 2141 Authentication Algorithm REQUIRED 2142 Authentication Mode REQUIRED 2143 Authentication Key(s) REQUIRED 2144 Key Lifetime or Key Rollover RECOMMENDED 2145 Security Association Lifetime RECOMMENDED 2146 Sensitivity Level (e.g. Secret, Unclassified) RECOMMENDED 2147 ESP Security Association 2148 _______________________SA_Attributes_______________________Requirement__ 2149 Encryption Algorithm REQUIRED 2150 Encryption Mode REQUIRED 2151 Encryption Transform REQUIRED 2152 Encryption Key(s) REQUIRED 2153 Presence / Absence of cryptographic synchronization or IV REQUIRED 2154 Size of cryptographic synchronization or IV REQUIRED 2155 Authentication Algorithm RECOMMENDED 2156 Authentication Mode RECOMMENDED 2157 Authentication Key(s) RECOMMENDED 2158 Key Lifetime or Key Rollover RECOMMENDED 2159 Security Association Lifetime RECOMMENDED 2160 Sensitivity Level (e.g. Secret, Unclassified) RECOMMENDED 2162 C.2.1 ESP and AH SA Examples 2164 AH SA #1 2165 ____________________SA_Class_____________________________SA_Type__________ 2167 Authentication Algorithm MD5 2168 Authentication Mode Keyed 2169 Authentication Key(s) Photuris 2170 Key Lifetime or Key Rollover 600 seconds (10 minutes) 2171 Security Association Lifetime 3600 seconds (1 hour) 2172 Sensitivity Level (e.g. Secret, Unclassified) N/A 2174 AH SA #2 2175 ____________________SA_Class_____________________________SA_Type__________ 2176 Authentication Algorithm SHA 2177 Authentication Mode NULL 2178 Authentication Key(s) NULL 2179 Key Lifetime or Key Rollover 600 seconds (10 minutes) 2180 Security Association Lifetime 3600 seconds (1 hour) 2181 Sensitivity Level (e.g. Secret, Unclassified) N/A 2182 ESP SA #1 2183 _________________________SA_Class___________________________________SA_Type__________ 2184 Encryption Algorithm DES 2185 Encryption Mode CBC 2186 Encryption Transform RFC-1829 2187 Encryption Key(s) Phutoris Generated 2188 Presence / Absence of cryptographic synchronization or IV Present 2189 Size of cryptographic synchronization or IV 64 bits 2190 Authentication Algorithm NULL 2191 Authentication Mode NULL 2192 Authentication Key(s) NULL 2193 Key Lifetime or Key Rollover 600 seconds (10 minutes) 2194 Security Association Lifetime 3600 seconds (1 hour) 2195 Sensitivity Level (e.g. Secret, Unclassified) N/A 2197 ESP SA #2 2198 _________________________SA_Class___________________________________SA_Type__________ 2199 Encryption Algorithm DES 2200 Encryption Mode CBC 2201 Encryption Transform RFC-1829 2202 Encryption Key(s) X9.42_DH Generated 2203 Presence / Absence of cryptographic synchronization or IV Present 2204 Size of cryptographic synchronization or IV 64 bits 2205 Authentication Algorithm NULL 2206 Authentication Mode NULL 2207 Authentication Key(s) NULL 2208 Key Lifetime or Key Rollover 600 seconds (10 minutes) 2209 Security Association Lifetime 3600 seconds (1 hour) 2210 Sensitivity Level (e.g. Secret, Unclassified) N/A 2212 C.2.2 Fortezza SA Examples 2214 Fortezza AH SA 2215 ____________________SA_Class___________________________SA_Type________ 2216 Authentication Algorithm SHA 2217 Authentication Mode NULL 2218 Authentication Key(s) DMS Root CAW 2219 Key Lifetime or Key Rollover 86400 seconds (1day) 2220 Security Association Lifetime 86400 seconds (1day) 2221 Sensitivity Level (e.g. Secret, Unclassified) N/A 2222 Fortezza ESP SA 2223 _________________________SA_Class__________________________________SA_Type_________ 2224 Encryption Algorithm Skipjack 2225 Encryption Mode CBC 2226 Encryption Transform NULL 2227 Encryption Key(s) Fortezza KEA Generated 2228 Presence / Absence of cryptographic synchronization or IV Present 2229 Size of cryptographic synchronization or IV 64 bits 2230 Authentication Algorithm DSA 2231 Authentication Mode NULL 2232 Authentication Key(s) DMS Root CAW 2233 Key Lifetime or Key Rollover 3600 seconds (1 hour) 2234 Security Association Lifetime 86400 seconds (1day) 2235 Sensitivity Level (e.g. Secret, Unclassified) Unclassified 2236 Security Considerations 2238 Cryptographic analysis techniques are improving at a steady pace. The 2239 continuing improvement in processing power makes once computational pro- 2240 hibitive cryptographic attacks more realistic. New cryptographic algo- 2241 rithms and public key generation techniques are also being developed at a 2242 steady pace. New security services and mechanisms are being developed at 2243 an accelerated pace. A consistent method of choosing from a variety of 2244 security services and mechanisms and to exchange attributes required by 2245 the mechanisms is important to security in the complex structure of the 2246 Internet. However a system that locks itself into a single cryptographic 2247 algorithm, key exchange technique, or security mechanism will become in- 2248 creasingly vulnerable as time passes. 2250 UDP is an unreliable datagram protocol and therefore its use in ISAKMP in- 2251 troduces a number of security considerations. Since UDP is unreliable, 2252 but a key management protocol must be reliable, the reliability is built 2253 into ISAKMP. While ISAKMP utilizes UDP as its transport mechanism, it 2254 doesn't soley rely on any UDP information (e.g. checksum, length) for its 2255 processing. 2257 Another issue that must be considered in the development of IKMP is the 2258 effect of firewalls on the protocol. Many firewalls filter out all UDP 2259 packets, making reliance on UDP questionable in certian environments. 2261 A number of very important security considerations are presented in 2262 [RFC-1825]. One bares repeating. Once a private session key is created 2263 it must be safely stored. Failure to properly protect the private key 2264 from access both internal and external to the system completely nullifies 2265 any protect provided by the IP Security services. 2267 Acknowledgements 2269 Marsha Gross, Bill Kutz, Mike Oehler, Mark Schneider, and Pete Sell pro- 2270 vided significant input and review to this document. 2272 Thanks to Carl Muckenhirn of SPARTA, Inc. for his assistance with LaTeX. 2274 References 2276 [ANSI94] ANSI, X9.42: Public Key Cryptography for the Financial Services 2277 Industry -- Establishment of Symmetric Algorithm Keys Using 2278 Diffie-Hellman, Working Draft, October 26, 1995. 2280 [DOW92] W. Diffie, M.Wiener, P. Van Oorschot, Authtication and 2281 Authenticated Key Exchanges, Designs, Codes, and Cryptography, 2, 2282 107-125, Kluwer Academic Publishers, 1992. 2284 [Berg] Berge, N.H., UNINETT PCA Policy Statements, Internet-Draft, work 2285 in progress, November, 1995. 2287 [EK94] Eastlake III, D. and C. Kaufman, Domain Name System Protocol 2288 Security Extensions, Internet-Draft, work in progress, Oct, 1995. 2290 [Karn95] Karn P. and B. Simpson, The Photuris Key Management Protocol, 2291 Internet-Draft, work in progress, November, 1995. 2293 [Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August 10, 2294 1994. 2296 [RFC-1155] Rose M. and K. McCloghrie, Structure and Identification of 2297 Management Information for TCP/IP-based Internets, RFC-1155, May, 2298 1990. 2300 [RFC-1212] McCloghrie K. and M. Rose, Concise MIB Definitions, RFC-1212, 2301 March 26, 1991. 2303 [RFC-1213] McCloghrie K. and M. Rose, Management Information Base for 2304 Network Management of TCP/IP-based Internets: MIB-II, RFC-1213, 2305 March 26, 1991. 2307 [RFC-1422] Steve Kent, Privacy Enhancement for Internet Electronic Mail: 2308 Part II: Certificate-Based Key Management, RFC-1422, February 1993. 2310 [RFC-1825] Randell Atkinson, Security Architecture for the Internet 2311 Protocol, RFC-1825, August, 1995. 2313 [Secu] SECUREWARE INC., Peer Authentication and Key Management Protocol 2314 Specification, Version 2.2, October 27, 1995. 2316 [Schn94] Bruce Schneier, Applied Cryptography - Protocols, Algorithms, 2317 and Source Code in C, John Wiley & Sons, Inc., 1994. 2319 [Spar94a] Harney H., C. Muckenhirn, and T. Rivers, Group Key Management 2320 (GKMP) Architecture, SPARTA, Inc., Internet-Draft, September, 1994. 2322 [Spar94b] Harney H., C. Muckenhirn, and T. Rivers, Group Key Management 2323 (GKMP) Specification, SPARTA, Inc., Internet-Draft, September, 1994. 2325 Addresses of Authors 2327 The two authors are with: 2329 National Security Agency 2330 ATTN: R23 2331 9800 Savage Road 2332 Ft. Meade, MD. 20755-6000 2334 Douglas Maughan 2335 Phone: 301-688-0847 2336 E-mail:wdmaugh@tycho.ncsc.mil 2338 Mark Schertler 2339 Phone: 301-688-0849 2340 E-mail:mjs@tycho.ncsc.mil