_b indicates the body of payload

-- the ISAKMP
vpayload is not included

SAi_b is the entire body of the SA payload (minus the
generic header)-- i.e. the DOI, situation, all proposals and
transforms offered by the Initiator

CKY-I and CKY-R are the Initiator's cookie and the Responder'
cookie, respectively, from the ISAKMP header

g^xi and g^xr are the Diffie-Hellman ([DH]) public values of
initiator and responder respectively

g^xy is the Diffie-Hellman shared secret

KE is the key exchange payload which contains the
information exchanged in a Diffie-Hellman exchange. There is
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
and responder respectively

IDx is the identification payload for "x". x can be: "ii" or "ir
for the ISAKMP initiator and responder respectively during
one negotiation; or "ui" or "ur" for the user initiator
responder respectively during phase two. The ID payload format
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
payload. The contents of the hash are specific to
authentication method

prf(key, msg) is the keyed pseudo-random function-- often a
hash function-- used to generate a deterministic output
appears pseudo-random. prf's are used both for key derivations
for authentication (i.e. as a keyed MAC). (See [KBC96]).

SKEYID is a string derived from secret material known only to
active players in the exchange

SKEYID_e is the keying material used by the ISAKMP SA to
the confidentiality of its messages

SKEYID_a is the keying material used by the ISAKMP SA
authenticate its messages

SKEYID_d is the keying material used to derive keys for non-
security associations

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
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)
begin immediately after the ISAKMP header. When communication
protected, all payloads following the ISAKMP header MUST
encrypted. Encryption keys are generated from SKEYID_e in a
that is defined for each algorithm

3.3 Perfect Forward

When used in the memo Perfect Forward Secrecy (PFS) refers to
notion that compromise of a single key will permit access to
data protected by a single key. For PFS to exist the key used
protect transmission of data MUST NOT be used to derive
additional keys, and if the key used to protect transmission of
was derived from some other keying material, that material MUST
be used to derive any more keys

Perfect Forward Secrecy for both keys and identities is provided
this protocol. (Sections 5.5 and 8).

3.4 Security

