Network Working Group D. Harkins
`Request for Comments: 2409 D. Carrel
`Category: Standards Track cisco Systems
` November 1998
`
` The Internet Key Exchange (IKE)
`
`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.
`
`Table Of Contents
`
`1 Abstract........................................................ 2
`2 Discussion...................................................... 2
`3 Terms and Definitions........................................... 3
`3.1 Requirements Terminology...................................... 3
`3.2 Notation...................................................... 3
`3.3 Perfect Forward Secrecty...................................... 5
`3.4 Security Association.......................................... 5
`4 Introduction.................................................... 5
`5 Exchanges....................................................... 8
`5.1 Authentication with Digital Signatures........................ 10
`5.2 Authentication with Public Key Encryption..................... 12
` 5.3 A Revised method of Authentication with Public Key Encryption. 13
`5.4 Authentication with a Pre-Shared Key.......................... 16
`5.5 Quick Mode.................................................... 16
`5.6 New Group Mode................................................ 20
`5.7 ISAKMP Informational Exchanges................................ 20
`6 Oakley Groups................................................... 21
`6.1 First Oakley Group............................................ 21
`6.2 Second Oakley Group........................................... 22
`6.3 Third Oakley Group............................................ 22
`6.4 Fourth Oakley Group........................................... 23
`7 Payload Explosion of Complete Exchange.......................... 23
`7.1 Phase 1 with Main Mode........................................ 23
`7.2 Phase 2 with Quick Mode....................................... 25
`8 Perfect Forward Secrecy Example................................. 27
`9 Implementation Hints............................................ 27
`
`Harkins & Carrel Standards Track [Page 1]
`
`Ex. 1008
`Apple v. MPH Techs. Oy
`IPR2019-00821
`
`

`

`RFC 2409 IKE November 1998
`
`10 Security Considerations........................................ 28
`11 IANA Considerations............................................ 30
`12 Acknowledgments................................................ 31
`13 References..................................................... 31
`Appendix A........................................................ 33
`Appendix B........................................................ 37
` Authors’ Addresses................................................ 40
` Authors’ Note..................................................... 40
` Full Copyright Statement.......................................... 41
`
`1. Abstract
`
` ISAKMP ([MSST98]) provides a framework for authentication and key
` exchange but does not define them. ISAKMP is designed to be key
` exchange independant; that is, it is designed to support many
` different key exchanges.
`
` Oakley ([Orm96]) describes a series of key exchanges-- called
` "modes"-- and details the services provided by each (e.g. perfect
` forward secrecy for keys, identity protection, and authentication).
`
` SKEME ([SKEME]) describes a versatile key exchange technique which
` provides anonymity, repudiability, and quick key refreshment.
`
` This document describes a protocol using part of Oakley and part of
` SKEME in conjunction with ISAKMP to obtain authenticated keying
` material for use with ISAKMP, and for other security associations
` such as AH and ESP for the IETF IPsec DOI.
`
`2. Discussion
`
` This memo describes a hybrid protocol. The purpose is to negotiate,
` and provide authenticated keying material for, security associations
` in a protected manner.
`
` Processes which implement this memo can be used for negotiating
` virtual private networks (VPNs) and also for providing a remote user
` from a remote site (whose IP address need not be known beforehand)
` access to a secure host or network.
`
` Client negotiation is supported. Client mode is where the
` negotiating parties are not the endpoints for which security
` association negotiation is taking place. When used in client mode,
` the identities of the end parties remain hidden.
`
`Harkins & Carrel Standards Track [Page 2]
`
`

`

`RFC 2409 IKE November 1998
`
` This does not implement the entire Oakley protocol, but only a subset
` necessary to satisfy its goals. It does not claim conformance or
` compliance with the entire Oakley protocol nor is it dependant in any
` way on the Oakley protocol.
`
` Likewise, this does not implement the entire SKEME protocol, but only
` the method of public key encryption for authentication and its
` concept of fast re-keying using an exchange of nonces. This protocol
` is not dependant in any way on the SKEME protocol.
`
`3. Terms and Definitions
`
`3.1 Requirements Terminology
`
` Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
` "MAY" that appear in this document are to be interpreted as described
` in [Bra97].
`
`3.2 Notation
`
` The following notation is used throughout this memo.
`
` HDR is an ISAKMP header whose exchange type is the mode. When
` writen as HDR* it indicates payload encryption.
`
` SA is an SA negotiation payload with one or more proposals. An
` initiator MAY provide multiple proposals for negotiation; a
` responder MUST reply with only one.
`
` <P>_b indicates the body of payload <P>-- the ISAKMP generic
` vpayload is not included.
`
` SAi_b is the entire body of the SA payload (minus the ISAKMP
` generic header)-- i.e. the DOI, situation, all proposals and all
` transforms offered by the Initiator.
`
` CKY-I and CKY-R are the Initiator’s cookie and the Responder’s
` cookie, respectively, from the ISAKMP header.
`
` g^xi and g^xr are the Diffie-Hellman ([DH]) public values of the
` initiator and responder respectively.
`
` g^xy is the Diffie-Hellman shared secret.
`
` KE is the key exchange payload which contains the public
` information exchanged in a Diffie-Hellman exchange. There is no
` particular encoding (e.g. a TLV) used for the data of a KE payload.
`
`Harkins & Carrel Standards Track [Page 3]
`
`

`

