tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 2408


Internet Security Association and Key Management Protocol (ISAKMP)

Part 4 of 4, p. 75 to 86
Prev RFC Part


prevText      Top      Up      ToC       Page 75 
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

   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.

Top      Up      ToC       Page 76 
   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.

Top      Up      ToC       Page 77 
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

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.

Top      Up      ToC       Page 78 
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


   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.

Top      Up      ToC       Page 79 
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.

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.

Top      Up      ToC       Page 80 
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
   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.

Top      Up      ToC       Page 81 
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

   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

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 RFC which describes the specific domain.

Top      Up      ToC       Page 82 
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,
              December 1995.

Top      Up      ToC       Page 83 
   [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, 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", 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.

Top      Up      ToC       Page 84 
   [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:

Top      Up      ToC       Page 85 
Authors' Addresses

   Douglas Maughan
   National Security Agency
   ATTN: R23
   9800 Savage Road
   Ft.  Meade, MD. 20755-6000

   Phone:  301-688-0847

   Mark Schneider
   National Security Agency
   ATTN: R23
   9800 Savage Road
   Ft.  Meade, MD. 20755-6000

   Phone:  301-688-0851

   Mark Schertler
   Securify, Inc.
   2415-B Charleston Road
   Mountain View, CA 94043

   Phone:  650-934-9303

   Jeff Turner
   RABA Technologies, Inc.
   10500 Little Patuxent Parkway
   Columbia, MD. 21044

   Phone:  410-715-9399

Top      Up      ToC       Page 86 
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