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.
`
`Maughan, et. al. Standards Track [Page 1]
`
`Petitioner Apple Inc. - Exhibit 1047, p. 1
`
`

`

`
`RFC 2408 ISAKMP November 1998
`
`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
`
`Maughan, et. al. Standards Track [Page 2]
`
`Petitioner Apple Inc. - Exhibit 1047, p. 2
`
`

`

`
`RFC 2408 ISAKMP November 1998
`
` 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
`
`Maughan, et. al. Standards Track [Page 3]
`
`Petitioner Apple Inc. - Exhibit 1047, p. 3
`
`

`

`
`RFC 2408 ISAKMP November 1998
`
` 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.
`
`Maughan, et. al. Standards Track [Page 4]
`
`Petitioner Apple Inc. - Exhibit 1047, p. 4
`
`

`

`
`RFC 2408 ISAKMP November 1998
`
` 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
`
`Maughan, et. al. Standards Track [Page 5]
`
`Petitioner Apple Inc. - Exhibit 1047, p. 5
`
`

`

`
`RFC 2408 ISAKMP November 1998
`
` 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.
`
`Maughan, et. al. Standards Track [Page 6]
`
`Petitioner Apple Inc. - Exhibit 1047, p. 6
`
`

`

`
`RFC 2408 ISAKMP November 1998
`
` 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.
`
`Maughan, et. al. Standards Track [Page 7]
`
`Petitioner Apple Inc. - Exhibit 1047, p. 7
`
`

`

`
`RFC 2408 ISAKMP November 1998
`
`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
`
`Maughan, et. al. Standards Track [Page 8]
`
`Petitioner Apple Inc. - Exhibit 1047, p. 8
`
`

`

`
`RFC 2408 ISAKMP November 1998
`
` 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.
`
`Maughan, et. al. Standards Track [Page 9]
`
`Petitioner Apple Inc. - Exhibit 1047, p. 9
`
`

`

`
`RFC 2408 ISAKMP November 1998
`
`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
`
`Maughan, et. al. Standards Track [Page 10]
`
`Petitioner Apple Inc. - Exhibit 1047, p. 10
`
`

`

`
`RFC 2408 ISAKMP November 1998
`
` 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 pr