`RFC 2409 IKE November 1998
`
` Nx is the nonce payload; x can be: i or r for the ISAKMP initiator
` and responder respectively.
`
` IDx is the identification payload for "x". x can be: "ii" or "ir"
` for the ISAKMP initiator and responder respectively during phase
` one negotiation; or "ui" or "ur" for the user initiator and
` responder respectively during phase two. The ID payload format for
` the Internet DOI is defined in [Pip97].
`
` SIG is the signature payload. The data to sign is exchange-
` specific.
`
` CERT is the certificate payload.
`
` HASH (and any derivitive such as HASH(2) or HASH_I) is the hash
` payload. The contents of the hash are specific to the
` authentication method.
`
` prf(key, msg) is the keyed pseudo-random function-- often a keyed
` hash function-- used to generate a deterministic output that
` appears pseudo-random. prf’s are used both for key derivations and
` for authentication (i.e. as a keyed MAC). (See [KBC96]).
`
` SKEYID is a string derived from secret material known only to the
` active players in the exchange.
`
` SKEYID_e is the keying material used by the ISAKMP SA to protect
` the confidentiality of its messages.
`
` SKEYID_a is the keying material used by the ISAKMP SA to
` authenticate its messages.
`
` SKEYID_d is the keying material used to derive keys for non-ISAKMP
` security associations.
`
` <x>y indicates that "x" is encrypted with the key "y".
`
` --> signifies "initiator to responder" communication (requests).
`
` <-- signifies "responder to initiator" communication (replies).
`
` | signifies concatenation of information-- e.g. X | Y is the
` concatentation of X with Y.
`
` [x] indicates that x is optional.
`
`Harkins & Carrel Standards Track [Page 4]
`
`

`

