- moved RFCs from ikev2 into doc dir
[strongswan.git] / doc / ikev2 / [RFC2408] - Internet Security Association and Key Management Protocol (ISAKMP).txt
1
2
3
4
5
6
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
16
17
18    Internet Security Association and Key Management Protocol (ISAKMP)
19
20 Status of this Memo
21
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.
27
28 Copyright Notice
29
30    Copyright (C) The Internet Society (1998).  All Rights Reserved.
31
32 Abstract
33
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.
51
52
53
54
55
56
57
58 Maughan, et. al.            Standards Track                     [Page 1]
59 \f
60 RFC 2408                         ISAKMP                    November 1998
61
62
63 Table of Contents
64
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
111
112
113
114 Maughan, et. al.            Standards Track                     [Page 2]
115 \f
116 RFC 2408                         ISAKMP                    November 1998
117
118
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
167
168
169
170 Maughan, et. al.            Standards Track                     [Page 3]
171 \f
172 RFC 2408                         ISAKMP                    November 1998
173
174
175    Acknowledgements                                                  82
176    References                                                        82
177    Authors' Addresses                                                85
178    Full Copyright Statement                                          86
179
180 List of Figures
181
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
199
200 1 Introduction
201
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.
207
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.
220
221
222
223
224
225
226 Maughan, et. al.            Standards Track                     [Page 4]
227 \f
228 RFC 2408                         ISAKMP                    November 1998
229
230
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.
238
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.
244
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.
251
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.
267
268 1.1 Requirements Terminology
269
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].
273
274 1.2 The Need for Negotiation
275
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
279
280
281
282 Maughan, et. al.            Standards Track                     [Page 5]
283 \f
284 RFC 2408                         ISAKMP                    November 1998
285
286
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.
307
308 1.3 What can be Negotiated?
309
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.
321
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.
333
334
335
336
337
338 Maughan, et. al.            Standards Track                     [Page 6]
339 \f
340 RFC 2408                         ISAKMP                    November 1998
341
342
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.
350
351 1.4 Security Associations and Management
352
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.
368
369 1.4.1 Security Associations and Registration
370
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.
380
381    NOTE: See [IPDOI] for a discussion of SA attributes that should be
382    considered when defining a security protocol or application.
383
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.
390
391
392
393
394 Maughan, et. al.            Standards Track                     [Page 7]
395 \f
396 RFC 2408                         ISAKMP                    November 1998
397
398
399 1.4.2 ISAKMP Requirements
400
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.
408
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.
426
427 1.5 Authentication
428
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
447
448
449
450 Maughan, et. al.            Standards Track                     [Page 8]
451 \f
452 RFC 2408                         ISAKMP                    November 1998
453
454
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].
461
462 1.5.1 Certificate Authorities
463
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.
483
484 1.5.2 Entity Naming
485
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.
501
502
503
504
505
506 Maughan, et. al.            Standards Track                     [Page 9]
507 \f
508 RFC 2408                         ISAKMP                    November 1998
509
510
511 1.5.3 ISAKMP Requirements
512
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.
523
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.
534
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.
545
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.
552
553 1.6 Public Key Cryptography
554
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
559
560
561
562 Maughan, et. al.            Standards Track                    [Page 10]
563 \f
564 RFC 2408                         ISAKMP                    November 1998
565
566
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.
571
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.
576
577 1.6.1 Key Exchange Properties
578
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.
604
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.
615
616
617
618 Maughan, et. al.            Standards Track                    [Page 11]
619 \f
620 RFC 2408                         ISAKMP                    November 1998
621
622
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.
630
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.
637
638 1.6.2 ISAKMP Requirements
639
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.
652
653 1.7 ISAKMP Protection
654
655 1.7.1 Anti-Clogging (Denial of Service)
656
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].
668
669
670
671
672
673
674 Maughan, et. al.            Standards Track                    [Page 12]
675 \f
676 RFC 2408                         ISAKMP                    November 1998
677
678
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].
686
687 1.7.2 Connection Hijacking
688
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.
694
695 1.7.3 Man-in-the-Middle Attacks
696
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.
714
715 1.8 Multicast Communications
716
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.
726
727
728
729
730 Maughan, et. al.            Standards Track                    [Page 13]
731 \f
732 RFC 2408                         ISAKMP                    November 1998
733
734
735 2 Terminology and Concepts
736
737 2.1 ISAKMP Terminology
738
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.
745
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.
754
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").
762
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.
765
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.
775
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
783
784
785
786 Maughan, et. al.            Standards Track                    [Page 14]
787 \f
788 RFC 2408                         ISAKMP                    November 1998
789
790
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:
794
795     o  A "situation":  the set of information that will be used to
796        determine the required security services.
797
798     o  The set of security policies that must, and may, be supported.
799
800     o  A syntax for the specification of proposed security services.
801
802     o  A scheme for naming security-relevant information, including
803        encryption algorithms, key exchange algorithms, security policy
804        attributes, and certificate authorities.
805
806     o  The specific formats of the various payload contents.
807
808     o  Additional exchange types, if required.
809
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.
813
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.
819
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.
823
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.
832
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
839
840
841
842 Maughan, et. al.            Standards Track                    [Page 15]
843 \f
844 RFC 2408                         ISAKMP                    November 1998
845
846
847    default set of ISAKMP exchange types.  Other exchange types can be
848    added to support additional key exchanges, if required.
849
850 2.2 ISAKMP Placement
851
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".
857
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                          +---------------------------------------------+
879
880
881                      Figure 1:  ISAKMP Relationships
882
883 2.3 Negotiation Phases
884
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.
891
892
893
894
895
896
897
898 Maughan, et. al.            Standards Track                    [Page 16]
899 \f
900 RFC 2408                         ISAKMP                    November 1998
901
902
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.
908
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.
912
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.
917
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.
926
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.
932
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.
936
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.
943
944 2.4 Identifying Security Associations
945
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
951
952
953
954 Maughan, et. al.            Standards Track                    [Page 17]
955 \f
956 RFC 2408                         ISAKMP                    November 1998
957
958
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.
964
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.
972
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
980
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.
984
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.
993
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.
998
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.
1005
1006
1007
1008
1009
1010 Maughan, et. al.            Standards Track                    [Page 18]
1011 \f
1012 RFC 2408                         ISAKMP                    November 1998
1013
1014
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.
1019
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).
1027
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.
1034
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]).
1040
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.
1046
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.
1060
1061
1062
1063
1064
1065
1066 Maughan, et. al.            Standards Track                    [Page 19]
1067 \f
1068 RFC 2408                         ISAKMP                    November 1998
1069
1070
1071 2.5 Miscellaneous
1072
1073 2.5.1 Transport Protocol
1074
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.
1081
1082 2.5.2 RESERVED Fields
1083
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.
1089
1090 2.5.3 Anti-Clogging Token ("Cookie") Creation
1091
1092    The details of cookie generation are implementation dependent, but
1093    MUST satisfy these basic requirements (originally stated by Phil Karn
1094    in [Karn]):
1095
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.
1101
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.
1108
1109       3.    The cookie generation function must be fast to thwart
1110             attacks intended to sabotage CPU resources.
1111
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
1119
1120
1121
1122 Maughan, et. al.            Standards Track                    [Page 20]
1123 \f
1124 RFC 2408                         ISAKMP                    November 1998
1125
1126
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.
1135
1136 3 ISAKMP Payloads
1137
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.
1145
1146 3.1 ISAKMP Header Format
1147
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.
1154
1155    The ISAKMP Header fields are defined as follows:
1156
1157     o  Initiator Cookie (8 octets) - Cookie of entity that initiated SA
1158        establishment, SA notification, or SA deletion.
1159
1160     o  Responder Cookie (8 octets) - Cookie of entity that is responding
1161        to an SA establishment request, SA notification, or SA deletion.
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178 Maughan, et. al.            Standards Track                    [Page 21]
1179 \f
1180 RFC 2408                         ISAKMP                    November 1998
1181
1182
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     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1198
1199
1200                  Figure 2:  ISAKMP Header Format
1201
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.
1206
1207
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
1225
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
1231
1232
1233
1234 Maughan, et. al.            Standards Track                    [Page 22]
1235 \f
1236 RFC 2408                         ISAKMP                    November 1998
1237
1238
1239        never accept packets with a major version number larger than its
1240        own.
1241
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.
1249
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.
1253
1254
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
1265
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.
1273
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.
1284
1285
1286
1287
1288
1289
1290 Maughan, et. al.            Standards Track                    [Page 23]
1291 \f
1292 RFC 2408                         ISAKMP                    November 1998
1293
1294
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.
1317
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.
1333
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
1343
1344
1345
1346 Maughan, et. al.            Standards Track                    [Page 24]
1347 \f
1348 RFC 2408                         ISAKMP                    November 1998
1349
1350
1351           the payload will not be encrypted.
1352
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.
1363
1364     o  Length (4 octets) - Length of total message (header + payloads)
1365        in octets.  Encryption can expand the size of an ISAKMP message.
1366
1367 3.2 Generic Payload Header
1368
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.
1373
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        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1379
1380                    Figure 3:  Generic Payload Header
1381
1382    The Generic Payload Header fields are defined as follows:
1383
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.
1388
1389     o  RESERVED (1 octet) - Unused, set to 0.
1390
1391     o  Payload Length (2 octets) - Length in octets of the current
1392        payload, including the generic payload header.
1393
1394 3.3 Data Attributes
1395
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
1399
1400
1401
1402 Maughan, et. al.            Standards Track                    [Page 25]
1403 \f
1404 RFC 2408                         ISAKMP                    November 1998
1405
1406
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].
1416
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1426
1427
1428                      Figure 4:  Data Attributes
1429
1430    The Data Attributes fields are defined as follows:
1431
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.
1435
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.
1442
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.
1446
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.
1452
1453
1454
1455
1456
1457
1458 Maughan, et. al.            Standards Track                    [Page 26]
1459 \f
1460 RFC 2408                         ISAKMP                    November 1998
1461
1462
1463 3.4 Security Association Payload
1464
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.
1469
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1481
1482
1483               Figure 5:  Security Association Payload
1484
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).
1494
1495     o  RESERVED (1 octet) - Unused, set to 0.
1496
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.
1501
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
1511
1512
1513
1514 Maughan, et. al.            Standards Track                    [Page 27]
1515 \f
1516 RFC 2408                         ISAKMP                    November 1998
1517
1518
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.
1522
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.
1529
1530 3.5 Proposal Payload
1531
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.
1537
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1547
1548
1549                  Figure 6:  Proposal Payload Format
1550
1551    The Proposal Payload fields are defined as follows:
1552
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.
1559
1560     o  RESERVED (1 octet) - Unused, set to 0.
1561
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
1567
1568
1569
1570 Maughan, et. al.            Standards Track                    [Page 28]
1571 \f
1572 RFC 2408                         ISAKMP                    November 1998
1573
1574
1575        only applies to the current Proposal payload and not to all
1576        Proposal payloads.
1577
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.
1581
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.
1585
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.
1596
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.
1600
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.
1605
1606    The payload type for the Proposal Payload is two (2).
1607
1608 3.6 Transform Payload
1609
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.
1618
1619
1620
1621
1622
1623
1624
1625
1626 Maughan, et. al.            Standards Track                    [Page 29]
1627 \f
1628 RFC 2408                         ISAKMP                    November 1998
1629
1630
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1642
1643
1644                 Figure 7:  Transform Payload Format
1645
1646    The Transform Payload fields are defined as follows:
1647
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.
1654
1655     o  RESERVED (1 octet) - Unused, set to 0.
1656
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.
1660
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.
1666
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.
1671
1672     o  RESERVED2 (2 octets) - Unused, set to 0.
1673
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,
1679
1680
1681
1682 Maughan, et. al.            Standards Track                    [Page 30]
1683 \f
1684 RFC 2408                         ISAKMP                    November 1998
1685
1686
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.
1690
1691    The payload type for the Transform Payload is three (3).
1692
1693 3.7 Key Exchange Payload
1694
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.
1700
1701    The Key Exchange Payload fields are defined as follows:
1702
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.
1706
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1716
1717
1718                Figure 8:  Key Exchange Payload Format
1719
1720     o  RESERVED (1 octet) - Unused, set to 0.
1721
1722     o  Payload Length (2 octets) - Length in octets of the current
1723        payload, including the generic payload header.
1724
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.
1729
1730    The payload type for the Key Exchange Payload is four (4).
1731
1732
1733
1734
1735
1736
1737
1738 Maughan, et. al.            Standards Track                    [Page 31]
1739 \f
1740 RFC 2408                         ISAKMP                    November 1998
1741
1742
1743 3.8 Identification Payload
1744
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.
1750
1751    The Identification Payload fields are defined as follows:
1752
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.
1756
1757     o  RESERVED (1 octet) - Unused, set to 0.
1758
1759     o  Payload Length (2 octets) - Length in octets of the current
1760        payload, including the generic payload header.
1761
1762     o  ID Type (1 octet) - Specifies the type of Identification being
1763        used.
1764
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1776
1777
1778               Figure 9:  Identification Payload Format
1779
1780        This field is DOI-dependent.
1781
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.
1785
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].
1791
1792
1793
1794 Maughan, et. al.            Standards Track                    [Page 32]
1795 \f
1796 RFC 2408                         ISAKMP                    November 1998
1797
1798
1799    The payload type for the Identification Payload is five (5).
1800
1801 3.9 Certificate Payload
1802
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.
1810
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.
1814
1815    The Certificate Payload fields are defined as follows:
1816
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.
1820
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1831
1832
1833                Figure 10:  Certificate Payload Format
1834
1835     o  RESERVED (1 octet) - Unused, set to 0.
1836
1837     o  Payload Length (2 octets) - Length in octets of the current
1838        payload, including the generic payload header.
1839
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.
1843
1844
1845
1846
1847
1848
1849
1850 Maughan, et. al.            Standards Track                    [Page 33]
1851 \f
1852 RFC 2408                         ISAKMP                    November 1998
1853
1854
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
1868
1869     o  Certificate Data (variable length) - Actual encoding of
1870        certificate data.  The type of certificate is indicated by the
1871        Certificate Encoding field.
1872
1873    The payload type for the Certificate Payload is six (6).
1874
1875 3.10 Certificate Request Payload
1876
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.
1888
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1899
1900
1901            Figure 11:  Certificate Request Payload Format
1902
1903
1904
1905
1906 Maughan, et. al.            Standards Track                    [Page 34]
1907 \f
1908 RFC 2408                         ISAKMP                    November 1998
1909
1910
1911    The Certificate Payload fields are defined as follows:
1912
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.
1916
1917     o  RESERVED (1 octet) - Unused, set to 0.
1918
1919     o  Payload Length (2 octets) - Length in octets of the current
1920        payload, including the generic payload header.
1921
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.
1925
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.
1936
1937    The payload type for the Certificate Request Payload is seven (7).
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962 Maughan, et. al.            Standards Track                    [Page 35]
1963 \f
1964 RFC 2408                         ISAKMP                    November 1998
1965
1966
1967 3.11 Hash Payload
1968
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.
1975
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1985
1986
1987                   Figure 12:  Hash Payload Format
1988
1989    The Hash Payload fields are defined as follows:
1990
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.
1994
1995     o  RESERVED (1 octet) - Unused, set to 0.
1996
1997     o  Payload Length (2 octets) - Length in octets of the current
1998        payload, including the generic payload header.
1999
2000     o  Hash Data (variable length) - Data that results from applying the
2001        hash routine to the ISAKMP message and/or state.
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018 Maughan, et. al.            Standards Track                    [Page 36]
2019 \f
2020 RFC 2408                         ISAKMP                    November 1998
2021
2022
2023 3.12 Signature Payload
2024
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.
2031
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2041
2042
2043                 Figure 13:  Signature Payload Format
2044
2045    The Signature Payload fields are defined as follows:
2046
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.
2050
2051     o  RESERVED (1 octet) - Unused, set to 0.
2052
2053     o  Payload Length (2 octets) - Length in octets of the current
2054        payload, including the generic payload header.
2055
2056     o  Signature Data (variable length) - Data that results from
2057        applying the digital signature function to the ISAKMP message
2058        and/or state.
2059
2060    The payload type for the Signature Payload is nine (9).
2061
2062 3.13 Nonce Payload
2063
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.
2071
2072
2073
2074 Maughan, et. al.            Standards Track                    [Page 37]
2075 \f
2076 RFC 2408                         ISAKMP                    November 1998
2077
2078
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2088
2089
2090                   Figure 14:  Nonce Payload Format
2091
2092    The Nonce Payload fields are defined as follows:
2093
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.
2097
2098     o  RESERVED (1 octet) - Unused, set to 0.
2099
2100     o  Payload Length (2 octets) - Length in octets of the current
2101        payload, including the generic payload header.
2102
2103     o  Nonce Data (variable length) - Contains the random data generated
2104        by the transmitting entity.
2105
2106    The payload type for the Nonce Payload is ten (10).
2107
2108 3.14 Notification Payload
2109
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.
2115
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.
2123
2124
2125
2126
2127
2128
2129
2130 Maughan, et. al.            Standards Track                    [Page 38]
2131 \f
2132 RFC 2408                         ISAKMP                    November 1998
2133
2134
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.
2140
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2158
2159
2160               Figure 15:  Notification Payload Format
2161
2162    The Notification Payload fields are defined as follows:
2163
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.
2167
2168     o  RESERVED (1 octet) - Unused, set to 0.
2169
2170     o  Payload Length (2 octets) - Length in octets of the current
2171        payload, including the generic payload header.
2172
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.
2178
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.
2182
2183
2184
2185
2186 Maughan, et. al.            Standards Track                    [Page 39]
2187 \f
2188 RFC 2408                         ISAKMP                    November 1998
2189
2190
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.
2198
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.
2202
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.
2207
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.
2211
2212    The payload type for the Notification Payload is eleven (11).
2213
2214 3.14.1 Notify Message Types
2215
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.
2224
2225                       NOTIFY MESSAGES - ERROR TYPES
2226
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
2239
2240
2241
2242 Maughan, et. al.            Standards Track                    [Page 40]
2243 \f
2244 RFC 2408                         ISAKMP                    November 1998
2245
2246
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
2268
2269
2270
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
2278
2279 3.15 Delete Payload
2280
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.
2288
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).
2294
2295
2296
2297
2298 Maughan, et. al.            Standards Track                    [Page 41]
2299 \f
2300 RFC 2408                         ISAKMP                    November 1998
2301
2302
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.
2309
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2323
2324
2325                  Figure 16:  Delete Payload Format
2326
2327    The Delete Payload fields are defined as follows:
2328
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.
2332
2333     o  RESERVED (1 octet) - Unused, set to 0.
2334
2335     o  Payload Length (2 octets) - Length in octets of the current
2336        payload, including the generic payload header.
2337
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.
2343
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.
2348
2349
2350
2351
2352
2353
2354 Maughan, et. al.            Standards Track                    [Page 42]
2355 \f
2356 RFC 2408                         ISAKMP                    November 1998
2357
2358
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.
2363
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.
2366
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.
2371
2372    The payload type for the Delete Payload is twelve (12).
2373
2374 3.16 Vendor ID Payload
2375
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.
2382
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.
2392
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.
2402
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.
2407
2408
2409
2410 Maughan, et. al.            Standards Track                    [Page 43]
2411 \f
2412 RFC 2408                         ISAKMP                    November 1998
2413
2414
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:
2420
2421    "Example Company IPsec.  Version 97.1"
2422
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.
2428
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      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2438
2439
2440                 Figure 17:  Vendor ID Payload Format
2441
2442    The Vendor ID Payload fields are defined as follows:
2443
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.
2447
2448     o  RESERVED (1 octet) - Unused, set to 0.
2449
2450     o  Payload Length (2 octets) - Length in octets of the current
2451        payload, including the generic payload header.
2452
2453     o  Vendor ID (variable length) - Hash of the vendor string plus
2454        version (as described above).
2455
2456    The payload type for the Vendor ID Payload is thirteen (13).
2457
2458 4 ISAKMP Exchanges
2459
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
2463
2464
2465
2466 Maughan, et. al.            Standards Track                    [Page 44]
2467 \f
2468 RFC 2408                         ISAKMP                    November 1998
2469
2470
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.
2476
2477 4.1 ISAKMP Exchange Types
2478
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.
2492
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).
2504
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.
2515
2516
2517
2518
2519
2520
2521
2522 Maughan, et. al.            Standards Track                    [Page 45]
2523 \f
2524 RFC 2408                         ISAKMP                    November 1998
2525
2526
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.
2532
2533 4.1.1 Notation
2534
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:
2538
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.
2556
2557      => signifies "initiator to responder" communication
2558      <= signifies "responder to initiator" communication
2559
2560 4.2 Security Association Establishment
2561
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
2575
2576
2577
2578 Maughan, et. al.            Standards Track                    [Page 46]
2579 \f
2580 RFC 2408                         ISAKMP                    November 1998
2581
2582
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.
2592
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,&nb