As per Relevance of the word exchange, we have this rfc below:
Network Working Group D.
Request for Comments: 2408 National Security
Category: Standards Track M.
Securify, Inc
M.
National Security
J.
RABA Technologies, Inc
November 1998
Internet Security Association and Key Management Protocol (ISAKMP
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This memo describes a protocol utilizing security concepts
for establishing Security Associations (SA) and cryptographic keys
an Internet environment. A Security Association protocol
negotiates, establishes, modifies and deletes Security
and their attributes is required for an evolving Internet,
there will be numerous security mechanisms and several options
each security mechanism. The key management protocol must be
in order to handle public key generation for the Internet
at large and private key requirements for those private networks
that requirement. The Internet Security Association and
Management Protocol (ISAKMP) defines the procedures
authenticating a communicating peer, creation and management
Security Associations, key generation techniques, and
mitigation (e.g. denial of service and replay attacks). All
these are necessary to establish and maintain secure
(via IP Security Service or any other security protocol) in
Internet environment
Maughan, et. al. Standards Track [Page 1]
RFC 2408 ISAKMP November 1998
Table of
1 Introduction 4
1.1 Requirements Terminology . . . . . . . . . . . . . . . . . 5
1.2 The Need for Negotiation . . . . . . . . . . . . . . . . . 5
1.3 What can be Negotiated? . . . . . . . . . . . . . . . . . 6
1.4 Security Associations and Management . . . . . . . . . . . 7
1.4.1 Security Associations and Registration . . . . . . . . 7
1.4.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 8
1.5 Authentication . . . . . . . . . . . . . . . . . . . . . . 8
1.5.1 Certificate Authorities . . . . . . . . . . . . . . . 9
1.5.2 Entity Naming . . . . . . . . . . . . . . . . . . . . 9
1.5.3 ISAKMP Requirements . . . . . . . . . . . . . . . . . 10
1.6 Public Key Cryptography . . . . . . . . . . . . . . . . . . 10
1.6.1 Key Exchange Properties . . . . . . . . . . . . . . . 11
1.6.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 12
1.7 ISAKMP Protection . . . . . . . . . . . . . . . . . . . . . 12
1.7.1 Anti-Clogging (Denial of Service) . . . . . . . . . . 12
1.7.2 Connection Hijacking . . . . . . . . . . . . . . . . . 13
1.7.3 Man-in-the-Middle Attacks . . . . . . . . . . . . . . 13
1.8 Multicast Communications . . . . . . . . . . . . . . . . . 13
2 Terminology and Concepts 14
2.1 ISAKMP Terminology . . . . . . . . . . . . . . . . . . . . 14
2.2 ISAKMP Placement . . . . . . . . . . . . . . . . . . . . . 16
2.3 Negotiation Phases . . . . . . . . . . . . . . . . . . . . 16
2.4 Identifying Security Associations . . . . . . . . . . . . . 17
2.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.1 Transport Protocol . . . . . . . . . . . . . . . . . . 20
2.5.2 RESERVED Fields . . . . . . . . . . . . . . . . . . . 20
2.5.3 Anti-Clogging Token ("Cookie") Creation . . . . . . . 20
3 ISAKMP Payloads 21
3.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 21
3.2 Generic Payload Header . . . . . . . . . . . . . . . . . . 25
3.3 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Security Association Payload . . . . . . . . . . . . . . . 27
3.5 Proposal Payload . . . . . . . . . . . . . . . . . . . . . 28
3.6 Transform Payload . . . . . . . . . . . . . . . . . . . . . 29
3.7 Key Exchange Payload . . . . . . . . . . . . . . . . . . . 31
3.8 Identification Payload . . . . . . . . . . . . . . . . . . 32
3.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . 33
3.10 Certificate Request Payload . . . . . . . . . . . . . . . 34
3.11 Hash Payload . . . . . . . . . . . . . . . . . . . . . . 36
3.12 Signature Payload . . . . . . . . . . . . . . . . . . . . 37
3.13 Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 37
3.14 Notification Payload . . . . . . . . . . . . . . . . . . 38
3.14.1 Notify Message Types . . . . . . . . . . . . . . . . 40
3.15 Delete Payload . . . . . . . . . . . . . . . . . . . . . 41
3.16 Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 43
Maughan, et. al. Standards Track [Page 2]
RFC 2408 ISAKMP November 1998
4 ISAKMP Exchanges 44
4.1 ISAKMP Exchange Types . . . . . . . . . . . . . . . . . . . 45
4.1.1 Notation . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Security Association Establishment . . . . . . . . . . . . 46
4.2.1 Security Association Establishment Examples . . . . . 48
4.3 Security Association Modification . . . . . . . . . . . . . 50
4.4 Base Exchange . . . . . . . . . . . . . . . . . . . . . . . 51
4.5 Identity Protection Exchange . . . . . . . . . . . . . . . 52
4.6 Authentication Only Exchange . . . . . . . . . . . . . . . 54
4.7 Aggressive Exchange . . . . . . . . . . . . . . . . . . . . 55
4.8 Informational Exchange . . . . . . . . . . . . . . . . . . 57
5 ISAKMP Payload Processing 58
5.1 General Message Processing . . . . . . . . . . . . . . . . 58
5.2 ISAKMP Header Processing . . . . . . . . . . . . . . . . . 59
5.3 Generic Payload Header Processing . . . . . . . . . . . . . 61
5.4 Security Association Payload Processing . . . . . . . . . . 62
5.5 Proposal Payload Processing . . . . . . . . . . . . . . . . 63
5.6 Transform Payload Processing . . . . . . . . . . . . . . . 64
5.7 Key Exchange Payload Processing . . . . . . . . . . . . . . 65
5.8 Identification Payload Processing . . . . . . . . . . . . . 66
5.9 Certificate Payload Processing . . . . . . . . . . . . . . 66
5.10 Certificate Request Payload Processing . . . . . . . . . 67
5.11 Hash Payload Processing . . . . . . . . . . . . . . . . . 69
5.12 Signature Payload Processing . . . . . . . . . . . . . . 69
5.13 Nonce Payload Processing . . . . . . . . . . . . . . . . 70
5.14 Notification Payload Processing . . . . . . . . . . . . . 71
5.15 Delete Payload Processing . . . . . . . . . . . . . . . . 73
6 Conclusions 75
A ISAKMP Security Association Attributes 77
A.1 Background/Rationale . . . . . . . . . . . . . . . . . . . 77
A.2 Internet IP Security DOI Assigned Value . . . . . . . . . . 77
A.3 Supported Security Protocols . . . . . . . . . . . . . . . 77
A.4 ISAKMP Identification Type Values . . . . . . . . . . . . . 78
A.4.1 ID_IPV4_ADDR . . . . . . . . . . . . . . . . . . . . . 78
A.4.2 ID_IPV4_ADDR_SUBNET . . . . . . . . . . . . . . . . . . 78
A.4.3 ID_IPV6_ADDR . . . . . . . . . . . . . . . . . . . . . 78
A.4.4 ID_IPV6_ADDR_SUBNET . . . . . . . . . . . . . . . . . 78
B Defining a new Domain of Interpretation 79
B.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.2 Security Policies . . . . . . . . . . . . . . . . . . . . . 80
B.3 Naming Schemes . . . . . . . . . . . . . . . . . . . . . . 80
B.4 Syntax for Specifying Security Services . . . . . . . . . . 80
B.5 Payload Specification . . . . . . . . . . . . . . . . . . . 80
B.6 Defining new Exchange Types . . . . . . . . . . . . . . . . 80
Security Considerations 81
IANA Considerations 81
Domain of Interpretation 81
Supported Security Protocols 82
Maughan, et. al. Standards Track [Page 3]
RFC 2408 ISAKMP November 1998
Acknowledgements 82
References 82
Authors' Addresses 85
Full Copyright Statement 86
List of
1 ISAKMP Relationships . . . . . . . . . . . . . . . . . . . 16
2 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 22
3 Generic Payload Header . . . . . . . . . . . . . . . . . . 25
4 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 26
5 Security Association Payload . . . . . . . . . . . . . . . 27
6 Proposal Payload Format . . . . . . . . . . . . . . . . . . 28
7 Transform Payload Format . . . . . . . . . . . . . . . . . 30
8 Key Exchange Payload Format . . . . . . . . . . . . . . . . 31
9 Identification Payload Format . . . . . . . . . . . . . . . 32
10 Certificate Payload Format . . . . . . . . . . . . . . . . 33
11 Certificate Request Payload Format . . . . . . . . . . . . 34
12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . 36
13 Signature Payload Format . . . . . . . . . . . . . . . . . 37
14 Nonce Payload Format . . . . . . . . . . . . . . . . . . . 38
15 Notification Payload Format . . . . . . . . . . . . . . . . 39
16 Delete Payload Format . . . . . . . . . . . . . . . . . . . 42
17 Vendor ID Payload Format . . . . . . . . . . . . . . . . . 44
1
This document describes an Internet Security Association and
Management Protocol (ISAKMP). ISAKMP combines the security
of authentication, key management, and security associations
establish the required security for government, commercial,
private communications on the Internet
The Internet Security Association and Key Management
(ISAKMP) defines procedures and packet formats to establish
negotiate, modify and delete Security Associations (SA). SAs
all the information required for execution of various
security services, such as the IP layer services (such as
authentication and payload encapsulation), transport or
layer services, or self-protection of negotiation traffic.
defines payloads for exchanging key generation and
data. These formats provide a consistent framework for
key and authentication data which is independent of the
generation technique, encryption algorithm and
mechanism
Maughan, et. al. Standards Track [Page 4]
RFC 2408 ISAKMP November 1998
ISAKMP is distinct from key exchange protocols in order to
separate the details of security association management (and
management) from the details of key exchange. There may be
different key exchange protocols, each with different
properties. However, a common framework is required for agreeing
the format of SA attributes, and for negotiating, modifying,
deleting SAs. ISAKMP serves as this common framework
Separating the functionality into three parts adds complexity to
security analysis of a complete ISAKMP implementation. However,
separation is critical for interoperability between systems
differing security requirements, and should also simplify
analysis of further evolution of a ISAKMP server
ISAKMP is intended to support the negotiation of SAs for
protocols at all layers of the network stack (e.g., IPSEC, TLS, TLSP
OSPF, etc.). By centralizing the management of the
associations, ISAKMP reduces the amount of duplicated
within each security protocol. ISAKMP can also reduce
setup time, by negotiating a whole stack of services at once
The remainder of section 1 establishes the motivation for
negotiation and outlines the major components of ISAKMP, i.e
Security Associations and Management, Authentication, Public
Cryptography, and Miscellaneous items. Section 2 presents
terminology and concepts associated with ISAKMP. Section 3
the different ISAKMP payload formats. Section 4 describes how
payloads of ISAKMP are composed together as exchange types
establish security associations and perform key exchanges in
authenticated manner. Additionally, security
modification, deletion, and error notification are discussed
Section 5 describes the processing of each payload within the
of ISAKMP exchanges, including error handling and associated actions
The appendices provide the attribute values necessary for ISAKMP
requirement for defining a new Domain of Interpretation (DOI)
ISAKMP
1.1 Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
document, are to be interpreted as described in [RFC-2119].
1.2 The Need for
ISAKMP extends the assertion in [DOW92] that authentication and
exchanges must be combined for better security to include
association exchanges. The security services required
Maughan, et. al. Standards Track [Page 5]
RFC 2408 ISAKMP November 1998
communications depends on the individual network configurations
environments. Organizations are setting up Virtual Private
(VPN), also known as Intranets, that will require one set of
functions for communications within the VPN and possibly
different security functions for communications outside the VPN
support geographically separate organizational components, customers
suppliers, sub-contractors (with their own VPNs), government,
others. Departments within large organizations may require a
of security associations to separate and protect data (e.g
personnel data, company proprietary data, medical) on
networks and other security associations to communicate within
same department. Nomadic users wanting to "phone home"
another set of security requirements. These requirements must
tempered with bandwidth challenges. Smaller groups of people
meet their security requirements by setting up "Webs of Trust".
ISAKMP exchanges provide these assorted networking communities
ability to present peers with the security functionality that
user supports in an authenticated and protected manner for
upon a common set of security attributes, i.e. an
security association
1.3 What can be Negotiated
Security associations must support different encryption algorithms
authentication mechanisms, and key establishment algorithms for
security protocols, as well as IP Security. Security
must also support host-oriented certificates for lower
protocols and user- oriented certificates for higher level protocols
Algorithm and mechanism independence is required in applications
as e-mail, remote login, and file transfer, as well as in
oriented protocols, routing protocols, and link layer protocols
ISAKMP provides a common security association and key
protocol for this wide range of security protocols, applications
security requirements, and network environments
ISAKMP is not bound to any specific cryptographic algorithm,
generation technique, or security mechanism. This flexibility
beneficial for a number of reasons. First, it supports the
communications environment described above. Second, the
from specific security mechanisms and algorithms provides a
migration path to better mechanisms and algorithms. When
security mechanisms are developed or new attacks against
encryption algorithms, authentication mechanisms and key
are discovered, ISAKMP will allow the updating of the algorithms
mechanisms without having to develop a completely new KMP or
the current one
Maughan, et. al. Standards Track [Page 6]
RFC 2408 ISAKMP November 1998
ISAKMP has basic requirements for its authentication and key
components. These requirements guard against denial of service
replay / reflection, man-in-the-middle, and connection
attacks. This is important because these are the types of
that are targeted against protocols. Complete Security
(SA) support, which provides mechanism and algorithm independence
and protection from protocol threats are the strengths of ISAKMP
1.4 Security Associations and
A Security Association (SA) is a relationship between two or
entities that describes how the entities will utilize
services to communicate securely. This relationship is
by a set of information that can be considered a contract between
entities. The information must be agreed upon and shared between
the entities. Sometimes the information alone is referred to as
SA, but this is just a physical instantiation of the
relationship. The existence of this relationship, represented by
information, is what provides the agreed upon security
needed by entities to securely interoperate. All entities
adhere to the SA for secure communications to be possible.
accessing SA attributes, entities use a pointer or identifier
to as the Security Parameter Index (SPI). [SEC-ARCH] provides
on IP Security Associations (SA) and Security Parameter Index (SPI
definitions
1.4.1 Security Associations and
The SA attributes required and recommended for the IP Security (AH
ESP) are defined in [SEC-ARCH]. The attributes specified for an
Security SA include, but are not limited to,
mechanism, cryptographic algorithm, algorithm mode, key length,
Initialization Vector (IV). Other protocols that provide
and mechanism independent security MUST define their requirements
SA attributes. The separation of ISAKMP from a specific
definition is important to ensure ISAKMP can es tablish SAs for
possible security protocols and applications
NOTE: See [IPDOI] for a discussion of SA attributes that should
considered when defining a security protocol or application
In order to facilitate easy identification of specific
(e.g. a specific encryption algorithm) among different
entites the attributes must be assigned identifiers and
identifiers must be registered by a central authority. The
Assigned Numbers Authority (IANA) provides this function for
Internet
Maughan, et. al. Standards Track [Page 7]
RFC 2408 ISAKMP November 1998
1.4.2 ISAKMP
Security Association (SA) establishment MUST be part of the
management protocol defined for IP based networks. The SA concept
required to support security protocols in a diverse and
networking environment. Just as authentication and key exchange
be linked to provide assurance that the key is established with
authenticated party [DOW92], SA establishment must be linked with
authentication and the key exchange protocol
ISAKMP provides the protocol exchanges to establish a
association between negotiating entities followed by
establishment of a security association by these negotiating
in behalf of some protocol (e.g. ESP/AH). First, an initial
exchange allows a basic set of security attributes to be agreed upon
This basic set provides protection for subsequent ISAKMP exchanges
It also indicates the authentication method and key exchange
will be performed as part of the ISAKMP protocol. If a basic set
security attributes is already in place between the
server entities, the initial ISAKMP exchange may be skipped and
establishment of a security association can be done directly.
the basic set of security attributes has been agreed upon,
identity authenticated, and required keys generated, the
SA can be used for subsequent communications by the entity
invoked ISAKMP. The basic set of SA attributes that MUST
implemented to provide ISAKMP interoperability are defined
Appendix A
1.5
A very important step in establishing secure network
is authentication of the entity at the other end of
communication. Many authentication mechanisms are available
Authentication mechanisms fall into two catagories of strength -
and strong. Sending cleartext keys or other
authenticating information over a network is weak, due to the
of reading them with a network sniffer. Additionally, sending one
way hashed poorly-chosen keys with low entropy is also weak, due
the threat of brute-force guessing attacks on the sniffed messages
While passwords can be used for establishing identity, they are
considered in this context because of recent statements from
Internet Architecture Board [IAB]. Digital signatures, such as
Digital Signature Standard (DSS) and the Rivest-Shamir-Adleman (RSA
signature, are public key based strong authentication mechanisms
When using public key digital signatures each entity requires
public key and a private key. Certificates are an essential part
a digital signature authentication mechanism. Certificates bind
specific entity's identity (be it host, network, user,
Maughan, et. al. Standards Track [Page 8]
RFC 2408 ISAKMP November 1998
application) to its public keys and possibly other security-
information such as privileges, clearances, and compartments
Authentication based on digital signatures requires a trusted
party or certificate authority to create, sign and
distribute certificates. For more detailed information on
signatures, such as DSS and RSA, and certificates see [Schneier].
1.5.1 Certificate
Certificates require an infrastructure for generation, verification
revocation, management and distribution. The Internet
Registration Authority (IPRA) [RFC-1422] has been established
direct this infrastructure for the IETF. The IPRA certifies
Certification Authorities (PCA). PCAs control Certificate
(CA) which certify users and subordinate entities.
certificate related work includes the Domain Name System (DNS
Security Extensions [DNSSEC] which will provide signed entity keys
the DNS. The Public Key Infrastucture (PKIX) working group
specifying an Internet profile for X.509 certificates. There is
work going on in industry to develop X.500 Directory Services
would provide X.509 certificates to users. The U.S. Post Office
developing a (CA) hierarchy. The NIST Public Key
Working Group has also been doing work in this area. The DOD
Level Information System Security Initiative (MISSI) program
begun deploying a certificate infrastructure for the U.S. Government
Alternatively, if no infrastructure exists, the PGP Web of
certificates can be used to provide user authentication and
in a community of users who know and trust each other
1.5.2 Entity
An entity's name is its identity and is bound to its public keys
certificates. The CA MUST define the naming semantics for
certificates it issues. See the UNINETT PCA Policy
[Berge] for an example of how a CA defines its naming policy.
the certificate is verified, the name is verified and that name
have meaning within the realm of that CA. An example is the
security extensions which make DNS servers CAs for the zones
nodes they serve. Resource records are provided for public keys
signatures on those keys. The names associated with the keys are
addresses and domain names which have meaning to entities
the DNS for this information. A Web of Trust is another example
When webs of trust are set up, names are bound with the public keys
In PGP the name is usually the entity's e-mail address which
meaning to those, and only those, who understand e-mail. Another
of trust could use an entirely different naming scheme
Maughan, et. al. Standards Track [Page 9]
RFC 2408 ISAKMP November 1998
1.5.3 ISAKMP
Strong authentication MUST be provided on ISAKMP exchanges.
being able to authenticate the entity at the other end, the
Association (SA) and session key established are suspect.
authentication you are unable to trust an entity's identification
which makes access control questionable. While encryption (e.g
ESP) and integrity (e.g. AH) will protect subsequent
from passive eavesdroppers, without authentication it is
that the SA and key may have been established with an adversary
performed an active man-in-the-middle attack and is now stealing
your personal data
A digital signature algorithm MUST be used within ISAKMP'
authentication component. However, ISAKMP does not mandate
specific signature algorithm or certificate authority (CA).
allows an entity initiating communications to indicate which CAs
supports. After selection of a CA, the protocol provides
messages required to support the actual authentication exchange.
protocol provides a facility for identification of
certificate authorities, certificate types (e.g. X.509, PKCS #7,
PGP, DNS SIG and KEY records), and the exchange of the
identified
ISAKMP utilizes digital signatures, based on public key cryptography
for authentication. There are other strong authentication
available, which could be specified as additional
authentication mechanisms for ISAKMP. Some of these
systems rely on a trusted third party called a key
center (KDC) to distribute secret session keys. An example
Kerberos, where the trusted third party is the Kerberos server,
holds secret keys for all clients and servers within its
domain. A client's proof that it holds its secret key
authenticaton to a server
The ISAKMP specification does not specify the protocol
communicating with the trusted third parties (TTP) or
directory services. These protocols are defined by the TTP
directory service themselves and are outside the scope of
specification. The use of these additional services and
will be described in a Key Exchange specific document
1.6 Public Key
Public key cryptography is the most flexible, scalable, and
way for users to obtain the shared secrets and session keys needed
support the large number of ways Internet users will interoperate
Many key generation algorithms, that have different properties,
Maughan, et. al. Standards Track [Page 10]
RFC 2408 ISAKMP November 1998
available to users (see [DOW92], [ANSI], and [Oakley]).
of key exchange protocols include the key establishment method
authentication, symmetry, perfect forward secrecy, and back
protection
NOTE: Cryptographic keys can protect information for a
length of time. However, this is based on the assumption that
used for protection of communications are destroyed after use and
kept for any reason
1.6.1 Key Exchange
Key Establishment (Key Generation / Key Transport): The two
methods of using public key cryptography for key establishment
key transport and key generation. An example of key transport is
use of the RSA algorithm to encrypt a randomly generated session
(for encrypting subsequent communications) with the recipient'
public key. The encrypted random key is then sent to the recipient
who decrypts it using his private key. At this point both sides
the same session key, however it was created based on input from
one side of the communications. The benefit of the key
method is that it has less computational overhead than the
method. The Diffie-Hellman (D-H) algorithm illustrates
generation using public key cryptography. The D-H algorithm is
by two users exchanging public information. Each user
mathematically combines the other's public information along
their own secret information to compute a shared secret value.
secret value can be used as a session key or as a key encryption
for encrypting a randomly generated session key. This
generates a session key based on public and secret information
by both users. The benefit of the D-H algorithm is that the key
for encrypting messages is based on information held by both
and the independence of keys from one key exchange to
provides perfect forward secrecy. Detailed descriptions of
algorithms can be found in [Schneier]. There are a number
variations on these two key generation schemes and these
do not necessarily interoperate
Key Exchange Authentication: Key exchanges may be
during the protocol or after protocol completion. Authentication
the key exchange during the protocol is provided when each
provides proof it has the secret session key before the end of
protocol. Proof can be provided by encrypting known data in
secret session key during the protocol echange. Authentication
the protocol must occur in subsequent commu nications
Authentication during the protocol is preferred so
communications are not initiated if the secret session key is
established with the desired party
Maughan, et. al. Standards Track [Page 11]
RFC 2408 ISAKMP November 1998
Key Exchange Symmetry: A key exchange provides symmetry if
party can initiate the exchange and exchanged messages can cross
transit without affecting the key that is generated. This
desirable so that computation of the keys does not require
party to know who initated the exchange. While key exchange
is desirable, symmetry in the entire key management protocol
provide a vulnerablity to reflection attacks
Perfect Forward Secrecy: As described in [DOW92], an
key exchange protocol provides perfect forward secrecy if
of longterm secret keying material does not compromise the secrecy
the exchanged keys from previous communications. The property
perfect forward secrecy does not apply to key exchange
authentication
1.6.2 ISAKMP
An authenticated key exchange MUST be supported by ISAKMP.
SHOULD choose additional key establishment algorithms based on
requirements. ISAKMP does not specify a specific key exchange
However, [IKE] describes a proposal for using the Oakley key
[Oakley] in conjunction with ISAKMP. Requirements that should
evaluated when choosing a key establishment algorithm
establishment method (generation vs. transport), perfect
secrecy, computational overhead, key escrow, and key strength.
on user requirements, ISAKMP allows an entity
communications to indicate which key exchanges it supports.
selection of a key exchange, the protocol provides the
required to support the actual key establishment
1.7 ISAKMP
1.7.1 Anti-Clogging (Denial of Service
Of the numerous security services available, protection
denial of service always seems to be one of the most difficult
address. A "cookie" or anti-clogging token (ACT) is aimed
protecting the computing resources from attack without
excessive CPU resources to determine its authenticity. An
prior to CPU-intensive public key operations can thwart some
of service attempts (e.g. simple flooding with bogus IP
addresses). Absolute protection against denial of service
impossible, but this anti-clogging token provides a technique
making it easier to handle. The use of an anti-clogging token
introduced by Karn and Simpson in [Karn].
Maughan, et. al. Standards Track [Page 12]
RFC 2408 ISAKMP November 1998
It should be noted that in the exchanges shown in section 4,
anticlogging mechanism should be used in conjuction with a garbage
state collection mechanism; an attacker can still flood a
using packets with bogus IP addresses and cause state to be created
Such aggressive memory management techniques SHOULD be employed
protocols using ISAKMP that do not go through an initial, anti
clogging only phase, as was done in [Karn].
1.7.2 Connection
ISAKMP prevents connection hijacking by linking the authentication
key exchange and security association exchanges. This
prevents an attacker from allowing the authentication to complete
then jumping in and impersonating one entity to the other during
key and security association exchanges
1.7.3 Man-in-the-Middle
Man-in-the-Middle attacks include interception, insertion, deletion
and modification of messages, reflecting messages back at the sender
replaying old messages and redirecting messages. ISAKMP
prevent these types of attacks from being successful. The linking
the ISAKMP exchanges prevents the insertion of messages in
protocol exchange. The ISAKMP protocol state machine is defined
deleted messages will not cause a partial SA to be created, the
machine will clear all state and return to idle. The state
also prevents reflection of a message from causing harm.
requirement for a new cookie with time variant material for each
SA establishment prevents attacks that involve replaying
messages. The ISAKMP strong authentication requirement prevents
SA from being established with anyone other than the intended party
Messages may be redirected to a different destination or modified
this will be detected and an SA will not be established. The
specification defines where abnormal processing has occurred
recommends notifying the appropriate party of this abnormality
1.8 Multicast
It is expected that multicast communications will require the
security services as unicast communications and may introduce
need for additional security services. The issues of
SPIs for multicast traffic are presented in [SEC-ARCH].
security issues are also discussed in [RFC-1949] and [BC]. A
extension to ISAKMP will support multicast key distribution. For
introduction to the issues related to multicast security, consult
Internet Drafts, [RFC-2094] and [RFC-2093], describing Sparta'
research in this area
Maughan, et. al. Standards Track [Page 13]
RFC 2408 ISAKMP November 1998
2 Terminology and
2.1 ISAKMP
Security Protocol: A Security Protocol consists of an entity at
single point in the network stack, performing a security service
network communication. For example, IPSEC ESP and IPSEC AH are
different security protocols. TLS is another example.
Protocols may perform more than one service, for example
integrity and confidentiality in one module
Protection Suite: A protection suite is a list of the
services that must be applied by various security protocols.
example, a protection suite may consist of DES encryption in IP ESP
and keyed MD5 in IP AH. All of the protections in a suite must
treated as a single unit. This is necessary because
services in different security protocols can have
interactions, and the effects of a suite must be analyzed
verified as a whole
Security Association (SA): A Security Association is a security
protocol- specific set of parameters that completely defines
services and mechanisms necessary to protect traffic at that
protocol location. These parameters can include
identifiers, modes, cryptographic keys, etc. The SA is referred
by its associated security protocol (for example, "ISAKMP SA", "
SA", "TLS SA").
ISAKMP SA: An SA used by the ISAKMP servers to protect their
traffic. Sections 2.3 and 2.4 provide more details about ISAKMP SAs
Security Parameter Index (SPI): An identifier for a
Assocation, relative to some security protocol. Each
protocol has its own "SPI-space". A (security protocol, SPI)
may uniquely identify an SA. The uniqueness of the SPI
implementation dependent, but could be based per system,
protocol, or other options. Depending on the DOI,
information (e.g. host address) may be necessary to identify an SA
The DOI will also determine which SPIs (i.e. initiator's
responder's) are sent during communication
Domain of Interpretation: A Domain of Interpretation (DOI)
payload formats, exchange types, and conventions for
security-relevant information such as security policies
cryptographic algorithms and modes. A Domain of Interpretation (DOI
identifier is used to interpret the payloads of ISAKMP payloads.
system SHOULD support multiple Domains of
simultaneously. The concept of a DOI is based on previous work
Maughan, et. al. Standards Track [Page 14]
RFC 2408 ISAKMP November 1998
the TSIG CIPSO Working Group, but extends beyond security
interpretation to include naming and interpretation of
services. A DOI defines
o A "situation": the set of information that will be used
determine the required security services
o The set of security policies that must, and may, be supported
o A syntax for the specification of proposed security services
o A scheme for naming security-relevant information,
encryption algorithms, key exchange algorithms, security
attributes, and certificate authorities
o The specific formats of the various payload contents
o Additional exchange types, if required
The rules for the IETF IP Security DOI are presented in [IPDOI].
Specifications of the rules for customized DOIs will be presented
separate documents
Situation: A situation contains all of the security-
information that a system considers necessary to decide the
services required to protect the session being negotiated.
situation may include addresses, security classifications, modes
operation (normal vs. emergency), etc
Proposal: A proposal is a list, in decreasing order of preference,
the protection suites that a system considers acceptable to
traffic under a given situation
Payload: ISAKMP defines several types of payloads, which are used
transfer information such as security association data, or
exchange data, in DOI-defined formats. A payload consists of
generic payload header and a string of octects that is opaque
ISAKMP. ISAKMP uses DOI- specific functionality to synthesize
interpret these payloads. Multiple payloads can be sent in a
ISAKMP message. See section 3 for more details on the payload types
and [IPDOI] for the formats of the IETF IP Security DOI payloads
Exchange Type: An exchange type is a specification of the number
messages in an ISAKMP exchange, and the payload types that
contained in each of those messages. Each exchange type is
to provide a particular set of security services, such as
of the participants, perfect forward secrecy of the keying material
authentication of the participants, etc. Section 4.1 defines
Maughan, et. al. Standards Track [Page 15]
RFC 2408 ISAKMP November 1998
default set of ISAKMP exchange types. Other exchange types can
added to support additional key exchanges, if required
2.2 ISAKMP
Figure 1 is a high level view of the placement of ISAKMP within
system context in a network architecture. An important part
negotiating security services is to consider the entire "stack"
individual SAs as a unit. This is referred to as a "
suite".
+------------+ +--------+ +--------------+
! DOI ! ! ! ! Application !
! Definition ! <----> ! ISAKMP ! ! Process !
+------------+ --> ! ! !--------------!
+--------------+ ! +--------+ ! Appl Protocol
! Key Exchange ! ! ^ ^ +--------------+
! Definition !<-- ! ! ^
+--------------+ ! ! !
! ! !
!----------------! ! !
v ! !
+-------+ v
! API ! +---------------------------------------------+
+-------+ ! Socket Layer !
! !---------------------------------------------!
v ! Transport Protocol (TCP / UDP) !
+----------+ !---------------------------------------------!
! Security ! <----> ! IP !
! Protocol ! !---------------------------------------------!
+----------+ ! Link Layer Protocol !
+---------------------------------------------+
Figure 1: ISAKMP
2.3 Negotiation
ISAKMP offers two "phases" of negotiation. In the first phase,
entities (e.g. ISAKMP servers) agree on how to protect
negotiation traffic between themselves, establishing an ISAKMP SA
This ISAKMP SA is then used to protect the negotiations for
Protocol SA being requested. Two entities (e.g. ISAKMP servers)
negotiate (and have active) multiple ISAKMP SAs
Maughan, et. al. Standards Track [Page 16]
RFC 2408 ISAKMP November 1998
The second phase of negotiation is used to establish
associations for other security protocols. This second phase can
used to establish many security associations. The
associations established by ISAKMP during this phase can be used by
security protocol to protect many message/data exchanges
While the two-phased approach has a higher start-up cost for
simple scenarios, there are several reasons that it is beneficial
most cases
First, entities (e.g. ISAKMP servers) can amortize the cost of
first phase across several second phase negotiations. This
multiple SAs to be established between peers over time without
to start over for each communication
Second, security services negotiated during the first phase
security properties for the second phase. For example, after
first phase of negotiation, the encryption provided by the ISAKMP
can provide identity protection, potentially allowing the use
simpler second-phase exchanges. On the other hand, if the
established during the first phase is not adequate to
identities, then the second phase must negotiate adequate
mechanisms
Third, having an ISAKMP SA in place considerably reduces the cost
ISAKMP management activity - without the "trusted path" that
ISAKMP SA gives you, the entities (e.g. ISAKMP servers) would
to go through a complete re-authentication for each
notification or deletion of an SA
Negotiation during each phase is accomplished using ISAKMP-
exchanges (see section 4) or exchanges defined for a key
within a DOI
Note that security services may be applied differently in
negotiation phase. For example, different parties are
authenticated during each of the phases of negotiation. During
first phase, the parties being authenticated may be the
servers/hosts, while during the second phase, users or
level programs are being authenticated
2.4 Identifying Security
While bootstrapping secure channels between systems, ISAKMP
assume the existence of security services, and must provide
protections for itself. Therefore, ISAKMP considers an
Security Association to be different than other types, and
ISAKMP SAs itself, in their own name space. ISAKMP uses the
Maughan, et. al. Standards Track [Page 17]
RFC 2408 ISAKMP November 1998
cookie fields in the ISAKMP header to identify ISAKMP SAs.
Message ID in the ISAKMP Header and the SPI field in the
payload are used during SA establishment to identify the SA for
security protocols. The interpretation of these four fields
dependent on the operation taking place
The following table shows the presence or absence of several
during SA establishment. The following fields are necessary
various operations associated with SA establishment: cookies in
ISAKMP header, the ISAKMP Header Message ID field, and the SPI
in the Proposal payload. An 'X' in the column means the value
be present. An 'NA' in the column means a value in the column is
Applicable to the operation
# Operation I-Cookie R-Cookie Message ID
(1) Start ISAKMP SA negotiation X 0 0 0
(2) Respond ISAKMP SA negotiation X X 0 0
(3) Init other SA negotiation X X X
(4) Respond other SA negotiation X X X
(5) Other (KE, ID, etc.) X X X/0
(6) Security Protocol (ESP, AH) NA NA NA
In the first line (1) of the table, the initiator includes
Initiator Cookie field in the ISAKMP Header, using the
outlined in sections 2.5.3 and 3.1.
In the second line (2) of the table, the responder includes
Initiator and Responder Cookie fields in the ISAKMP Header, using
procedures outlined in sections 2.5.3 and 3.1. Additional
may be exchanged between ISAKMP peers, depending on the
exchange type used during the phase 1 negotiation. Once the phase 1
exchange is completed, the Initiator and Responder cookies
included in the ISAKMP Header of all subsequent
between the ISAKMP peers
During phase 1 negotiations, the initiator and responder
determine the ISAKMP SA. Therefore, the SPI field in the
payload is redundant and MAY be set to 0 or it MAY contain
transmitting entity's cookie
In the third line (3) of the table, the initiator associates
Message ID with the Protocols contained in the SA Proposal.
Message ID and the initiator's SPI(s) to be associated with
protocol in the Proposal are sent to the responder. The SPI(s)
be used by the security protocols once the phase 2 negotiation
completed
Maughan, et. al. Standards Track [Page 18]
RFC 2408 ISAKMP November 1998
In the fourth line (4) of the table, the responder includes the
Message ID and the responder's SPI(s) to be associated with
protocol in the accepted Proposal. This information is returned
the initiator
In the fifth line (5) of the table, the initiator and responder
the Message ID field in the ISAKMP Header to keep track of the in
progress protocol negotiation. This is only applicable for a phase 2
exchange and the value MUST be 0 for a phase 1 exchange because
combined cookies identify the ISAKMP SA. The SPI field in
Proposal payload is not applicable because the Proposal payload
only used during the SA negotiation message exchange (steps 3 and 4).
In the sixth line (6) of the table, the phase 2 negotiation
complete. The security protocols use the SPI(s) to determine
security services and mechanisms to apply to the
between them. The SPI value shown in the sixth line (6) is not
SPI field in the Proposal payload, but the SPI field contained
the security protocol header
During the SA establishment, a SPI MUST be generated. ISAKMP
designed to handle variable sized SPIs. This is accomplished
using the SPI Size field within the Proposal payload during
establishment. Handling of SPIs will be outlined by the
specification (e.g. [IPDOI]).
When a security association (SA) is initially established, one
assumes the role of initiator and the other the role of responder
Once the SA is established, both the original initiator and
can initiate a phase 2 negotiation with the peer entity. Thus
ISAKMP SAs are bidirectional in nature
Additionally, ISAKMP allows both initiator and responder to have
control during the negotiation process. While ISAKMP is designed
allow an SA negotiation that includes multiple proposals,
initiator can maintain some control by only making one proposal
accordance with the initiator's local security policy. Once
initiator sends a proposal containing more than one proposal (
are sent in decreasing preference order), the initiator
control to the responder. Once the responder is controlling the
establishment, the responder can make its policy take precedence
the initiator within the context of the multiple options offered
the initiator. This is accomplished by selecting the proposal
suited for the responder's local security policy and returning
selection to the initiator
Maughan, et. al. Standards Track [Page 19]
RFC 2408 ISAKMP November 1998
2.5
2.5.1 Transport
ISAKMP can be implemented over any transport protocol or over
itself. Implementations MUST include send and receive capability
ISAKMP using the User Datagram Protocol (UDP) on port 500. UDP
500 has been assigned to ISAKMP by the Internet Assigned
Authority (IANA). Implementations MAY additionally support
over other transport protocols or over IP itself
2.5.2 RESERVED
The existence of RESERVED fields within ISAKMP payloads are
strictly to preserve byte alignment. All RESERVED fields in
ISAKMP protocol MUST be set to zero (0) when a packet is issued.
receiver SHOULD check the RESERVED fields for a zero (0) value
discard the packet if other values are found
2.5.3 Anti-Clogging Token ("Cookie")
The details of cookie generation are implementation dependent,
MUST satisfy these basic requirements (originally stated by Phil
in [Karn]):
1. The cookie must depend on the specific parties.
prevents an attacker from obtaining a cookie using a real
address and UDP port, and then using it to swamp the
with Diffie-Hellman requests from randomly chosen
addresses or ports
2. It must not be possible for anyone other than the
entity to generate cookies that will be accepted by
entity. This implies that the issuing entity must use
secret information in the generation and
verification of a cookie. It must not be possible to
this secret information from any particular cookie
3. The cookie generation function must be fast to
attacks intended to sabotage CPU resources
Karn's suggested method for creating the cookie is to perform a
hash (e.g. MD5) over the IP Source and Destination Address, the
Source and Destination Ports and a locally generated secret
value. ISAKMP requires that the cookie be unique for each
establishment to help prevent replay attacks, therefore, the date
time MUST be added to the information hashed. The generated
are placed in the ISAKMP Header (described in section 3.1)
Maughan, et. al. Standards Track [Page 20]
RFC 2408 ISAKMP November 1998
and Responder cookie fields. These fields are 8 octets in length
thus, requiring a generated cookie to be 8 octets. Notify and
messages (see sections 3.14, 3.15, and 4.8) are uni-
transmissions and are done under the protection of an existing
SA, thus, not requiring the generation of a new cookie.
exception to this is the transmission of a Notify message during
Phase 1 exchange, prior to completing the establishment of an SA
Sections 3.14 and 4.8 provide additional details
3 ISAKMP
ISAKMP payloads provide modular building blocks for
ISAKMP messages. The presence and ordering of payloads in ISAKMP
defined by and dependent upon the Exchange Type Field located in
ISAKMP Header (see Figure 2). The ISAKMP payload types are
in sections 3.4 through 3.15. The descriptions of the
payloads, messages, and exchanges (see Section 4) are shown
network octet ordering
3.1 ISAKMP Header
An ISAKMP message has a fixed header format, shown in Figure 2,
followed by a variable number of payloads. A fixed header
parsing, providing the benefit of protocol parsing software that
less complex and easier to implement. The fixed header contains
information required by the protocol to maintain state,
payloads and possibly prevent denial of service or replay attacks
The ISAKMP Header fields are defined as follows
o Initiator Cookie (8 octets) - Cookie of entity that initiated
establishment, SA notification, or SA deletion
o Responder Cookie (8 octets) - Cookie of entity that is
to an SA establishment request, SA notification, or SA deletion
Maughan, et. al. Standards Track [Page 21]
RFC 2408 ISAKMP November 1998
1 2 3
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