`RFC 2409 IKE November 1998
`
` Message encryption (when noted by a ’*’ after the ISAKMP header) MUST
` begin immediately after the ISAKMP header. When communication is
` protected, all payloads following the ISAKMP header MUST be
` encrypted. Encryption keys are generated from SKEYID_e in a manner
` that is defined for each algorithm.
`
`3.3 Perfect Forward Secrecy
`
` When used in the memo Perfect Forward Secrecy (PFS) refers to the
` notion that compromise of a single key will permit access to only
` data protected by a single key. For PFS to exist the key used to
` protect transmission of data MUST NOT be used to derive any
` additional keys, and if the key used to protect transmission of data
` was derived from some other keying material, that material MUST NOT
` be used to derive any more keys.
`
` Perfect Forward Secrecy for both keys and identities is provided in
` this protocol. (Sections 5.5 and 8).
`
`3.4 Security Association
`
` A security association (SA) is a set of policy and key(s) used to
` protect information. The ISAKMP SA is the shared policy and key(s)
` used by the negotiating peers in this protocol to protect their
` communication.
`
`4. Introduction
`
` Oakley and SKEME each define a method to establish an authenticated
` key exchange. This includes payloads construction, the information
` payloads carry, the order in which they are processed and how they
` are used.
`
` While Oakley defines "modes", ISAKMP defines "phases". The
` relationship between the two is very straightforward and IKE presents
` different exchanges as modes which operate in one of two phases.
`
` Phase 1 is where the two ISAKMP peers establish a secure,
` authenticated channel with which to communicate. This is called the
` ISAKMP Security Association (SA). "Main Mode" and "Aggressive Mode"
` each accomplish a phase 1 exchange. "Main Mode" and "Aggressive Mode"
` MUST ONLY be used in phase 1.
`
` Phase 2 is where Security Associations are negotiated on behalf of
` services such as IPsec or any other service which needs key material
` and/or parameter negotiation. "Quick Mode" accomplishes a phase 2
` exchange. "Quick Mode" MUST ONLY be used in phase 2.
`
`Harkins & Carrel Standards Track [Page 5]
`
`

`

`RFC 2409 IKE November 1998
`
` "New Group Mode" is not really a phase 1 or phase 2. It follows
` phase 1, but serves to establish a new group which can be used in
` future negotiations. "New Group Mode" MUST ONLY be used after phase
` 1.
`
` The ISAKMP SA is bi-directional. That is, once established, either
` party may initiate Quick Mode, Informational, and New Group Mode
` Exchanges. Per the base ISAKMP document, the ISAKMP SA is identified
` by the Initiator’s cookie followed by the Responder’s cookie-- the
` role of each party in the phase 1 exchange dictates which cookie is
` the Initiator’s. The cookie order established by the phase 1 exchange
` continues to identify the ISAKMP SA regardless of the direction the
` Quick Mode, Informational, or New Group exchange. In other words, the
` cookies MUST NOT swap places when the direction of the ISAKMP SA
` changes.
`
` With the use of ISAKMP phases, an implementation can accomplish very
` fast keying when necessary. A single phase 1 negotiation may be used
` for more than one phase 2 negotiation. Additionally a single phase 2
` negotiation can request multiple Security Associations. With these
` optimizations, an implementation can see less than one round trip per
` SA as well as less than one DH exponentiation per SA. "Main Mode"
` for phase 1 provides identity protection. When identity protection
` is not needed, "Aggressive Mode" can be used to reduce round trips
` even further. Developer hints for doing these optimizations are
` included below. It should also be noted that using public key
` encryption to authenticate an Aggressive Mode exchange will still
` provide identity protection.
`
` This protocol does not define its own DOI per se. The ISAKMP SA,
` established in phase 1, MAY use the DOI and situation from a non-
` ISAKMP service (such as the IETF IPSec DOI [Pip97]). In this case an
` implementation MAY choose to restrict use of the ISAKMP SA for
` establishment of SAs for services of the same DOI. Alternately, an
` ISAKMP SA MAY be established with the value zero in both the DOI and
` situation (see [MSST98] for a description of these fields) and in
` this case implementations will be free to establish security services
` for any defined DOI using this ISAKMP SA. If a DOI of zero is used
` for establishment of a phase 1 SA, the syntax of the identity
` payloads used in phase 1 is that defined in [MSST98] and not from any
` DOI-- e.g. [Pip97]-- which may further expand the syntax and
` semantics of identities.
`
` The following attributes are used by IKE and are negotiated as part
` of the ISAKMP Security Association. (These attributes pertain only
` to the ISAKMP Security Association and not to any Security
` Associations that ISAKMP may be negotiating on behalf of other
` services.)
`
`Harkins & Carrel Standards Track [Page 6]
`
`

