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