A security association (SA) is a set of policy and key(s) used
protect information. The ISAKMP SA is the shared policy and key(s
used by the negotiating peers in this protocol to protect
communication

4.

Oakley and SKEME each define a method to establish an
key exchange. This includes payloads construction, the
payloads carry, the order in which they are processed and how
are used

While Oakley defines "modes", ISAKMP defines "phases".
relationship between the two is very straightforward and IKE
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
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
services such as IPsec or any other service which needs key
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
phase 1, but serves to establish a new group which can be used
future negotiations. "New Group Mode" MUST ONLY be used after
1.

The ISAKMP SA is bi-directional. That is, once established,
party may initiate Quick Mode, Informational, and New Group
Exchanges. Per the base ISAKMP document, the ISAKMP SA is
by the Initiator's cookie followed by the Responder's cookie--
role of each party in the phase 1 exchange dictates which cookie
the Initiator's. The cookie order established by the phase 1
continues to identify the ISAKMP SA regardless of the direction
Quick Mode, Informational, or New Group exchange. In other words,
cookies MUST NOT swap places when the direction of the ISAKMP
changes

With the use of ISAKMP phases, an implementation can accomplish
fast keying when necessary. A single phase 1 negotiation may be
for more than one phase 2 negotiation. Additionally a single phase 2
negotiation can request multiple Security Associations. With
optimizations, an implementation can see less than one round trip
SA as well as less than one DH exponentiation per SA. "Main Mode
for phase 1 provides identity protection. When identity
is not needed, "Aggressive Mode" can be used to reduce round
even further. Developer hints for doing these optimizations
included below. It should also be noted that using public
encryption to authenticate an Aggressive Mode exchange will
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
implementation MAY choose to restrict use of the ISAKMP SA
establishment of SAs for services of the same DOI. Alternately,
ISAKMP SA MAY be established with the value zero in both the DOI
situation (see [MSST98] for a description of these fields) and
this case implementations will be free to establish security
for any defined DOI using this ISAKMP SA. If a DOI of zero is
for establishment of a phase 1 SA, the syntax of the
payloads used in phase 1 is that defined in [MSST98] and not from
DOI-- e.g. [Pip97]-- which may further expand the syntax
semantics of identities

The following attributes are used by IKE and are negotiated as
of the ISAKMP Security Association. (These attributes pertain
to the ISAKMP Security Association and not to any
Associations that ISAKMP may be negotiating on behalf of
services.)



Harkins & Carrel Standards Track [Page 6]

RFC 2409 IKE November 1998


- encryption

- hash

- authentication

- information about a group over which to do Diffie-Hellman

All of these attributes are mandatory and MUST be negotiated.
addition, it is possible to optionally negotiate a psuedo-
function ("prf"). (There are currently no negotiable pseudo-
functions defined in this document. Private use attribute values
be used for prf negotiation between consenting parties). If a "prf
is not negotiation, the HMAC (see [KBC96]) version of the
hash algorithm is used as a pseudo-random function. Other non
mandatory attributes are described in Appendix A. The selected
algorithm MUST support both native and HMAC modes

The Diffie-Hellman group MUST be either specified using a
group description (section 6) or by defining all attributes of
group (section 5.6). Group attributes (such as group type or prime--
see Appendix A) MUST NOT be offered in conjunction with a
defined group (either a reserved group description or a private
description that is established after conclusion of a New Group
exchange).

IKE implementations MUST support the following attribute values

- DES [DES] in CBC mode with a weak, and semi-weak, key
(weak and semi-weak keys are referenced in [Sch96] and listed
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;
MODP group number 2. IKE implementations MAY support any
encryption algorithms defined in Appendix A and MAY support ECP
EC2N groups

The IKE modes described here MUST be implemented whenever the
IPsec DOI [Pip97] is implemented. Other DOIs MAY use the
described here



Harkins & Carrel Standards Track [Page 7]

RFC 2409 IKE November 1998


5.

There are two basic methods used to establish an authenticated
exchange: Main Mode and Aggressive Mode. Each generates
keying material from an ephemeral Diffie-Hellman exchange. Main
MUST be implemented; Aggressive Mode SHOULD be implemented.
addition, Quick Mode MUST be implemented as a mechanism to
fresh keying material and negotiate non-ISAKMP security services.
addition, New Group Mode SHOULD be implemented as a mechanism
define private groups for Diffie-Hellman exchanges.
MUST NOT switch exchange types in the middle of an exchange

Exchanges conform to standard ISAKMP payload syntax,
encoding, timeouts and retransmits of messages, and
messages-- e.g a notify response is sent when, for example,
proposal is unacceptable, or a signature verification or
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
payloads in any message to be in any particular order

The Diffie-Hellman public value passed in a KE payload, in either
phase 1 or phase 2 exchange, MUST be the length of the
Diffie-Hellman group enforced, if necessary, by pre-pending the
with zeros

The length of nonce payload MUST be between 8 and 256
inclusive

Main Mode is an instantiation of the ISAKMP Identity
Exchange: The first two messages negotiate policy; the next
exchange Diffie-Hellman public values and ancillary data (e.g
nonces) necessary for the exchange; and the last two
authenticate the Diffie-Hellman Exchange. The authentication
negotiated as part of the initial ISAKMP exchange influences
composition of the payloads but not their purpose. The XCHG for
Mode is ISAKMP Identity Protect

Similarly, Aggressive Mode is an instantiation of the
Aggressive Exchange. The first two messages negotiate policy
exchange Diffie-Hellman public values and ancillary data
for the exchange, and identities. In addition the second
authenticates the responder. The third message authenticates
initiator and provides a proof of participation in the exchange.
XCHG for Aggressive Mode is ISAKMP Aggressive. The final message
NOT be sent under protection of the ISAKMP SA allowing each party




Harkins & Carrel Standards Track [Page 8]

RFC 2409 IKE November 1998


postpone exponentiation, if desired, until negotiation of
exchange is complete. The graphic depictions of Aggressive Mode
the final payload in the clear; it need not be

Exchanges in IKE are not open ended and have a fixed number
messages. Receipt of a Certificate Request payload MUST NOT
the number of messages transmitted or expected

Security Association negotiation is limited with Aggressive Mode.
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
negotiation. For example, authentication with public key
cannot be negotiated and when using the revised method of public
encryption for authentication the cipher and hash cannot
negotiated. For situations where the rich attribute
capabilities of IKE are required Main Mode may be required

Quick Mode and New Group Mode have no analog in ISAKMP. The
values for Quick Mode and New Group Mode are defined in Appendix A

Main Mode, Aggressive Mode, and Quick Mode do security
negotiation. Security Association offers take the form of
Payload(s) encapsulated in Proposal Payload(s) encapsulated
Security Association (SA) payload(s). If multiple offers are
made for phase 1 exchanges (Main Mode and Aggressive Mode) they
take the form of multiple Transform Payloads for a single
Payload in a single SA payload. To put it another way, for phase 1
exchanges there MUST NOT be multiple Proposal Payloads for a
SA payload and there MUST NOT be multiple SA payloads. This
does not proscribe such behavior on offers in phase 2 exchanges

There is no limit on the number of offers the initiator may send
the responder but conformant implementations MAY choose to limit
number of offers it will inspect for performance reasons

During security association negotiation, initiators present
for potential security associations to responders. Responders
NOT modify attributes of any offer, attribute encoding excepted (
Appendix A). If the initiator of an exchange notices that
values have changed or attributes have been added or deleted from
offer made, that response MUST be rejected

Four different authentication methods are allowed with either
Mode or Aggressive Mode-- digital signature, two forms
authentication with public key encryption, or pre-shared key.
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
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
of 0, 1, and 2 above are represented by a single octet. The key
for encryption is derived from SKEYID_e in an algorithm-
manner (see appendix B).

To authenticate either exchange the initiator of the
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
signed and verified; for authentication with either public
encryption or pre-shared keys, HASH_I and HASH_R
authenticate the exchange. The entire ID payload (including ID type
port, and protocol but excluding the generic header) is hashed
both HASH_I and HASH_R

As mentioned above, the negotiated authentication method
the content and use of messages for Phase 1 Modes, but not
intent. When using public keys for authentication, the Phase 1
exchange can be accomplished either by using signatures or by
public key encryption (if the algorithm supports it). Following
Phase 1 exchanges with different authentication options

5.1 IKE Phase 1 Authenticated With

Using signatures, the ancillary information exchanged during
second roundtrip are nonces; the exchange is authenticated by
a mutually obtainable hash. Main Mode with signature
is described as follows







Harkins & Carrel Standards Track [Page 10]

RFC 2409 IKE November 1998


Initiator
----------- -----------
HDR, SA -->
<-- HDR,
HDR, KE, Ni -->
<-- HDR, KE,
HDR*, IDii, [ CERT, ] SIG_I -->
<-- HDR*, IDir, [ CERT, ] SIG_

Aggressive mode with signatures in conjunction with ISAKMP
described as follows

Initiator
----------- -----------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir
[ CERT, ] SIG_
HDR, [ CERT, ] SIG_I -->

In both modes, the signed data, SIG_I or SIG_R, is the result of
negotiated digital signature algorithm applied to HASH_I or HASH_
respectively

In general the signature will be over HASH_I and HASH_R as
using the negotiated prf, or the HMAC version of the negotiated
function (if no prf is negotiated). However, this can be
for construction of the signature if the signature algorithm is
to a particular hash algorithm (e.g. DSS is only defined with SHA'
160 bit output). In this case, the signature will be over HASH_I
HASH_R as above, except using the HMAC version of the hash
associated with the signature method. The negotiated prf and
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
encode its OID into the signature. In addition, there is no
between the OIDs used for RSA signatures in PKCS #1 and those used
this document. Therefore, RSA signatures MUST be encoded as a
key encryption in PKCS #1 format and not as a signature in PKCS #1
format (which includes the OID of the hash algorithm). DSS
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

Using public key encryption to authenticate the exchange,
ancillary information exchanged is encrypted nonces. Each party'
ability to reconstruct a hash (proving that the other party
the nonce) authenticates the exchange

In order to perform the public key encryption, the initiator
already have the responder's public key. In the case where
responder has multiple public keys, a hash of the certificate
initiator is using to encrypt the ancillary information is passed
part of the third message. In this way the responder can
which corresponding private key to use to decrypt the
payloads and identity protection is retained

In addition to the nonce, the identities of the parties (IDii
IDir) are also encrypted with the other party's public key. If
authentication method is public key encryption, the nonce
identity payloads MUST be encrypted with the public key of the
party. Only the body of the payloads are encrypted, the
headers are left in the clear

When using encryption for authentication, Main Mode is defined
follows

Initiator
----------- -----------
HDR, SA -->
<-- HDR,
HDR, KE, [ HASH(1), ]
PubKey_r
PubKey_r -->
HDR, KE, PubKey_i
<-- PubKey_
HDR*, HASH_I -->
<-- HDR*, HASH_

Aggressive Mode authenticated with encryption is described
follows

Initiator
----------- -----------
HDR, SA, [ HASH(1),] KE
Pubkey_r
Pubkey_r -->
HDR, SA, KE, PubKey_i
<-- PubKey_i, HASH_
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
certificate which the initiator is using to encrypt the nonce
identity

RSA encryption MUST be encoded in PKCS #1 format. While only the
of the ID and nonce payloads is encrypted, the encrypted data must
preceded by a valid ISAKMP generic header. The payload length is
length of the entire encrypted payload plus header. The PKCS #1
encoding allows for determination of the actual length of
cleartext payload upon decryption

Using encryption for authentication provides for a plausably
exchange. There is no proof (as with a digital signature) that
conversation ever took place since each party can
reconstruct both sides of the exchange. In addition, security
added to secret generation since an attacker would have
successfully break not only the Diffie-Hellman exchange but also
RSA encryptions. This exchange was motivated by [SKEME].

Note that, unlike other authentication methods, authentication
public key encryption allows for identity protection with
Mode

5.3 Phase 1 Authenticated With a Revised Mode of Public Key

Authentication with Public Key Encryption has significant
over authentication with signatures (see section 5.2 above).
Unfortunately, this is at the cost of 4 public key operations--
public key encryptions and two private key decryptions.
authentication mode retains the advantages of authentication
public key encryption but does so with half the public
operations

In this mode, the nonce is still encrypted using the public key
the peer, however the peer's identity (and the certificate if it
sent) is encrypted using the negotiated symmetric
algorithm (from the SA payload) with a key derived from the nonce
This solution adds minimal complexity and state yet saves two
public key operations on each side. In addition, the Key
payload is also encrypted using the same derived key. This
additional protection against cryptanalysis of the Diffie-
exchange

As with the public key encryption method of authentication (
5.2), a HASH payload may be sent to identify a certificate if
responder has multiple certificates which contain useable public
(e.g. if the certificate is not for signatures only, either due
certificate restrictions or algorithmic restrictions). If the



Harkins & Carrel Standards Track [Page 13]

RFC 2409 IKE November 1998


payload is sent it MUST be the first payload of the second
exchange and MUST be followed by the encrypted nonce. If the
payload is not sent, the first payload of the second message
MUST be the encrypted nonce. In addition, the initiator my
send a certificate payload to provide the responder with a public
with which to respond

When using the revised encryption mode for authentication, Main
is defined as follows

Initiator
----------- -----------
HDR, SA -->
<-- HDR,
HDR, [ HASH(1), ]
Pubkey_r
Ke_i
Ke_i
[<Ke_i] -->
HDR, PubKey_i
Ke_r
<-- Ke_r
HDR*, HASH_I -->
<-- HDR*, HASH_

Aggressive Mode authenticated with the revised encryption method
described as follows

Initiator
----------- -----------
HDR, SA, [ HASH(1),]
Pubkey_r
Ke_i, Ke_
[, Ke_i ] -->
HDR, SA, PubKey_i
Ke_r, Ke_r
<-- HASH_
HDR, HASH_I -->

where HASH(1) is identical to section 5.2. Ke_i and Ke_r are keys
the symmetric encryption algorithm negotiated in the SA
exchange. Only the body of the payloads are encrypted (in both
key and symmetric operations), the generic payload headers are
in the clear. The payload length includes that added to
encryption

The symmetric cipher keys are derived from the decrypted nonces
follows. First the values Ne_i and Ne_r are computed



Harkins & Carrel Standards Track [Page 14]

RFC 2409 IKE November 1998


Ne_i = prf(Ni_b, CKY-I
Ne_r = prf(Nr_b, CKY-R

The keys Ke_i and Ke_r are then taken from Ne_i and Ne_r
in the manner described in Appendix B used to derive symmetric
for use with the negotiated encryption algorithm. If the length
the output of the negotiated prf is greater than or equal to the
length requirements of the cipher, Ke_i and Ke_r are derived from
most significant bits of Ne_i and Ne_r respectively. If the
length of Ke_i and Ke_r exceed the length of the output of the
the necessary number of bits is obtained by repeatedly feeding
results of the prf back into itself and concatenating the
until the necessary number has been achieved. For example, if
negotiated encryption algorithm requires 320 bits of key and
output of the prf is only 128 bits, Ke_i is the most significant 320
bits of K,

K = K1 | K2 | K3
K1 = prf(Ne_i, 0)
K2 = prf(Ne_i, K1)
K3 = prf(Ne_i, K2)

For brevity, only derivation of Ke_i is shown; Ke_r is identical.
length of the value 0 in the computation of K1 is a single octet
Note that Ne_i, Ne_r, Ke_i, and Ke_r are all ephemeral and MUST
discarded after use

Save the requirements on the location of the optional HASH
and the mandatory nonce payload there are no further
requirements. All payloads-- in whatever order-- following
encrypted nonce MUST be encrypted with Ke_i or Ke_r depending on
direction

If CBC mode is used for the symmetric encryption then
initialization vectors (IVs) are set as follows. The IV
encrypting the first payload following the nonce is set to 0 (zero).
The IV for subsequent payloads encrypted with the ephemeral
cipher key, Ke_i, is the last ciphertext block of the
payload. Encrypted payloads are padded up to the nearest block size
All padding bytes, except for the last one, contain 0x00. The
byte of the padding contains the number of the padding bytes used
excluding the last one. Note that this means there will always
padding








Harkins & Carrel Standards Track [Page 15]

RFC 2409 IKE November 1998


5.4 Phase 1 Authenticated With a Pre-Shared

A key derived by some out-of-band mechanism may also be used
authenticate the exchange. The actual establishment of this key
out of the scope of this document

When doing a pre-shared key authentication, Main Mode is defined
follows

Initiator
---------- -----------
HDR, SA -->
<-- HDR,
HDR, KE, Ni -->
<-- HDR, KE,
HDR*, IDii, HASH_I -->
<-- HDR*, IDir, HASH_

Aggressive mode with a pre-shared key is described as follows

Initiator
----------- -----------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir, HASH_
HDR, HASH_I -->

When using pre-shared key authentication with Main Mode the key
only be identified by the IP address of the peers since HASH_I
be computed before the initiator has processed IDir. Aggressive
allows for a wider range of identifiers of the pre-shared secret
be used. In addition, Aggressive Mode allows two parties to
multiple, different pre-shared keys and identify the correct one
a particular exchange

5.5 Phase 2 - Quick

Quick Mode is not a complete exchange itself (in that it is bound
a phase 1 exchange), but is used as part of the SA
process (phase 2) to derive keying material and negotiate
policy for non-ISAKMP SAs. The information exchanged along with
Mode MUST be protected by the ISAKMP SA-- i.e. all payloads
the ISAKMP header are encrypted. In Quick Mode, a HASH payload
immediately follow the ISAKMP header and a SA payload
immediately follow the HASH. This HASH authenticates the message
also provides liveliness proofs






Harkins & Carrel Standards Track [Page 16]

RFC 2409 IKE November 1998


The message ID in the ISAKMP header identifies a Quick Mode
progress for a particular ISAKMP SA which itself is identified by
cookies in the ISAKMP header. Since each instance of a Quick
uses a unique initialization vector (see Appendix B) it is
to have multiple simultaneous Quick Modes, based off a single
SA, in progress at any one time

Quick Mode is essentially a SA negotiation and an exchange of
that provides replay protection. The nonces are used to
fresh key material and prevent replay attacks from generating
security associations. An optional Key Exchange payload can
exchanged to allow for an additional Diffie-Hellman exchange
exponentiation per Quick Mode. While use of the key exchange
with Quick Mode is optional it MUST be supported

Base Quick Mode (without the KE payload) refreshes the
material derived from the exponentiation in phase 1. This does
provide PFS. Using the optional KE payload, an
exponentiation is performed and PFS is provided for the
material

The identities of the SAs negotiated in Quick Mode are
assumed to be the IP addresses of the ISAKMP peers, without
implied constraints on the protocol or port numbers allowed,
client identifiers are specified in Quick Mode. If ISAKMP is
as a client negotiator on behalf of another party, the identities
the parties MUST be passed as IDci and then IDcr. Local policy
dictate whether the proposals are acceptable for the
specified. If the client identities are not acceptable to the
Mode responder (due to policy or other reasons), a Notify
with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent

The client identities are used to identify and direct traffic to
appropriate tunnel in cases where multiple tunnels exist between
peers and also to allow for unique and shared SAs with
granularities

All offers made during a Quick Mode are logically related and must
consistant. For example, if a KE payload is sent, the
describing the Diffie-Hellman group (see section 6.1 and [Pip97])
MUST be included in every transform of every proposal of every
being negotiated. Similarly, if client identities are used, they
apply to every SA in the negotiation

Quick Mode is defined as follows






Harkins & Carrel Standards Track [Page 17]

RFC 2409 IKE November 1998


Initiator
----------- -----------
HDR*, HASH(1), SA,
[, KE ] [, IDci, IDcr ] -->
<-- HDR*, HASH(2), SA,
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) -->

Where
HASH(1) is the prf over the message id (M-ID) from the ISAKMP
concatenated with the entire message that follows the hash
all payload headers, but excluding any padding added for encryption
HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni
minus the payload header-- is added after M-ID but before
complete message. The addition of the nonce to HASH(2) is for
liveliness proof. HASH(3)-- for liveliness-- is the prf over
value zero represented as a single octet, followed by a
of the message id and the two nonces-- the initiator's followed
the responder's-- minus the payload header. In other words,
hashes for the above exchange are

HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci |
IDcr )
HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b

With the exception of the HASH, SA, and the optional ID payloads
there are no payload ordering restrictions on Quick Mode. HASH(1)
HASH(2) may differ from the illustration above if the order
payloads in the message differs from the illustrative example or
any optional payloads, for example a notify payload, have
chained to the message

If PFS is not needed, and KE payloads are not exchanged, the
keying material is defined

KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b).