`

`RFC 2409 IKE November 1998
`
` - encryption algorithm
`
` - hash algorithm
`
` - authentication method
`
` - information about a group over which to do Diffie-Hellman.
`
` All of these attributes are mandatory and MUST be negotiated. In
` addition, it is possible to optionally negotiate a psuedo-random
` function ("prf"). (There are currently no negotiable pseudo-random
` functions defined in this document. Private use attribute values can
` be used for prf negotiation between consenting parties). If a "prf"
` is not negotiation, the HMAC (see [KBC96]) version of the negotiated
` hash algorithm is used as a pseudo-random function. Other non-
` mandatory attributes are described in Appendix A. The selected hash
` algorithm MUST support both native and HMAC modes.
`
` The Diffie-Hellman group MUST be either specified using a defined
` group description (section 6) or by defining all attributes of a
` group (section 5.6). Group attributes (such as group type or prime--
` see Appendix A) MUST NOT be offered in conjunction with a previously
` defined group (either a reserved group description or a private use
` description that is established after conclusion of a New Group Mode
` exchange).
`
` IKE implementations MUST support the following attribute values:
`
` - DES [DES] in CBC mode with a weak, and semi-weak, key check
` (weak and semi-weak keys are referenced in [Sch96] and listed in
`Appendix A). The key is derived according to Appendix B.
`
` - MD5 [MD5] and SHA [SHA}.
`
` - Authentication via pre-shared keys.
`
` - MODP over default group number one (see below).
`
` In addition, IKE implementations SHOULD support: 3DES for encryption;
` Tiger ([TIGER]) for hash; the Digital Signature Standard, RSA [RSA]
` signatures and authentication with RSA public key encryption; and
` MODP group number 2. IKE implementations MAY support any additional
` encryption algorithms defined in Appendix A and MAY support ECP and
` EC2N groups.
`
` The IKE modes described here MUST be implemented whenever the IETF
` IPsec DOI [Pip97] is implemented. Other DOIs MAY use the modes
` described here.
`
`Harkins & Carrel Standards Track [Page 7]
`
`

`

`RFC 2409 IKE November 1998
`
`5. Exchanges
`
` There are two basic methods used to establish an authenticated key
` exchange: Main Mode and Aggressive Mode. Each generates authenticated
` keying material from an ephemeral Diffie-Hellman exchange. Main Mode
` MUST be implemented; Aggressive Mode SHOULD be implemented. In
` addition, Quick Mode MUST be implemented as a mechanism to generate
` fresh keying material and negotiate non-ISAKMP security services. In
` addition, New Group Mode SHOULD be implemented as a mechanism to
` define private groups for Diffie-Hellman exchanges. Implementations
` MUST NOT switch exchange types in the middle of an exchange.
`
` Exchanges conform to standard ISAKMP payload syntax, attribute
` encoding, timeouts and retransmits of messages, and informational
` messages-- e.g a notify response is sent when, for example, a
` proposal is unacceptable, or a signature verification or decryption
` was unsuccessful, etc.
`
` The SA payload MUST precede all other payloads in a phase 1 exchange.
` Except where otherwise noted, there are no requirements for ISAKMP
` payloads in any message to be in any particular order.
`
` The Diffie-Hellman public value passed in a KE payload, in either a
` phase 1 or phase 2 exchange, MUST be the length of the negotiated
` Diffie-Hellman group enforced, if necessary, by pre-pending the value
` with zeros.
`
` The length of nonce payload MUST be between 8 and 256 bytes
` inclusive.
`
` Main Mode is an instantiation of the ISAKMP Identity Protect
` Exchange: The first two messages negotiate policy; the next two
` exchange Diffie-Hellman public values and ancillary data (e.g.
` nonces) necessary for the exchange; and the last two messages
` authenticate the Diffie-Hellman Exchange. The authentication method
` negotiated as part of the initial ISAKMP exchange influences the
` composition of the payloads but not their purpose. The XCHG for Main
` Mode is ISAKMP Identity Protect.
`
` Similarly, Aggressive Mode is an instantiation of the ISAKMP
` Aggressive Exchange. The first two messages negotiate policy,
` exchange Diffie-Hellman public values and ancillary data necessary
` for the exchange, and identities. In addition the second message
` authenticates the responder. The third message authenticates the
` initiator and provides a proof of participation in the exchange. The
` XCHG for Aggressive Mode is ISAKMP Aggressive. The final message MAY
` NOT be sent under protection of the ISAKMP SA allowing each party to
`
`Harkins & Carrel Standards Track [Page 8]
`
`

`

