containing the INVALID-HASH-INFORMATION message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
2. Perform the Hash function as outlined in the DOI and/or Key
Exchange protocol documents. If the Hash function fails, the
message is discarded and the following actions are taken:
(a) The event, INVALID HASH VALUE, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the AUTHENTICATION-FAILED message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
5.12 Signature Payload Processing
When creating a Signature Payload, the transmitting entity (initiator
or responder) MUST do the following:
1. Determine the Signature function to be used as defined by the SA
negotiation.
2. Determine the usage of the Signature Data field as defined by the
DOI.
3. Construct a Signature payload.
4. Transmit the message to the receiving entity as described in
section 5.1.
When a Signature payload is received, the receiving entity (initiator
or responder) MUST do the following:
1. Determine if the Signature is supported. If the Signature
determination fails, the message is discarded and the following
actions are taken:
(a) The event, INVALID SIGNATURE INFORMATION, MAY be logged in
the appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-SIGNATURE message type MAY be sent to
the transmitting entity. This action is dictated by a
system security policy.
2. Perform the Signature function as outlined in the DOI and/or Key
Exchange protocol documents. If the Signature function fails,
the message is discarded and the following actions are taken:
(a) The event, INVALID SIGNATURE VALUE, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the AUTHENTICATION-FAILED message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
5.13 Nonce Payload Processing
When creating a Nonce Payload, the transmitting entity (initiator or
responder) MUST do the following:
1. Create a unique random value to be used as a nonce.
2. Construct a Nonce payload.
3. Transmit the message to the receiving entity as described in
section 5.1.
When a Nonce payload is received, the receiving entity (initiator or
responder) MUST do the following:
1. There are no specific procedures for handling Nonce payloads.
The procedures are defined by the exchange types (and possibly
the DOI and Key Exchange descriptions).
5.14 Notification Payload Processing
During communications it is possible that errors may occur. The
Informational Exchange with a Notify Payload provides a controlled
method of informing a peer entity that errors have occurred during
protocol processing. It is RECOMMENDED that Notify Payloads be sent
in a separate Informational Exchange rather than appending a Notify
Payload to an existing exchange.
When creating a Notification Payload, the transmitting entity
(initiator or responder) MUST do the following:
1. Determine the DOI for this Notification.
2. Determine the Protocol-ID for this Notification.
3. Determine the SPI size based on the Protocol-ID field. This
field is necessary because different security protocols have
different SPI sizes. For example, ISAKMP combines the Initiator
and Responder cookie pair (16 octets) as a SPI, while ESP and AH
have 4 octet SPIs.
4. Determine the Notify Message Type based on the error or status
message desired.
5. Determine the SPI which is associated with this notification.
6. Determine if additional Notification Data is to be included.
This is additional information specified by the DOI.
7. Construct a Notification payload.
8. Transmit the message to the receiving entity as described in
section 5.1.
Because the Informational Exchange with a Notification payload is a
unidirectional message a retransmission will not be performed. The
local security policy will dictate the procedures for continuing.
However, we RECOMMEND that a NOTIFICATION PAYLOAD ERROR event be
logged in the appropriate system audit file by the receiving entity.
If the Informational Exchange occurs prior to the exchange of keying
material during an ISAKMP Phase 1 negotiation there will be no
protection provided for the Informational Exchange. Once the keying
material has been exchanged or the ISAKMP SA has been established,
the Informational Exchange MUST be transmitted under the protection
provided by the keying material or the ISAKMP SA.
When a Notification payload is received, the receiving entity
(initiator or responder) MUST do the following:
1. Determine if the Informational Exchange has any protection
applied to it by checking the Encryption Bit and the
Authentication Only Bit in the ISAKMP Header. If the Encryption
Bit is set, i.e. the Informational Exchange is encrypted, then
the message MUST be decrypted using the (in-progress or
completed) ISAKMP SA. Once the decryption is complete the
processing can continue as described below. If the
Authentication Only Bit is set, then the message MUST be
authenticated using the (in-progress or completed) ISAKMP SA.
Once the authentication is completed, the processing can continue
as described below. If the Informational Exchange is not
encrypted or authentication, the payload processing can continue
as described below.
2. Determine if the Domain of Interpretation (DOI) is supported. If
the DOI determination fails, the payload is discarded and the
following action is taken:
(a) The event, INVALID DOI, MAY be logged in the appropriate
system audit file.
3. Determine if the Protocol-Id is supported. If the Protocol-Id
determination fails, the payload is discarded and the following
action is taken:
(a) The event, INVALID PROTOCOL-ID, MAY be logged in the
appropriate system audit file.
4. Determine if the SPI is valid. If the SPI is invalid, the
payload is discarded and the following action is taken:
(a) The event, INVALID SPI, MAY be logged in the appropriate
system audit file.
5. Determine if the Notify Message Type is valid. If the Notify
Message Type is invalid, the payload is discarded and the
following action is taken:
(a) The event, INVALID MESSAGE TYPE, MAY be logged in the
appropriate system audit file.
6. Process the Notification payload, including additional
Notification Data, and take appropriate action, according to
local security policy.
5.15 Delete Payload Processing
During communications it is possible that hosts may be compromised or
that information may be intercepted during transmission. Determining
whether this has occurred is not an easy task and is outside the
scope of this memo. However, if it is discovered that transmissions
are being compromised, then it is necessary to establish a new SA and
delete the current SA.
The Informational Exchange with a Delete Payload provides a
controlled method of informing a peer entity that the transmitting
entity has deleted the SA(s). Deletion of Security Associations MUST
always be performed under the protection of an ISAKMP SA. The
receiving entity SHOULD clean up its local SA database. However,
upon receipt of a Delete message the SAs listed in the Security
Parameter Index (SPI) field of the Delete payload cannot be used with
the transmitting entity. The SA Establishment procedure must be
invoked to re-establish secure communications.
When creating a Delete Payload, the transmitting entity (initiator or
responder) MUST do the following:
1. Determine the DOI for this Deletion.
2. Determine the Protocol-ID for this Deletion.
3. Determine the SPI size based on the Protocol-ID field. This
field is necessary because different security protocols have
different SPI sizes. For example, ISAKMP combines the Initiator
and Responder cookie pair (16 octets) as a SPI, while ESP and AH
have 4 octet SPIs.
4. Determine the # of SPIs to be deleted for this protocol.
5. Determine the SPI(s) which is (are) associated with this
deletion.
6. Construct a Delete payload.
7. Transmit the message to the receiving entity as described in
section 5.1.
Because the Informational Exchange with a Delete payload is a
unidirectional message a retransmission will not be performed. The
local security policy will dictate the procedures for continuing.
However, we RECOMMEND that a DELETE PAYLOAD ERROR event be logged in
the appropriate system audit file by the receiving entity.
As described above, the Informational Exchange with a Delete payload
MUST be transmitted under the protection provided by an ISAKMP SA.
When a Delete payload is received, the receiving entity (initiator or
responder) MUST do the following:
1. Because the Informational Exchange is protected by some security
service (e.g. authentication for an Auth-Only SA, encryption for
other exchanges), the message MUST have these security services
applied using the ISAKMP SA. Once the security service processing
is complete the processing can continue as described below. Any
errors that occur during the security service processing will be
evident when checking information in the Delete payload. The
local security policy SHOULD dictate any action to be taken as a
result of security service processing errors.
2. Determine if the Domain of Interpretation (DOI) is supported. If
the DOI determination fails, the payload is discarded and the
following action is taken:
(a) The event, INVALID DOI, MAY be logged in the appropriate
system audit file.
3. Determine if the Protocol-Id is supported. If the Protocol-Id
determination fails, the payload is discarded and the following
action is taken:
(a) The event, INVALID PROTOCOL-ID, MAY be logged in the
appropriate system audit file.
4. Determine if the SPI is valid for each SPI included in the Delete
payload. For each SPI that is invalid, the following action is
taken:
(a) The event, INVALID SPI, MAY be logged in the appropriate
system audit file.
5. Process the Delete payload and take appropriate action, according
to local security policy. As described above, one appropriate
action SHOULD include cleaning up the local SA database.
6 Conclusions
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
communications environment.
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
interoperate.
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
A.1 Background/Rationale
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
Security.
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
RESERVED 0
ISAKMP 1
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
ID_IPV4_ADDR 0
ID_IPV4_ADDR_SUBNET 1
ID_IPV6_ADDR 2
ID_IPV6_ADDR_SUBNET 3
A.4.1 ID_IPV4_ADDR
The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
A.4.2 ID_IPV4_ADDR_SUBNET
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.
A.4.3 ID_IPV6_ADDR
The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6
address.
A.4.4 ID_IPV6_ADDR_SUBNET
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
defined:
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.
B.1 Situation
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
the situation.
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
extensions.
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
exchange payload).
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
absolutely necessary.
Security Considerations
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
environments.
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
services.
IANA Considerations
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 RFCwhich 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 RFCwhich describes the security protocol and its
relationship to ISAKMP.
Acknowledgements
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
LaTeX.
References
[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", RFC1875,
December 1995.
[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,
1992.
[IAB] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC2316, April 1998.
[IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange
(IKE)", RFC2409, November 1998.
[IPDOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC2407, November 1998.
[Karn] Karn, P., and B. Simpson, Photuris: Session Key
Management Protocol, Work in Progress.
[Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August
10, 1994.
[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", RFC2093, July 1997.
[RFC-2094] Harney, H., and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC2094, July 1997.
[RFC-2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, 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", RFC2401, November 1998.
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
Authors' Addresses
Douglas Maughan
National Security Agency
ATTN: R23
9800 Savage Road
Ft. Meade, MD. 20755-6000
Phone: 301-688-0847
EMail:wdm@tycho.ncsc.mil
Mark Schneider
National Security Agency
ATTN: R23
9800 Savage Road
Ft. Meade, MD. 20755-6000
Phone: 301-688-0851
EMail:mss@tycho.ncsc.mil
Mark Schertler
Securify, Inc.
2415-B Charleston Road
Mountain View, CA 94043
Phone: 650-934-9303
EMail:mjs@securify.com
Jeff Turner
RABA Technologies, Inc.
10500 Little Patuxent Parkway
Columbia, MD. 21044
Phone: 410-715-9399
EMail:jeff.turner@raba.com
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
English.
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.