If PFS is desired and KE payloads were exchanged, the new
material is defined

KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b

where g(qm)^xy is the shared secret from the ephemeral Diffie-
exchange of this Quick Mode

In either case, "protocol" and "SPI" are from the ISAKMP
Payload that contained the negotiated Transform



Harkins & Carrel Standards Track [Page 18]

RFC 2409 IKE November 1998


A single SA negotiation results in two security assocations--
inbound and one outbound. Different SPIs for each SA (one chosen
the initiator, the other by the responder) guarantee a different
for each direction. The SPI chosen by the destination of the SA
used to derive KEYMAT for that SA

For situations where the amount of keying material desired is
than that supplied by the prf, KEYMAT is expanded by feeding
results of the prf back into itself and concatenating results
the required keying material has been reached. In other words

KEYMAT = K1 | K2 | K3 | ...

K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b
K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b |
Nr_b
K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b |
Nr_b
etc

This keying material (whether with PFS or without, and
derived directly or through concatenation) MUST be used with
negotiated SA. It is up to the service to define how keys are
from the keying material

In the case of an ephemeral Diffie-Hellman exchange in Quick Mode
the exponential (g(qm)^xy) is irretreivably removed from the
state and SKEYID_e and SKEYID_a (derived from phase 1 negotiation
continue to protect and authenticate the ISAKMP SA and SKEYID_
continues to be used to derive keys

Using Quick Mode, multiple SA's and keys can be negotiated with
exchange as follows

Initiator
----------- -----------
HDR*, HASH(1), SA0, SA1, Ni
[, KE ] [, IDci, IDcr ] -->
<-- HDR*, HASH(2), SA0, SA1, Nr
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) -->