`RFC 2409 IKE November 1998
`
` postpone exponentiation, if desired, until negotiation of this
` exchange is complete. The graphic depictions of Aggressive Mode show
` the final payload in the clear; it need not be.
`
` Exchanges in IKE are not open ended and have a fixed number of
` messages. Receipt of a Certificate Request payload MUST NOT extend
` the number of messages transmitted or expected.
`
` Security Association negotiation is limited with Aggressive Mode. Due
` to message construction requirements the group in which the Diffie-
` Hellman exchange is performed cannot be negotiated. In addition,
` different authentication methods may further constrain attribute
` negotiation. For example, authentication with public key encryption
` cannot be negotiated and when using the revised method of public key
` encryption for authentication the cipher and hash cannot be
` negotiated. For situations where the rich attribute negotiation
` capabilities of IKE are required Main Mode may be required.
`
` Quick Mode and New Group Mode have no analog in ISAKMP. The XCHG
` values for Quick Mode and New Group Mode are defined in Appendix A.
`
` Main Mode, Aggressive Mode, and Quick Mode do security association
` negotiation. Security Association offers take the form of Tranform
` Payload(s) encapsulated in Proposal Payload(s) encapsulated in
` Security Association (SA) payload(s). If multiple offers are being
` made for phase 1 exchanges (Main Mode and Aggressive Mode) they MUST
` take the form of multiple Transform Payloads for a single Proposal
` Payload in a single SA payload. To put it another way, for phase 1
` exchanges there MUST NOT be multiple Proposal Payloads for a single
` SA payload and there MUST NOT be multiple SA payloads. This document
` does not proscribe such behavior on offers in phase 2 exchanges.
`
` There is no limit on the number of offers the initiator may send to
` the responder but conformant implementations MAY choose to limit the
` number of offers it will inspect for performance reasons.
`
` During security association negotiation, initiators present offers
` for potential security associations to responders. Responders MUST
` NOT modify attributes of any offer, attribute encoding excepted (see
`Appendix A). If the initiator of an exchange notices that attribute
` values have changed or attributes have been added or deleted from an
` offer made, that response MUST be rejected.
`
` Four different authentication methods are allowed with either Main
` Mode or Aggressive Mode-- digital signature, two forms of
` authentication with public key encryption, or pre-shared key. The
` value SKEYID is computed seperately for each authentication method.
`
`Harkins & Carrel Standards Track [Page 9]
`
`

`

