The Internet Security Association and Key Management Protocol
(ISAKMP) is a well designed protocol aimed at the Internet of the
future. The massive growth of the Internet will lead to great
diversity in network utilization, communications, security
requirements, and security mechanisms. ISAKMP contains all the
features that will be needed for this dynamic and expanding
ISAKMP's Security Association (SA) feature coupled with
authentication and key establishment provides the security and
flexibility that will be needed for future growth and diversity.
This security diversity of multiple key exchange techniques,
encryption algorithms, authentication mechanisms, security services,
and security attributes will allow users to select the appropriate
security for their network, communications, and security needs. The
SA feature allows users to specify and negotiate security
requirements with other users. An additional benefit of supporting
multiple techniques in a single protocol is that as new techniques
are developed they can easily be added to the protocol. This
provides a path for the growth of Internet security services. ISAKMP
supports both publicly or privately defined SAs, making it ideal for
government, commercial, and private communications.
ISAKMP provides the ability to establish SAs for multiple security
protocols and applications. These protocols and applications may be
session-oriented or sessionless. Having one SA establishment
protocol that supports multiple security protocols eliminates the
need for multiple, nearly identical authentication, key exchange and
SA establishment protocols when more than one security protocol is in
use or desired. Just as IP has provided the common networking layer
for the Internet, a common security establishment protocol is needed
if security is to become a reality on the Internet. ISAKMP provides
the common base that allows all other security protocols to
ISAKMP follows good security design principles. It is not coupled to
other insecure transport protocols, therefore it is not vulnerable or
weakened by attacks on other protocols. Also, when more secure
transport protocols are developed, ISAKMP can be easily migrated to
them. ISAKMP also provides protection against protocol related
attacks. This protection provides the assurance that the SAs and
keys established are with the desired party and not with an attacker.
ISAKMP also follows good protocol design principles. Protocol
specific information only is in the protocol header, following the
design principles of IPv6. The data transported by the protocol is
separated into functional payloads. As the Internet grows and
evolves, new payloads to support new security functionality can be
added without modifying the entire protocol.
A ISAKMP Security Association Attributes
As detailed in previous sections, ISAKMP is designed to provide a
flexible and extensible framework for establishing and managing
Security Associations and cryptographic keys. The framework provided
by ISAKMP consists of header and payload definitions, exchange types
for guiding message and payload exchanges, and general processing
guidelines. ISAKMP does not define the mechanisms that will be used
to establish and manage Security Associations and cryptographic keys
in an authenticated and confidential manner. The definition of
mechanisms and their application is the purview of individual Domains
of Interpretation (DOIs).
This section describes the ISAKMP values for the Internet IP Security
DOI, supported security protocols, and identification values for
ISAKMP Phase 1 negotiations. The Internet IP Security DOI is
MANDATORY to implement for IP Security. [Oakley] and [IKE] describe,
in detail, the mechanisms and their application for establishing and
managing Security Associations and cryptographic keys for IP
A.2 Internet IP Security DOI Assigned Value
As described in [IPDOI], the Internet IP Security DOI Assigned Number
is one (1).
A.3 Supported Security Protocols
Values for supported security protocols are specified in the most
recent "Assigned Numbers" RFC [STD-2]. Presented in the following
table are the values for the security protocols supported by ISAKMP
for the Internet IP Security DOI.
Protocol Assigned Value
All DOIs MUST reserve ISAKMP with a Protocol-ID of 1. All other
security protocols within that DOI will be numbered accordingly.
Security protocol values 2-15359 are reserved to IANA for future use.
Values 15360-16383 are permanently reserved for private use amongst
mutually consenting implementations. Such private use values are
unlikely to be interoperable across different implementations.
A.4 ISAKMP Identification Type Values
The following table lists the assigned values for the Identification
Type field found in the Identification payload during a generic Phase
1 exchange, which is not for a specific protocol.
ID Type Value
The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses,
represented by two four (4) octet values. The first value is an IPv4
address. The second is an IPv4 network mask. Note that ones (1s) in
the network mask indicate that the corresponding bit in the address
is fixed, while zeros (0s) indicate a "wildcard" bit.
The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6
The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses,
represented by two sixteen (16) octet values. The first value is an
IPv6 address. The second is an IPv6 network mask. Note that ones
(1s) in the network mask indicate that the corresponding bit in the
address is fixed, while zeros (0s) indicate a "wildcard" bit.
B Defining a new Domain of Interpretation
The Internet DOI may be sufficient to meet the security requirements
of a large portion of the internet community. However, some groups
may have a need to customize some aspect of a DOI, perhaps to add a
different set of cryptographic algorithms, or perhaps because they
want to make their security-relevant decisions based on something
other than a host id or user id. Also, a particular group may have a
need for a new exchange type, for example to support key management
for multicast groups.
This section discusses guidelines for defining a new DOI. The full
specification for the Internet DOI can be found in [IPDOI].
Defining a new DOI is likely to be a time-consuming process. If at
all possible, it is recommended that the designer begin with an
existing DOI and customize only the parts that are unacceptable.
If a designer chooses to start from scratch, the following MUST be
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 be supported.
o A scheme for naming security-relevant information, including
encryption algorithms, key exchange algorithms, etc.
o A syntax for the specification of proposed security services,
attributes, and certificate authorities.
o The specific formats of the various payload contents.
o Additional exchange types, if required.
The situation is the basis for deciding how to protect a
communications channel. It must contain all of the data that will be
used to determine the types and strengths of protections applied in
an SA. For example, a US Department of Defense DOI would probably use
unpublished algorithms and have additional special attributes to
negotiate. These additional security attributes would be included in
B.2 Security Policies
Security policies define how various types of information must be
categorized and protected. The DOI must define the set of security
policies supported, because both parties in a negotiation must trust
that the other party understands a situation, and will protect
information appropriately, both in transit and in storage. In a
corporate setting, for example, both parties in a negotiation must
agree to the meaning of the term "proprietary information" before
they can negotiate how to protect it.
Note that including the required security policies in the DOI only
specifies that the participating hosts understand and implement those
policies in a full system context.
B.3 Naming Schemes
Any DOI must define a consistent way to name cryptographic
algorithms, certificate authorities, etc. This can usually be done
by using IANA naming conventions, perhaps with some private
B.4 Syntax for Specifying Security Services
In addition to simply specifying how to name entities, the DOI must
also specify the format for complete proposals of how to protect
traffic under a given situation.
B.5 Payload Specification
The DOI must specify the format of each of the payload types. For
several of the payload types, ISAKMP has included fields that would
have to be present across all DOI (such as a certificate authority in
the certificate payload, or a key exchange identifier in the key
B.6 Defining new Exchange Types
If the basic exchange types are inadequate to meet the requirements
within a DOI, a designer can define up to thirteen extra exchange
types per DOI. The designer creates a new exchange type by choosing
an unused exchange type value, and defining a sequence of messages
composed of strings of the ISAKMP payload types.
Note that any new exchange types must be rigorously analyzed for
vulnerabilities. Since this is an expensive and imprecise
undertaking, a new exchange type should only be created when
Cryptographic analysis techniques are improving at a steady pace.
The continuing improvement in processing power makes once
computationally prohibitive cryptographic attacks more realistic.
New cryptographic algorithms and public key generation techniques are
also being developed at a steady pace. New security services and
mechanisms are being developed at an accelerated pace. A consistent
method of choosing from a variety of security services and mechanisms
and to exchange attributes required by the mechanisms is important to
security in the complex structure of the Internet. However, a system
that locks itself into a single cryptographic algorithm, key exchange
technique, or security mechanism will become increasingly vulnerable
as time passes.
UDP is an unreliable datagram protocol and therefore its use in
ISAKMP introduces a number of security considerations. Since UDP is
unreliable, but a key management protocol must be reliable, the
reliability is built into ISAKMP. While ISAKMP utilizes UDP as its
transport mechanism, it doesn't rely on any UDP information (e.g.
checksum, length) for its processing.
Another issue that must be considered in the development of ISAKMP is
the effect of firewalls on the protocol. Many firewalls filter out
all UDP packets, making reliance on UDP questionable in certain
A number of very important security considerations are presented in
[SEC-ARCH]. One bears repeating. Once a private session key is
created, it must be safely stored. Failure to properly protect the
private key from access both internal and external to the system
completely nullifies any protection provided by the IP Security
This document contains many "magic" numbers to be maintained by the
IANA. This section explains the criteria to be used by the IANA to
assign additional numbers in each of these lists.
Domain of Interpretation
The Domain of Interpretation (DOI) is a 32-bit field which identifies
the domain under which the security association negotiation is taking
place. Requests for assignments of new DOIs must be accompanied by a
standards-track RFC which describes the specific domain.
Supported Security Protocols
ISAKMP is designed to provide security association negotiation and
key management for many security protocols. Requests for identifiers
for additional security protocols must be accompanied by a
standards-track RFC which describes the security protocol and its
relationship to ISAKMP.
Dan Harkins, Dave Carrel, and Derrell Piper of Cisco Systems provided
design assistance with the protocol and coordination for the [IKE]
and [IPDOI] documents.
Hilarie Orman, via the Oakley key exchange protocol, has
significantly influenced the design of ISAKMP.
Marsha Gross, Bill Kutz, Mike Oehler, Pete Sell, and Ruth Taylor
provided significant input and review to this document.
Scott Carlson ported the TIS DNSSEC prototype to FreeBSD for use with
the ISAKMP prototype.
Jeff Turner and Steve Smalley contributed to the prototype
development and integration with ESP and AH.
Mike Oehler and Pete Sell performed interoperability testing with
other ISAKMP implementors.
Thanks to Carl Muckenhirn of SPARTA, Inc. for his assistance with
[ANSI] ANSI, X9.42: Public Key Cryptography for the Financial
Services Industry -- Establishment of Symmetric Algorithm
Keys Using Diffie-Hellman, Working Draft, April 19, 1996.
[BC] Ballardie, A., and J. Crowcroft, Multicast-specific
Security Threats and Countermeasures, Proceedings of 1995
ISOC Symposium on Networks & Distributed Systems Security,
pp. 17-30, Internet Society, San Diego, CA, February 1995.
[Berge] Berge, N., "UNINETT PCA Policy Statements", RFC 1875,
[CW87] Clark, D.D. and D.R. Wilson, A Comparison of Commercial
and Military Computer Security Policies, Proceedings of
the IEEE Symposium on Security & Privacy, Oakland, CA,
1987, pp. 184-193.
[DNSSEC] D. Eastlake III, Domain Name System Protocol Security
Extensions, Work in Progress.
[DOW92] Diffie, W., M.Wiener, P. Van Oorschot, Authentication and
Authenticated Key Exchanges, Designs, Codes, and
Cryptography, 2, 107-125, Kluwer Academic Publishers,
[IAB] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
[IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IPDOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[Karn] Karn, P., and B. Simpson, Photuris: Session Key
Management Protocol, Work in Progress.
[Kent94] Steve Kent, IPSEC SMIB, e-mail to email@example.com, August
[Oakley] Orman, H., "The Oakley Key Determination Protocol", RFC
2412, November 1998.
[RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management", RFC
1422, February 1993.
[RFC-1949] Ballardie, A., "Scalable Multicast Key Distribution", RFC
1949, May 1996.
[RFC-2093] Harney, H., and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Specification", RFC 2093, July 1997.
[RFC-2094] Harney, H., and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC 2094, July 1997.
[RFC-2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Schneier] Bruce Schneier, Applied Cryptography - Protocols,
Algorithms, and Source Code in C (Second Edition), John
Wiley & Sons, Inc., 1996.
[SEC-ARCH] Atkinson, R., and S. Kent, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
National Security Agency
9800 Savage Road
Ft. Meade, MD. 20755-6000
National Security Agency
9800 Savage Road
Ft. Meade, MD. 20755-6000
2415-B Charleston Road
Mountain View, CA 94043
RABA Technologies, Inc.
10500 Little Patuxent Parkway
Columbia, MD. 21044
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.