The keying material is derived identically as in the case of a
SA. In this case (negotiation of two SA payloads) the result would
four security associations-- two each way for both SAs






Harkins & Carrel Standards Track [Page 19]

RFC 2409 IKE November 1998


5.6 New Group

New Group Mode MUST NOT be used prior to establishment of an
SA. The description of a new group MUST only follow phase 1
negotiation. (It is not a phase 2 exchange, though).

Initiator
----------- -----------
HDR*, HASH(1), SA -->
<-- HDR*, HASH(2),

where HASH(1) is the prf output, using SKEYID_a as the key, and
message-ID from the ISAKMP header concatenated with the entire
proposal, body and header, as the data; HASH(2) is the prf output
using SKEYID_a as the key, and the message-ID from the ISAKMP
concatenated with the reply as the data. In other words the
for the above exchange are

HASH(1) = prf(SKEYID_a, M-ID | SA
HASH(2) = prf(SKEYID_a, M-ID | SA

The proposal will specify the characteristics of the group (
appendix A, "Attribute Assigned Numbers"). Group descriptions
private Groups MUST be greater than or equal to 2^15. If the
is not acceptable, the responder MUST reply with a Notify
with the message type set to ATTRIBUTES-NOT-SUPPORTED (13).

ISAKMP implementations MAY require private groups to expire with
SA under which they were established

Groups may be directly negotiated in the SA proposal with Main Mode
To do this the component parts-- for a MODP group, the type,
and generator; for a EC2N group the type, the Irreducible Polynomial
Group Generator One, Group Generator Two, Group Curve A, Group
B and Group Order-- are passed as SA attributes (see Appendix A).
Alternately, the nature of the group can be hidden using New
Mode and only the group identifier is passed in the clear
phase 1 negotiation

5.7 ISAKMP Informational

This protocol protects ISAKMP Informational Exchanges when possible
Once the ISAKMP security association has been established (
SKEYID_e and SKEYID_a have been generated) ISAKMP
Exchanges, when used with this protocol, are as follows






Harkins & Carrel Standards Track [Page 20]

RFC 2409 IKE November 1998


Initiator
----------- -----------
HDR*, HASH(1), N/D -->

where N/D is either an ISAKMP Notify Payload or an ISAKMP
Payload and HASH(1) is the prf output, using SKEYID_a as the key,
a M-ID unique to this exchange concatenated with the
informational payload (either a Notify or Delete) as the data.
other words, the hash for the above exchange is

HASH(1) = prf(SKEYID_a, M-ID | N/D

As noted the message ID in the ISAKMP header-- and used in the
computation-- is unique to this exchange and MUST NOT be the same
the message ID of another phase 2 exchange which generated
informational exchange. The derivation of the initialization vector
used with SKEYID_e to encrypt this message, is described in
B

If the ISAKMP security association has not yet been established
the time of the Informational Exchange, the exchange is done in
clear without an accompanying HASH payload

6 Oakley

With IKE, the group in which to do the Diffie-Hellman exchange
negotiated. Four groups-- values 1 through 4-- are defined below
These groups originated with the Oakley protocol and are
called "Oakley Groups". The attribute class for "Group" is defined
Appendix A. All values 2^15 and higher are used for private
identifiers. For a discussion on the strength of the default
groups please see the Security Considerations section below

These groups were all generated by Richard Schroeppel at
University of Arizona. Properties of these groups are described
[Orm96].

6.1 First Oakley Default

Oakley implementations MUST support a MODP group with the
prime and generator. This group is assigned id 1 (one).

The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }
Its hexadecimal value







Harkins & Carrel Standards Track [Page 21]

RFC 2409 IKE November 1998


FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF

The generator is: 2.

6.2 Second Oakley

IKE implementations SHOULD support a MODP group with the
prime and generator. This group is assigned id 2 (two).

The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its hexadecimal value

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF

The generator is 2 (decimal

6.3 Third Oakley

IKE implementations SHOULD support a EC2N group with the
characteristics. This group is assigned id 3 (three). The curve
based on the Galois Field GF[2^155]. The field size is 155.
irreducible polynomial for the field is
u^155 + u^62 + 1.
The equation for the elliptic curve is
y^2 + xy = x^3 + ax^2 + b

Field Size: 155
Group Prime/Irreducible Polynomial
0x0800000000000000000000004000000000000001
Group Generator One: 0x7
Group Curve A: 0x
Group Curve B: 0x07338

Group Order: 0X0800000000000000000057db5698537193aef944

The data in the KE payload when using this group is the value x
the solution (x,y), the point on the curve chosen by taking
randomly chosen secret Ka and computing Ka*P, where * is
repetition of the group addition and double operations, P is
curve point with x coordinate equal to generator 1 and the



Harkins & Carrel Standards Track [Page 22]

RFC 2409 IKE November 1998


coordinate determined from the defining equation. The equation
curve is implicitly known by the Group Type and the A and
coefficients. There are two possible values for the y coordinate
either one can be used successfully (the two parties need not
on the selection).

6.4 Fourth Oakley

IKE implementations SHOULD support a EC2N group with the
characteristics. This group is assigned id 4 (four). The curve
based on the Galois Field GF[2^185]. The field size is 185.
irreducible polynomial for the field is
u^185 + u^69 + 1.
equation for the elliptic curve is
y^2 + xy = x^3 + ax^2 + b

Field Size: 185
Group Prime/Irreducible Polynomial
0x020000000000000000000000000000200000000000000001
Group Generator One: 0x18
Group Curve A: 0x
Group Curve B: 0x1ee

Group Order: 0X01ffffffffffffffffffffffdbf2f889b73e484175f94

The data in the KE payload when using this group will be identical
that as when using Oakley Group 3 (three).

Other groups can be defined using New Group Mode. These
groups were generated by Richard Schroeppel at the University
Arizona. Properties of these primes are described in [Orm96].

7. Payload Explosion for a Complete IKE

This section illustrates how the IKE protocol is used to

- establish a secure and authenticated channel between
processes (phase 1);

- generate key material for, and negotiate, an IPsec SA (phase 2).

7.1 Phase 1 using Main

The following diagram illustrates the payloads exchanged between
two parties in the first round trip exchange. The initiator
propose several proposals; the responder MUST reply with one





Harkins & Carrel Standards Track [Page 23]

RFC 2409 IKE November 1998


0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_SA ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_TRANS ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #1 ! KEY_OAKLEY | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ prefered SA attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #2 ! KEY_OAKLEY | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ alternate SA attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The responder replies in kind but selects, and returns, one
proposal (the ISAKMP SA attributes).

The second exchange consists of the following payloads

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_KE ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_NONCE ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ D-H Public Value (g^xi from initiator g^xr from responder) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ni (from initiator) or Nr (from responder) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Harkins & Carrel Standards Track [Page 24]

RFC 2409 IKE November 1998


The shared keys, SKEYID_e and SKEYID_a, are now used to protect
authenticate all further communication. Note that both SKEYID_e
SKEYID_a are unauthenticated

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Main Mode, ~
~ and Next Payload of ISA_ID and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_SIG ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data of the ISAKMP negotiator ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ signature verified by the public key of the ID above ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The key exchange is authenticated over a signed hash as described
section 5.1. Once the signature has been verified using
authentication algorithm negotiated as part of the ISAKMP SA,
shared keys, SKEYID_e and SKEYID_a can be marked as authenticated
(For brevity, certificate payloads were not exchanged).

7.2 Phase 2 using Quick

The following payloads are exchanged in the first round of Quick
with ISAKMP SA negotiation. In this hypothetical exchange, the
negotiators are proxies for other parties which have
authentication

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Quick Mode, ~
~ Next Payload of ISA_HASH and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_SA ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ keyed hash of message ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_NONCE ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain Of Interpretation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Harkins & Carrel Standards Track [Page 25]

RFC 2409 IKE November 1998


! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (4 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_TRANS ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #1 ! AH_SHA | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! other SA attributes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform #2 ! AH_MD5 | RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! other SA attributes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_ID ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ISA_ID ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ID of source for which ISAKMP is a client ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ID of destination for which ISAKMP is a client ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where the contents of the hash are described in 5.5 above.
responder replies with a similar message which only contains
transform-- the selected AH transform. Upon receipt, the
can provide the key engine with the negotiated security
and the keying material. As a check against replay attacks,
responder waits until receipt of the next message

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ISAKMP Header with XCHG of Quick Mode, ~
~ Next Payload of ISA_HASH and the encryption bit set ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ hash data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where the contents of the hash are described in 5.5 above




Harkins & Carrel Standards Track [Page 26]

RFC 2409 IKE November 1998


8. Perfect Forward Secrecy

This protocol can provide PFS of both keys and identities.
identies of both the ISAKMP negotiating peer and, if applicable,
identities for whom the peers are negotiating can be protected
PFS

To provide Perfect Forward Secrecy of both keys and all identities
two parties would perform the following

o A Main Mode Exchange to protect the identities of the
peers
This establishes an ISAKMP SA
o A Quick Mode Exchange to negotiate other security
protection
This establishes a SA on each end for this protocol
o Delete the ISAKMP SA and its associated state

Since the key for use in the non-ISAKMP SA was derived from
single ephemeral Diffie-Hellman exchange PFS is preserved

To provide Perfect Forward Secrecy of merely the keys of a non-
security association, it in not necessary to do a phase 1 exchange
an ISAKMP SA exists between the two peers. A single Quick Mode
which the optional KE payload is passed, and an additional Diffie
Hellman exchange is performed, is all that is required. At this
the state derived from this Quick Mode must be deleted from
ISAKMP SA as described in section 5.5.

9. Implementation

Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2
negotiations extremely quick. As long as the Phase 1 state
cached, and PFS is not needed, Phase 2 can proceed without
exponentiation. How many Phase 2 negotiations can be performed for
single Phase 1 is a local policy issue. The decision will depend
the strength of the algorithms being used and level of trust in
peer system

An implementation may wish to negotiate a range of SAs
performing Quick Mode. By doing this they can speed up the "re
keying". Quick Mode defines how KEYMAT is defined for a range of SAs
When one peer feels it is time to change SAs they simply use the
one within the stated range. A range of SAs can be established
negotiating multiple SAs (identical attributes, different SPIs)
one Quick Mode





Harkins & Carrel Standards Track [Page 27]

RFC 2409 IKE November 1998


An optimization that is often useful is to establish
Associations with peers before they are needed so that when
become needed they are already in place. This ensures there would
no delays due to key management before initial data transmission
This optimization is easily implemented by setting up more than
Security Association with a peer for each requested
Association and caching those not immediately used

Also, if an ISAKMP implementation is alerted that a SA will soon
needed (e.g. to replace an existing SA that will expire in the
future), then it can establish the new SA before that new SA
needed

The base ISAKMP specification describes conditions in which one
of the protocol may inform the other party of some activity--
deletion of a security association or in response to some error
the protocol such as a signature verification failed or a
failed to decrypt. It is strongly suggested that these
exchanges not be responded to under any circumstances. Such
condition may result in a "notify war" in which failure to
a message results in a notify to the peer who cannot understand
and sends his own notify back which is also not understood

10. Security

This entire memo discusses a hybrid protocol, combining parts
Oakley and parts of SKEME with ISAKMP, to negotiate, and
keying material for, security associations in a secure
authenticated manner

Confidentiality is assured by the use of a negotiated
algorithm. Authentication is assured by the use of a
method: a digital signature algorithm; a public key algorithm
supports encryption; or, a pre-shared key. The confidentiality
authentication of this exchange is only as good as the
negotiated as part of the ISAKMP security association

Repeated re-keying using Quick Mode can consume the entropy of
Diffie-Hellman shared secret. Implementors should take note of
fact and set a limit on Quick Mode Exchanges between exponentiations
This memo does not prescribe such a limit

Perfect Forward Secrecy (PFS) of both keying material and
is possible with this protocol. By specifying a Diffie-Hellman group
and passing public values in KE payloads, ISAKMP peers can
PFS of keys-- the identities would be protected by SKEYID_e from
ISAKMP SA and would therefore not be protected by PFS. If PFS of
keying material and identities is desired, an ISAKMP peer



Harkins & Carrel Standards Track [Page 28]

RFC 2409 IKE November 1998


establish only one non-ISAKMP security association (e.g.
Security Association) per ISAKMP SA. PFS for keys and identities
accomplished by deleting the ISAKMP SA (and optionally issuing
DELETE message) upon establishment of the single non-ISAKMP SA.
this way a phase one negotiation is uniquely tied to a single
two negotiation, and the ISAKMP SA established during phase
negotiation is never used again

The strength of a key derived from a Diffie-Hellman exchange
any of the groups defined here depends on the inherent strength
the group, the size of the exponent used, and the entropy provided
the random number generator used. Due to these inputs it is
to determine the strength of a key for any of the defined groups.
default Diffie-Hellman group (number one) when used with a
random number