`RFC 2409 IKE November 1998
`
` For signatures: SKEYID = prf(Ni_b | Nr_b, g^xy)
` For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I |
` CKY-R)
` For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b |
` Nr_b)
`
` The result of either Main Mode or Aggressive Mode is three groups of
` authenticated keying material:
`
` SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
` SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
` SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
`
` and agreed upon policy to protect further communications. The values
` of 0, 1, and 2 above are represented by a single octet. The key used
` for encryption is derived from SKEYID_e in an algorithm-specific
` manner (see appendix B).
`
` To authenticate either exchange the initiator of the protocol
` generates HASH_I and the responder generates HASH_R where:
`
` HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
` HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
`
` For authentication with digital signatures, HASH_I and HASH_R are
` signed and verified; for authentication with either public key
` encryption or pre-shared keys, HASH_I and HASH_R directly
` authenticate the exchange. The entire ID payload (including ID type,
` port, and protocol but excluding the generic header) is hashed into
` both HASH_I and HASH_R.
`
` As mentioned above, the negotiated authentication method influences
` the content and use of messages for Phase 1 Modes, but not their
` intent. When using public keys for authentication, the Phase 1
` exchange can be accomplished either by using signatures or by using
` public key encryption (if the algorithm supports it). Following are
` Phase 1 exchanges with different authentication options.
`
`5.1 IKE Phase 1 Authenticated With Signatures
`
` Using signatures, the ancillary information exchanged during the
` second roundtrip are nonces; the exchange is authenticated by signing
` a mutually obtainable hash. Main Mode with signature authentication
` is described as follows:
`
`Harkins & Carrel Standards Track [Page 10]
`
`

`

`RFC 2409 IKE November 1998
`
` Initiator Responder
` ----------- -----------
` HDR, SA -->
` <-- HDR, SA
` HDR, KE, Ni -->
` <-- HDR, KE, Nr
` HDR*, IDii, [ CERT, ] SIG_I -->
` <-- HDR*, IDir, [ CERT, ] SIG_R
`
` Aggressive mode with signatures in conjunction with ISAKMP is
` described as follows:
`
` Initiator Responder
` ----------- -----------
` HDR, SA, KE, Ni, IDii -->
` <-- HDR, SA, KE, Nr, IDir,
` [ CERT, ] SIG_R
` HDR, [ CERT, ] SIG_I -->
`
` In both modes, the signed data, SIG_I or SIG_R, is the result of the
` negotiated digital signature algorithm applied to HASH_I or HASH_R
` respectively.
`
` In general the signature will be over HASH_I and HASH_R as above
` using the negotiated prf, or the HMAC version of the negotiated hash
` function (if no prf is negotiated). However, this can be overridden
` for construction of the signature if the signature algorithm is tied
` to a particular hash algorithm (e.g. DSS is only defined with SHA’s
` 160 bit output). In this case, the signature will be over HASH_I and
` HASH_R as above, except using the HMAC version of the hash algorithm
` associated with the signature method. The negotiated prf and hash
` function would continue to be used for all other prescribed pseudo-
` random functions.
`
` Since the hash algorithm used is already known there is no need to
` encode its OID into the signature. In addition, there is no binding
` between the OIDs used for RSA signatures in PKCS #1 and those used in
` this document. Therefore, RSA signatures MUST be encoded as a private
` key encryption in PKCS #1 format and not as a signature in PKCS #1
` format (which includes the OID of the hash algorithm). DSS signatures
` MUST be encoded as r followed by s.
`
` One or more certificate payloads MAY be optionally passed.
`
`Harkins & Carrel Standards Track [Page 11]
`
`

`

`RFC 2409 IKE November 1998
`
`5.2 Phase 1 Authenticated With Public Key Encryption
`
` Using public key encryption to authenticate the exchange, the
` ancillary information exchanged is encrypted nonces. Each party’s
` ability to reconstruct a hash (proving that the other party decrypted
` the nonce) authenticates the exchange.
`
` In order to perform the public key encryption, the initiator must
` already have the responder’s public key. In the case where the
` responder has multiple public keys, a hash of the certificate the
` initiator is using to encrypt the ancillary information is passed as
` part of the third message. In this way the responder can determine
` which corresponding private key to use to decrypt the encrypted
` payloads and identity protection is retained.
`
` In addition to the nonce, the identities of the parties (IDii and
` IDir) are also encrypted with the other party’s public key. If the
` authentication method is public key encryption, the nonce and
` identity payloads MUST be encrypted with the public key of the other
` party. Only the body of the payloads are encrypted, the payload
` headers are left in the clear.
`
` When using encryption for authentication, Main Mode is defined as
` follows.
`
` Initiator Responder
` ----------- -----------
` HDR, SA -->
` <-- HDR, SA
` HDR, KE, [ HASH(1), ]
` <IDii_b>PubKey_r,
` <Ni_b>PubKey_r -->
` HDR, KE, <IDir_b>PubKey_i,
` <-- <Nr_b>PubKey_i
` HDR*, HASH_I -->
` <-- HDR*, HASH_R
`
` Aggressive Mode authenticated with encryption is described as
` follows:
`
` Initiator Responder
` ----------- -----------
` HDR, SA, [ HASH(1),] KE,
` <IDii_b>Pubkey_r,
` <Ni_b>Pubkey_r -->
` HDR, SA, KE, <IDir_b>PubKey_i,
` <-- <Nr_b>PubKey_i, HASH_R
` HDR, HASH_I -->
`
`Harkins & Carrel Standards Track [Page 12]
`
`

`

