Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2408

Internet Security Association and Key Management Protocol (ISAKMP)

Pages: 86
Obsoleted by:  4306
Part 1 of 4 – Pages 1 to 21
None   None   Next

ToP   noToC   RFC2408 - Page 1
Network Working Group                                      D. Maughan
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.
ToP   noToC   RFC2408 - Page 2
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
ToP   noToC   RFC2408 - Page 3
   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
ToP   noToC   RFC2408 - Page 4
   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.
ToP   noToC   RFC2408 - Page 5
   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
ToP   noToC   RFC2408 - Page 6
   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.
ToP   noToC   RFC2408 - Page 7
   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.
ToP   noToC   RFC2408 - Page 8
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
ToP   noToC   RFC2408 - Page 9
   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.
ToP   noToC   RFC2408 - Page 10
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
ToP   noToC   RFC2408 - Page 11
   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.
ToP   noToC   RFC2408 - Page 12
   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].
ToP   noToC   RFC2408 - Page 13
   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.
ToP   noToC   RFC2408 - Page 14
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
ToP   noToC   RFC2408 - Page 15
   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
ToP   noToC   RFC2408 - Page 16
   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.
ToP   noToC   RFC2408 - Page 17
   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
ToP   noToC   RFC2408 - Page 18
   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.
ToP   noToC   RFC2408 - Page 19
   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.
ToP   noToC   RFC2408 - Page 20
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
   MUST satisfy these basic requirements (originally stated by Phil Karn
   in [Karn]):

      1.    The cookie must depend on the specific parties.  This
            prevents an attacker from obtaining a cookie using a real IP
            address and UDP port, and then using it to swamp the victim
            with Diffie-Hellman requests from randomly chosen IP
            addresses or ports.

      2.    It must not be possible for anyone other than the issuing
            entity to generate cookies that will be accepted by that
            entity.  This implies that the issuing entity must use local
            secret information in the generation and subsequent
            verification of a cookie.  It must not be possible to deduce
            this secret information from any particular cookie.

      3.    The cookie generation function must be fast to thwart
            attacks intended to sabotage CPU resources.

   Karn's suggested method for creating the cookie is to perform a fast
   hash (e.g.  MD5) over the IP Source and Destination Address, the UDP
   Source and Destination Ports and a locally generated secret random
   value.  ISAKMP requires that the cookie be unique for each SA
   establishment to help prevent replay attacks, therefore, the date and
   time MUST be added to the information hashed.  The generated cookies
   are placed in the ISAKMP Header (described in section 3.1) Initiator
ToP   noToC   RFC2408 - Page 21
   and Responder cookie fields.  These fields are 8 octets in length,
   thus, requiring a generated cookie to be 8 octets.  Notify and Delete
   messages (see sections 3.14, 3.15, and 4.8) are uni-directional
   transmissions and are done under the protection of an existing ISAKMP
   SA, thus, not requiring the generation of a new cookie.  One
   exception to this is the transmission of a Notify message during a
   Phase 1 exchange, prior to completing the establishment of an SA.
   Sections 3.14 and 4.8 provide additional details.



(page 21 continued on part 2)

Next Section