| blob | c3af56268c9cad8616241eb76bd19fe121aa1145 |
7 Network Working Group D. Maughan
8 Request for Comments: 2408 National Security Agency
9 Category: Standards Track M. Schertler
10 Securify, Inc.
11 M. Schneider
12 National Security Agency
13 J. Turner
14 RABA Technologies, Inc.
15 November 1998
18 Internet Security Association and Key Management Protocol (ISAKMP)
20 Status of this Memo
22 This document specifies an Internet standards track protocol for the
23 Internet community, and requests discussion and suggestions for
24 improvements. Please refer to the current edition of the "Internet
25 Official Protocol Standards" (STD 1) for the standardization state
26 and status of this protocol. Distribution of this memo is unlimited.
28 Copyright Notice
30 Copyright (C) The Internet Society (1998). All Rights Reserved.
32 Abstract
34 This memo describes a protocol utilizing security concepts necessary
35 for establishing Security Associations (SA) and cryptographic keys in
36 an Internet environment. A Security Association protocol that
37 negotiates, establishes, modifies and deletes Security Associations
38 and their attributes is required for an evolving Internet, where
39 there will be numerous security mechanisms and several options for
40 each security mechanism. The key management protocol must be robust
41 in order to handle public key generation for the Internet community
42 at large and private key requirements for those private networks with
43 that requirement. The Internet Security Association and Key
44 Management Protocol (ISAKMP) defines the procedures for
45 authenticating a communicating peer, creation and management of
46 Security Associations, key generation techniques, and threat
47 mitigation (e.g. denial of service and replay attacks). All of
48 these are necessary to establish and maintain secure communications
49 (via IP Security Service or any other security protocol) in an
50 Internet environment.
58 Maughan, et. al. Standards Track [Page 1]
59 \f
60 RFC 2408 ISAKMP November 1998
63 Table of Contents
65 1 Introduction 4
66 1.1 Requirements Terminology . . . . . . . . . . . . . . . . . 5
67 1.2 The Need for Negotiation . . . . . . . . . . . . . . . . . 5
68 1.3 What can be Negotiated? . . . . . . . . . . . . . . . . . 6
69 1.4 Security Associations and Management . . . . . . . . . . . 7
70 1.4.1 Security Associations and Registration . . . . . . . . 7
71 1.4.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 8
72 1.5 Authentication . . . . . . . . . . . . . . . . . . . . . . 8
73 1.5.1 Certificate Authorities . . . . . . . . . . . . . . . 9
74 1.5.2 Entity Naming . . . . . . . . . . . . . . . . . . . . 9
75 1.5.3 ISAKMP Requirements . . . . . . . . . . . . . . . . . 10
76 1.6 Public Key Cryptography . . . . . . . . . . . . . . . . . . 10
77 1.6.1 Key Exchange Properties . . . . . . . . . . . . . . . 11
78 1.6.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 12
79 1.7 ISAKMP Protection . . . . . . . . . . . . . . . . . . . . . 12
80 1.7.1 Anti-Clogging (Denial of Service) . . . . . . . . . . 12
81 1.7.2 Connection Hijacking . . . . . . . . . . . . . . . . . 13
82 1.7.3 Man-in-the-Middle Attacks . . . . . . . . . . . . . . 13
83 1.8 Multicast Communications . . . . . . . . . . . . . . . . . 13
84 2 Terminology and Concepts 14
85 2.1 ISAKMP Terminology . . . . . . . . . . . . . . . . . . . . 14
86 2.2 ISAKMP Placement . . . . . . . . . . . . . . . . . . . . . 16
87 2.3 Negotiation Phases . . . . . . . . . . . . . . . . . . . . 16
88 2.4 Identifying Security Associations . . . . . . . . . . . . . 17
89 2.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . 20
90 2.5.1 Transport Protocol . . . . . . . . . . . . . . . . . . 20
91 2.5.2 RESERVED Fields . . . . . . . . . . . . . . . . . . . 20
92 2.5.3 Anti-Clogging Token ("Cookie") Creation . . . . . . . 20
93 3 ISAKMP Payloads 21
94 3.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 21
95 3.2 Generic Payload Header . . . . . . . . . . . . . . . . . . 25
96 3.3 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 25
97 3.4 Security Association Payload . . . . . . . . . . . . . . . 27
98 3.5 Proposal Payload . . . . . . . . . . . . . . . . . . . . . 28
99 3.6 Transform Payload . . . . . . . . . . . . . . . . . . . . . 29
100 3.7 Key Exchange Payload . . . . . . . . . . . . . . . . . . . 31
101 3.8 Identification Payload . . . . . . . . . . . . . . . . . . 32
102 3.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . 33
103 3.10 Certificate Request Payload . . . . . . . . . . . . . . . 34
104 3.11 Hash Payload . . . . . . . . . . . . . . . . . . . . . . 36
105 3.12 Signature Payload . . . . . . . . . . . . . . . . . . . . 37
106 3.13 Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 37
107 3.14 Notification Payload . . . . . . . . . . . . . . . . . . 38
108 3.14.1 Notify Message Types . . . . . . . . . . . . . . . . 40
109 3.15 Delete Payload . . . . . . . . . . . . . . . . . . . . . 41
110 3.16 Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 43
114 Maughan, et. al. Standards Track [Page 2]
115 \f
116 RFC 2408 ISAKMP November 1998
119 4 ISAKMP Exchanges 44
120 4.1 ISAKMP Exchange Types . . . . . . . . . . . . . . . . . . . 45
121 4.1.1 Notation . . . . . . . . . . . . . . . . . . . . . . . 46
122 4.2 Security Association Establishment . . . . . . . . . . . . 46
123 4.2.1 Security Association Establishment Examples . . . . . 48
124 4.3 Security Association Modification . . . . . . . . . . . . . 50
125 4.4 Base Exchange . . . . . . . . . . . . . . . . . . . . . . . 51
126 4.5 Identity Protection Exchange . . . . . . . . . . . . . . . 52
127 4.6 Authentication Only Exchange . . . . . . . . . . . . . . . 54
128 4.7 Aggressive Exchange . . . . . . . . . . . . . . . . . . . . 55
129 4.8 Informational Exchange . . . . . . . . . . . . . . . . . . 57
130 5 ISAKMP Payload Processing 58
131 5.1 General Message Processing . . . . . . . . . . . . . . . . 58
132 5.2 ISAKMP Header Processing . . . . . . . . . . . . . . . . . 59
133 5.3 Generic Payload Header Processing . . . . . . . . . . . . . 61
134 5.4 Security Association Payload Processing . . . . . . . . . . 62
135 5.5 Proposal Payload Processing . . . . . . . . . . . . . . . . 63
136 5.6 Transform Payload Processing . . . . . . . . . . . . . . . 64
137 5.7 Key Exchange Payload Processing . . . . . . . . . . . . . . 65
138 5.8 Identification Payload Processing . . . . . . . . . . . . . 66
139 5.9 Certificate Payload Processing . . . . . . . . . . . . . . 66
140 5.10 Certificate Request Payload Processing . . . . . . . . . 67
141 5.11 Hash Payload Processing . . . . . . . . . . . . . . . . . 69
142 5.12 Signature Payload Processing . . . . . . . . . . . . . . 69
143 5.13 Nonce Payload Processing . . . . . . . . . . . . . . . . 70
144 5.14 Notification Payload Processing . . . . . . . . . . . . . 71
145 5.15 Delete Payload Processing . . . . . . . . . . . . . . . . 73
146 6 Conclusions 75
147 A ISAKMP Security Association Attributes 77
148 A.1 Background/Rationale . . . . . . . . . . . . . . . . . . . 77
149 A.2 Internet IP Security DOI Assigned Value . . . . . . . . . . 77
150 A.3 Supported Security Protocols . . . . . . . . . . . . . . . 77
151 A.4 ISAKMP Identification Type Values . . . . . . . . . . . . . 78
152 A.4.1 ID_IPV4_ADDR . . . . . . . . . . . . . . . . . . . . . 78
153 A.4.2 ID_IPV4_ADDR_SUBNET . . . . . . . . . . . . . . . . . . 78
154 A.4.3 ID_IPV6_ADDR . . . . . . . . . . . . . . . . . . . . . 78
155 A.4.4 ID_IPV6_ADDR_SUBNET . . . . . . . . . . . . . . . . . 78
156 B Defining a new Domain of Interpretation 79
157 B.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . 79
158 B.2 Security Policies . . . . . . . . . . . . . . . . . . . . . 80
159 B.3 Naming Schemes . . . . . . . . . . . . . . . . . . . . . . 80
160 B.4 Syntax for Specifying Security Services . . . . . . . . . . 80
161 B.5 Payload Specification . . . . . . . . . . . . . . . . . . . 80
162 B.6 Defining new Exchange Types . . . . . . . . . . . . . . . . 80
163 Security Considerations 81
164 IANA Considerations 81
165 Domain of Interpretation 81
166 Supported Security Protocols 82
170 Maughan, et. al. Standards Track [Page 3]
171 \f
172 RFC 2408 ISAKMP November 1998
175 Acknowledgements 82
176 References 82
177 Authors' Addresses 85
178 Full Copyright Statement 86
180 List of Figures
182 1 ISAKMP Relationships . . . . . . . . . . . . . . . . . . . 16
183 2 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 22
184 3 Generic Payload Header . . . . . . . . . . . . . . . . . . 25
185 4 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 26
186 5 Security Association Payload . . . . . . . . . . . . . . . 27
187 6 Proposal Payload Format . . . . . . . . . . . . . . . . . . 28
188 7 Transform Payload Format . . . . . . . . . . . . . . . . . 30
189 8 Key Exchange Payload Format . . . . . . . . . . . . . . . . 31
190 9 Identification Payload Format . . . . . . . . . . . . . . . 32
191 10 Certificate Payload Format . . . . . . . . . . . . . . . . 33
192 11 Certificate Request Payload Format . . . . . . . . . . . . 34
193 12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . 36
194 13 Signature Payload Format . . . . . . . . . . . . . . . . . 37
195 14 Nonce Payload Format . . . . . . . . . . . . . . . . . . . 38
196 15 Notification Payload Format . . . . . . . . . . . . . . . . 39
197 16 Delete Payload Format . . . . . . . . . . . . . . . . . . . 42
198 17 Vendor ID Payload Format . . . . . . . . . . . . . . . . . 44
200 1 Introduction
202 This document describes an Internet Security Association and Key
203 Management Protocol (ISAKMP). ISAKMP combines the security concepts
204 of authentication, key management, and security associations to
205 establish the required security for government, commercial, and
206 private communications on the Internet.
208 The Internet Security Association and Key Management Protocol
209 (ISAKMP) defines procedures and packet formats to establish,
210 negotiate, modify and delete Security Associations (SA). SAs contain
211 all the information required for execution of various network
212 security services, such as the IP layer services (such as header
213 authentication and payload encapsulation), transport or application
214 layer services, or self-protection of negotiation traffic. ISAKMP
215 defines payloads for exchanging key generation and authentication
216 data. These formats provide a consistent framework for transferring
217 key and authentication data which is independent of the key
218 generation technique, encryption algorithm and authentication
219 mechanism.
226 Maughan, et. al. Standards Track [Page 4]
227 \f
228 RFC 2408 ISAKMP November 1998
231 ISAKMP is distinct from key exchange protocols in order to cleanly
232 separate the details of security association management (and key
233 management) from the details of key exchange. There may be many
234 different key exchange protocols, each with different security
235 properties. However, a common framework is required for agreeing to
236 the format of SA attributes, and for negotiating, modifying, and
237 deleting SAs. ISAKMP serves as this common framework.
239 Separating the functionality into three parts adds complexity to the
240 security analysis of a complete ISAKMP implementation. However, the
241 separation is critical for interoperability between systems with
242 differing security requirements, and should also simplify the
243 analysis of further evolution of a ISAKMP server.
245 ISAKMP is intended to support the negotiation of SAs for security
246 protocols at all layers of the network stack (e.g., IPSEC, TLS, TLSP,
247 OSPF, etc.). By centralizing the management of the security
248 associations, ISAKMP reduces the amount of duplicated functionality
249 within each security protocol. ISAKMP can also reduce connection
250 setup time, by negotiating a whole stack of services at once.
252 The remainder of section 1 establishes the motivation for security
253 negotiation and outlines the major components of ISAKMP, i.e.
254 Security Associations and Management, Authentication, Public Key
255 Cryptography, and Miscellaneous items. Section 2 presents the
256 terminology and concepts associated with ISAKMP. Section 3 describes
257 the different ISAKMP payload formats. Section 4 describes how the
258 payloads of ISAKMP are composed together as exchange types to
259 establish security associations and perform key exchanges in an
260 authenticated manner. Additionally, security association
261 modification, deletion, and error notification are discussed.
262 Section 5 describes the processing of each payload within the context
263 of ISAKMP exchanges, including error handling and associated actions.
264 The appendices provide the attribute values necessary for ISAKMP and
265 requirement for defining a new Domain of Interpretation (DOI) within
266 ISAKMP.
268 1.1 Requirements Terminology
270 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
271 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
272 document, are to be interpreted as described in [RFC-2119].
274 1.2 The Need for Negotiation
276 ISAKMP extends the assertion in [DOW92] that authentication and key
277 exchanges must be combined for better security to include security
278 association exchanges. The security services required for
282 Maughan, et. al. Standards Track [Page 5]
283 \f
284 RFC 2408 ISAKMP November 1998
287 communications depends on the individual network configurations and
288 environments. Organizations are setting up Virtual Private Networks
289 (VPN), also known as Intranets, that will require one set of security
290 functions for communications within the VPN and possibly many
291 different security functions for communications outside the VPN to
292 support geographically separate organizational components, customers,
293 suppliers, sub-contractors (with their own VPNs), government, and
294 others. Departments within large organizations may require a number
295 of security associations to separate and protect data (e.g.
296 personnel data, company proprietary data, medical) on internal
297 networks and other security associations to communicate within the
298 same department. Nomadic users wanting to "phone home" represent
299 another set of security requirements. These requirements must be
300 tempered with bandwidth challenges. Smaller groups of people may
301 meet their security requirements by setting up "Webs of Trust".
302 ISAKMP exchanges provide these assorted networking communities the
303 ability to present peers with the security functionality that the
304 user supports in an authenticated and protected manner for agreement
305 upon a common set of security attributes, i.e. an interoperable
306 security association.
308 1.3 What can be Negotiated?
310 Security associations must support different encryption algorithms,
311 authentication mechanisms, and key establishment algorithms for other
312 security protocols, as well as IP Security. Security associations
313 must also support host-oriented certificates for lower layer
314 protocols and user- oriented certificates for higher level protocols.
315 Algorithm and mechanism independence is required in applications such
316 as e-mail, remote login, and file transfer, as well as in session
317 oriented protocols, routing protocols, and link layer protocols.
318 ISAKMP provides a common security association and key establishment
319 protocol for this wide range of security protocols, applications,
320 security requirements, and network environments.
322 ISAKMP is not bound to any specific cryptographic algorithm, key
323 generation technique, or security mechanism. This flexibility is
324 beneficial for a number of reasons. First, it supports the dynamic
325 communications environment described above. Second, the independence
326 from specific security mechanisms and algorithms provides a forward
327 migration path to better mechanisms and algorithms. When improved
328 security mechanisms are developed or new attacks against current
329 encryption algorithms, authentication mechanisms and key exchanges
330 are discovered, ISAKMP will allow the updating of the algorithms and
331 mechanisms without having to develop a completely new KMP or patch
332 the current one.
338 Maughan, et. al. Standards Track [Page 6]
339 \f
340 RFC 2408 ISAKMP November 1998
343 ISAKMP has basic requirements for its authentication and key exchange
344 components. These requirements guard against denial of service,
345 replay / reflection, man-in-the-middle, and connection hijacking
346 attacks. This is important because these are the types of attacks
347 that are targeted against protocols. Complete Security Association
348 (SA) support, which provides mechanism and algorithm independence,
349 and protection from protocol threats are the strengths of ISAKMP.
351 1.4 Security Associations and Management
353 A Security Association (SA) is a relationship between two or more
354 entities that describes how the entities will utilize security
355 services to communicate securely. This relationship is represented
356 by a set of information that can be considered a contract between the
357 entities. The information must be agreed upon and shared between all
358 the entities. Sometimes the information alone is referred to as an
359 SA, but this is just a physical instantiation of the existing
360 relationship. The existence of this relationship, represented by the
361 information, is what provides the agreed upon security information
362 needed by entities to securely interoperate. All entities must
363 adhere to the SA for secure communications to be possible. When
364 accessing SA attributes, entities use a pointer or identifier refered
365 to as the Security Parameter Index (SPI). [SEC-ARCH] provides details
366 on IP Security Associations (SA) and Security Parameter Index (SPI)
367 definitions.
369 1.4.1 Security Associations and Registration
371 The SA attributes required and recommended for the IP Security (AH,
372 ESP) are defined in [SEC-ARCH]. The attributes specified for an IP
373 Security SA include, but are not limited to, authentication
374 mechanism, cryptographic algorithm, algorithm mode, key length, and
375 Initialization Vector (IV). Other protocols that provide algorithm
376 and mechanism independent security MUST define their requirements for
377 SA attributes. The separation of ISAKMP from a specific SA
378 definition is important to ensure ISAKMP can es tablish SAs for all
379 possible security protocols and applications.
381 NOTE: See [IPDOI] for a discussion of SA attributes that should be
382 considered when defining a security protocol or application.
384 In order to facilitate easy identification of specific attributes
385 (e.g. a specific encryption algorithm) among different network
386 entites the attributes must be assigned identifiers and these
387 identifiers must be registered by a central authority. The Internet
388 Assigned Numbers Authority (IANA) provides this function for the
389 Internet.
394 Maughan, et. al. Standards Track [Page 7]
395 \f
396 RFC 2408 ISAKMP November 1998
399 1.4.2 ISAKMP Requirements
401 Security Association (SA) establishment MUST be part of the key
402 management protocol defined for IP based networks. The SA concept is
403 required to support security protocols in a diverse and dynamic
404 networking environment. Just as authentication and key exchange must
405 be linked to provide assurance that the key is established with the
406 authenticated party [DOW92], SA establishment must be linked with the
407 authentication and the key exchange protocol.
409 ISAKMP provides the protocol exchanges to establish a security
410 association between negotiating entities followed by the
411 establishment of a security association by these negotiating entities
412 in behalf of some protocol (e.g. ESP/AH). First, an initial protocol
413 exchange allows a basic set of security attributes to be agreed upon.
414 This basic set provides protection for subsequent ISAKMP exchanges.
415 It also indicates the authentication method and key exchange that
416 will be performed as part of the ISAKMP protocol. If a basic set of
417 security attributes is already in place between the negotiating
418 server entities, the initial ISAKMP exchange may be skipped and the
419 establishment of a security association can be done directly. After
420 the basic set of security attributes has been agreed upon, initial
421 identity authenticated, and required keys generated, the established
422 SA can be used for subsequent communications by the entity that
423 invoked ISAKMP. The basic set of SA attributes that MUST be
424 implemented to provide ISAKMP interoperability are defined in
425 Appendix A.
427 1.5 Authentication
429 A very important step in establishing secure network communications
430 is authentication of the entity at the other end of the
431 communication. Many authentication mechanisms are available.
432 Authentication mechanisms fall into two catagories of strength - weak
433 and strong. Sending cleartext keys or other unprotected
434 authenticating information over a network is weak, due to the threat
435 of reading them with a network sniffer. Additionally, sending one-
436 way hashed poorly-chosen keys with low entropy is also weak, due to
437 the threat of brute-force guessing attacks on the sniffed messages.
438 While passwords can be used for establishing identity, they are not
439 considered in this context because of recent statements from the
440 Internet Architecture Board [IAB]. Digital signatures, such as the
441 Digital Signature Standard (DSS) and the Rivest-Shamir-Adleman (RSA)
442 signature, are public key based strong authentication mechanisms.
443 When using public key digital signatures each entity requires a
444 public key and a private key. Certificates are an essential part of
445 a digital signature authentication mechanism. Certificates bind a
446 specific entity's identity (be it host, network, user, or
450 Maughan, et. al. Standards Track [Page 8]
451 \f
452 RFC 2408 ISAKMP November 1998
455 application) to its public keys and possibly other security-related
456 information such as privileges, clearances, and compartments.
457 Authentication based on digital signatures requires a trusted third
458 party or certificate authority to create, sign and properly
459 distribute certificates. For more detailed information on digital
460 signatures, such as DSS and RSA, and certificates see [Schneier].
462 1.5.1 Certificate Authorities
464 Certificates require an infrastructure for generation, verification,
465 revocation, management and distribution. The Internet Policy
466 Registration Authority (IPRA) [RFC-1422] has been established to
467 direct this infrastructure for the IETF. The IPRA certifies Policy
468 Certification Authorities (PCA). PCAs control Certificate Authorities
469 (CA) which certify users and subordinate entities. Current
470 certificate related work includes the Domain Name System (DNS)
471 Security Extensions [DNSSEC] which will provide signed entity keys in
472 the DNS. The Public Key Infrastucture (PKIX) working group is
473 specifying an Internet profile for X.509 certificates. There is also
474 work going on in industry to develop X.500 Directory Services which
475 would provide X.509 certificates to users. The U.S. Post Office is
476 developing a (CA) hierarchy. The NIST Public Key Infrastructure
477 Working Group has also been doing work in this area. The DOD Multi
478 Level Information System Security Initiative (MISSI) program has
479 begun deploying a certificate infrastructure for the U.S. Government.
480 Alternatively, if no infrastructure exists, the PGP Web of Trust
481 certificates can be used to provide user authentication and privacy
482 in a community of users who know and trust each other.
484 1.5.2 Entity Naming
486 An entity's name is its identity and is bound to its public keys in
487 certificates. The CA MUST define the naming semantics for the
488 certificates it issues. See the UNINETT PCA Policy Statements
489 [Berge] for an example of how a CA defines its naming policy. When
490 the certificate is verified, the name is verified and that name will
491 have meaning within the realm of that CA. An example is the DNS
492 security extensions which make DNS servers CAs for the zones and
493 nodes they serve. Resource records are provided for public keys and
494 signatures on those keys. The names associated with the keys are IP
495 addresses and domain names which have meaning to entities accessing
496 the DNS for this information. A Web of Trust is another example.
497 When webs of trust are set up, names are bound with the public keys.
498 In PGP the name is usually the entity's e-mail address which has
499 meaning to those, and only those, who understand e-mail. Another web
500 of trust could use an entirely different naming scheme.
506 Maughan, et. al. Standards Track [Page 9]
507 \f
508 RFC 2408 ISAKMP November 1998
511 1.5.3 ISAKMP Requirements
513 Strong authentication MUST be provided on ISAKMP exchanges. Without
514 being able to authenticate the entity at the other end, the Security
515 Association (SA) and session key established are suspect. Without
516 authentication you are unable to trust an entity's identification,
517 which makes access control questionable. While encryption (e.g.
518 ESP) and integrity (e.g. AH) will protect subsequent communications
519 from passive eavesdroppers, without authentication it is possible
520 that the SA and key may have been established with an adversary who
521 performed an active man-in-the-middle attack and is now stealing all
522 your personal data.
524 A digital signature algorithm MUST be used within ISAKMP's
525 authentication component. However, ISAKMP does not mandate a
526 specific signature algorithm or certificate authority (CA). ISAKMP
527 allows an entity initiating communications to indicate which CAs it
528 supports. After selection of a CA, the protocol provides the
529 messages required to support the actual authentication exchange. The
530 protocol provides a facility for identification of different
531 certificate authorities, certificate types (e.g. X.509, PKCS #7,
532 PGP, DNS SIG and KEY records), and the exchange of the certificates
533 identified.
535 ISAKMP utilizes digital signatures, based on public key cryptography,
536 for authentication. There are other strong authentication systems
537 available, which could be specified as additional optional
538 authentication mechanisms for ISAKMP. Some of these authentication
539 systems rely on a trusted third party called a key distribution
540 center (KDC) to distribute secret session keys. An example is
541 Kerberos, where the trusted third party is the Kerberos server, which
542 holds secret keys for all clients and servers within its network
543 domain. A client's proof that it holds its secret key provides
544 authenticaton to a server.
546 The ISAKMP specification does not specify the protocol for
547 communicating with the trusted third parties (TTP) or certificate
548 directory services. These protocols are defined by the TTP and
549 directory service themselves and are outside the scope of this
550 specification. The use of these additional services and protocols
551 will be described in a Key Exchange specific document.
553 1.6 Public Key Cryptography
555 Public key cryptography is the most flexible, scalable, and efficient
556 way for users to obtain the shared secrets and session keys needed to
557 support the large number of ways Internet users will interoperate.
558 Many key generation algorithms, that have different properties, are
562 Maughan, et. al. Standards Track [Page 10]
563 \f
564 RFC 2408 ISAKMP November 1998
567 available to users (see [DOW92], [ANSI], and [Oakley]). Properties
568 of key exchange protocols include the key establishment method,
569 authentication, symmetry, perfect forward secrecy, and back traffic
570 protection.
572 NOTE: Cryptographic keys can protect information for a considerable
573 length of time. However, this is based on the assumption that keys
574 used for protection of communications are destroyed after use and not
575 kept for any reason.
577 1.6.1 Key Exchange Properties
579 Key Establishment (Key Generation / Key Transport): The two common
580 methods of using public key cryptography for key establishment are
581 key transport and key generation. An example of key transport is the
582 use of the RSA algorithm to encrypt a randomly generated session key
583 (for encrypting subsequent communications) with the recipient's
584 public key. The encrypted random key is then sent to the recipient,
585 who decrypts it using his private key. At this point both sides have
586 the same session key, however it was created based on input from only
587 one side of the communications. The benefit of the key transport
588 method is that it has less computational overhead than the following
589 method. The Diffie-Hellman (D-H) algorithm illustrates key
590 generation using public key cryptography. The D-H algorithm is begun
591 by two users exchanging public information. Each user then
592 mathematically combines the other's public information along with
593 their own secret information to compute a shared secret value. This
594 secret value can be used as a session key or as a key encryption key
595 for encrypting a randomly generated session key. This method
596 generates a session key based on public and secret information held
597 by both users. The benefit of the D-H algorithm is that the key used
598 for encrypting messages is based on information held by both users
599 and the independence of keys from one key exchange to another
600 provides perfect forward secrecy. Detailed descriptions of these
601 algorithms can be found in [Schneier]. There are a number of
602 variations on these two key generation schemes and these variations
603 do not necessarily interoperate.
605 Key Exchange Authentication: Key exchanges may be authenticated
606 during the protocol or after protocol completion. Authentication of
607 the key exchange during the protocol is provided when each party
608 provides proof it has the secret session key before the end of the
609 protocol. Proof can be provided by encrypting known data in the
610 secret session key during the protocol echange. Authentication after
611 the protocol must occur in subsequent commu nications.
612 Authentication during the protocol is preferred so subsequent
613 communications are not initiated if the secret session key is not
614 established with the desired party.
618 Maughan, et. al. Standards Track [Page 11]
619 \f
620 RFC 2408 ISAKMP November 1998
623 Key Exchange Symmetry: A key exchange provides symmetry if either
624 party can initiate the exchange and exchanged messages can cross in
625 transit without affecting the key that is generated. This is
626 desirable so that computation of the keys does not require either
627 party to know who initated the exchange. While key exchange symmetry
628 is desirable, symmetry in the entire key management protocol may
629 provide a vulnerablity to reflection attacks.
631 Perfect Forward Secrecy: As described in [DOW92], an authenticated
632 key exchange protocol provides perfect forward secrecy if disclosure
633 of longterm secret keying material does not compromise the secrecy of
634 the exchanged keys from previous communications. The property of
635 perfect forward secrecy does not apply to key exchange without
636 authentication.
638 1.6.2 ISAKMP Requirements
640 An authenticated key exchange MUST be supported by ISAKMP. Users
641 SHOULD choose additional key establishment algorithms based on their
642 requirements. ISAKMP does not specify a specific key exchange.
643 However, [IKE] describes a proposal for using the Oakley key exchange
644 [Oakley] in conjunction with ISAKMP. Requirements that should be
645 evaluated when choosing a key establishment algorithm include
646 establishment method (generation vs. transport), perfect forward
647 secrecy, computational overhead, key escrow, and key strength. Based
648 on user requirements, ISAKMP allows an entity initiating
649 communications to indicate which key exchanges it supports. After
650 selection of a key exchange, the protocol provides the messages
651 required to support the actual key establishment.
653 1.7 ISAKMP Protection
655 1.7.1 Anti-Clogging (Denial of Service)
657 Of the numerous security services available, protection against
658 denial of service always seems to be one of the most difficult to
659 address. A "cookie" or anti-clogging token (ACT) is aimed at
660 protecting the computing resources from attack without spending
661 excessive CPU resources to determine its authenticity. An exchange
662 prior to CPU-intensive public key operations can thwart some denial
663 of service attempts (e.g. simple flooding with bogus IP source
664 addresses). Absolute protection against denial of service is
665 impossible, but this anti-clogging token provides a technique for
666 making it easier to handle. The use of an anti-clogging token was
667 introduced by Karn and Simpson in [Karn].
674 Maughan, et. al. Standards Track [Page 12]
675 \f
676 RFC 2408 ISAKMP November 1998
679 It should be noted that in the exchanges shown in section 4, the
680 anticlogging mechanism should be used in conjuction with a garbage-
681 state collection mechanism; an attacker can still flood a server
682 using packets with bogus IP addresses and cause state to be created.
683 Such aggressive memory management techniques SHOULD be employed by
684 protocols using ISAKMP that do not go through an initial, anti-
685 clogging only phase, as was done in [Karn].
687 1.7.2 Connection Hijacking
689 ISAKMP prevents connection hijacking by linking the authentication,
690 key exchange and security association exchanges. This linking
691 prevents an attacker from allowing the authentication to complete and
692 then jumping in and impersonating one entity to the other during the
693 key and security association exchanges.
695 1.7.3 Man-in-the-Middle Attacks
697 Man-in-the-Middle attacks include interception, insertion, deletion,
698 and modification of messages, reflecting messages back at the sender,
699 replaying old messages and redirecting messages. ISAKMP features
700 prevent these types of attacks from being successful. The linking of
701 the ISAKMP exchanges prevents the insertion of messages in the
702 protocol exchange. The ISAKMP protocol state machine is defined so
703 deleted messages will not cause a partial SA to be created, the state
704 machine will clear all state and return to idle. The state machine
705 also prevents reflection of a message from causing harm. The
706 requirement for a new cookie with time variant material for each new
707 SA establishment prevents attacks that involve replaying old
708 messages. The ISAKMP strong authentication requirement prevents an
709 SA from being established with anyone other than the intended party.
710 Messages may be redirected to a different destination or modified but
711 this will be detected and an SA will not be established. The ISAKMP
712 specification defines where abnormal processing has occurred and
713 recommends notifying the appropriate party of this abnormality.
715 1.8 Multicast Communications
717 It is expected that multicast communications will require the same
718 security services as unicast communications and may introduce the
719 need for additional security services. The issues of distributing
720 SPIs for multicast traffic are presented in [SEC-ARCH]. Multicast
721 security issues are also discussed in [RFC-1949] and [BC]. A future
722 extension to ISAKMP will support multicast key distribution. For an
723 introduction to the issues related to multicast security, consult the
724 Internet Drafts, [RFC-2094] and [RFC-2093], describing Sparta's
725 research in this area.
730 Maughan, et. al. Standards Track [Page 13]
731 \f
732 RFC 2408 ISAKMP November 1998
735 2 Terminology and Concepts
737 2.1 ISAKMP Terminology
739 Security Protocol: A Security Protocol consists of an entity at a
740 single point in the network stack, performing a security service for
741 network communication. For example, IPSEC ESP and IPSEC AH are two
742 different security protocols. TLS is another example. Security
743 Protocols may perform more than one service, for example providing
744 integrity and confidentiality in one module.
746 Protection Suite: A protection suite is a list of the security
747 services that must be applied by various security protocols. For
748 example, a protection suite may consist of DES encryption in IP ESP,
749 and keyed MD5 in IP AH. All of the protections in a suite must be
750 treated as a single unit. This is necessary because security
751 services in different security protocols can have subtle
752 interactions, and the effects of a suite must be analyzed and
753 verified as a whole.
755 Security Association (SA): A Security Association is a security-
756 protocol- specific set of parameters that completely defines the
757 services and mechanisms necessary to protect traffic at that security
758 protocol location. These parameters can include algorithm
759 identifiers, modes, cryptographic keys, etc. The SA is referred to
760 by its associated security protocol (for example, "ISAKMP SA", "ESP
761 SA", "TLS SA").
763 ISAKMP SA: An SA used by the ISAKMP servers to protect their own
764 traffic. Sections 2.3 and 2.4 provide more details about ISAKMP SAs.
766 Security Parameter Index (SPI): An identifier for a Security
767 Assocation, relative to some security protocol. Each security
768 protocol has its own "SPI-space". A (security protocol, SPI) pair
769 may uniquely identify an SA. The uniqueness of the SPI is
770 implementation dependent, but could be based per system, per
771 protocol, or other options. Depending on the DOI, additional
772 information (e.g. host address) may be necessary to identify an SA.
773 The DOI will also determine which SPIs (i.e. initiator's or
774 responder's) are sent during communication.
776 Domain of Interpretation: A Domain of Interpretation (DOI) defines
777 payload formats, exchange types, and conventions for naming
778 security-relevant information such as security policies or
779 cryptographic algorithms and modes. A Domain of Interpretation (DOI)
780 identifier is used to interpret the payloads of ISAKMP payloads. A
781 system SHOULD support multiple Domains of Interpretation
782 simultaneously. The concept of a DOI is based on previous work by
786 Maughan, et. al. Standards Track [Page 14]
787 \f
788 RFC 2408 ISAKMP November 1998
791 the TSIG CIPSO Working Group, but extends beyond security label
792 interpretation to include naming and interpretation of security
793 services. A DOI defines:
795 o A "situation": the set of information that will be used to
796 determine the required security services.
798 o The set of security policies that must, and may, be supported.
800 o A syntax for the specification of proposed security services.
802 o A scheme for naming security-relevant information, including
803 encryption algorithms, key exchange algorithms, security policy
804 attributes, and certificate authorities.
806 o The specific formats of the various payload contents.
808 o Additional exchange types, if required.
810 The rules for the IETF IP Security DOI are presented in [IPDOI].
811 Specifications of the rules for customized DOIs will be presented in
812 separate documents.
814 Situation: A situation contains all of the security-relevant
815 information that a system considers necessary to decide the security
816 services required to protect the session being negotiated. The
817 situation may include addresses, security classifications, modes of
818 operation (normal vs. emergency), etc.
820 Proposal: A proposal is a list, in decreasing order of preference, of
821 the protection suites that a system considers acceptable to protect
822 traffic under a given situation.
824 Payload: ISAKMP defines several types of payloads, which are used to
825 transfer information such as security association data, or key
826 exchange data, in DOI-defined formats. A payload consists of a
827 generic payload header and a string of octects that is opaque to
828 ISAKMP. ISAKMP uses DOI- specific functionality to synthesize and
829 interpret these payloads. Multiple payloads can be sent in a single
830 ISAKMP message. See section 3 for more details on the payload types,
831 and [IPDOI] for the formats of the IETF IP Security DOI payloads.
833 Exchange Type: An exchange type is a specification of the number of
834 messages in an ISAKMP exchange, and the payload types that are
835 contained in each of those messages. Each exchange type is designed
836 to provide a particular set of security services, such as anonymity
837 of the participants, perfect forward secrecy of the keying material,
838 authentication of the participants, etc. Section 4.1 defines the
842 Maughan, et. al. Standards Track [Page 15]
843 \f
844 RFC 2408 ISAKMP November 1998
847 default set of ISAKMP exchange types. Other exchange types can be
848 added to support additional key exchanges, if required.
850 2.2 ISAKMP Placement
852 Figure 1 is a high level view of the placement of ISAKMP within a
853 system context in a network architecture. An important part of
854 negotiating security services is to consider the entire "stack" of
855 individual SAs as a unit. This is referred to as a "protection
856 suite".
858 +------------+ +--------+ +--------------+
859 ! DOI ! ! ! ! Application !
860 ! Definition ! <----> ! ISAKMP ! ! Process !
861 +------------+ --> ! ! !--------------!
862 +--------------+ ! +--------+ ! Appl Protocol!
863 ! Key Exchange ! ! ^ ^ +--------------+
864 ! Definition !<-- ! ! ^
865 +--------------+ ! ! !
866 ! ! !
867 !----------------! ! !
868 v ! !
869 +-------+ v v
870 ! API ! +---------------------------------------------+
871 +-------+ ! Socket Layer !
872 ! !---------------------------------------------!
873 v ! Transport Protocol (TCP / UDP) !
874 +----------+ !---------------------------------------------!
875 ! Security ! <----> ! IP !
876 ! Protocol ! !---------------------------------------------!
877 +----------+ ! Link Layer Protocol !
878 +---------------------------------------------+
881 Figure 1: ISAKMP Relationships
883 2.3 Negotiation Phases
885 ISAKMP offers two "phases" of negotiation. In the first phase, two
886 entities (e.g. ISAKMP servers) agree on how to protect further
887 negotiation traffic between themselves, establishing an ISAKMP SA.
888 This ISAKMP SA is then used to protect the negotiations for the
889 Protocol SA being requested. Two entities (e.g. ISAKMP servers) can
890 negotiate (and have active) multiple ISAKMP SAs.
898 Maughan, et. al. Standards Track [Page 16]
899 \f
900 RFC 2408 ISAKMP November 1998
903 The second phase of negotiation is used to establish security
904 associations for other security protocols. This second phase can be
905 used to establish many security associations. The security
906 associations established by ISAKMP during this phase can be used by a
907 security protocol to protect many message/data exchanges.
909 While the two-phased approach has a higher start-up cost for most
910 simple scenarios, there are several reasons that it is beneficial for
911 most cases.
913 First, entities (e.g. ISAKMP servers) can amortize the cost of the
914 first phase across several second phase negotiations. This allows
915 multiple SAs to be established between peers over time without having
916 to start over for each communication.
918 Second, security services negotiated during the first phase provide
919 security properties for the second phase. For example, after the
920 first phase of negotiation, the encryption provided by the ISAKMP SA
921 can provide identity protection, potentially allowing the use of
922 simpler second-phase exchanges. On the other hand, if the channel
923 established during the first phase is not adequate to protect
924 identities, then the second phase must negotiate adequate security
925 mechanisms.
927 Third, having an ISAKMP SA in place considerably reduces the cost of
928 ISAKMP management activity - without the "trusted path" that an
929 ISAKMP SA gives you, the entities (e.g. ISAKMP servers) would have
930 to go through a complete re-authentication for each error
931 notification or deletion of an SA.
933 Negotiation during each phase is accomplished using ISAKMP-defined
934 exchanges (see section 4) or exchanges defined for a key exchange
935 within a DOI.
937 Note that security services may be applied differently in each
938 negotiation phase. For example, different parties are being
939 authenticated during each of the phases of negotiation. During the
940 first phase, the parties being authenticated may be the ISAKMP
941 servers/hosts, while during the second phase, users or application
942 level programs are being authenticated.
944 2.4 Identifying Security Associations
946 While bootstrapping secure channels between systems, ISAKMP cannot
947 assume the existence of security services, and must provide some
948 protections for itself. Therefore, ISAKMP considers an ISAKMP
949 Security Association to be different than other types, and manages
950 ISAKMP SAs itself, in their own name space. ISAKMP uses the two
954 Maughan, et. al. Standards Track [Page 17]
955 \f
956 RFC 2408 ISAKMP November 1998
959 cookie fields in the ISAKMP header to identify ISAKMP SAs. The
960 Message ID in the ISAKMP Header and the SPI field in the Proposal
961 payload are used during SA establishment to identify the SA for other
962 security protocols. The interpretation of these four fields is
963 dependent on the operation taking place.
965 The following table shows the presence or absence of several fields
966 during SA establishment. The following fields are necessary for
967 various operations associated with SA establishment: cookies in the
968 ISAKMP header, the ISAKMP Header Message ID field, and the SPI field
969 in the Proposal payload. An 'X' in the column means the value MUST
970 be present. An 'NA' in the column means a value in the column is Not
971 Applicable to the operation.
973 # Operation I-Cookie R-Cookie Message ID SPI
974 (1) Start ISAKMP SA negotiation X 0 0 0
975 (2) Respond ISAKMP SA negotiation X X 0 0
976 (3) Init other SA negotiation X X X X
977 (4) Respond other SA negotiation X X X X
978 (5) Other (KE, ID, etc.) X X X/0 NA
979 (6) Security Protocol (ESP, AH) NA NA NA X
981 In the first line (1) of the table, the initiator includes the
982 Initiator Cookie field in the ISAKMP Header, using the procedures
983 outlined in sections 2.5.3 and 3.1.
985 In the second line (2) of the table, the responder includes the
986 Initiator and Responder Cookie fields in the ISAKMP Header, using the
987 procedures outlined in sections 2.5.3 and 3.1. Additional messages
988 may be exchanged between ISAKMP peers, depending on the ISAKMP
989 exchange type used during the phase 1 negotiation. Once the phase 1
990 exchange is completed, the Initiator and Responder cookies are
991 included in the ISAKMP Header of all subsequent communications
992 between the ISAKMP peers.
994 During phase 1 negotiations, the initiator and responder cookies
995 determine the ISAKMP SA. Therefore, the SPI field in the Proposal
996 payload is redundant and MAY be set to 0 or it MAY contain the
997 transmitting entity's cookie.
999 In the third line (3) of the table, the initiator associates a
1000 Message ID with the Protocols contained in the SA Proposal. This
1001 Message ID and the initiator's SPI(s) to be associated with each
1002 protocol in the Proposal are sent to the responder. The SPI(s) will
1003 be used by the security protocols once the phase 2 negotiation is
1004 completed.
1010 Maughan, et. al. Standards Track [Page 18]
1011 \f
1012 RFC 2408 ISAKMP November 1998
1015 In the fourth line (4) of the table, the responder includes the same
1016 Message ID and the responder's SPI(s) to be associated with each
1017 protocol in the accepted Proposal. This information is returned to
1018 the initiator.
1020 In the fifth line (5) of the table, the initiator and responder use
1021 the Message ID field in the ISAKMP Header to keep track of the in-
1022 progress protocol negotiation. This is only applicable for a phase 2
1023 exchange and the value MUST be 0 for a phase 1 exchange because the
1024 combined cookies identify the ISAKMP SA. The SPI field in the
1025 Proposal payload is not applicable because the Proposal payload is
1026 only used during the SA negotiation message exchange (steps 3 and 4).
1028 In the sixth line (6) of the table, the phase 2 negotiation is
1029 complete. The security protocols use the SPI(s) to determine which
1030 security services and mechanisms to apply to the communication
1031 between them. The SPI value shown in the sixth line (6) is not the
1032 SPI field in the Proposal payload, but the SPI field contained within
1033 the security protocol header.
1035 During the SA establishment, a SPI MUST be generated. ISAKMP is
1036 designed to handle variable sized SPIs. This is accomplished by
1037 using the SPI Size field within the Proposal payload during SA
1038 establishment. Handling of SPIs will be outlined by the DOI
1039 specification (e.g. [IPDOI]).
1041 When a security association (SA) is initially established, one side
1042 assumes the role of initiator and the other the role of responder.
1043 Once the SA is established, both the original initiator and responder
1044 can initiate a phase 2 negotiation with the peer entity. Thus,
1045 ISAKMP SAs are bidirectional in nature.
1047 Additionally, ISAKMP allows both initiator and responder to have some
1048 control during the negotiation process. While ISAKMP is designed to
1049 allow an SA negotiation that includes multiple proposals, the
1050 initiator can maintain some control by only making one proposal in
1051 accordance with the initiator's local security policy. Once the
1052 initiator sends a proposal containing more than one proposal (which
1053 are sent in decreasing preference order), the initiator relinquishes
1054 control to the responder. Once the responder is controlling the SA
1055 establishment, the responder can make its policy take precedence over
1056 the initiator within the context of the multiple options offered by
1057 the initiator. This is accomplished by selecting the proposal best
1058 suited for the responder's local security policy and returning this
1059 selection to the initiator.
1066 Maughan, et. al. Standards Track [Page 19]
1067 \f
1068 RFC 2408 ISAKMP November 1998
1071 2.5 Miscellaneous
1073 2.5.1 Transport Protocol
1075 ISAKMP can be implemented over any transport protocol or over IP
1076 itself. Implementations MUST include send and receive capability for
1077 ISAKMP using the User Datagram Protocol (UDP) on port 500. UDP Port
1078 500 has been assigned to ISAKMP by the Internet Assigned Numbers
1079 Authority (IANA). Implementations MAY additionally support ISAKMP
1080 over other transport protocols or over IP itself.
1082 2.5.2 RESERVED Fields
1084 The existence of RESERVED fields within ISAKMP payloads are used
1085 strictly to preserve byte alignment. All RESERVED fields in the
1086 ISAKMP protocol MUST be set to zero (0) when a packet is issued. The
1087 receiver SHOULD check the RESERVED fields for a zero (0) value and
1088 discard the packet if other values are found.
1090 2.5.3 Anti-Clogging Token ("Cookie") Creation
1092 The details of cookie generation are implementation dependent, but
1093 MUST satisfy these basic requirements (originally stated by Phil Karn
1094 in [Karn]):
1096 1. The cookie must depend on the specific parties. This
1097 prevents an attacker from obtaining a cookie using a real IP
1098 address and UDP port, and then using it to swamp the victim
1099 with Diffie-Hellman requests from randomly chosen IP
1100 addresses or ports.
1102 2. It must not be possible for anyone other than the issuing
1103 entity to generate cookies that will be accepted by that
1104 entity. This implies that the issuing entity must use local
1105 secret information in the generation and subsequent
1106 verification of a cookie. It must not be possible to deduce
1107 this secret information from any particular cookie.
1109 3. The cookie generation function must be fast to thwart
1110 attacks intended to sabotage CPU resources.
1112 Karn's suggested method for creating the cookie is to perform a fast
1113 hash (e.g. MD5) over the IP Source and Destination Address, the UDP
1114 Source and Destination Ports and a locally generated secret random
1115 value. ISAKMP requires that the cookie be unique for each SA
1116 establishment to help prevent replay attacks, therefore, the date and
1117 time MUST be added to the information hashed. The generated cookies
1118 are placed in the ISAKMP Header (described in section 3.1) Initiator
1122 Maughan, et. al. Standards Track [Page 20]
1123 \f
1124 RFC 2408 ISAKMP November 1998
1127 and Responder cookie fields. These fields are 8 octets in length,
1128 thus, requiring a generated cookie to be 8 octets. Notify and Delete
1129 messages (see sections 3.14, 3.15, and 4.8) are uni-directional
1130 transmissions and are done under the protection of an existing ISAKMP
1131 SA, thus, not requiring the generation of a new cookie. One
1132 exception to this is the transmission of a Notify message during a
1133 Phase 1 exchange, prior to completing the establishment of an SA.
1134 Sections 3.14 and 4.8 provide additional details.
1136 3 ISAKMP Payloads
1138 ISAKMP payloads provide modular building blocks for constructing
1139 ISAKMP messages. The presence and ordering of payloads in ISAKMP is
1140 defined by and dependent upon the Exchange Type Field located in the
1141 ISAKMP Header (see Figure 2). The ISAKMP payload types are discussed
1142 in sections 3.4 through 3.15. The descriptions of the ISAKMP
1143 payloads, messages, and exchanges (see Section 4) are shown using
1144 network octet ordering.
1146 3.1 ISAKMP Header Format
1148 An ISAKMP message has a fixed header format, shown in Figure 2,
1149 followed by a variable number of payloads. A fixed header simplifies
1150 parsing, providing the benefit of protocol parsing software that is
1151 less complex and easier to implement. The fixed header contains the
1152 information required by the protocol to maintain state, process
1153 payloads and possibly prevent denial of service or replay attacks.
1155 The ISAKMP Header fields are defined as follows:
1157 o Initiator Cookie (8 octets) - Cookie of entity that initiated SA
1158 establishment, SA notification, or SA deletion.
1160 o Responder Cookie (8 octets) - Cookie of entity that is responding
1161 to an SA establishment request, SA notification, or SA deletion.
1178 Maughan, et. al. Standards Track [Page 21]
1179 \f
1180 RFC 2408 ISAKMP November 1998
1183 1 2 3
1184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1186 ! Initiator !
1187 ! Cookie !
1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1189 ! Responder !
1190 ! Cookie !
1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1192 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1194 ! Message ID !
1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1196 ! Length !
1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1200 Figure 2: ISAKMP Header Format
1202 o Next Payload (1 octet) - Indicates the type of the first payload
1203 in the message. The format for each payload is defined in
1204 sections 3.4 through 3.16. The processing for the payloads is
1205 defined in section 5.
1208 Next Payload Type Value
1209 NONE 0
1210 Security Association (SA) 1
1211 Proposal (P) 2
1212 Transform (T) 3
1213 Key Exchange (KE) 4
1214 Identification (ID) 5
1215 Certificate (CERT) 6
1216 Certificate Request (CR) 7
1217 Hash (HASH) 8
1218 Signature (SIG) 9
1219 Nonce (NONCE) 10
1220 Notification (N) 11
1221 Delete (D) 12
1222 Vendor ID (VID) 13
1223 RESERVED 14 - 127
1224 Private USE 128 - 255
1226 o Major Version (4 bits) - indicates the major version of the ISAKMP
1227 protocol in use. Implementations based on this version of the
1228 ISAKMP Internet-Draft MUST set the Major Version to 1.
1229 Implementations based on previous versions of ISAKMP Internet-
1230 Drafts MUST set the Major Version to 0. Implementations SHOULD
1234 Maughan, et. al. Standards Track [Page 22]
1235 \f
1236 RFC 2408 ISAKMP November 1998
1239 never accept packets with a major version number larger than its
1240 own.
1242 o Minor Version (4 bits) - indicates the minor version of the
1243 ISAKMP protocol in use. Implementations based on this version of
1244 the ISAKMP Internet-Draft MUST set the Minor Version to 0.
1245 Implementations based on previous versions of ISAKMP Internet-
1246 Drafts MUST set the Minor Version to 1. Implementations SHOULD
1247 never accept packets with a minor version number larger than its
1248 own, given the major version numbers are identical.
1250 o Exchange Type (1 octet) - indicates the type of exchange being
1251 used. This dictates the message and payload orderings in the
1252 ISAKMP exchanges.
1255 Exchange Type Value
1256 NONE 0
1257 Base 1
1258 Identity Protection 2
1259 Authentication Only 3
1260 Aggressive 4
1261 Informational 5
1262 ISAKMP Future Use 6 - 31
1263 DOI Specific Use 32 - 239
1264 Private Use 240 - 255
1266 o Flags (1 octet) - indicates specific options that are set for the
1267 ISAKMP exchange. The flags listed below are specified in the
1268 Flags field beginning with the least significant bit, i.e the
1269 Encryption bit is bit 0 of the Flags field, the Commit bit is bit
1270 1 of the Flags field, and the Authentication Only bit is bit 2 of
1271 the Flags field. The remaining bits of the Flags field MUST be
1272 set to 0 prior to transmission.
1274 -- E(ncryption Bit) (1 bit) - If set (1), all payloads following
1275 the header are encrypted using the encryption algorithm
1276 identified in the ISAKMP SA. The ISAKMP SA Identifier is the
1277 combination of the initiator and responder cookie. It is
1278 RECOMMENDED that encryption of communications be done as soon
1279 as possible between the peers. For all ISAKMP exchanges
1280 described in section 4.1, the encryption SHOULD begin after
1281 both parties have exchanged Key Exchange payloads. If the
1282 E(ncryption Bit) is not set (0), the payloads are not
1283 encrypted.
1290 Maughan, et. al. Standards Track [Page 23]
1291 \f
1292 RFC 2408 ISAKMP November 1998
1295 -- C(ommit Bit) (1 bit) - This bit is used to signal key exchange
1296 synchronization. It is used to ensure that encrypted material
1297 is not received prior to completion of the SA establishment.
1298 The Commit Bit can be set (at anytime) by either party
1299 participating in the SA establishment, and can be used during
1300 both phases of an ISAKMP SA establishment. However, the value
1301 MUST be reset after the Phase 1 negotiation. If set(1), the
1302 entity which did not set the Commit Bit MUST wait for an
1303 Informational Exchange containing a Notify payload (with the
1304 CONNECTED Notify Message) from the entity which set the Commit
1305 Bit. In this instance, the Message ID field of the
1306 Informational Exchange MUST contain the Message ID of the
1307 original ISAKMP Phase 2 SA negotiation. This is done to
1308 ensure that the Informational Exchange with the CONNECTED
1309 Notify Message can be associated with the correct Phase 2 SA.
1310 The receipt and processing of the Informational Exchange
1311 indicates that the SA establishment was successful and either
1312 entity can now proceed with encrypted traffic communication.
1313 In addition to synchronizing key exchange, the Commit Bit can
1314 be used to protect against loss of transmissions over
1315 unreliable networks and guard against the need for multiple
1316 re-transmissions.
1318 NOTE: It is always possible that the final message of an
1319 exchange can be lost. In this case, the entity expecting to
1320 receive the final message of an exchange would receive the
1321 Phase 2 SA negotiation message following a Phase 1 exchange or
1322 encrypted traffic following a Phase 2 exchange. Handling of
1323 this situation is not standardized, but we propose the
1324 following possibilities. If the entity awaiting the
1325 Informational Exchange can verify the received message (i.e.
1326 Phase 2 SA negotiation message or encrypted traffic), then
1327 they MAY consider the SA was established and continue
1328 processing. The other option is to retransmit the last ISAKMP
1329 message to force the other entity to retransmit the final
1330 message. This suggests that implementations may consider
1331 retaining the last message (locally) until they are sure the
1332 SA is established.
1334 -- A(uthentication Only Bit) (1 bit) - This bit is intended for
1335 use with the Informational Exchange with a Notify payload and
1336 will allow the transmission of information with integrity
1337 checking, but no encryption (e.g. "emergency mode"). Section
1338 4.8 states that a Phase 2 Informational Exchange MUST be sent
1339 under the protection of an ISAKMP SA. This is the only
1340 exception to that policy. If the Authentication Only bit is
1341 set (1), only authentication security services will be applied
1342 to the entire Notify payload of the Informational Exchange and
1346 Maughan, et. al. Standards Track [Page 24]
1347 \f
1348 RFC 2408 ISAKMP November 1998
1351 the payload will not be encrypted.
1353 o Message ID (4 octets) - Unique Message Identifier used to
1354 identify protocol state during Phase 2 negotiations. This value
1355 is randomly generated by the initiator of the Phase 2
1356 negotiation. In the event of simultaneous SA establishments
1357 (i.e. collisions), the value of this field will likely be
1358 different because they are independently generated and, thus, two
1359 security associations will progress toward establishment.
1360 However, it is unlikely there will be absolute simultaneous
1361 establishments. During Phase 1 negotiations, the value MUST be
1362 set to 0.
1364 o Length (4 octets) - Length of total message (header + payloads)
1365 in octets. Encryption can expand the size of an ISAKMP message.
1367 3.2 Generic Payload Header
1369 Each ISAKMP payload defined in sections 3.4 through 3.16 begins with
1370 a generic header, shown in Figure 3, which provides a payload
1371 "chaining" capability and clearly defines the boundaries of a
1372 payload.
1374 1 2 3
1375 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1377 ! Next Payload ! RESERVED ! Payload Length !
1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1380 Figure 3: Generic Payload Header
1382 The Generic Payload Header fields are defined as follows:
1384 o Next Payload (1 octet) - Identifier for the payload type of the
1385 next payload in the message. If the current payload is the last
1386 in the message, then this field will be 0. This field provides
1387 the "chaining" capability.
1389 o RESERVED (1 octet) - Unused, set to 0.
1391 o Payload Length (2 octets) - Length in octets of the current
1392 payload, including the generic payload header.
1394 3.3 Data Attributes
1396 There are several instances within ISAKMP where it is necessary to
1397 represent Data Attributes. An example of this is the Security
1398 Association (SA) Attributes contained in the Transform payload
1402 Maughan, et. al. Standards Track [Page 25]
1403 \f
1404 RFC 2408 ISAKMP November 1998
1407 (described in section 3.6). These Data Attributes are not an ISAKMP
1408 payload, but are contained within ISAKMP payloads. The format of the
1409 Data Attributes provides the flexibility for representation of many
1410 different types of information. There can be multiple Data
1411 Attributes within a payload. The length of the Data Attributes will
1412 either be 4 octets or defined by the Attribute Length field. This is
1413 done using the Attribute Format bit described below. Specific
1414 information about the attributes for each domain will be described in
1415 a DOI document, e.g. IPSEC DOI [IPDOI].
1417 1 2 3
1418 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1420 !A! Attribute Type ! AF=0 Attribute Length !
1421 !F! ! AF=1 Attribute Value !
1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1423 . AF=0 Attribute Value .
1424 . AF=1 Not Transmitted .
1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1428 Figure 4: Data Attributes
1430 The Data Attributes fields are defined as follows:
1432 o Attribute Type (2 octets) - Unique identifier for each type of
1433 attribute. These attributes are defined as part of the DOI-
1434 specific information.
1436 The most significant bit, or Attribute Format (AF), indicates
1437 whether the data attributes follow the Type/Length/Value (TLV)
1438 format or a shortened Type/Value (TV) format. If the AF bit is a
1439 zero (0), then the Data Attributes are of the Type/Length/Value
1440 (TLV) form. If the AF bit is a one (1), then the Data Attributes
1441 are of the Type/Value form.
1443 o Attribute Length (2 octets) - Length in octets of the Attribute
1444 Value. When the AF bit is a one (1), the Attribute Value is only
1445 2 octets and the Attribute Length field is not present.
1447 o Attribute Value (variable length) - Value of the attribute
1448 associated with the DOI-specific Attribute Type. If the AF bit
1449 is a zero (0), this field has a variable length defined by the
1450 Attribute Length field. If the AF bit is a one (1), the
1451 Attribute Value has a length of 2 octets.
1458 Maughan, et. al. Standards Track [Page 26]
1459 \f
1460 RFC 2408 ISAKMP November 1998
1463 3.4 Security Association Payload
1465 The Security Association Payload is used to negotiate security
1466 attributes and to indicate the Domain of Interpretation (DOI) and
1467 Situation under which the negotiation is taking place. Figure 5
1468 shows the format of the Security Association payload.
1470 1 2 3
1471 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1473 ! Next Payload ! RESERVED ! Payload Length !
1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1475 ! Domain of Interpretation (DOI) !
1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1477 ! !
1478 ~ Situation ~
1479 ! !
1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1483 Figure 5: Security Association Payload
1485 o Next Payload (1 octet) - Identifier for the payload type of the
1486 next payload in the message. If the current payload is the last
1487 in the message, then this field will be 0. This field MUST NOT
1488 contain the values for the Proposal or Transform payloads as they
1489 are considered part of the security association negotiation. For
1490 example, this field would contain the value "10" (Nonce payload)
1491 in the first message of a Base Exchange (see Section 4.4) and the
1492 value "0" in the first message of an Identity Protect Exchange
1493 (see Section 4.5).
1495 o RESERVED (1 octet) - Unused, set to 0.
1497 o Payload Length (2 octets) - Length in octets of the entire
1498 Security Association payload, including the SA payload, all
1499 Proposal payloads, and all Transform payloads associated with the
1500 proposed Security Association.
1502 o Domain of Interpretation (4 octets) - Identifies the DOI (as
1503 described in Section 2.1) under which this negotiation is taking
1504 place. The DOI is a 32-bit unsigned integer. A DOI value of 0
1505 during a Phase 1 exchange specifies a Generic ISAKMP SA which can
1506 be used for any protocol during the Phase 2 exchange. The
1507 necessary SA Attributes are defined in A.4. A DOI value of 1 is
1508 assigned to the IPsec DOI [IPDOI]. All other DOI values are
1509 reserved to IANA for future use. IANA will not normally assign a
1510 DOI value without referencing some public specification, such as
1514 Maughan, et. al. Standards Track [Page 27]
1515 \f
1516 RFC 2408 ISAKMP November 1998
1519 an Internet RFC. Other DOI's can be defined using the description
1520 in appendix B. This field MUST be present within the Security
1521 Association payload.
1523 o Situation (variable length) - A DOI-specific field that
1524 identifies the situation under which this negotiation is taking
1525 place. The Situation is used to make policy decisions regarding
1526 the security attributes being negotiated. Specifics for the IETF
1527 IP Security DOI Situation are detailed in [IPDOI]. This field
1528 MUST be present within the Security Association payload.
1530 3.5 Proposal Payload
1532 The Proposal Payload contains information used during Security
1533 Association negotiation. The proposal consists of security
1534 mechanisms, or transforms, to be used to secure the communications
1535 channel. Figure 6 shows the format of the Proposal Payload. A
1536 description of its use can be found in section 4.2.
1538 1 2 3
1539 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1541 ! Next Payload ! RESERVED ! Payload Length !
1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1543 ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms!
1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1545 ! SPI (variable) !
1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1549 Figure 6: Proposal Payload Format
1551 The Proposal Payload fields are defined as follows:
1553 o Next Payload (1 octet) - Identifier for the payload type of the
1554 next payload in the message. This field MUST only contain the
1555 value "2" or "0". If there are additional Proposal payloads in
1556 the message, then this field will be 2. If the current Proposal
1557 payload is the last within the security association proposal,
1558 then this field will be 0.
1560 o RESERVED (1 octet) - Unused, set to 0.
1562 o Payload Length (2 octets) - Length in octets of the entire
1563 Proposal payload, including generic payload header, the Proposal
1564 payload, and all Transform payloads associated with this
1565 proposal. In the event there are multiple proposals with the
1566 same proposal number (see section 4.2), the Payload Length field
1570 Maughan, et. al. Standards Track [Page 28]
1571 \f
1572 RFC 2408 ISAKMP November 1998
1575 only applies to the current Proposal payload and not to all
1576 Proposal payloads.
1578 o Proposal # (1 octet) - Identifies the Proposal number for the
1579 current payload. A description of the use of this field is found
1580 in section 4.2.
1582 o Protocol-Id (1 octet) - Specifies the protocol identifier for the
1583 current negotiation. Examples might include IPSEC ESP, IPSEC AH,
1584 OSPF, TLS, etc.
1586 o SPI Size (1 octet) - Length in octets of the SPI as defined by
1587 the Protocol-Id. In the case of ISAKMP, the Initiator and
1588 Responder cookie pair from the ISAKMP Header is the ISAKMP SPI,
1589 therefore, the SPI Size is irrelevant and MAY be from zero (0) to
1590 sixteen (16). If the SPI Size is non-zero, the content of the
1591 SPI field MUST be ignored. If the SPI Size is not a multiple of
1592 4 octets it will have some impact on the SPI field and the
1593 alignment of all payloads in the message. The Domain of
1594 Interpretation (DOI) will dictate the SPI Size for other
1595 protocols.
1597 o # of Transforms (1 octet) - Specifies the number of transforms
1598 for the Proposal. Each of these is contained in a Transform
1599 payload.
1601 o SPI (variable) - The sending entity's SPI. In the event the SPI
1602 Size is not a multiple of 4 octets, there is no padding applied
1603 to the payload, however, it can be applied at the end of the
1604 message.
1606 The payload type for the Proposal Payload is two (2).
1608 3.6 Transform Payload
1610 The Transform Payload contains information used during Security
1611 Association negotiation. The Transform payload consists of a
1612 specific security mechanism, or transforms, to be used to secure the
1613 communications channel. The Transform payload also contains the
1614 security association attributes associated with the specific
1615 transform. These SA attributes are DOI-specific. Figure 7 shows the
1616 format of the Transform Payload. A description of its use can be
1617 found in section 4.2.
1626 Maughan, et. al. Standards Track [Page 29]
1627 \f
1628 RFC 2408 ISAKMP November 1998
1631 1 2 3
1632 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1634 ! Next Payload ! RESERVED ! Payload Length !
1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1636 ! Transform # ! Transform-Id ! RESERVED2 !
1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1638 ! !
1639 ~ SA Attributes ~
1640 ! !
1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1644 Figure 7: Transform Payload Format
1646 The Transform Payload fields are defined as follows:
1648 o Next Payload (1 octet) - Identifier for the payload type of the
1649 next payload in the message. This field MUST only contain the
1650 value "3" or "0". If there are additional Transform payloads in
1651 the proposal, then this field will be 3. If the current
1652 Transform payload is the last within the proposal, then this
1653 field will be 0.
1655 o RESERVED (1 octet) - Unused, set to 0.
1657 o Payload Length (2 octets) - Length in octets of the current
1658 payload, including the generic payload header, Transform values,
1659 and all SA Attributes.
1661 o Transform # (1 octet) - Identifies the Transform number for the
1662 current payload. If there is more than one transform proposed
1663 for a specific protocol within the Proposal payload, then each
1664 Transform payload has a unique Transform number. A description
1665 of the use of this field is found in section 4.2.
1667 o Transform-Id (1 octet) - Specifies the Transform identifier for
1668 the protocol within the current proposal. These transforms are
1669 defined by the DOI and are dependent on the protocol being
1670 negotiated.
1672 o RESERVED2 (2 octets) - Unused, set to 0.
1674 o SA Attributes (variable length) - This field contains the
1675 security association attributes as defined for the transform
1676 given in the Transform-Id field. The SA Attributes SHOULD be
1677 represented using the Data Attributes format described in section
1678 3.3. If the SA Attributes are not aligned on 4-byte boundaries,
1682 Maughan, et. al. Standards Track [Page 30]
1683 \f
1684 RFC 2408 ISAKMP November 1998
1687 then subsequent payloads will not be aligned and any padding will
1688 be added at the end of the message to make the message 4-octet
1689 aligned.
1691 The payload type for the Transform Payload is three (3).
1693 3.7 Key Exchange Payload
1695 The Key Exchange Payload supports a variety of key exchange
1696 techniques. Example key exchanges are Oakley [Oakley], Diffie-
1697 Hellman, the enhanced Diffie-Hellman key exchange described in X9.42
1698 [ANSI], and the RSA-based key exchange used by PGP. Figure 8 shows
1699 the format of the Key Exchange payload.
1701 The Key Exchange Payload fields are defined as follows:
1703 o Next Payload (1 octet) - Identifier for the payload type of the
1704 nextpayload in the message. If the current payload is the last
1705 in the message, then this field will be 0.
1707 1 2 3
1708 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1710 ! Next Payload ! RESERVED ! Payload Length !
1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1712 ! !
1713 ~ Key Exchange Data ~
1714 ! !
1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1718 Figure 8: Key Exchange Payload Format
1720 o RESERVED (1 octet) - Unused, set to 0.
1722 o Payload Length (2 octets) - Length in octets of the current
1723 payload, including the generic payload header.
1725 o Key Exchange Data (variable length) - Data required to generate a
1726 session key. The interpretation of this data is specified by the
1727 DOI and the associated Key Exchange algorithm. This field may
1728 also contain pre-placed key indicators.
1730 The payload type for the Key Exchange Payload is four (4).
1738 Maughan, et. al. Standards Track [Page 31]
1739 \f
1740 RFC 2408 ISAKMP November 1998
1743 3.8 Identification Payload
1745 The Identification Payload contains DOI-specific data used to
1746 exchange identification information. This information is used for
1747 determining the identities of communicating peers and may be used for
1748 determining authenticity of information. Figure 9 shows the format
1749 of the Identification Payload.
1751 The Identification Payload fields are defined as follows:
1753 o Next Payload (1 octet) - Identifier for the payload type of the
1754 next payload in the message. If the current payload is the last
1755 in the message, then this field will be 0.
1757 o RESERVED (1 octet) - Unused, set to 0.
1759 o Payload Length (2 octets) - Length in octets of the current
1760 payload, including the generic payload header.
1762 o ID Type (1 octet) - Specifies the type of Identification being
1763 used.
1765 1 2 3
1766 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1768 ! Next Payload ! RESERVED ! Payload Length !
1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1770 ! ID Type ! DOI Specific ID Data !
1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1772 ! !
1773 ~ Identification Data ~
1774 ! !
1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1778 Figure 9: Identification Payload Format
1780 This field is DOI-dependent.
1782 o DOI Specific ID Data (3 octets) - Contains DOI specific
1783 Identification data. If unused, then this field MUST be set to
1784 0.
1786 o Identification Data (variable length) - Contains identity
1787 information. The values for this field are DOI-specific and the
1788 format is specified by the ID Type field. Specific details for
1789 the IETF IP Security DOI Identification Data are detailed in
1790 [IPDOI].
1794 Maughan, et. al. Standards Track [Page 32]
1795 \f
1796 RFC 2408 ISAKMP November 1998
1799 The payload type for the Identification Payload is five (5).
1801 3.9 Certificate Payload
1803 The Certificate Payload provides a means to transport certificates or
1804 other certificate-related information via ISAKMP and can appear in
1805 any ISAKMP message. Certificate payloads SHOULD be included in an
1806 exchange whenever an appropriate directory service (e.g. Secure DNS
1807 [DNSSEC]) is not available to distribute certificates. The
1808 Certificate payload MUST be accepted at any point during an exchange.
1809 Figure 10 shows the format of the Certificate Payload.
1811 NOTE: Certificate types and formats are not generally bound to a DOI
1812 - it is expected that there will only be a few certificate types, and
1813 that most DOIs will accept all of these types.
1815 The Certificate Payload fields are defined as follows:
1817 o Next Payload (1 octet) - Identifier for the payload type of the
1818 next payload in the message. If the current payload is the last
1819 in the message, then this field will be 0.
1821 1 2 3
1822 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1824 ! Next Payload ! RESERVED ! Payload Length !
1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1826 ! Cert Encoding ! !
1827 +-+-+-+-+-+-+-+-+ !
1828 ~ Certificate Data ~
1829 ! !
1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1833 Figure 10: Certificate Payload Format
1835 o RESERVED (1 octet) - Unused, set to 0.
1837 o Payload Length (2 octets) - Length in octets of the current
1838 payload, including the generic payload header.
1840 o Certificate Encoding (1 octet) - This field indicates the type of
1841 certificate or certificate-related information contained in the
1842 Certificate Data field.
1850 Maughan, et. al. Standards Track [Page 33]
1851 \f
1852 RFC 2408 ISAKMP November 1998
1855 Certificate Type Value
1856 NONE 0
1857 PKCS #7 wrapped X.509 certificate 1
1858 PGP Certificate 2
1859 DNS Signed Key 3
1860 X.509 Certificate - Signature 4
1861 X.509 Certificate - Key Exchange 5
1862 Kerberos Tokens 6
1863 Certificate Revocation List (CRL) 7
1864 Authority Revocation List (ARL) 8
1865 SPKI Certificate 9
1866 X.509 Certificate - Attribute 10
1867 RESERVED 11 - 255
1869 o Certificate Data (variable length) - Actual encoding of
1870 certificate data. The type of certificate is indicated by the
1871 Certificate Encoding field.
1873 The payload type for the Certificate Payload is six (6).
1875 3.10 Certificate Request Payload
1877 The Certificate Request Payload provides a means to request
1878 certificates via ISAKMP and can appear in any message. Certificate
1879 Request payloads SHOULD be included in an exchange whenever an
1880 appropriate directory service (e.g. Secure DNS [DNSSEC]) is not
1881 available to distribute certificates. The Certificate Request
1882 payload MUST be accepted at any point during the exchange. The
1883 responder to the Certificate Request payload MUST send its
1884 certificate, if certificates are supported, based on the values
1885 contained in the payload. If multiple certificates are required,
1886 then multiple Certificate Request payloads SHOULD be transmitted.
1887 Figure 11 shows the format of the Certificate Request Payload.
1889 1 2 3
1890 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1892 ! Next Payload ! RESERVED ! Payload Length !
1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1894 ! Cert. Type ! !
1895 +-+-+-+-+-+-+-+-+ !
1896 ~ Certificate Authority ~
1897 ! !
1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1901 Figure 11: Certificate Request Payload Format
1906 Maughan, et. al. Standards Track [Page 34]
1907 \f
1908 RFC 2408 ISAKMP November 1998
1911 The Certificate Payload fields are defined as follows:
1913 o Next Payload (1 octet) - Identifier for the payload type of the
1914 next payload in the message. If the current payload is the last
1915 in the message, then this field will be 0.
1917 o RESERVED (1 octet) - Unused, set to 0.
1919 o Payload Length (2 octets) - Length in octets of the current
1920 payload, including the generic payload header.
1922 o Certificate Type (1 octet) - Contains an encoding of the type of
1923 certificate requested. Acceptable values are listed in section
1924 3.9.
1926 o Certificate Authority (variable length) - Contains an encoding of
1927 an acceptable certificate authority for the type of certificate
1928 requested. As an example, for an X.509 certificate this field
1929 would contain the Distinguished Name encoding of the Issuer Name
1930 of an X.509 certificate authority acceptable to the sender of
1931 this payload. This would be included to assist the responder in
1932 determining how much of the certificate chain would need to be
1933 sent in response to this request. If there is no specific
1934 certificate authority requested, this field SHOULD not be
1935 included.
1937 The payload type for the Certificate Request Payload is seven (7).
1962 Maughan, et. al. Standards Track [Page 35]
1963 \f
1964 RFC 2408 ISAKMP November 1998
1967 3.11 Hash Payload
1969 The Hash Payload contains data generated by the hash function
1970 (selected during the SA establishment exchange), over some part of
1971 the message and/or ISAKMP state. This payload may be used to verify
1972 the integrity of the data in an ISAKMP message or for authentication
1973 of the negotiating entities. Figure 12 shows the format of the Hash
1974 Payload.
1976 1 2 3
1977 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1979 ! Next Payload ! RESERVED ! Payload Length !
1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1981 ! !
1982 ~ Hash Data ~
1983 ! !
1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1987 Figure 12: Hash Payload Format
1989 The Hash Payload fields are defined as follows:
1991 o Next Payload (1 octet) - Identifier for the payload type of the
1992 next payload in the message. If the current payload is the last
1993 in the message, then this field will be 0.
1995 o RESERVED (1 octet) - Unused, set to 0.
1997 o Payload Length (2 octets) - Length in octets of the current
1998 payload, including the generic payload header.
2000 o Hash Data (variable length) - Data that results from applying the
2001 hash routine to the ISAKMP message and/or state.
2018 Maughan, et. al. Standards Track [Page 36]
2019 \f
2020 RFC 2408 ISAKMP November 1998
2023 3.12 Signature Payload
2025 The Signature Payload contains data generated by the digital
2026 signature function (selected during the SA establishment exchange),
2027 over some part of the message and/or ISAKMP state. This payload is
2028 used to verify the integrity of the data in the ISAKMP message, and
2029 may be of use for non-repudiation services. Figure 13 shows the
2030 format of the Signature Payload.
2032 1 2 3
2033 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2035 ! Next Payload ! RESERVED ! Payload Length !
2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2037 ! !
2038 ~ Signature Data ~
2039 ! !
2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2043 Figure 13: Signature Payload Format
2045 The Signature Payload fields are defined as follows:
2047 o Next Payload (1 octet) - Identifier for the payload type of the
2048 next payload in the message. If the current payload is the last
2049 in the message, then this field will be 0.
2051 o RESERVED (1 octet) - Unused, set to 0.
2053 o Payload Length (2 octets) - Length in octets of the current
2054 payload, including the generic payload header.
2056 o Signature Data (variable length) - Data that results from
2057 applying the digital signature function to the ISAKMP message
2058 and/or state.
2060 The payload type for the Signature Payload is nine (9).
2062 3.13 Nonce Payload
2064 The Nonce Payload contains random data used to guarantee liveness
2065 during an exchange and protect against replay attacks. Figure 14
2066 shows the format of the Nonce Payload. If nonces are used by a
2067 particular key exchange, the use of the Nonce payload will be
2068 dictated by the key exchange. The nonces may be transmitted as part
2069 of the key exchange data, or as a separate payload. However, this is
2070 defined by the key exchange, not by ISAKMP.
2074 Maughan, et. al. Standards Track [Page 37]
2075 \f
2076 RFC 2408 ISAKMP November 1998
2079 1 2 3
2080 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2082 ! Next Payload ! RESERVED ! Payload Length !
2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2084 ! !
2085 ~ Nonce Data ~
2086 ! !
2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2090 Figure 14: Nonce Payload Format
2092 The Nonce Payload fields are defined as follows:
2094 o Next Payload (1 octet) - Identifier for the payload type of the
2095 next payload in the message. If the current payload is the last
2096 in the message, then this field will be 0.
2098 o RESERVED (1 octet) - Unused, set to 0.
2100 o Payload Length (2 octets) - Length in octets of the current
2101 payload, including the generic payload header.
2103 o Nonce Data (variable length) - Contains the random data generated
2104 by the transmitting entity.
2106 The payload type for the Nonce Payload is ten (10).
2108 3.14 Notification Payload
2110 The Notification Payload can contain both ISAKMP and DOI-specific
2111 data and is used to transmit informational data, such as error
2112 conditions, to an ISAKMP peer. It is possible to send multiple
2113 Notification payloads in a single ISAKMP message. Figure 15 shows
2114 the format of the Notification Payload.
2116 Notification which occurs during, or is concerned with, a Phase 1
2117 negotiation is identified by the Initiator and Responder cookie pair
2118 in the ISAKMP Header. The Protocol Identifier, in this case, is
2119 ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP
2120 Header identifies the ISAKMP SA. If the notification takes place
2121 prior to the completed exchange of keying information, then the
2122 notification will be unprotected.
2130 Maughan, et. al. Standards Track [Page 38]
2131 \f
2132 RFC 2408 ISAKMP November 1998
2135 Notification which occurs during, or is concerned with, a Phase 2
2136 negotiation is identified by the Initiator and Responder cookie pair
2137 in the ISAKMP Header and the Message ID and SPI associated with the
2138 current negotiation. One example for this type of notification is to
2139 indicate why a proposal was rejected.
2141 1 2 3
2142 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2144 ! Next Payload ! RESERVED ! Payload Length !
2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2146 ! Domain of Interpretation (DOI) !
2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2148 ! Protocol-ID ! SPI Size ! Notify Message Type !
2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2150 ! !
2151 ~ Security Parameter Index (SPI) ~
2152 ! !
2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2154 ! !
2155 ~ Notification Data ~
2156 ! !
2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2160 Figure 15: Notification Payload Format
2162 The Notification Payload fields are defined as follows:
2164 o Next Payload (1 octet) - Identifier for the payload type of the
2165 next payload in the message. If the current payload is the last
2166 in the message, then this field will be 0.
2168 o RESERVED (1 octet) - Unused, set to 0.
2170 o Payload Length (2 octets) - Length in octets of the current
2171 payload, including the generic payload header.
2173 o Domain of Interpretation (4 octets) - Identifies the DOI (as
2174 described in Section 2.1) under which this notification is taking
2175 place. For ISAKMP this value is zero (0) and for the IPSEC DOI
2176 it is one (1). Other DOI's can be defined using the description
2177 in appendix B.
2179 o Protocol-Id (1 octet) - Specifies the protocol identifier for the
2180 current notification. Examples might include ISAKMP, IPSEC ESP,
2181 IPSEC AH, OSPF, TLS, etc.
2186 Maughan, et. al. Standards Track [Page 39]
2187 \f
2188 RFC 2408 ISAKMP November 1998
2191 o SPI Size (1 octet) - Length in octets of the SPI as defined by
2192 the Protocol-Id. In the case of ISAKMP, the Initiator and
2193 Responder cookie pair from the ISAKMP Header is the ISAKMP SPI,
2194 therefore, the SPI Size is irrelevant and MAY be from zero (0) to
2195 sixteen (16). If the SPI Size is non-zero, the content of the
2196 SPI field MUST be ignored. The Domain of Interpretation (DOI)
2197 will dictate the SPI Size for other protocols.
2199 o Notify Message Type (2 octets) - Specifies the type of
2200 notification message (see section 3.14.1). Additional text, if
2201 specified by the DOI, is placed in the Notification Data field.
2203 o SPI (variable length) - Security Parameter Index. The receiving
2204 entity's SPI. The use of the SPI field is described in section
2205 2.4. The length of this field is determined by the SPI Size
2206 field and is not necessarily aligned to a 4 octet boundary.
2208 o Notification Data (variable length) - Informational or error data
2209 transmitted in addition to the Notify Message Type. Values for
2210 this field are DOI-specific.
2212 The payload type for the Notification Payload is eleven (11).
2214 3.14.1 Notify Message Types
2216 Notification information can be error messages specifying why an SA
2217 could not be established. It can also be status data that a process
2218 managing an SA database wishes to communicate with a peer process.
2219 For example, a secure front end or security gateway may use the
2220 Notify message to synchronize SA communication. The table below
2221 lists the Nofitication messages and their corresponding values.
2222 Values in the Private Use range are expected to be DOI-specific
2223 values.
2225 NOTIFY MESSAGES - ERROR TYPES
2227 Errors Value
2228 INVALID-PAYLOAD-TYPE 1
2229 DOI-NOT-SUPPORTED 2
2230 SITUATION-NOT-SUPPORTED 3
2231 INVALID-COOKIE 4
2232 INVALID-MAJOR-VERSION 5
2233 INVALID-MINOR-VERSION 6
2234 INVALID-EXCHANGE-TYPE 7
2235 INVALID-FLAGS 8
2236 INVALID-MESSAGE-ID 9
2237 INVALID-PROTOCOL-ID 10
2238 INVALID-SPI 11
2242 Maughan, et. al. Standards Track [Page 40]
2243 \f
2244 RFC 2408 ISAKMP November 1998
2247 INVALID-TRANSFORM-ID 12
2248 ATTRIBUTES-NOT-SUPPORTED 13
2249 NO-PROPOSAL-CHOSEN 14
2250 BAD-PROPOSAL-SYNTAX 15
2251 PAYLOAD-MALFORMED 16
2252 INVALID-KEY-INFORMATION 17
2253 INVALID-ID-INFORMATION 18
2254 INVALID-CERT-ENCODING 19
2255 INVALID-CERTIFICATE 20
2256 CERT-TYPE-UNSUPPORTED 21
2257 INVALID-CERT-AUTHORITY 22
2258 INVALID-HASH-INFORMATION 23
2259 AUTHENTICATION-FAILED 24
2260 INVALID-SIGNATURE 25
2261 ADDRESS-NOTIFICATION 26
2262 NOTIFY-SA-LIFETIME 27
2263 CERTIFICATE-UNAVAILABLE 28
2264 UNSUPPORTED-EXCHANGE-TYPE 29
2265 UNEQUAL-PAYLOAD-LENGTHS 30
2266 RESERVED (Future Use) 31 - 8191
2267 Private Use 8192 - 16383
2271 NOTIFY MESSAGES - STATUS TYPES
2272 Status Value
2273 CONNECTED 16384
2274 RESERVED (Future Use) 16385 - 24575
2275 DOI-specific codes 24576 - 32767
2276 Private Use 32768 - 40959
2277 RESERVED (Future Use) 40960 - 65535
2279 3.15 Delete Payload
2281 The Delete Payload contains a protocol-specific security association
2282 identifier that the sender has removed from its security association
2283 database and is, therefore, no longer valid. Figure 16 shows the
2284 format of the Delete Payload. It is possible to send multiple SPIs
2285 in a Delete payload, however, each SPI MUST be for the same protocol.
2286 Mixing of Protocol Identifiers MUST NOT be performed with the Delete
2287 payload.
2289 Deletion which is concerned with an ISAKMP SA will contain a
2290 Protocol-Id of ISAKMP and the SPIs are the initiator and responder
2291 cookies from the ISAKMP Header. Deletion which is concerned with a
2292 Protocol SA, such as ESP or AH, will contain the Protocol-Id of that
2293 protocol (e.g. ESP, AH) and the SPI is the sending entity's SPI(s).
2298 Maughan, et. al. Standards Track [Page 41]
2299 \f
2300 RFC 2408 ISAKMP November 1998
2303 NOTE: The Delete Payload is not a request for the responder to delete
2304 an SA, but an advisory from the initiator to the responder. If the
2305 responder chooses to ignore the message, the next communication from
2306 the responder to the initiator, using that security association, will
2307 fail. A responder is not expected to acknowledge receipt of a Delete
2308 payload.
2310 1 2 3
2311 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2313 ! Next Payload ! RESERVED ! Payload Length !
2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2315 ! Domain of Interpretation (DOI) !
2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2317 ! Protocol-Id ! SPI Size ! # of SPIs !
2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2319 ! !
2320 ~ Security Parameter Index(es) (SPI) ~
2321 ! !
2322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2325 Figure 16: Delete Payload Format
2327 The Delete Payload fields are defined as follows:
2329 o Next Payload (1 octet) - Identifier for the payload type of the
2330 next payload in the message. If the current payload is the last
2331 in the message, then this field will be 0.
2333 o RESERVED (1 octet) - Unused, set to 0.
2335 o Payload Length (2 octets) - Length in octets of the current
2336 payload, including the generic payload header.
2338 o Domain of Interpretation (4 octets) - Identifies the DOI (as
2339 described in Section 2.1) under which this deletion is taking
2340 place. For ISAKMP this value is zero (0) and for the IPSEC DOI
2341 it is one (1). Other DOI's can be defined using the description
2342 in appendix B.
2344 o Protocol-Id (1 octet) - ISAKMP can establish security
2345 associations for various protocols, including ISAKMP and IPSEC.
2346 This field identifies which security association database to
2347 apply the delete request.
2354 Maughan, et. al. Standards Track [Page 42]
2355 \f
2356 RFC 2408 ISAKMP November 1998
2359 o SPI Size (1 octet) - Length in octets of the SPI as defined by
2360 the Protocol-Id. In the case of ISAKMP, the Initiator and
2361 Responder cookie pair is the ISAKMP SPI. In this case, the SPI
2362 Size would be 16 octets for each SPI being deleted.
2364 o # of SPIs (2 octets) - The number of SPIs contained in the Delete
2365 payload. The size of each SPI is defined by the SPI Size field.
2367 o Security Parameter Index(es) (variable length) - Identifies the
2368 specific security association(s) to delete. Values for this
2369 field are DOI and protocol specific. The length of this field is
2370 determined by the SPI Size and # of SPIs fields.
2372 The payload type for the Delete Payload is twelve (12).
2374 3.16 Vendor ID Payload
2376 The Vendor ID Payload contains a vendor defined constant. The
2377 constant is used by vendors to identify and recognize remote
2378 instances of their implementations. This mechanism allows a vendor
2379 to experiment with new features while maintaining backwards
2380 compatibility. This is not a general extension facility of ISAKMP.
2381 Figure 17 shows the format of the Vendor ID Payload.
2383 The Vendor ID payload is not an announcement from the sender that it
2384 will send private payload types. A vendor sending the Vendor ID MUST
2385 not make any assumptions about private payloads that it may send
2386 unless a Vendor ID is received as well. Multiple Vendor ID payloads
2387 MAY be sent. An implementation is NOT REQUIRED to understand any
2388 Vendor ID payloads. An implementation is NOT REQUIRED to send any
2389 Vendor ID payload at all. If a private payload was sent without
2390 prior agreement to send it, a compliant implementation may reject a
2391 proposal with a notify message of type INVALID-PAYLOAD-TYPE.
2393 If a Vendor ID payload is sent, it MUST be sent during the Phase 1
2394 negotiation. Reception of a familiar Vendor ID payload in the Phase
2395 1 negotiation allows an implementation to make use of Private USE
2396 payload numbers (128-255), described in section 3.1 for vendor
2397 specific extensions during Phase 2 negotiations. The definition of
2398 "familiar" is left to implementations to determine. Some vendors may
2399 wish to implement another vendor's extension prior to
2400 standardization. However, this practice SHOULD not be widespread and
2401 vendors should work towards standardization instead.
2403 The vendor defined constant MUST be unique. The choice of hash and
2404 text to hash is left to the vendor to decide. As an example, vendors
2405 could generate their vendor id by taking a plain (non-keyed) hash of
2406 a string containing the product name, and the version of the product.
2410 Maughan, et. al. Standards Track [Page 43]
2411 \f
2412 RFC 2408 ISAKMP November 1998
2415 A hash is used instead of a vendor registry to avoid local
2416 cryptographic policy problems with having a list of "approved"
2417 products, to keep away from maintaining a list of vendors, and to
2418 allow classified products to avoid having to appear on any list. For
2419 instance:
2421 "Example Company IPsec. Version 97.1"
2423 (not including the quotes) has MD5 hash:
2424 48544f9b1fe662af98b9b39e50c01a5a, when using MD5file. Vendors may
2425 include all of the hash, or just a portion of it, as the payload
2426 length will bound the data. There are no security implications of
2427 this hash, so its choice is arbitrary.
2429 1 2 3
2430 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2432 ! Next Payload ! RESERVED ! Payload Length !
2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2434 ! !
2435 ~ Vendor ID (VID) ~
2436 ! !
2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2440 Figure 17: Vendor ID Payload Format
2442 The Vendor ID Payload fields are defined as follows:
2444 o Next Payload (1 octet) - Identifier for the payload type of the
2445 next payload in the message. If the current payload is the last
2446 in the message, then this field will be 0.
2448 o RESERVED (1 octet) - Unused, set to 0.
2450 o Payload Length (2 octets) - Length in octets of the current
2451 payload, including the generic payload header.
2453 o Vendor ID (variable length) - Hash of the vendor string plus
2454 version (as described above).
2456 The payload type for the Vendor ID Payload is thirteen (13).
2458 4 ISAKMP Exchanges
2460 ISAKMP supplies the basic syntax of a message exchange. The basic
2461 building blocks for ISAKMP messages are the payload types described
2462 in section 3. This section describes the procedures for SA
2466 Maughan, et. al. Standards Track [Page 44]
2467 \f
2468 RFC 2408 ISAKMP November 1998
2471 establishment and SA modification, followed by a default set of
2472 exchanges that MAY be used for initial interoperability. Other
2473 exchanges will be defined depending on the DOI and key exchange.
2474 [IPDOI] and [IKE] are examples of how this is achieved. Appendix B
2475 explains the procedures for accomplishing these additions.
2477 4.1 ISAKMP Exchange Types
2479 ISAKMP allows the creation of exchanges for the establishment of
2480 Security Associations and keying material. There are currently five
2481 default Exchange Types defined for ISAKMP. Sections 4.4 through 4.8
2482 describe these exchanges. Exchanges define the content and ordering
2483 of ISAKMP messages during communications between peers. Most
2484 exchanges will include all the basic payload types - SA, KE, ID, SIG
2485 - and may include others. The primary difference between exchange
2486 types is the ordering of the messages and the payload ordering within
2487 each message. While the ordering of payloads within messages is not
2488 mandated, for processing efficiency it is RECOMMENDED that the
2489 Security Association payload be the first payload within an exchange.
2490 Processing of each payload within an exchange is described in section
2491 5.
2493 Sections 4.4 through 4.8 provide a default set of ISAKMP exchanges.
2494 These exchanges provide different security protection for the
2495 exchange itself and information exchanged. The diagrams in each of
2496 the following sections show the message ordering for each exchange
2497 type as well as the payloads included in each message, and provide
2498 basic notes describing what has happened after each message exchange.
2499 None of the examples include any "optional payloads", like
2500 certificate and certificate request. Additionally, none of the
2501 examples include an initial exchange of ISAKMP Headers (containing
2502 initiator and responder cookies) which would provide protection
2503 against clogging (see section 2.5.3).
2505 The defined exchanges are not meant to satisfy all DOI and key
2506 exchange protocol requirements. If the defined exchanges meet the
2507 DOI requirements, then they can be used as outlined. If the defined
2508 exchanges do not meet the security requirements defined by the DOI,
2509 then the DOI MUST specify new exchange type(s) and the valid
2510 sequences of payloads that make up a successful exchange, and how to
2511 build and interpret those payloads. All ISAKMP implementations MUST
2512 implement the Informational Exchange and SHOULD implement the other
2513 four exchanges. However, this is dependent on the definition of the
2514 DOI and associated key exchange protocols.
2522 Maughan, et. al. Standards Track [Page 45]
2523 \f
2524 RFC 2408 ISAKMP November 1998
2527 As discussed above, these exchange types can be used in either phase
2528 of negotiation. However, they may provide different security
2529 properties in each of the phases. With each of these exchanges, the
2530 combination of cookies and SPI fields identifies whether this
2531 exchange is being used in the first or second phase of a negotiation.
2533 4.1.1 Notation
2535 The following notation is used to describe the ISAKMP exchange types,
2536 shown in the next section, with the message formats and associated
2537 payloads:
2539 HDR is an ISAKMP header whose exchange type defines the payload
2540 orderings
2541 SA is an SA negotiation payload with one or more Proposal and
2542 Transform payloads. An initiator MAY provide multiple proposals
2543 for negotiation; a responder MUST reply with only one.
2544 KE is the key exchange payload.
2545 IDx is the identity payload for "x". x can be: "ii" or "ir"
2546 for the ISAKMP initiator and responder, respectively, or x can
2547 be: "ui", "ur" (when the ISAKMP daemon is a proxy negotiator),
2548 for the user initiator and responder, respectively.
2549 HASH is the hash payload.
2550 SIG is the signature payload. The data to sign is exchange-specific.
2551 AUTH is a generic authentication mechanism, such as HASH or SIG.
2552 NONCE is the nonce payload.
2553 '*' signifies payload encryption after the ISAKMP header. This
2554 encryption MUST begin immediately after the ISAKMP header and
2555 all payloads following the ISAKMP header MUST be encrypted.
2557 => signifies "initiator to responder" communication
2558 <= signifies "responder to initiator" communication
2560 4.2 Security Association Establishment
2562 The Security Association, Proposal, and Transform payloads are used
2563 to build ISAKMP messages for the negotiation and establishment of
2564 SAs. An SA establishment message consists of a single SA payload
2565 followed by at least one, and possibly many, Proposal payloads and at
2566 least one, and possibly many, Transform payloads associated with each
2567 Proposal payload. Because these payloads are considered together,
2568 the SA payload will point to any following payloads and not to the
2569 Proposal payload included with the SA payload. The SA Payload
2570 contains the DOI and Situation for the proposed SA. Each Proposal
2571 payload contains a Security Parameter Index (SPI) and ensures that
2572 the SPI is associated with the Protocol-Id in accordance with the
2573 Internet Security Architecture [SEC-ARCH]. Proposal payloads may or
2574 may not have the same SPI, as this is implementation dependent. Each
2578 Maughan, et. al. Standards Track [Page 46]
2579 \f
2580 RFC 2408 ISAKMP November 1998
2583 Transform Payload contains the specific security mechanisms to be
2584 used for the designated protocol. It is expected that the Proposal
2585 and Transform payloads will be used only during SA establishment
2586 negotiation. The creation of payloads for security association
2587 negotiation and establishment described here in this section are
2588 applicable for all ISAKMP exchanges described later in sections 4.4
2589 through 4.8. The examples shown in 4.2.1 contain only the SA,
2590 Proposal, and Transform payloads and do not contain other payloads
2591 that might exist for a given ISAKMP exchange.
2593 The Proposal payload provides the initiating entity with the
2594 capability to present to the responding entity the security protocols
2595 and associated security mechanisms for use with the security
2596 association being negotiated. If the SA establishment negotiation is
2597 for a combined protection suite consisting of multiple protocols,
2598 then there MUST be multiple Proposal payloads each with the same
2599 Proposal number. These proposals MUST be considered as a unit and
2600 MUST NOT be separated by a proposal with a different proposal number.
2601 The use of the same Proposal number in multiple Proposal payloads
2602 provides a logical AND operation, i.e. Protocol 1 AND Protocol 2.
2603 The first example below shows an ESP AND AH protection suite. If the
2604 SA establishment negotiation is for different protection suites, then
2605 there MUST be multiple Proposal payloads each with a monotonically
2606 increasing Proposal number. The different proposals MUST be
2607 presented in the initiator's preference order. The use of different
2608 Proposal numbers in multiple Proposal payloads provides a logical OR
2609 operation, i.e. Proposal 1 OR Proposal 2, where each proposal may
2610 have more than one protocol. The second example below shows either
2611 an AH AND ESP protection suite OR just an ESP protection suite. Note
2612 that the Next Payload field of the Proposal payload points to another
2613 Proposal payload (if it exists). The existence of a Proposal payload
2614 implies the existence of one or more Transform payloads.
2616 The Transform payload provides the initiating entity with the
2617 capability to present to the responding entity multiple mechanisms,
2618 or transforms, for a given protocol. The Proposal payload identifies
2619 a Protocol for which services and mechanisms are being negotiated.
2620 The Transform payload allows the initiating entity to present several
2621 possible supported transforms for that proposed protocol. There may
2622 be several transforms associated with a specific Proposal payload
2623 each identified in a separate Transform payload. The multiple
2624 transforms MUST be presented with monotonically increasing numbers in
2625 the initiator's preference order. The receiving entity MUST select a
2626 single transform for each protocol in a proposal or reject the entire
2627 proposal. The use of the Transform number in multiple Transform
2628 payloads provides a second level OR operation, i.e. Transform 1 OR
2629 Transform 2 OR Transform 3. Example 1 below shows two possible
2630 transforms for ESP and a single transform for AH. Example 2 below
2634 Maughan, et. al. Standards Track [Page 47]
2635 \f
2636 RFC 2408 ISAKMP November 1998
2639 shows one transform for AH AND one transform for ESP OR two
2640 transforms for ESP alone. Note that the Next Payload field of the
2641 Transform payload points to another Transform payload or 0. The
2642 Proposal payload delineates the different proposals.
2644 When responding to a Security Association payload, the responder MUST
2645 send a Security Association payload with the selected proposal, which
2646 may consist of multiple Proposal payloads and their associated
2647 Transform payloads. Each of the Proposal payloads MUST contain a
2648 single Transform payload associated with the Protocol. The responder
2649 SHOULD retain the Proposal # field in the Proposal payload and the
2650 Transform # field in each Transform payload of the selected Proposal.
2651 Retention of Proposal and Transform numbers should speed the
2652 initiator's protocol processing by negating the need to compare the
2653 respondor's selection with every offered option. These values enable
2654 the initiator to perform the comparison directly and quickly. The
2655 initiator MUST verify that the Security Association payload received
2656 from the responder matches one of the proposals sent initially.
2658 4.2.1 Security Association Establishment Examples
2660 This example shows a Proposal for a combined protection suite with
2661 two different protocols. The first protocol is presented with two
2662 transforms supported by the proposer. The second protocol is
2663 presented with a single transform. An example for this proposal
2664 might be: Protocol 1 is ESP with Transform 1 as 3DES and Transform 2
2665 as DES AND Protocol 2 is AH with Transform 1 as SHA. The responder
2666 MUST select from the two transforms proposed for ESP. The resulting
2667 protection suite will be either (1) 3DES AND SHA OR (2) DES AND SHA,
2668 depending on which ESP transform was selected by the responder. Note
2669 this example is shown using the Base Exchange.
2671 1 2 3
2672 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2673 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2674 / ! NP = Nonce ! RESERVED ! Payload Length !
2675 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2676 SA Pay ! Domain of Interpretation (DOI) !
2677 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2678 \ ! Situation !
2679 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2680 / ! NP = Proposal ! RESERVED ! Payload Length !
2681 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2682 Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans. = 2!
2683 Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2684 \ ! SPI (variable) !
2685 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2686 / ! NP = Transform! RESERVED ! Payload Length !
2690 Maughan, et. al. Standards Track [Page 48]
2691 \f
2692 RFC 2408 ISAKMP November 1998
2695 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2696 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
2697 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2698 \ ! SA Attributes !
2699 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2700 / ! NP = 0 ! RESERVED ! Payload Length !
2701 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2702 Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 !
2703 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2704 \ ! SA Attributes !
2705 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2706 / ! NP = 0 ! RESERVED ! Payload Length !
2707 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2708 Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
2709 Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2710 \ ! SPI (variable) !
2711 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2712 / ! NP = 0 ! RESERVED ! Payload Length !
2713 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2714 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
2715 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2716 \ ! SA Attributes !
2717 \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2719 This second example shows a Proposal for two different protection
2720 suites. The SA Payload was omitted for space reasons. The first
2721 protection suite is presented with one transform for the first
2722 protocol and one transform for the second protocol. The second
2723 protection suite is presented with two transforms for a single
2724 protocol. An example for this proposal might be: Proposal 1 with
2725 Protocol 1 as AH with Transform 1 as MD5 AND Protocol 2 as ESP with
2726 Transform 1 as 3DES. This is followed by Proposal 2 with Protocol 1
2727 as ESP with Transform 1 as DES and Transform 2 as 3DES. The responder
2728 MUST select from the two different proposals. If the second Proposal
2729 is selected, the responder MUST select from the two transforms for
2730 ESP. The resulting protection suite will be either (1) MD5 AND 3DES
2731 OR the selection between (2) DES OR (3) 3DES.
2733 1 2 3
2734 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2735 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2736 / ! NP = Proposal ! RESERVED ! Payload Length !
2737 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2738 Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
2739 Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2740 \ ! SPI (variable) !
2741 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2742 / ! NP = 0 ! RESERVED ! Payload Length !
2746 Maughan, et. al. Standards Track [Page 49]
2747 \f
2748 RFC 2408 ISAKMP November 1998
2751 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2752 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
2753 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2754 \ ! SA Attributes !
2755 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2756 / ! NP = Proposal ! RESERVED ! Payload Length !
2757 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2758 Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
2759 Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2760 \ ! SPI (variable) !
2761 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2762 / ! NP = 0 ! RESERVED ! Payload Length !
2763 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2764 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
2765 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2766 \ ! SA Attributes !
2767 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2768 / ! NP = 0 ! RESERVED ! Payload Length !
2769 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2770 Prop 2 ! Proposal # = 2! Protocol ID ! SPI Size !# of Trans. = 2!
2771 Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2772 \ ! SPI (variable) !
2773 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2774 / ! NP = Transform! RESERVED ! Payload Length !
2775 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2776 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
2777 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2778 \ ! SA Attributes !
2779 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2780 / ! NP = 0 ! RESERVED ! Payload Length !
2781 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2782 Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 !
2783 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2784 \ ! SA Attributes !
2785 \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2787 4.3 Security Association Modification
2789 Security Association modification within ISAKMP is accomplished by
2790 creating a new SA and initiating communications using that new SA.
2791 Deletion of the old SA can be done anytime after the new SA is
2792 established. Deletion of the old SA is dependent on local security
2793 policy. Modification of SAs by using a "Create New SA followed by
2794 Delete Old SA" method is done to avoid potential vulnerabilities in
2795 synchronizing modification of existing SA attributes. The procedure
2796 for creating new SAs is outlined in section 4.2. The procedure for
2797 deleting SAs is outlined in section 5.15.
2802 Maughan, et. al. Standards Track [Page 50]
2803 \f
2804 RFC 2408 ISAKMP November 1998
2807 Modification of an ISAKMP SA (phase 1 negotiation) follows the same
2808 procedure as creation of an ISAKMP SA. There is no relationship
2809 between the two SAs and the initiator and responder cookie pairs
2810 SHOULD be different, as outlined in section 2.5.3.
2812 Modification of a Protocol SA (phase 2 negotiation) follows the same
2813 procedure as creation of a Protocol SA. The creation of a new SA is
2814 protected by the existing ISAKMP SA. There is no relationship between
2815 the two Protocol SAs. A protocol implementation SHOULD begin using
2816 the newly created SA for outbound traffic and SHOULD continue to
2817 support incoming traffic on the old SA until it is deleted or until
2818 traffic is received under the protection of the newly created SA. As
2819 stated previously in this section, deletion of an old SA is then
2820 dependent on local security policy.
2822 4.4 Base Exchange
2824 The Base Exchange is designed to allow the Key Exchange and
2825 Authentication related information to be transmitted together.
2826 Combining the Key Exchange and Authentication-related information
2827 into one message reduces the number of round-trips at the expense of
2828 not providing identity protection. Identity protection is not
2829 provided because identities are exchanged before a common shared
2830 secret has been established and, therefore, encryption of the
2831 identities is not possible. The following diagram shows the messages
2832 with the possible payloads sent in each message and notes for an
2833 example of the Base Exchange.
2835 BASE EXCHANGE
2837 # Initiator Direction Responder NOTE
2838 (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation
2840 (2) <= HDR; SA; NONCE
2841 Basic SA agreed upon
2842 (3) HDR; KE; =>
2843 IDii; AUTH Key Generated (by responder)
2844 Initiator Identity Verified by
2845 Responder
2846 (4) <= HDR; KE;
2847 IDir; AUTH
2848 Responder Identity Verified by
2849 Initiator Key Generated (by
2850 initiator) SA established
2858 Maughan, et. al. Standards Track [Page 51]
2859 \f
2860 RFC 2408 ISAKMP November 1998
2863 In the first message (1), the initiator generates a proposal it
2864 considers adequate to protect traffic for the given situation. The
2865 Security Association, Proposal, and Transform payloads are included
2866 in the Security Association payload (for notation purposes). Random
2867 information which is used to guarantee liveness and protect against
2868 replay attacks is also transmitted. Random information provided by
2869 both parties SHOULD be used by the authentication mechanism to
2870 provide shared proof of participation in the exchange.
2872 In the second message (2), the responder indicates the protection
2873 suite it has accepted with the Security Association, Proposal, and
2874 Transform payloads. Again, random information which is used to
2875 guarantee liveness and protect against replay attacks is also
2876 transmitted. Random information provided by both parties SHOULD be
2877 used by the authentication mechanism to provide shared proof of
2878 participation in the exchange. Local security policy dictates the
2879 action of the responder if no proposed protection suite is accepted.
2880 One possible action is the transmission of a Notify payload as part
2881 of an Informational Exchange.
2883 In the third (3) and fourth (4) messages, the initiator and
2884 responder, respectively, exchange keying material used to arrive at a
2885 common shared secret and identification information. This
2886 information is transmitted under the protection of the agreed upon
2887 authentication function. Local security policy dictates the action
2888 if an error occurs during these messages. One possible action is the
2889 transmission of a Notify payload as part of an Informational
2890 Exchange.
2892 4.5 Identity Protection Exchange
2894 The Identity Protection Exchange is designed to separate the Key
2895 Exchange information from the Identity and Authentication related
2896 information. Separating the Key Exchange from the Identity and
2897 Authentication related information provides protection of the
2898 communicating identities at the expense of two additional messages.
2899 Identities are exchanged under the protection of a previously
2900 established common shared secret. The following diagram shows the
2901 messages with the possible payloads sent in each message and notes
2902 for an example of the Identity Protection Exchange.
2914 Maughan, et. al. Standards Track [Page 52]
2915 \f
2916 RFC 2408 ISAKMP November 1998
2919 IDENTITY PROTECTION EXCHANGE
2921 # Initiator Direction Responder NOTE
2922 (1) HDR; SA => Begin ISAKMP-SA or
2923 Proxy negotiation
2924 (2) <= HDR; SA
2925 Basic SA agreed upon
2926 (3) HDR; KE; NONCE =>
2927 (4) <= HDR; KE; NONCE
2928 Key Generated (by
2929 Initiator and
2930 Responder)
2931 (5) HDR*; IDii; AUTH =>
2932 Initiator Identity
2933 Verified by
2934 Responder
2935 (6) <= HDR*; IDir; AUTH
2936 Responder Identity
2937 Verified by
2938 Initiator
2939 SA established
2941 In the first message (1), the initiator generates a proposal it
2942 considers adequate to protect traffic for the given situation. The
2943 Security Association, Proposal, and Transform payloads are included
2944 in the Security Association payload (for notation purposes).
2946 In the second message (2), the responder indicates the protection
2947 suite it has accepted with the Security Association, Proposal, and
2948 Transform payloads. Local security policy dictates the action of the
2949 responder if no proposed protection suite is accepted. One possible
2950 action is the transmission of a Notify payload as part of an
2951 Informational Exchange.
2953 In the third (3) and fourth (4) messages, the initiator and
2954 responder, respectively, exchange keying material used to arrive at a
2955 common shared secret and random information which is used to
2956 guarantee liveness and protect against replay attacks. Random
2957 information provided by both parties SHOULD be used by the
2958 authentication mechanism to provide shared proof of participation in
2959 the exchange. Local security policy dictates the action if an error
2960 occurs during these messages. One possible action is the
2961 transmission of a Notify payload as part of an Informational
2962 Exchange.
2964 In the fifth (5) and sixth (6) messages, the initiator and responder,
2965 respectively, exchange identification information and the results of
2966 the agreed upon authentication function. This information is
2970 Maughan, et. al. Standards Track [Page 53]
2971 \f
2972 RFC 2408 ISAKMP November 1998
2975 transmitted under the protection of the common shared secret. Local
2976 security policy dictates the action if an error occurs during these
2977 messages. One possible action is the transmission of a Notify
2978 payload as part of an Informational Exchange.
2980 4.6 Authentication Only Exchange
2982 The Authentication Only Exchange is designed to allow only
2983 Authentication related information to be transmitted. The benefit of
2984 this exchange is the ability to perform only authentication without
2985 the computational expense of computing keys. Using this exchange
2986 during negotiation, none of the transmitted information will be
2987 encrypted. However, the information may be encrypted in other
2988 places. For example, if encryption is negotiated during the first
2989 phase of a negotiation and the authentication only exchange is used
2990 in the second phase of a negotiation, then the authentication only
2991 exchange will be encrypted by the ISAKMP SAs negotiated in the first
2992 phase. The following diagram shows the messages with possible
2993 payloads sent in each message and notes for an example of the
2994 Authentication Only Exchange.
2996 AUTHENTICATION ONLY EXCHANGE
2998 # Initiator Direction Responder NOTE
2999 (1) HDR; SA; NONCE => Begin ISAKMP-SA or
3000 Proxy negotiation
3001 (2) <= HDR; SA; NONCE;
3002 IDir; AUTH
3003 Basic SA agreed upon
3004 Responder Identity
3005 Verified by Initiator
3006 (3) HDR; IDii; AUTH =>
3007 Initiator Identity
3008 Verified by Responder
3009 SA established
3011 In the first message (1), the initiator generates a proposal it
3012 considers adequate to protect traffic for the given situation. The
3013 Security Association, Proposal, and Transform payloads are included
3014 in the Security Association payload (for notation purposes). Random
3015 information which is used to guarantee liveness and protect against
3016 replay attacks is also transmitted. Random information provided by
3017 both parties SHOULD be used by the authentication mechanism to
3018 provide shared proof of participation in the exchange.
3020 In the second message (2), the responder indicates the protection
3021 suite it has accepted with the Security Association, Proposal, and
3022 Transform payloads. Again, random information which is used to
3026 Maughan, et. al. Standards Track [Page 54]
3027 \f
3028 RFC 2408 ISAKMP November 1998
3031 guarantee liveness and protect against replay attacks is also
3032 transmitted. Random information provided by both parties SHOULD be
3033 used by the authentication mechanism to provide shared proof of
3034 participation in the exchange. Additionally, the responder transmits
3035 identification information. All of this information is transmitted
3036 under the protection of the agreed upon authentication function.
3037 Local security policy dictates the action of the responder if no
3038 proposed protection suite is accepted. One possible action is the
3039 transmission of a Notify payload as part of an Informational
3040 Exchange.
3042 In the third message (3), the initiator transmits identification
3043 information. This information is transmitted under the protection of
3044 the agreed upon authentication function. Local security policy
3045 dictates the action if an error occurs during these messages. One
3046 possible action is the transmission of a Notify payload as part of an
3047 Informational Exchange.
3049 4.7 Aggressive Exchange
3051 The Aggressive Exchange is designed to allow the Security
3052 Association, Key Exchange and Authentication related payloads to be
3053 transmitted together. Combining the Security Association, Key
3054 Exchange, and Authentication-related information into one message
3055 reduces the number of round-trips at the expense of not providing
3056 identity protection. Identity protection is not provided because
3057 identities are exchanged before a common shared secret has been
3058 established and, therefore, encryption of the identities is not
3059 possible. Additionally, the Aggressive Exchange is attempting to
3060 establish all security relevant information in a single exchange.
3061 The following diagram shows the messages with possible payloads sent
3062 in each message and notes for an example of the Aggressive Exchange.
3082 Maughan, et. al. Standards Track [Page 55]
3083 \f
3084 RFC 2408 ISAKMP November 1998
3087 AGGRESSIVE EXCHANGE
3089 # Initiator Direction Responder NOTE
3090 (1) HDR; SA; KE; => Begin ISAKMP-SA or
3091 Proxy negotiation
3092 NONCE; IDii and Key Exchange
3094 (2) <= HDR; SA; KE;
3095 NONCE; IDir; AUTH
3096 Initiator Identity
3097 Verified by Responder
3098 Key Generated
3099 Basic SA agreed upon
3100 (3) HDR*; AUTH =>
3101 Responder Identity
3102 Verified by Initiator
3103 SA established
3105 In the first message (1), the initiator generates a proposal it
3106 considers adequate to protect traffic for the given situation. The
3107 Security Association, Proposal, and Transform payloads are included
3108 in the Security Association payload (for notation purposes). There
3109 can be only one Proposal and one Transform offered (i.e. no choices)
3110 in order for the aggressive exchange to work. Keying material used
3111 to arrive at a common shared secret and random information which is
3112 used to guarantee liveness and protect against replay attacks are
3113 also transmitted. Random information provided by both parties SHOULD
3114 be used by the authentication mechanism to provide shared proof of
3115 participation in the exchange. Additionally, the initiator transmits
3116 identification information.
3118 In the second message (2), the responder indicates the protection
3119 suite it has accepted with the Security Association, Proposal, and
3120 Transform payloads. Keying material used to arrive at a common
3121 shared secret and random information which is used to guarantee
3122 liveness and protect against replay attacks is also transmitted.
3123 Random information provided by both parties SHOULD be used by the
3124 authentication mechanism to provide shared proof of participation in
3125 the exchange. Additionally, the responder transmits identification
3126 information. All of this information is transmitted under the
3127 protection of the agreed upon authentication function. Local
3128 security policy dictates the action of the responder if no proposed
3129 protection suite is accepted. One possible action is the
3130 transmission of a Notify payload as part of an Informational
3131 Exchange.
3138 Maughan, et. al. Standards Track [Page 56]
3139 \f
3140 RFC 2408 ISAKMP November 1998
3143 In the third (3) message, the initiator transmits the results of the
3144 agreed upon authentication function. This information is transmitted
3145 under the protection of the common shared secret. Local security
3146 policy dictates the action if an error occurs during these messages.
3147 One possible action is the transmission of a Notify payload as part
3148 of an Informational Exchange.
3150 4.8 Informational Exchange
3152 The Informational Exchange is designed as a one-way transmittal of
3153 information that can be used for security association management.
3154 The following diagram shows the messages with possible payloads sent
3155 in each message and notes for an example of the Informational
3156 Exchange.
3158 INFORMATIONAL EXCHANGE
3160 # Initiator Direction Responder NOTE
3161 (1) HDR*; N/D => Error Notification or Deletion
3163 In the first message (1), the initiator or responder transmits an
3164 ISAKMP Notify or Delete payload.
3166 If the Informational Exchange occurs prior to the exchange of keying
3167 meterial during an ISAKMP Phase 1 negotiation, there will be no
3168 protection provided for the Informational Exchange. Once keying
3169 material has been exchanged or an ISAKMP SA has been established, the
3170 Informational Exchange MUST be transmitted under the protection
3171 provided by the keying material or the ISAKMP SA.
3173 All exchanges are similar in that with the beginning of any exchange,
3174 cryptographic synchronization MUST occur. The Informational Exchange
3175 is an exchange and not an ISAKMP message. Thus, the generation of an
3176 Message ID (MID) for an Informational Exchange SHOULD be independent
3177 of IVs of other on-going communication. This will ensure
3178 cryptographic synchronization is maintained for existing
3179 communications and the Informational Exchange will be processed
3180 correctly. The only exception to this is when the Commit Bit of the
3181 ISAKMP Header is set. When the Commit Bit is set, the Message ID
3182 field of the Informational Exchange MUST contain the Message ID of
3183 the original ISAKMP Phase 2 SA negotiation, rather than a new Message
3184 ID (MID). This is done to ensure that the Informational Exchange with
3185 the CONNECTED Notify Message can be associated with the correct Phase
3186 2 SA. For a description of the Commit Bit, see section 3.1.
3194 Maughan, et. al. Standards Track [Page 57]
3195 \f
3196 RFC 2408 ISAKMP November 1998
3199 5 ISAKMP Payload Processing
3201 Section 3 describes the ISAKMP payloads. These payloads are used in
3202 the exchanges described in section 4 and can be used in exchanges
3203 defined for a specific DOI. This section describes the processing for
3204 each of the payloads. This section suggests the logging of events to
3205 a system audit file. This action is controlled by a system security
3206 policy and is, therefore, only a suggested action.
3208 5.1 General Message Processing
3210 Every ISAKMP message has basic processing applied to insure protocol
3211 reliability, and to minimize threats, such as denial of service and
3212 replay attacks. All processing SHOULD include packet length checks
3213 to insure the packet received is at least as long as the length given
3214 in the ISAKMP Header. If the ISAKMP message length and the value in
3215 the Payload Length field of the ISAKMP Header are not the same, then
3216 the ISAKMP message MUST be rejected. The receiving entity (initiator
3217 or responder) MUST do the following:
3219 1. The event, UNEQUAL PAYLOAD LENGTHS, MAY be logged in the
3220 appropriate system audit file.
3222 2. An Informational Exchange with a Notification payload containing
3223 the UNEQUAL-PAYLOAD-LENGTHS message type MAY be sent to the
3224 transmitting entity. This action is dictated by a system
3225 security policy.
3227 When transmitting an ISAKMP message, the transmitting entity
3228 (initiator or responder) MUST do the following:
3230 1. Set a timer and initialize a retry counter.
3232 NOTE: Implementations MUST NOT use a fixed timer. Instead,
3233 transmission timer values should be adjusted dynamically based on
3234 measured round trip times. In addition, successive
3235 retransmissions of the same packet should be separated by
3236 increasingly longer time intervals (e.g., exponential backoff).
3238 2. If the timer expires, the ISAKMP message is resent and the retry
3239 counter is decremented.
3241 3. If the retry counter reaches zero (0), the event, RETRY LIMIT
3242 REACHED, MAY be logged in the appropriate system audit file.
3244 4. The ISAKMP protocol machine clears all states and returns to
3245 IDLE.
3250 Maughan, et. al. Standards Track [Page 58]
3251 \f
3252 RFC 2408 ISAKMP November 1998
3255 5.2 ISAKMP Header Processing
3257 When creating an ISAKMP message, the transmitting entity (initiator
3258 or responder) MUST do the following:
3260 1. Create the respective cookie. See section 2.5.3 for details.
3262 2. Determine the relevant security characteristics of the session
3263 (i.e. DOI and situation).
3265 3. Construct an ISAKMP Header with fields as described in section
3266 3.1.
3268 4. Construct other ISAKMP payloads, depending on the exchange type.
3270 5. Transmit the message to the destination host as described in
3271 section5.1.
3273 When an ISAKMP message is received, the receiving entity (initiator
3274 or responder) MUST do the following:
3276 1. Verify the Initiator and Responder "cookies". If the cookie
3277 validation fails, the message is discarded and the following
3278 actions are taken:
3280 (a) The event, INVALID COOKIE, MAY be logged in the
3281 appropriate system audit file.
3283 (b) An Informational Exchange with a Notification payload
3284 containing the INVALID-COOKIE message type MAY be sent to
3285 the transmitting entity. This action is dictated by a
3286 system security policy.
3288 2. Check the Next Payload field to confirm it is valid. If the Next
3289 Payload field validation fails, the message is discarded and the
3290 following actions are taken:
3292 (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the
3293 appropriate system audit file.
3295 (b) An Informational Exchange with a Notification payload
3296 containing the INVALID-PAYLOAD-TYPE message type MAY be sent
3297 to the transmitting entity. This action is dictated by a
3298 system security policy.
3300 3. Check the Major and Minor Version fields to confirm they are
3301 correct (see section 3.1). If the Version field validation
3302 fails, the message is discarded and the following actions are
3306 Maughan, et. al. Standards Track [Page 59]
3307 \f
3308 RFC 2408 ISAKMP November 1998
3311 taken:
3313 (a) The event, INVALID ISAKMP VERSION, MAY be logged in the
3314 appropriate system audit file.
3316 (b) An Informational Exchange with a Notification payload
3317 containing the INVALID-MAJOR-VERSION or INVALID-MINOR-
3318 VERSION message type MAY be sent to the transmitting entity.
3319 This action is dictated by a system security policy.
3321 4. Check the Exchange Type field to confirm it is valid. If the
3322 Exchange Type field validation fails, the message is discarded
3323 and the following actions are taken:
3325 (a) The event, INVALID EXCHANGE TYPE, MAY be logged in the
3326 appropriate system audit file.
3328 (b) An Informational Exchange with a Notification payload
3329 containing the INVALID-EXCHANGE-TYPE message type MAY be
3330 sent to the transmitting entity. This action is dictated by
3331 a system security policy.
3333 5. Check the Flags field to ensure it contains correct values. If
3334 the Flags field validation fails, the message is discarded and
3335 the following actions are taken:
3337 (a) The event, INVALID FLAGS, MAY be logged in the appropriate
3338 systemaudit file.
3340 (b) An Informational Exchange with a Notification payload
3341 containing the INVALID-FLAGS message type MAY be sent to the
3342 transmitting entity. This action is dictated by a system
3343 security policy.
3345 6. Check the Message ID field to ensure it contains correct values.
3346 If the Message ID validation fails, the message is discarded and
3347 the following actions are taken:
3349 (a) The event, INVALID MESSAGE ID, MAY be logged in the
3350 appropriate system audit file.
3352 (b) An Informational Exchange with a Notification payload
3353 containing the INVALID-MESSAGE-ID message type MAY be sent
3354 to the transmitting entity. This action is dictated by a
3355 system security policy.
3357 7. Processing of the ISAKMP message continues using the value in the
3358 Next Payload field.
3362 Maughan, et. al. Standards Track [Page 60]
3363 \f
3364 RFC 2408 ISAKMP November 1998
3367 5.3 Generic Payload Header Processing
3369 When creating any of the ISAKMP Payloads described in sections 3.4
3370 through 3.15 a Generic Payload Header is placed at the beginning of
3371 these payloads. When creating the Generic Payload Header, the
3372 transmitting entity (initiator or responder) MUST do the following:
3374 1. Place the value of the Next Payload in the Next Payload field.
3375 These values are described in section 3.1.
3377 2. Place the value zero (0) in the RESERVED field.
3379 3. Place the length (in octets) of the payload in the Payload Length
3380 field.
3382 4. Construct the payloads as defined in the remainder of this
3383 section.
3385 When any of the ISAKMP Payloads are received, the receiving entity
3386 (initiator or responder) MUST do the following:
3388 1. Check the Next Payload field to confirm it is valid. If the Next
3389 Payload field validation fails, the message is discarded and the
3390 following actions are taken:
3392 (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the
3393 appropriate system audit file.
3395 (b) An Informational Exchange with a Notification payload
3396 containing the INVALID-PAYLOAD-TYPE message type MAY be sent
3397 to the transmitting entity. This action is dictated by a
3398 system security policy.
3400 2. Verify the RESERVED field contains the value zero. If the value
3401 in the RESERVED field is not zero, the message is discarded and
3402 the following actions are taken:
3404 (a) The event, INVALID RESERVED FIELD, MAY be logged in the
3405 appropriate system audit file.
3407 (b) An Informational Exchange with a Notification payload
3408 containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED
3409 message type MAY be sent to the transmitting entity. This
3410 action is dictated by a system security policy.
3412 3. Process the remaining payloads as defined by the Next Payload
3413 field.
3418 Maughan, et. al. Standards Track [Page 61]
3419 \f
3420 RFC 2408 ISAKMP November 1998
3423 5.4 Security Association Payload Processing
3425 When creating a Security Association Payload, the transmitting entity
3426 (initiator or responder) MUST do the following:
3428 1. Determine the Domain of Interpretation for which this negotiation
3429 is being performed.
3431 2. Determine the situation within the determined DOI for which this
3432 negotiation is being performed.
3434 3. Determine the proposal(s) and transform(s) within the situation.
3435 These are described, respectively, in sections 3.5 and 3.6.
3437 4. Construct a Security Association payload.
3439 5. Transmit the message to the receiving entity as described in
3440 section 5.1.
3442 When a Security Association payload is received, the receiving entity
3443 (initiator or responder) MUST do the following:
3445 1. Determine if the Domain of Interpretation (DOI) is supported. If
3446 the DOI determination fails, the message is discarded and the
3447 following actions are taken:
3449 (a) The event, INVALID DOI, MAY be logged in the appropriate
3450 system audit file.
3452 (b) An Informational Exchange with a Notification payload
3453 containing the DOI-NOT-SUPPORTED message type MAY be sent to
3454 the transmitting entity. This action is dictated by a
3455 system security policy.
3457 2. Determine if the given situation can be protected. If the
3458 Situation determination fails, the message is discarded and the
3459 following actions are taken:
3461 (a) The event, INVALID SITUATION, MAY be logged in the
3462 appropriate system audit file.
3464 (b) An Informational Exchange with a Notification payload
3465 containing the SITUATION-NOT-SUPPORTED message type MAY be
3466 sent to the transmitting entity. This action is dictated by
3467 a system security policy.
3469 3. Process the remaining payloads (i.e. Proposal, Transform) of the
3470 Security Association Payload. If the Security Association
3474 Maughan, et. al. Standards Track [Page 62]
3475 \f
3476 RFC 2408 ISAKMP November 1998
3479 Proposal (as described in sections 5.5 and 5.6) is not accepted,
3480 then the following actions are taken:
3482 (a) The event, INVALID PROPOSAL, MAY be logged in the
3483 appropriate system audit file.
3485 (b) An Informational Exchange with a Notification payload
3486 containing the NO-PROPOSAL-CHOSEN message type MAY be sent
3487 to the transmitting entity. This action is dictated by a
3488 system security policy.
3490 5.5 Proposal Payload Processing
3492 When creating a Proposal Payload, the transmitting entity (initiator
3493 or responder) MUST do the following:
3495 1. Determine the Protocol for this proposal.
3497 2. Determine the number of proposals to be offered for this protocol
3498 and the number of transforms for each proposal. Transforms are
3499 described in section 3.6.
3501 3. Generate a unique pseudo-random SPI.
3503 4. Construct a Proposal payload.
3505 When a Proposal payload is received, the receiving entity (initiator
3506 or responder) MUST do the following:
3508 1. Determine if the Protocol is supported. If the Protocol-ID field
3509 is invalid, the payload is discarded and the following actions
3510 are taken:
3512 (a) The event, INVALID PROTOCOL, MAY be logged in the
3513 appropriate system audit file.
3515 (b) An Informational Exchange with a Notification payload
3516 containing the INVALID-PROTOCOL-ID message type MAY be sent
3517 to the transmitting entity. This action is dictated by a
3518 system security policy.
3520 2. Determine if the SPI is valid. If the SPI is invalid, the
3521 payload is discarded and the following actions are taken:
3523 (a) The event, INVALID SPI, MAY be logged in the appropriate
3524 system audit file.
3530 Maughan, et. al. Standards Track [Page 63]
3531 \f
3532 RFC 2408 ISAKMP November 1998
3535 (b) An Informational Exchange with a Notification payload
3536 containing the INVALID-SPI message type MAY be sent to the
3537 transmitting entity. This action is dictated by a system
3538 security policy.
3540 3. Ensure the Proposals are presented according to the details given
3541 in section 3.5 and 4.2. If the proposals are not formed
3542 correctly, the following actions are taken:
3544 (a) Possible events, BAD PROPOSAL SYNTAX, INVALID PROPOSAL, are
3545 logged in the appropriate system audit file.
3547 (b) An Informational Exchange with a Notification payload
3548 containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED
3549 message type MAY be sent to the transmitting entity. This
3550 action is dictated by a system security policy.
3552 4. Process the Proposal and Transform payloads as defined by the
3553 Next Payload field. Examples of processing these payloads are
3554 given in section 4.2.1.
3556 5.6 Transform Payload Processing
3558 When creating a Transform Payload, the transmitting entity (initiator
3559 or responder) MUST do the following:
3561 1. Determine the Transform # for this transform.
3563 2. Determine the number of transforms to be offered for this
3564 proposal. Transforms are described in sections 3.6.
3566 3. Construct a Transform payload.
3568 When a Transform payload is received, the receiving entity (initiator
3569 or responder) MUST do the following:
3571 1. Determine if the Transform is supported. If the Transform-ID
3572 field contains an unknown or unsupported value, then that
3573 Transform payload MUST be ignored and MUST NOT cause the
3574 generation of an INVALID TRANSFORM event. If the Transform-ID
3575 field is invalid, the payload is discarded and the following
3576 actions are taken:
3578 (a) The event, INVALID TRANSFORM, MAY be logged in the
3579 appropriate system audit file.
3581 (b) An Informational Exchange with a Notification payload
3582 containing the INVALID-TRANSFORM-ID message type MAY be sent
3586 Maughan, et. al. Standards Track [Page 64]
3587 \f
3588 RFC 2408 ISAKMP November 1998
3591 to the transmitting entity. This action is dictated by a
3592 system security policy.
3594 2. Ensure the Transforms are presented according to the details
3595 given in section 3.6 and 4.2. If the transforms are not formed
3596 correctly, the following actions are taken:
3598 (a) Possible events, BAD PROPOSAL SYNTAX, INVALID TRANSFORM,
3599 INVALID ATTRIBUTES, are logged in the appropriate system
3600 audit file.
3602 (b) An Informational Exchange with a Notification payload
3603 containing the BAD-PROPOSAL-SYNTAX, PAYLOAD-MALFORMED or
3604 ATTRIBUTES-NOT-SUPPORTED message type MAY be sent to the
3605 transmitting entity. This action is dictated by a system
3606 security policy.
3608 3. Process the subsequent Transform and Proposal payloads as defined
3609 by the Next Payload field. Examples of processing these payloads
3610 are given in section 4.2.1.
3612 5.7 Key Exchange Payload Processing
3614 When creating a Key Exchange Payload, the transmitting entity
3615 (initiator or responder) MUST do the following:
3617 1. Determine the Key Exchange to be used as defined by the DOI.
3619 2. Determine the usage of the Key Exchange Data field as defined by
3620 the DOI.
3622 3. Construct a Key Exchange payload.
3624 4. Transmit the message to the receiving entity as described in
3625 section 5.1.
3627 When a Key Exchange payload is received, the receiving entity
3628 (initiator or responder) MUST do the following:
3630 1. Determine if the Key Exchange is supported. If the Key Exchange
3631 determination fails, the message is discarded and the following
3632 actions are taken:
3634 (a) The event, INVALID KEY INFORMATION, MAY be logged in the
3635 appropriate system audit file.
3637 (b) An Informational Exchange with a Notification payload
3638 containing the INVALID-KEY-INFORMATION message type MAY be
3642 Maughan, et. al. Standards Track [Page 65]
3643 \f
3644 RFC 2408 ISAKMP November 1998
3647 sent to the transmitting entity. This action is dictated by
3648 a system security policy.
3650 5.8 Identification Payload Processing
3652 When creating an Identification Payload, the transmitting entity
3653 (initiator or responder) MUST do the following:
3655 1. Determine the Identification information to be used as defined by
3656 the DOI (and possibly the situation).
3658 2. Determine the usage of the Identification Data field as defined
3659 by the DOI.
3661 3. Construct an Identification payload.
3663 4. Transmit the message to the receiving entity as described in
3664 section 5.1.
3666 When an Identification payload is received, the receiving entity
3667 (initiator or responder) MUST do the following:
3669 1. Determine if the Identification Type is supported. This may be
3670 based on the DOI and Situation. If the Identification
3671 determination fails, the message is discarded and the following
3672 actions are taken:
3674 (a) The event, INVALID ID INFORMATION, MAY be logged in the
3675 appropriate system audit file.
3677 (b) An Informational Exchange with a Notification payload
3678 containing the INVALID-ID-INFORMATION message type MAY be
3679 sent to the transmitting entity. This action is dictated by
3680 a system security policy.
3682 5.9 Certificate Payload Processing
3684 When creating a Certificate Payload, the transmitting entity
3685 (initiator or responder) MUST do the following:
3687 1. Determine the Certificate Encoding to be used. This may be
3688 specified by the DOI.
3690 2. Ensure the existence of a certificate formatted as defined by the
3691 Certificate Encoding.
3693 3. Construct a Certificate payload.
3698 Maughan, et. al. Standards Track [Page 66]
3699 \f
3700 RFC 2408 ISAKMP November 1998
3703 4. Transmit the message to the receiving entity as described in
3704 section 5.1.
3706 When a Certificate payload is received, the receiving entity
3707 (initiator or responder) MUST do the following:
3709 1. Determine if the Certificate Encoding is supported. If the
3710 Certificate Encoding is not supported, the payload is discarded
3711 and the following actions are taken:
3713 (a) The event, INVALID CERTIFICATE TYPE, MAY be logged in the
3714 appropriate system audit file.
3716 (b) An Informational Exchange with a Notification payload
3717 containing the INVALID-CERT-ENCODING message type MAY be
3718 sent to the transmitting entity. This action is dictated by
3719 a system security policy.
3721 2. Process the Certificate Data field. If the Certificate Data is
3722 invalid or improperly formatted, the payload is discarded and the
3723 following actions are taken:
3725 (a) The event, INVALID CERTIFICATE, MAY be logged in the
3726 appropriate system audit file.
3728 (b) An Informational Exchange with a Notification payload
3729 containing the INVALID-CERTIFICATE message type MAY be sent
3730 to the transmitting entity. This action is dictated by a
3731 system security policy.
3733 5.10 Certificate Request Payload Processing
3735 When creating a Certificate Request Payload, the transmitting entity
3736 (initiator or responder) MUST do the following:
3738 1. Determine the type of Certificate Encoding to be requested. This
3739 may be specified by the DOI.
3741 2. Determine the name of an acceptable Certificate Authority which
3742 is to be requested (if applicable).
3744 3. Construct a Certificate Request payload.
3746 4. Transmit the message to the receiving entity as described in
3747 section 5.1.
3749 When a Certificate Request payload is received, the receiving entity
3750 (initiator or responder) MUST do the following:
3754 Maughan, et. al. Standards Track [Page 67]
3755 \f
3756 RFC 2408 ISAKMP November 1998
3759 1. Determine if the Certificate Encoding is supported. If the
3760 Certificate Encoding is invalid, the payload is discarded and the
3761 following actions are taken:
3763 (a) The event, INVALID CERTIFICATE TYPE, MAY be logged in
3764 the appropriate system audit file.
3766 (b) An Informational Exchange with a Notification payload
3767 containing the INVALID-CERT-ENCODING message type MAY be
3768 sent to the transmitting entity. This action is dictated by
3769 a system security policy.
3771 If the Certificate Encoding is not supported, the payload is
3772 discarded and the following actions are taken:
3774 (a) The event, CERTIFICATE TYPE UNSUPPORTED, MAY be logged in
3775 the appropriate system audit file.
3777 (b) An Informational Exchange with a Notification payload
3778 containing the CERT-TYPE-UNSUPPORTED message type MAY be
3779 sent to the transmitting entity. This action is dictated by
3780 a system security policy.
3782 2. Determine if the Certificate Authority is supported for the
3783 specified Certificate Encoding. If the Certificate Authority is
3784 invalid or improperly formatted, the payload is discarded and the
3785 following actions are taken:
3787 (a) The event, INVALID CERTIFICATE AUTHORITY, MAY be logged in
3788 the appropriate system audit file.
3790 (b) An Informational Exchange with a Notification payload
3791 containing the INVALID-CERT-AUTHORITY message type MAY be
3792 sent to the transmitting entity. This action is dictated by
3793 a system security policy.
3795 3. Process the Certificate Request. If a requested Certificate Type
3796 with the specified Certificate Authority is not available, then
3797 the payload is discarded and the following actions are taken:
3799 (a) The event, CERTIFICATE-UNAVAILABLE, MAY be logged in the
3800 appropriate system audit file.
3802 (b) An Informational Exchange with a Notification payload
3803 containing the CERTIFICATE-UNAVAILABLE message type MAY be
3804 sent to the transmitting entity. This action is dictated by
3805 a system security policy.
3810 Maughan, et. al. Standards Track [Page 68]
3811 \f
3812 RFC 2408 ISAKMP November 1998
3815 5.11 Hash Payload Processing
3817 When creating a Hash Payload, the transmitting entity (initiator or
3818 responder) MUST do the following:
3820 1. Determine the Hash function to be used as defined by the SA
3821 negotiation.
3823 2. Determine the usage of the Hash Data field as defined by the DOI.
3825 3. Construct a Hash payload.
3827 4. Transmit the message to the receiving entity as described in
3828 section 5.1.
3830 When a Hash payload is received, the receiving entity (initiator or
3831 responder) MUST do the following:
3833 1. Determine if the Hash is supported. If the Hash determination
3834 fails, the message is discarded and the following actions are
3835 taken:
3837 (a) The event, INVALID HASH INFORMATION, MAY be logged in the
3838 appropriate system audit file.
3840 (b) An Informational Exchange with a Notification payload
3841 containing the INVALID-HASH-INFORMATION message type MAY be
3842 sent to the transmitting entity. This action is dictated by
3843 a system security policy.
3845 2. Perform the Hash function as outlined in the DOI and/or Key
3846 Exchange protocol documents. If the Hash function fails, the
3847 message is discarded and the following actions are taken:
3849 (a) The event, INVALID HASH VALUE, MAY be logged in the
3850 appropriate system audit file.
3852 (b) An Informational Exchange with a Notification payload
3853 containing the AUTHENTICATION-FAILED message type MAY be
3854 sent to the transmitting entity. This action is dictated by
3855 a system security policy.
3857 5.12 Signature Payload Processing
3859 When creating a Signature Payload, the transmitting entity (initiator
3860 or responder) MUST do the following:
3866 Maughan, et. al. Standards Track [Page 69]
3867 \f
3868 RFC 2408 ISAKMP November 1998
3871 1. Determine the Signature function to be used as defined by the SA
3872 negotiation.
3874 2. Determine the usage of the Signature Data field as defined by the
3875 DOI.
3877 3. Construct a Signature payload.
3879 4. Transmit the message to the receiving entity as described in
3880 section 5.1.
3882 When a Signature payload is received, the receiving entity (initiator
3883 or responder) MUST do the following:
3885 1. Determine if the Signature is supported. If the Signature
3886 determination fails, the message is discarded and the following
3887 actions are taken:
3889 (a) The event, INVALID SIGNATURE INFORMATION, MAY be logged in
3890 the appropriate system audit file.
3892 (b) An Informational Exchange with a Notification payload
3893 containing the INVALID-SIGNATURE message type MAY be sent to
3894 the transmitting entity. This action is dictated by a
3895 system security policy.
3897 2. Perform the Signature function as outlined in the DOI and/or Key
3898 Exchange protocol documents. If the Signature function fails,
3899 the message is discarded and the following actions are taken:
3901 (a) The event, INVALID SIGNATURE VALUE, MAY be logged in the
3902 appropriate system audit file.
3904 (b) An Informational Exchange with a Notification payload
3905 containing the AUTHENTICATION-FAILED message type MAY be
3906 sent to the transmitting entity. This action is dictated by
3907 a system security policy.
3909 5.13 Nonce Payload Processing
3911 When creating a Nonce Payload, the transmitting entity (initiator or
3912 responder) MUST do the following:
3914 1. Create a unique random value to be used as a nonce.
3916 2. Construct a Nonce payload.
3922 Maughan, et. al. Standards Track [Page 70]
3923 \f
3924 RFC 2408 ISAKMP November 1998
3927 3. Transmit the message to the receiving entity as described in
3928 section 5.1.
3930 When a Nonce payload is received, the receiving entity (initiator or
3931 responder) MUST do the following:
3933 1. There are no specific procedures for handling Nonce payloads.
3934 The procedures are defined by the exchange types (and possibly
3935 the DOI and Key Exchange descriptions).
3937 5.14 Notification Payload Processing
3939 During communications it is possible that errors may occur. The
3940 Informational Exchange with a Notify Payload provides a controlled
3941 method of informing a peer entity that errors have occurred during
3942 protocol processing. It is RECOMMENDED that Notify Payloads be sent
3943 in a separate Informational Exchange rather than appending a Notify
3944 Payload to an existing exchange.
3946 When creating a Notification Payload, the transmitting entity
3947 (initiator or responder) MUST do the following:
3949 1. Determine the DOI for this Notification.
3951 2. Determine the Protocol-ID for this Notification.
3953 3. Determine the SPI size based on the Protocol-ID field. This
3954 field is necessary because different security protocols have
3955 different SPI sizes. For example, ISAKMP combines the Initiator
3956 and Responder cookie pair (16 octets) as a SPI, while ESP and AH
3957 have 4 octet SPIs.
3959 4. Determine the Notify Message Type based on the error or status
3960 message desired.
3962 5. Determine the SPI which is associated with this notification.
3964 6. Determine if additional Notification Data is to be included.
3965 This is additional information specified by the DOI.
3967 7. Construct a Notification payload.
3969 8. Transmit the message to the receiving entity as described in
3970 section 5.1.
3972 Because the Informational Exchange with a Notification payload is a
3973 unidirectional message a retransmission will not be performed. The
3974 local security policy will dictate the procedures for continuing.
3978 Maughan, et. al. Standards Track [Page 71]
3979 \f
3980 RFC 2408 ISAKMP November 1998
3983 However, we RECOMMEND that a NOTIFICATION PAYLOAD ERROR event be
3984 logged in the appropriate system audit file by the receiving entity.
3986 If the Informational Exchange occurs prior to the exchange of keying
3987 material during an ISAKMP Phase 1 negotiation there will be no
3988 protection provided for the Informational Exchange. Once the keying
3989 material has been exchanged or the ISAKMP SA has been established,
3990 the Informational Exchange MUST be transmitted under the protection
3991 provided by the keying material or the ISAKMP SA.
3993 When a Notification payload is received, the receiving entity
3994 (initiator or responder) MUST do the following:
3996 1. Determine if the Informational Exchange has any protection
3997 applied to it by checking the Encryption Bit and the
3998 Authentication Only Bit in the ISAKMP Header. If the Encryption
3999 Bit is set, i.e. the Informational Exchange is encrypted, then
4000 the message MUST be decrypted using the (in-progress or
4001 completed) ISAKMP SA. Once the decryption is complete the
4002 processing can continue as described below. If the
4003 Authentication Only Bit is set, then the message MUST be
4004 authenticated using the (in-progress or completed) ISAKMP SA.
4005 Once the authentication is completed, the processing can continue
4006 as described below. If the Informational Exchange is not
4007 encrypted or authentication, the payload processing can continue
4008 as described below.
4010 2. Determine if the Domain of Interpretation (DOI) is supported. If
4011 the DOI determination fails, the payload is discarded and the
4012 following action is taken:
4014 (a) The event, INVALID DOI, MAY be logged in the appropriate
4015 system audit file.
4017 3. Determine if the Protocol-Id is supported. If the Protocol-Id
4018 determination fails, the payload is discarded and the following
4019 action is taken:
4021 (a) The event, INVALID PROTOCOL-ID, MAY be logged in the
4022 appropriate system audit file.
4024 4. Determine if the SPI is valid. If the SPI is invalid, the
4025 payload is discarded and the following action is taken:
4027 (a) The event, INVALID SPI, MAY be logged in the appropriate
4028 system audit file.
4034 Maughan, et. al. Standards Track [Page 72]
4035 \f
4036 RFC 2408 ISAKMP November 1998
4039 5. Determine if the Notify Message Type is valid. If the Notify
4040 Message Type is invalid, the payload is discarded and the
4041 following action is taken:
4043 (a) The event, INVALID MESSAGE TYPE, MAY be logged in the
4044 appropriate system audit file.
4046 6. Process the Notification payload, including additional
4047 Notification Data, and take appropriate action, according to
4048 local security policy.
4050 5.15 Delete Payload Processing
4052 During communications it is possible that hosts may be compromised or
4053 that information may be intercepted during transmission. Determining
4054 whether this has occurred is not an easy task and is outside the
4055 scope of this memo. However, if it is discovered that transmissions
4056 are being compromised, then it is necessary to establish a new SA and
4057 delete the current SA.
4059 The Informational Exchange with a Delete Payload provides a
4060 controlled method of informing a peer entity that the transmitting
4061 entity has deleted the SA(s). Deletion of Security Associations MUST
4062 always be performed under the protection of an ISAKMP SA. The
4063 receiving entity SHOULD clean up its local SA database. However,
4064 upon receipt of a Delete message the SAs listed in the Security
4065 Parameter Index (SPI) field of the Delete payload cannot be used with
4066 the transmitting entity. The SA Establishment procedure must be
4067 invoked to re-establish secure communications.
4069 When creating a Delete Payload, the transmitting entity (initiator or
4070 responder) MUST do the following:
4072 1. Determine the DOI for this Deletion.
4074 2. Determine the Protocol-ID for this Deletion.
4076 3. Determine the SPI size based on the Protocol-ID field. This
4077 field is necessary because different security protocols have
4078 different SPI sizes. For example, ISAKMP combines the Initiator
4079 and Responder cookie pair (16 octets) as a SPI, while ESP and AH
4080 have 4 octet SPIs.
4082 4. Determine the # of SPIs to be deleted for this protocol.
4084 5. Determine the SPI(s) which is (are) associated with this
4085 deletion.
4090 Maughan, et. al. Standards Track [Page 73]
4091 \f
4092 RFC 2408 ISAKMP November 1998
4095 6. Construct a Delete payload.
4097 7. Transmit the message to the receiving entity as described in
4098 section 5.1.
4100 Because the Informational Exchange with a Delete payload is a
4101 unidirectional message a retransmission will not be performed. The
4102 local security policy will dictate the procedures for continuing.
4103 However, we RECOMMEND that a DELETE PAYLOAD ERROR event be logged in
4104 the appropriate system audit file by the receiving entity.
4106 As described above, the Informational Exchange with a Delete payload
4107 MUST be transmitted under the protection provided by an ISAKMP SA.
4109 When a Delete payload is received, the receiving entity (initiator or
4110 responder) MUST do the following:
4112 1. Because the Informational Exchange is protected by some security
4113 service (e.g. authentication for an Auth-Only SA, encryption for
4114 other exchanges), the message MUST have these security services
4115 applied using the ISAKMP SA. Once the security service processing
4116 is complete the processing can continue as described below. Any
4117 errors that occur during the security service processing will be
4118 evident when checking information in the Delete payload. The
4119 local security policy SHOULD dictate any action to be taken as a
4120 result of security service processing errors.
4122 2. Determine if the Domain of Interpretation (DOI) is supported. If
4123 the DOI determination fails, the payload is discarded and the
4124 following action is taken:
4126 (a) The event, INVALID DOI, MAY be logged in the appropriate
4127 system audit file.
4129 3. Determine if the Protocol-Id is supported. If the Protocol-Id
4130 determination fails, the payload is discarded and the following
4131 action is taken:
4133 (a) The event, INVALID PROTOCOL-ID, MAY be logged in the
4134 appropriate system audit file.
4136 4. Determine if the SPI is valid for each SPI included in the Delete
4137 payload. For each SPI that is invalid, the following action is
4138 taken:
4140 (a) The event, INVALID SPI, MAY be logged in the appropriate
4141 system audit file.
4146 Maughan, et. al. Standards Track [Page 74]
4147 \f
4148 RFC 2408 ISAKMP November 1998
4151 5. Process the Delete payload and take appropriate action, according
4152 to local security policy. As described above, one appropriate
4153 action SHOULD include cleaning up the local SA database.
4155 6 Conclusions
4157 The Internet Security Association and Key Management Protocol
4158 (ISAKMP) is a well designed protocol aimed at the Internet of the
4159 future. The massive growth of the Internet will lead to great
4160 diversity in network utilization, communications, security
4161 requirements, and security mechanisms. ISAKMP contains all the
4162 features that will be needed for this dynamic and expanding
4163 communications environment.
4165 ISAKMP's Security Association (SA) feature coupled with
4166 authentication and key establishment provides the security and
4167 flexibility that will be needed for future growth and diversity.
4168 This security diversity of multiple key exchange techniques,
4169 encryption algorithms, authentication mechanisms, security services,
4170 and security attributes will allow users to select the appropriate
4171 security for their network, communications, and security needs. The
4172 SA feature allows users to specify and negotiate security
4173 requirements with other users. An additional benefit of supporting
4174 multiple techniques in a single protocol is that as new techniques
4175 are developed they can easily be added to the protocol. This
4176 provides a path for the growth of Internet security services. ISAKMP
4177 supports both publicly or privately defined SAs, making it ideal for
4178 government, commercial, and private communications.
4180 ISAKMP provides the ability to establish SAs for multiple security
4181 protocols and applications. These protocols and applications may be
4182 session-oriented or sessionless. Having one SA establishment
4183 protocol that supports multiple security protocols eliminates the
4184 need for multiple, nearly identical authentication, key exchange and
4185 SA establishment protocols when more than one security protocol is in
4186 use or desired. Just as IP has provided the common networking layer
4187 for the Internet, a common security establishment protocol is needed
4188 if security is to become a reality on the Internet. ISAKMP provides
4189 the common base that allows all other security protocols to
4190 interoperate.
4192 ISAKMP follows good security design principles. It is not coupled to
4193 other insecure transport protocols, therefore it is not vulnerable or
4194 weakened by attacks on other protocols. Also, when more secure
4195 transport protocols are developed, ISAKMP can be easily migrated to
4196 them. ISAKMP also provides protection against protocol related
4197 attacks. This protection provides the assurance that the SAs and
4198 keys established are with the desired party and not with an attacker.
4202 Maughan, et. al. Standards Track [Page 75]
4203 \f
4204 RFC 2408 ISAKMP November 1998
4207 ISAKMP also follows good protocol design principles. Protocol
4208 specific information only is in the protocol header, following the
4209 design principles of IPv6. The data transported by the protocol is
4210 separated into functional payloads. As the Internet grows and
4211 evolves, new payloads to support new security functionality can be
4212 added without modifying the entire protocol.
4258 Maughan, et. al. Standards Track [Page 76]
4259 \f
4260 RFC 2408 ISAKMP November 1998
4263 A ISAKMP Security Association Attributes
4265 A.1 Background/Rationale
4267 As detailed in previous sections, ISAKMP is designed to provide a
4268 flexible and extensible framework for establishing and managing
4269 Security Associations and cryptographic keys. The framework provided
4270 by ISAKMP consists of header and payload definitions, exchange types
4271 for guiding message and payload exchanges, and general processing
4272 guidelines. ISAKMP does not define the mechanisms that will be used
4273 to establish and manage Security Associations and cryptographic keys
4274 in an authenticated and confidential manner. The definition of
4275 mechanisms and their application is the purview of individual Domains
4276 of Interpretation (DOIs).
4278 This section describes the ISAKMP values for the Internet IP Security
4279 DOI, supported security protocols, and identification values for
4280 ISAKMP Phase 1 negotiations. The Internet IP Security DOI is
4281 MANDATORY to implement for IP Security. [Oakley] and [IKE] describe,
4282 in detail, the mechanisms and their application for establishing and
4283 managing Security Associations and cryptographic keys for IP
4284 Security.
4286 A.2 Internet IP Security DOI Assigned Value
4288 As described in [IPDOI], the Internet IP Security DOI Assigned Number
4289 is one (1).
4291 A.3 Supported Security Protocols
4293 Values for supported security protocols are specified in the most
4294 recent "Assigned Numbers" RFC [STD-2]. Presented in the following
4295 table are the values for the security protocols supported by ISAKMP
4296 for the Internet IP Security DOI.
4299 Protocol Assigned Value
4300 RESERVED 0
4301 ISAKMP 1
4303 All DOIs MUST reserve ISAKMP with a Protocol-ID of 1. All other
4304 security protocols within that DOI will be numbered accordingly.
4306 Security protocol values 2-15359 are reserved to IANA for future use.
4307 Values 15360-16383 are permanently reserved for private use amongst
4308 mutually consenting implementations. Such private use values are
4309 unlikely to be interoperable across different implementations.
4314 Maughan, et. al. Standards Track [Page 77]
4315 \f
4316 RFC 2408 ISAKMP November 1998
4319 A.4 ISAKMP Identification Type Values
4321 The following table lists the assigned values for the Identification
4322 Type field found in the Identification payload during a generic Phase
4323 1 exchange, which is not for a specific protocol.
4326 ID Type Value
4327 ID_IPV4_ADDR 0
4328 ID_IPV4_ADDR_SUBNET 1
4329 ID_IPV6_ADDR 2
4330 ID_IPV6_ADDR_SUBNET 3
4332 A.4.1 ID_IPV4_ADDR
4334 The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
4336 A.4.2 ID_IPV4_ADDR_SUBNET
4338 The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses,
4339 represented by two four (4) octet values. The first value is an IPv4
4340 address. The second is an IPv4 network mask. Note that ones (1s) in
4341 the network mask indicate that the corresponding bit in the address
4342 is fixed, while zeros (0s) indicate a "wildcard" bit.
4344 A.4.3 ID_IPV6_ADDR
4346 The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6
4347 address.
4349 A.4.4 ID_IPV6_ADDR_SUBNET
4351 The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses,
4352 represented by two sixteen (16) octet values. The first value is an
4353 IPv6 address. The second is an IPv6 network mask. Note that ones
4354 (1s) in the network mask indicate that the corresponding bit in the
4355 address is fixed, while zeros (0s) indicate a "wildcard" bit.
4370 Maughan, et. al. Standards Track [Page 78]
4371 \f
4372 RFC 2408 ISAKMP November 1998
4375 B Defining a new Domain of Interpretation
4377 The Internet DOI may be sufficient to meet the security requirements
4378 of a large portion of the internet community. However, some groups
4379 may have a need to customize some aspect of a DOI, perhaps to add a
4380 different set of cryptographic algorithms, or perhaps because they
4381 want to make their security-relevant decisions based on something
4382 other than a host id or user id. Also, a particular group may have a
4383 need for a new exchange type, for example to support key management
4384 for multicast groups.
4386 This section discusses guidelines for defining a new DOI. The full
4387 specification for the Internet DOI can be found in [IPDOI].
4389 Defining a new DOI is likely to be a time-consuming process. If at
4390 all possible, it is recommended that the designer begin with an
4391 existing DOI and customize only the parts that are unacceptable.
4393 If a designer chooses to start from scratch, the following MUST be
4394 defined:
4396 o A "situation": the set of information that will be used to
4397 determine the required security services.
4399 o The set of security policies that must be supported.
4401 o A scheme for naming security-relevant information, including
4402 encryption algorithms, key exchange algorithms, etc.
4404 o A syntax for the specification of proposed security services,
4405 attributes, and certificate authorities.
4407 o The specific formats of the various payload contents.
4409 o Additional exchange types, if required.
4411 B.1 Situation
4413 The situation is the basis for deciding how to protect a
4414 communications channel. It must contain all of the data that will be
4415 used to determine the types and strengths of protections applied in
4416 an SA. For example, a US Department of Defense DOI would probably use
4417 unpublished algorithms and have additional special attributes to
4418 negotiate. These additional security attributes would be included in
4419 the situation.
4426 Maughan, et. al. Standards Track [Page 79]
4427 \f
4428 RFC 2408 ISAKMP November 1998
4431 B.2 Security Policies
4433 Security policies define how various types of information must be
4434 categorized and protected. The DOI must define the set of security
4435 policies supported, because both parties in a negotiation must trust
4436 that the other party understands a situation, and will protect
4437 information appropriately, both in transit and in storage. In a
4438 corporate setting, for example, both parties in a negotiation must
4439 agree to the meaning of the term "proprietary information" before
4440 they can negotiate how to protect it.
4442 Note that including the required security policies in the DOI only
4443 specifies that the participating hosts understand and implement those
4444 policies in a full system context.
4446 B.3 Naming Schemes
4448 Any DOI must define a consistent way to name cryptographic
4449 algorithms, certificate authorities, etc. This can usually be done
4450 by using IANA naming conventions, perhaps with some private
4451 extensions.
4453 B.4 Syntax for Specifying Security Services
4455 In addition to simply specifying how to name entities, the DOI must
4456 also specify the format for complete proposals of how to protect
4457 traffic under a given situation.
4459 B.5 Payload Specification
4461 The DOI must specify the format of each of the payload types. For
4462 several of the payload types, ISAKMP has included fields that would
4463 have to be present across all DOI (such as a certificate authority in
4464 the certificate payload, or a key exchange identifier in the key
4465 exchange payload).
4467 B.6 Defining new Exchange Types
4469 If the basic exchange types are inadequate to meet the requirements
4470 within a DOI, a designer can define up to thirteen extra exchange
4471 types per DOI. The designer creates a new exchange type by choosing
4472 an unused exchange type value, and defining a sequence of messages
4473 composed of strings of the ISAKMP payload types.
4475 Note that any new exchange types must be rigorously analyzed for
4476 vulnerabilities. Since this is an expensive and imprecise
4477 undertaking, a new exchange type should only be created when
4478 absolutely necessary.
4482 Maughan, et. al. Standards Track [Page 80]
4483 \f
4484 RFC 2408 ISAKMP November 1998
4487 Security Considerations
4489 Cryptographic analysis techniques are improving at a steady pace.
4490 The continuing improvement in processing power makes once
4491 computationally prohibitive cryptographic attacks more realistic.
4492 New cryptographic algorithms and public key generation techniques are
4493 also being developed at a steady pace. New security services and
4494 mechanisms are being developed at an accelerated pace. A consistent
4495 method of choosing from a variety of security services and mechanisms
4496 and to exchange attributes required by the mechanisms is important to
4497 security in the complex structure of the Internet. However, a system
4498 that locks itself into a single cryptographic algorithm, key exchange
4499 technique, or security mechanism will become increasingly vulnerable
4500 as time passes.
4502 UDP is an unreliable datagram protocol and therefore its use in
4503 ISAKMP introduces a number of security considerations. Since UDP is
4504 unreliable, but a key management protocol must be reliable, the
4505 reliability is built into ISAKMP. While ISAKMP utilizes UDP as its
4506 transport mechanism, it doesn't rely on any UDP information (e.g.
4507 checksum, length) for its processing.
4509 Another issue that must be considered in the development of ISAKMP is
4510 the effect of firewalls on the protocol. Many firewalls filter out
4511 all UDP packets, making reliance on UDP questionable in certain
4512 environments.
4514 A number of very important security considerations are presented in
4515 [SEC-ARCH]. One bears repeating. Once a private session key is
4516 created, it must be safely stored. Failure to properly protect the
4517 private key from access both internal and external to the system
4518 completely nullifies any protection provided by the IP Security
4519 services.
4521 IANA Considerations
4523 This document contains many "magic" numbers to be maintained by the
4524 IANA. This section explains the criteria to be used by the IANA to
4525 assign additional numbers in each of these lists.
4527 Domain of Interpretation
4529 The Domain of Interpretation (DOI) is a 32-bit field which identifies
4530 the domain under which the security association negotiation is taking
4531 place. Requests for assignments of new DOIs must be accompanied by a
4532 standards-track RFC which describes the specific domain.
4538 Maughan, et. al. Standards Track [Page 81]
4539 \f
4540 RFC 2408 ISAKMP November 1998
4543 Supported Security Protocols
4545 ISAKMP is designed to provide security association negotiation and
4546 key management for many security protocols. Requests for identifiers
4547 for additional security protocols must be accompanied by a
4548 standards-track RFC which describes the security protocol and its
4549 relationship to ISAKMP.
4551 Acknowledgements
4553 Dan Harkins, Dave Carrel, and Derrell Piper of Cisco Systems provided
4554 design assistance with the protocol and coordination for the [IKE]
4555 and [IPDOI] documents.
4557 Hilarie Orman, via the Oakley key exchange protocol, has
4558 significantly influenced the design of ISAKMP.
4560 Marsha Gross, Bill Kutz, Mike Oehler, Pete Sell, and Ruth Taylor
4561 provided significant input and review to this document.
4563 Scott Carlson ported the TIS DNSSEC prototype to FreeBSD for use with
4564 the ISAKMP prototype.
4566 Jeff Turner and Steve Smalley contributed to the prototype
4567 development and integration with ESP and AH.
4569 Mike Oehler and Pete Sell performed interoperability testing with
4570 other ISAKMP implementors.
4572 Thanks to Carl Muckenhirn of SPARTA, Inc. for his assistance with
4573 LaTeX.
4575 References
4577 [ANSI] ANSI, X9.42: Public Key Cryptography for the Financial
4578 Services Industry -- Establishment of Symmetric Algorithm
4579 Keys Using Diffie-Hellman, Working Draft, April 19, 1996.
4581 [BC] Ballardie, A., and J. Crowcroft, Multicast-specific
4582 Security Threats and Countermeasures, Proceedings of 1995
4583 ISOC Symposium on Networks & Distributed Systems Security,
4584 pp. 17-30, Internet Society, San Diego, CA, February 1995.
4586 [Berge] Berge, N., "UNINETT PCA Policy Statements", RFC 1875,
4587 December 1995.
4594 Maughan, et. al. Standards Track [Page 82]
4595 \f
4596 RFC 2408 ISAKMP November 1998
4599 [CW87] Clark, D.D. and D.R. Wilson, A Comparison of Commercial
4600 and Military Computer Security Policies, Proceedings of
4601 the IEEE Symposium on Security & Privacy, Oakland, CA,
4602 1987, pp. 184-193.
4604 [DNSSEC] D. Eastlake III, Domain Name System Protocol Security
4605 Extensions, Work in Progress.
4607 [DOW92] Diffie, W., M.Wiener, P. Van Oorschot, Authentication and
4608 Authenticated Key Exchanges, Designs, Codes, and
4609 Cryptography, 2, 107-125, Kluwer Academic Publishers,
4610 1992.
4612 [IAB] Bellovin, S., "Report of the IAB Security Architecture
4613 Workshop", RFC 2316, April 1998.
4615 [IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange
4616 (IKE)", RFC 2409, November 1998.
4618 [IPDOI] Piper, D., "The Internet IP Security Domain of
4619 Interpretation for ISAKMP", RFC 2407, November 1998.
4621 [Karn] Karn, P., and B. Simpson, Photuris: Session Key
4622 Management Protocol, Work in Progress.
4624 [Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August
4625 10, 1994.
4627 [Oakley] Orman, H., "The Oakley Key Determination Protocol", RFC
4628 2412, November 1998.
4630 [RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic
4631 Mail: Part II: Certificate-Based Key Management", RFC
4632 1422, February 1993.
4634 [RFC-1949] Ballardie, A., "Scalable Multicast Key Distribution", RFC
4635 1949, May 1996.
4637 [RFC-2093] Harney, H., and C. Muckenhirn, "Group Key Management
4638 Protocol (GKMP) Specification", RFC 2093, July 1997.
4640 [RFC-2094] Harney, H., and C. Muckenhirn, "Group Key Management
4641 Protocol (GKMP) Architecture", RFC 2094, July 1997.
4643 [RFC-2119] Bradner, S., "Key Words for use in RFCs to Indicate
4644 Requirement Levels", BCP 14, RFC 2119, March 1997.
4650 Maughan, et. al. Standards Track [Page 83]
4651 \f
4652 RFC 2408 ISAKMP November 1998
4655 [Schneier] Bruce Schneier, Applied Cryptography - Protocols,
4656 Algorithms, and Source Code in C (Second Edition), John
4657 Wiley & Sons, Inc., 1996.
4659 [SEC-ARCH] Atkinson, R., and S. Kent, "Security Architecture for the
4660 Internet Protocol", RFC 2401, November 1998.
4662 [STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
4663 1700, October 1994. See also:
4664 http://www.iana.org/numbers.html
4706 Maughan, et. al. Standards Track [Page 84]
4707 \f
4708 RFC 2408 ISAKMP November 1998
4711 Authors' Addresses
4713 Douglas Maughan
4714 National Security Agency
4715 ATTN: R23
4716 9800 Savage Road
4717 Ft. Meade, MD. 20755-6000
4719 Phone: 301-688-0847
4720 EMail:wdm@tycho.ncsc.mil
4723 Mark Schneider
4724 National Security Agency
4725 ATTN: R23
4726 9800 Savage Road
4727 Ft. Meade, MD. 20755-6000
4729 Phone: 301-688-0851
4730 EMail:mss@tycho.ncsc.mil
4733 Mark Schertler
4734 Securify, Inc.
4735 2415-B Charleston Road
4736 Mountain View, CA 94043
4738 Phone: 650-934-9303
4739 EMail:mjs@securify.com
4742 Jeff Turner
4743 RABA Technologies, Inc.
4744 10500 Little Patuxent Parkway
4745 Columbia, MD. 21044
4747 Phone: 410-715-9399
4748 EMail:jeff.turner@raba.com
4762 Maughan, et. al. Standards Track [Page 85]
4763 \f
4764 RFC 2408 ISAKMP November 1998
4767 Full Copyright Statement
4769 Copyright (C) The Internet Society (1998). All Rights Reserved.
4771 This document and translations of it may be copied and furnished to
4772 others, and derivative works that comment on or otherwise explain it
4773 or assist in its implementation may be prepared, copied, published
4774 and distributed, in whole or in part, without restriction of any
4775 kind, provided that the above copyright notice and this paragraph are
4776 included on all such copies and derivative works. However, this
4777 document itself may not be modified in any way, such as by removing
4778 the copyright notice or references to the Internet Society or other
4779 Internet organizations, except as needed for the purpose of
4780 developing Internet standards in which case the procedures for
4781 copyrights defined in the Internet Standards process must be
4782 followed, or as required to translate it into languages other than
4783 English.
4785 The limited permissions granted above are perpetual and will not be
4786 revoked by the Internet Society or its successors or assigns.
4788 This document and the information contained herein is provided on an
4789 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
4790 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
4791 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
4792 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
4793 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
4818 Maughan, et. al. Standards Track [Page 86]
4819 \f