`RFC 2409 IKE November 1998
`
` Where HASH(1) is a hash (using the negotiated hash function) of the
` certificate which the initiator is using to encrypt the nonce and
` identity.
`
` RSA encryption MUST be encoded in PKCS #1 format. While only the body
` of the ID and nonce payloads is encrypted, the encrypted data must be
` preceded by a valid ISAKMP generic header. The payload length is the
` length of the entire encrypted payload plus header. The PKCS #1
` encoding allows for determination of the actual length of the
` cleartext payload upon decryption.
`
` Using encryption for authentication provides for a plausably deniable
` exchange. There is no proof (as with a digital signature) that the
` conversation ever took place since each party can completely
` reconstruct both sides of the exchange. In addition, security is
` added to secret generation since an attacker would have to
` successfully break not only the Diffie-Hellman exchange but also both
` RSA encryptions. This exchange was motivated by [SKEME].
`
` Note that, unlike other authentication methods, authentication with
` public key encryption allows for identity protection with Aggressive
` Mode.
`
`5.3 Phase 1 Authenticated With a Revised Mode of Public Key Encryption
`
` Authentication with Public Key Encryption has significant advantages
` over authentication with signatures (see section 5.2 above).
` Unfortunately, this is at the cost of 4 public key operations-- two
` public key encryptions and two private key decryptions. This
` authentication mode retains the advantages of authentication using
` public key encryption but does so with half the public key
` operations.
`
` In this mode, the nonce is still encrypted using the public key of
` the peer, however the peer’s identity (and the certificate if it is
` sent) is encrypted using the negotiated symmetric encryption
` algorithm (from the SA payload) with a key derived from the nonce.
` This solution adds minimal complexity and state yet saves two costly
` public key operations on each side. In addition, the Key Exchange
` payload is also encrypted using the same derived key. This provides
` additional protection against cryptanalysis of the Diffie-Hellman
` exchange.
`
` As with the public key encryption method of authentication (section
`5.2), a HASH payload may be sent to identify a certificate if the
` responder has multiple certificates which contain useable public keys
` (e.g. if the certificate is not for signatures only, either due to
` certificate restrictions or algorithmic restrictions). If the HASH
`
`Harkins & Carrel Standards Track [Page 13]
`
`

`

`RFC 2409 IKE November 1998
`
` payload is sent it MUST be the first payload of the second message
` exchange and MUST be followed by the encrypted nonce. If the HASH
` payload is not sent, the first payload of the second message exchange
` MUST be the encrypted nonce. In addition, the initiator my optionally
` send a certificate payload to provide the responder with a public key
` with which to respond.
`
` When using the revised encryption mode for authentication, Main Mode
` is defined as follows.
`
` Initiator Responder
` ----------- -----------
` HDR, SA -->
` <-- HDR, SA
` HDR, [ HASH(1), ]
` <Ni_b>Pubkey_r,
` <KE_b>Ke_i,
` <IDii_b>Ke_i,
` [<<Cert-I_b>Ke_i] -->
` HDR, <Nr_b>PubKey_i,
` <KE_b>K