WDIFF

draft-ietf-ipsec-ikev2-02.txt --> draft-ietf-ipsec-ikev2-03.txt

IPSEC Working Group Dan Harkins
INTERNET-DRAFT Charlie Kaufman
Steve Kent
Tero Kivinen
Radia Perlman
editors
draft-ietf-ipsec-ikev2-02.txt April
INTERNET-DRAFT editor
draft-ietf-ipsec-ikev2-03.txt October 2002

Proposal for the IKEv2

Internet Key Exchange (IKEv2) Protocol
<draft-ietf-ipsec-ikev2-02.txt>
<draft-ietf-ipsec-ikev2-03.txt>

Status of this Memo

This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and working groups. Note that other groups may also distribute
working documents as Internet Drafts.

Internet Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as "work in progress."

The list of

To learn the current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list status of Internet-Draft any Internet Draft, please check the
"1id-abstracts.txt" listing contained in the Internet Drafts Shadow
Directories can be accessed at
http://www.ietf.org/shadow.html on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Australia), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

This document describes version 2 of the IKE (Internet Key Exchange)
protocol. IKE performs mutual authentication and establishes an IKE
security association that can be used to efficiently establish SAs
for ESP, AH and/or IPcomp. This version greatly simplifies IKE by
replacing the 8 possible phase 1 exchanges with a single exchange
based on either public signature keys or shared secret keys. The
single exchange provides identity hiding, yet works in 2 round trips
(all the identity hiding exchanges in IKE v1 required 3 round trips).
Latency of setup of an IPsec SA is further reduced from IKEv1 by
allowing setup of an SA for ESP, AH, and/or IPcomp to be piggybacked
on the initial IKE exchange. It also improves security by allowing
the Responder to be stateless until it can be assured that the
Initiator can receive at the claimed IP source address. This version

Harkins Kaufman Kent Kivinen Perlman [Page 1]

INTERNET DRAFT April 2002
also presents the entire protocol in a single self-contained
document, in contrast to IKEv1, in which the protocol was described
in ISAKMP (RFC 2408), IKE (RFC 2409), and the DOI (RFC 2407)
documents.

IKEv2 [Page 1]

INTERNET DRAFT October 2002

Table of Contents

1. Introduction..............................................3
1.1

Abstract.....................................................1
1 Summary of Changes from IKEv1..............................3
2 Requirements Terminology...................................4
3 IKE Protocol Overview......................................4
3.1 The Initial (Phase 1) Exchange...........................6
3.2 The CREATE_CHILD_SA (Phase 2) Exchange...................7
3.3 Informational (Phase 2) Exchange.........................9
4 IKE Protocol.........................................3
1.2 Change History...........................................4
1.3 Requirements Terminology.................................7
2 Protocol Overview..........................................7
2.1 Details and Variations.......................10
4.1 Use of Retransmission Timers.............................8
2.2 Timers............................10
4.2 Use of Sequence Numbers for Message ID...................8
2.3 ID..................11
4.3 Window Size for overlapping requests.....................9
2.4 requests....................12
4.4 State Synchronization and Connection Timeouts............9
2.5 Timeouts...........12
4.5 Version Numbers and Forward Compatibility................11
2.6 Cookies..................................................12
2.7 Compatibility...............14
4.6 Cookies.................................................15
4.7 Cryptographic Algorithm Negotiation......................16
2.8 Rekeying.................................................17
2.9 Negotiation.....................18
4.8 Rekeying................................................19
4.9 Traffic Selector Negotiation.............................18
2.10 Nonces..................................................18
2.11 Negotiation............................20
4.10 Nonces.................................................21
4.11 Address and Port Agility................................19
2.12 Agility...............................22
4.12 Reuse of Diffie-Hellman Exponentials....................19
3 The Phase 1 Exchange.......................................20
3.1 Exponentials...................22
4.13 Generating Keying Material.............................23
4.14 Generating Keying Material for the IKE-SA................21
3.2 IKE-SA..............23
4.15 Authentication of the IKE-SA.............................22
4 The CREATE-CHILD-SA (Phase 2) Exchange.....................23
4.1 Generating Keying Material for Child-SAs.................24
4.2 IKE-SA...........................24
4.16 Generating Keying Material for Child-SAs...............25
4.17 Rekaying IKE-SAs during rollover...25
5 Informational (Phase 2) Exchange...........................26
6 using a CREATE_CHILD_SA exchange......26
4.18 Error Handling.............................................27
7 Handling.........................................26
5 Header and Payload Formats.................................28
7.1 Formats................................27
5.1 The IKE Header...........................................28
7.2 Header..........................................27
5.2 Generic Payload Header...................................30
7.3 Header..................................30
5.3 Security Association Payload.............................32
7.3.1 Payload............................31
5.3.1 Proposal Substructure..................................34
7.3.2 Transform Substructure.................................36
7.3.3 Mandatory Transform Types..............................39
7.3.4 Mandatory Transform-IDs................................39
7.3.5 Transform Attributes...................................40
7.3.6 Attribute Negotiation..................................41
7.4 Substructure.................................32
5.4 Key Exchange Payload.....................................41
7.5 Payload....................................33
5.5 Identification Payload...................................42
7.6 Payload..................................34
5.6 Certificate Payload......................................44
7.7 Payload.....................................36
5.7 Certificate Request Payload..............................45

Harkins Kaufman Kent Kivinen Perlman [Page 2]

INTERNET DRAFT April 2002

7.8 Payload.............................37
5.8 Authentication Payload...................................46
7.9 Payload..................................38
5.9 Nonce Payload............................................47
7.10 Payload...........................................39
5.10 Notify Payload..........................................48
7.10.1 Payload.........................................40
5.10.1 Notify Message Types..................................49
7.11 Types.................................41
5.11 Delete Payload..........................................53
7.12 Payload.........................................43
5.12 Vendor ID Payload.......................................54
7.13 Payload......................................45
5.13 Traffic Selector Payload................................55
7.13.1 Payload...............................46
5.13.1 Traffic Selector Substructure.........................56
7.14 Selector.....................................46
5.14 Encrypted Payload......................................48
5.15 Other Payload types.....................................58 types....................................49

IKEv2 [Page 2]

INTERNET DRAFT October 2002

6 Conformance Requirements..................................50
7 Security Considerations...................................50
8 Diffie-Hellman Groups......................................58 IANA Considerations.......................................51
9 Security Considerations....................................60 Acknowledgements..........................................52
10 IANA Considerations.......................................61
10.1 Transform Types and Attribute Values....................61
10.2 Exchange Types..........................................59
10.3 Payload Types...........................................63
11 Acknowledgements..........................................63
12 References................................................63
Appendix A: Attribute Assigned Numbers.......................66 References...............................................52
Appendix B: Cryptographic Protection Diffie-Hellman Groups...........................55
Change History..............................................58
Author's Address............................................59

1 Summary of IKE Data.............68
Authors' Addresses...........................................70

1. Introduction

IP Security (IPsec) provides confidentiality, data integrity, and
data source authentication to IP datagrams. These services are
provided by maintaining shared state between the source and the sink changes from IKEv1

The goals of an IP datagram. This state defines, among other things, the
specific services provided to the datagram, which cryptographic
algorithms will be used to provide the services, and the keys used as
input this revision to IKE are:

1) To define the cryptographic algorithms.

Establishing this shared state in a manual fashion does not scale
well. Therefore a entire IKE protocol to establish this state dynamically is
needed. This memo describes such in a protocol-- the Internet Key
Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was
defined in RFCs 2407, 2408, and 2409. This single document is
intended to replace all document, rather
than three of those RFCs.

1.1 The IKE Protocol

IKE performs mutual authentication between two parties and
establishes an IKE security association that includes shared secret
information that can be used to efficiently establish SAs for ESP
(RFC 2406), AH (RFC 2402) and/or IPcomp (RFC 2393). We call the cross reference one another;

2) To simplify IKE
SA an "IKE-SA", and by replacing the SAs for ESP, AH, and/or IPcomp that get set
up through that IKE-SA we call "child-SA"s.

We call eight different initial phase 1
exchanges with a single four message exchange (with changes in
authentication mechanisms affecting only a single AUTH payload rather
than restructuring the setup entire exchange);

3) To remove the Domain of Interpretation (DOI), Situation (SIT), and
Labeled Domain Identifier fields, and the IKE-SA "phase 1" Commit and subsequent IKE

Harkins Kaufman Kent Kivinen Perlman [Page 3]

INTERNET DRAFT April 2002

exchanges "phase 2" even though setup of a child-SA can be
piggybacked on Authentication
only bits;

4) To decrease IKE's latency by making the initial phase 1 exchange. The phase 1 exchange is
two request/response pairs. A phase be 2 exchange is one
request/response pair,
round trips (4 messages), and can be used to create or delete a child-
SA, rekey or delete allowing the IKE-SA, or give information such as error
conditions.

IKE message flow always consists ability to piggyback setup
of a request followed by a response.
It is Child-SA on that exchange;

5) To replace the responsibility of cryptographic syntax for protecting the requester IKE
messages themselves with one based closely on ESP to ensure reliability. If
the response is not received within a timeout interval, the requester
retransmits simplify
implementation and security analysis;

6) To reduce the request.

The first request/response number of a phase 1 exchange, which we'll call
IKE_SA_init, negotiates security parameters for possible error states by making the IKE-SA,
protocol reliable (all messages are acknowledged) and sends
Diffie-Hellman values. We call sequenced. This
allows shortening Phase 2 exchanges from 3 messages to 2;

7) To increase robustness by allowing the response IKE_SA_init_response.

The second request/response, which we'll call IKE_auth, transmits
identities, proves knowledge of responder to not do
significant processing until it receives a message proving that the private signature key,
initiator can receive messages at its claimed IP address, and sets
up not
commit any state to an SA for exchange until the first (and often only) AH and/or ESP and/or IPcomp.
We call initiator can be
cryptographically authenticated;

8) To fix bugs such as the response IKE_auth_response.

If hash problem documented in [draft-ietf-
ipsec-ike-hash-revised-02.txt];

9) To specify Traffic Selectors in their own payloads type rather

IKEv2 [Page 3]

INTERNET DRAFT October 2002

than overloading ID payloads, and making more flexible the Responder feels it is under attack, Traffic
Selectors that may be specified;

10) To replace the complex mix and wishes to use a
stateless cookie (see section match negotiation of cryptographic
algorithms with proposals based on cookies). suites of algorithms.

11) To specify required behavior under certain error conditions or
when data that is not understood is received in order to make it can respond
easier to an
IKE_SA_init with an IKE_SA_init_reject with make future revisions in a cookie value way that must
be sent with a subsequent IKE_SA_init_request. The Initiator then
sends another IKE_SA_init, but this time including does not break
backwards compatibility;

12) To simplify and clarify how shared state is maintained in the Responder's
cookie value.

Phase 2 exchanges each consist
presence of a single request/response pair. The
types network failures and Denial of exchanges are CREATE_CHILD_SA (creates a child-SA), or an
informational exchange which deletes a child-SA or the IKE-SA or
informs Service attacks; and

13) To maintain existing syntax and magic numbers to the other side extent
possible to make it likely that implementations of some error condition. All these messages
require a response, so an informational message with no payloads can
serve as a check for liveness.

1.2 Change History

1.2.1 Changes from IKEv1 can be
enhanced to IKEv2-00 November 2001

The goals of support IKEv2 with minimum effort.

2 Requirements Terminology

Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
"MAY" that appear in this revision document are to IKE are:

1) To define the entire IKE protocol be interpreted as described
in a single document, rather
than three that cross reference one another;

2) To simplify [Bra97].

3 IKE Protocol Overview

IP Security (IPsec) provides confidentiality, data integrity, and
data source authentication to IP datagrams. These services are
provided by eliminating maintaining shared state between the Aggressive Mode option source and all
but one the sink
of an IP datagram. This state defines, among other things, the authentication
specific services provided to the datagram, which cryptographic
algorithms making phase 1 a single
exchange (based on public signature keys);

Harkins Kaufman Kent Kivinen Perlman [Page 4]

INTERNET DRAFT April 2002

3) To remove will be used to provide the Domain of Interpretation (DOI), Situation (SIT), and
Labeled Domain Identifier fields, services, and the Commit and Authentication
only bits;

4) To decrease IKE's latency by making keys used as
input to the initial exchange be cryptographic algorithms.

Establishing this shared state in a manual fashion does not scale
well. Therefore a protocol to establish this state dynamically is
needed. This memo describes such a protocol-- the Internet Key
Exchange (IKE). This is version 2
round trips (4 messages), of IKE. Version 1 of IKE was
defined in RFCs 2407, 2408, and allowing the ability 2409. This single document is
intended to piggyback setup replace all three of a Child-SA on those RFCs.

IKE performs mutual authentication between two parties and
establishes an IKE security association that exchange;

5) To replace the cryptographic algorithms includes shared secret
information that can be used to efficiently establish SAs for protecting ESP
(RFC 2406), AH (RFC 2402) and/or IPcomp (RFC 2393). We call the IKE
SA an "IKE-SA". The SAs for ESP, AH, and/or IPcomp that get set up
through that IKE-SA we call "child-SA"s.

IKEv2 [Page 4]

INTERNET DRAFT October 2002

We call the first four messages themselves with one based closely on ESP to simplify
implementation establishing an IKE-SA a "phase 1"
exchange and security analysis;

6) To reduce subsequent IKE exchanges "phase 2", inheriting this
terminology from IKEv1. The phase 1 exchange establishes the number of possible error states by making IKE-SA
and the
protocol reliable (all messages are acknowledged) first child-SA. In some scenarios, only a single child-SA is
needed between the IPsec endpoints and sequenced. This
allows shortening therefore there would be no
phase 2 exchanges. Phase 2 exchanges from 3 messages to 2;

7) To increase robustness by allowing the Responder, if under attack, MAY be used to require return of a cookie before establish
additional child-SAs between the Responder commits any state same authenticated pair of endpoints
as well as other housekeeping. The phase 1 exchange consists of two
request/response pairs. A phase 2 exchange is one request/response
pair, and can be used to create or delete a child-SA, rekey or delete
the exchange;

8) To fix bugs IKE-SA, or report information such as the hash problem documented in [draft-ietf-
ipsec-ike-hash-revised-02.txt];

9) To specify Traffic Selectors in their own payload type rather then
overloading ID payloads, and making more flexible the Traffic
Selectors that may be specified;

10) To avoid unnecessary exponential explosion error conditions.

IKE message flow always consists of space in attribute
negotiation, a request followed by allowing choices when multiple algorithms of one type
(say, encryption) can work with any of a number of acceptable
algorithms response.
It is the responsibility of another type (say, integrity protection);

11) To specify required behavior under certain error conditions or
when data that the requester to ensure reliability. If
the response is not understood is received in order to make it
easier to make future revisions in within a way that does not break
backwards compatibility;

12) To simplify and clarify how shared state is maintained in timeout interval, the
presence of network failures and Denial requester
MUST retransmit the request (or abandon the connection).

The first request/response of Service attacks; a phase 1 exchange negotiates security
parameters for the IKE-SA, sends nonces, and

13) To maintain existing syntax sends Diffie-Hellman
values. We call the request message IKE_SA_init and magic numbers to the extent
possible to make it likely that implementations of IKEv1 can be
enhanced to support IKEv2 with minimum effort.

1.2.2 Changes from IKEv2-00 to IKEv2-01 February 2002

1) Changed Appendix B to specify the encryption response
IKE_SA_init_response.

The second request/response, which we'll call IKE_auth and authentication
processing for IKE rather than referencing ESP. Simplified the format

Harkins Kaufman Kent Kivinen Perlman [Page 5]

INTERNET DRAFT April 2002

by removing idiosyncracies not needed for IKE.

2) Added option for authentication via a shared secret key.

3) Specified different keys in the two directions of IKE messages.
Removed requirement
IKE_auth_response transmits identities, proves knowledge of different cookies in the two directions since
now no longer required.

4) Change the quantities signed by the two ends in AUTH fields
secrets corresponding to
assure the two parties sign different quantities.

5) Changed reference to AES to AES_128.

6) Removed requirement that Diffie-Hellman be repeated when rekeying
IKE SA.

7) Fixed typos.

8) Clarified requirements around use of port 500 at the remote end in
support of NAT.

9) Clarified required ordering for payloads.

10) Suggested mechanisms identities, and sets up an SA for avoiding DoS attacks.

11) Removed claims in some places that
the first phase 2 piggybacked
on phase 1 was optional.

1.2.3 Changes from IKEv2-01 (and often only) AH and/or ESP and/or IPcomp child-SA. In
order to IKEv2-02 April 2002

1) Moved the Initiator CERTREQ payload from message 1 allow Bob to be stateless until receiving message 3.

2) Added a second optional ID payload in 3, message
3 for the Initiator
to name a desired Responder must repeat all of message 1 and Bob must be able to support the case where multiple named
identities are served by a single IP address.

3) Deleted the optimization whereby the Diffie-Hellman group did not
need to be specified reconstruct
(bit for bit) what he sent in phase message 2.

Phase 2 if it was exchanges each consist of a single request/response pair. The
types of exchanges are CREATE_CHILD_SA (which creates a child-SA), or
an Informational exchange which deletes a child-SA or the same as in phase 1 (it
complicated IKE-SA or
informs the design other side of some error condition. All these messages
require a response. An informational message with no meaningful benefit).

4) Added payloads is
commonly used as a section on the implications of reusing Diffie-Hellman
expontentials

5) Changed check for liveness.

In the specification of sequence numbers description that follow, we assume that no errors occur.
Modifications to being at 0 in
both directions.

6) Many editorial changes and corrections, the most significant being flow should errors occur are described in
section 4.

3.1 The Initial (Phase 1) Exchange

The base Phase 1 exchange is a global replace four message exchange (two
request/response pairs). The first pair of "byte" with "octet".

Harkins Kaufman Kent Kivinen Perlman messages (IKE_SA_init)
negotiate cryptographic algorithms, exchange nonces, and do a
Diffie-Hellman exchange.

IKEv2 [Page 6] 5]

INTERNET DRAFT April October 2002

1.3 Requirements Terminology

Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT"

The second pair of messages (IKE_AUTH) authenticate the previous
messages, exchange identities and
"MAY" that appear in this document certificates, and establish the
first child_SA. Parts of these messages are to be interpreted as described encrypted and integrity
protected with keys established through the IKE_SA_init exchange, so
the identities are hidden from eavesdroppers and all fields in [Bra97].

2 Protocol Overview

IKE runs over UDP port 500. Since UDP is a datagram (unreliable)
protocol, IKE includes in its definition recovery from transmission
errors, including packet loss, packet replay, and packet forgery. IKE
is designed to function so long as at least one of a series of
retransmitted packets reaches its destination before timing out and all
the channel is not so full of forged and replayed packets so as to
exhaust messages are authenticated.

In the network or CPU capacities of either endpoint. Even following description, the payloads contained in the
absence message
are indicated by names such as SA. The details of those minimum performance requirements, IKE is designed to
fail cleanly (as though the network were broken).

Harkins Kaufman Kent Kivinen Perlman [Page 7]

INTERNET DRAFT April 2002

2.1 Use contents of Retransmission Timers

All messages in IKE exist
each payload are described later. Payloads which may optionally
appear will be shown in pairs: brackets, such as [CERTREQ], would indicate
that optionally a certificate request and a response. The
setup of an IKE SA normally consists of two request/response pairs.
Once the IKE SA is set up, either end of a security association may
initiate requests at any time, and there payload can be many requests and
responses "in flight" at any given moment. But each message included.

The Phase 1 exchange is
labelled as either a request or a response follows:

Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->

HDR contains the SPIs (formerly called cookies), version numbers, and for each pair one end
flags of various sorts. The SAi1 payload states the security association is cryptographic
algorithms the Initiator and supports for the other IKE SA. The KE payload
sends the Initiator's Diffie-Hellman value. Ni is the
Responder.

For every pair of messages, the Initiator is responsible for
retransmission in the event of a timeout. Initiator's
nonce.

<-- HDR, SAr1, KEr, Nr, [CERTREQ]

The Responder will never
retransmit a response unless it receives chooses a retransmission of cryptographic suite from the
request. In Initiator's
offered choices and expresses that event, the Responder MUST either ignore the
retransmitted request except insofar as it triggers a retransmission
of the response OR if processing choice in the request a second time has no
adverse effects, SAr1 payload,
completes the Responder may choose to process Diffie-Hellman exchange with the request
again KEr payload, and send a semantically equivalent reply.

IKE is a reliable protocol, sends
its nonce in the sense Nr payload.

At this point in time each party can generate SKEYSEED from which all
keys are derived for that IKE SA. Parts of the Initiator MUST
retransmit a request until either it receives a corresponding reply
OR it deems following two
messages, the IKE security association to have failed IKE_AUTH and it
discards all state associated with the IKE-SA IKE_AUTH_response, are encrypted and any Child-SAs
negotiated using that IKE-SA.

2.2 Use of Sequence Numbers
integrity protected. The keys used for Message ID

Every IKE message contains a Message ID the encryption and integrity
protection are derived from SKEYSEED and are known as part of its fixed header.
This Message ID is used to match up requests SK_e
(encryption) and responses, SK_a (authentication, a.k.a. integrity protection).
A separate SK_e and to
identify retransmissions of messages.

The Message ID is a 32 bit quantity, which SK_a is zero computed for the first IKE
request in each direction. The IKE SA initial setup messages will
always be numbered 0 and 1. Each endpoint in the IKE Security
Association maintains two "current" Message IDs: the next one to be
used for a request it initiates and the next one it expects to see
from the other end. These counters increment as requests
notation SK { ... } indicates that these payloads are
generated encrypted and received. Responses always contain the same message ID
as the corresponding request. That means
integrity protected using that after the direction's SK_e and SK_a.

HDR, SAi1, KEi, Ni, Nr,
SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr} -->

The initial
exchange, each integer n will appear as payloads in message three are identical to the payloads
in message ID 1. If message 1 included any optional payloads (e.g.

IKEv2 [Page 6]

INTERNET DRAFT October 2002

Vendor ID), they must be repeated in four
distinct messages: The nth request message 3 in the same order.
Then she includes Nr (Bob's nonce) copied from message 2. The
Initiator identifies herself with the original IKE Initiator, IDi payload, proves knowledge
of the secret corresponding response, the nth request from the original IKE
Responder, to IDi and integrity protects the corresponding response. If
contents of the first two ends make very
different numbers of requests, messages using the Message IDs AUTH payload. She might
also send her certificate(s) in the two directions
can be very different. There is no ambiguity CERT payload(s) and a list of her
trust anchors in the messages,
however, because each packet contains enough information CERTREQ payload(s). The optional payload IDr
enables Alice to determine specify which of Bob's identities she wants to talk
to. This is useful when Bob is hosting multiple identities at the four messages
same IP address. She begins negotiation of a particular one is.

Harkins Kaufman Kent Kivinen Perlman [Page 8]

INTERNET DRAFT April 2002

In child-SA using the case SAi2
payload. The fields starting with SAi2 are described in the
description of Phase 2.

There are optional fields where the IKE_SA_init is rejected (e.g. Initiator can provide
certificates [CERT] the Responder might find useful in order to
require a cookie), validating
AUTH, her list of preferred root certifiers [CERTREQ], and the second IKE_SA_init message will begin name
of the
sequence over entity with Message #0.

2.3 Window Size for overlapping requests

In order which she is trying to maximize IKE throughput, an IKE endpoint MAY issue
multiple requests before getting open a response to any of them. For
simplicity, an IKE implementation MAY choose to process requests
strictly in order and/or wait for connection [IDr]
(for the case where multiple named entities exist at a response to one request before
issuing another. Certain rules must be followed to assure
interoperability between implementations using different strategies.

After an IKE-SA is set up, either end can initiate single IP
address).

<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}

The Responder identifies himself with the IDr payload, optionally
sends one or more
requests. These requests may pass one another over certificates, authenticates himself with the network. An
IKE endpoint MUST be prepared to accept AUTH
payload, and process a request while
it has a request outstanding in order to avoid completes negotiation of a deadlock child-SA with the additional
fields described below in this
situation. An IKE endpoint SHOULD be prepared to accept the phase 2 exchange.

The recipients of messages 3 and process
multiple requests while it has a request outstanding.

An IKE endpoint 4 MUST NOT exceed verify that all signatures
and MACs are computed correctly and that the peer's stated window size (see
section 7.3.2) for transmitted IKE requests. In other words, if Bob
stated his window size is N, then when Alice needs to make a request
X, she MUST wait until she has received responses to all requests up
through request X-N. An IKE endpoint MUST keep a copy of (or be able
to regenerate exactly) each request it has sent until it receives names in the
corresponding response. An IKE endpoint MUST keep a copy of (or be
able ID payloads
correspond to regenerate with semantic equivalence) the number of previous
responses equal keys used to its contracted window size in case its response
was lost and the Initiator requests its retransmission by
retransmitting generate the request.

An IKE endpoint SHOULD AUTH payload.

3.2 The CREATE_CHILD_SA (Phase 2) Exchange

A phase 2 exchange is one request/response pair, and can be capable of processing incoming requests out
of order used to maximize performance in
create or delete a child-SA, delete or rekey the event IKE-SA, check the
liveness of network failures the IKE-SA, or
packet reordering.

2.4 State Synchronization and Connection Timeouts

An IKE endpoint deliver information such as error
conditions. It is allowed to forget all of its state associated with
an IKE-SA encrypted and integrity protected using the collection keys
negotiated during the creation of corresponding child-SAs at any time.
This is the anticipated behavior IKE-SA.

Messages are cryptographically protected using the cryptographic
algorithms and keys negotiated in the event first two messages of an endpoint crash
and restart. It is important when an endpoint either fails or
reinitializes its state that the other endpoint detect those
conditions and not continue to waste network bandwidth by sending
packets over those SAs and having them fall into a black hole.

Since IKE is designed to operate
exchange using a syntax described in spite of Denial of Service (DoS)

Harkins Kaufman Kent Kivinen Perlman [Page 9]

INTERNET DRAFT April 2002

attacks section 5.14. Encryption uses
keys derived from the network, an endpoint MUST NOT conclude that the
other endpoint has failed based on any routing information (e.g. ICMP
messages) or IKE messages that arrive without cryptographic
protection (e.g., notify messages complaining about unknown SPIs). An SK_e, one in each direction; Integrity uses keys
derived from SK_a, one in each direction.

Either endpoint MUST conclude that may initiate a CREATE_CHILD_SA exchange, so in this
section the other endpoint has failed only when
repeated attempts term Initiator refers to contact it have gone unanswered for a timeout
period. An endpoint SHOULD suspect that the other endpoint has failed
based on routing information and initiate initiating this

IKEv2 [Page 7]

INTERNET DRAFT October 2002

exchange.

A child-SA is created by sending a CREATE_CHILD_SA request. The
CREATE_CHILD_SA request MAY optionally contain a KE payload for an
additional Diffie-Hellman exchange to see whether enable stronger guarantees of
forward secrecy for the other endpoint is alive. To check whether child-SA. The keying material for the other side child-
SA is
alive, IKE provides a null query notify message that requires an
acknowledgment. If a cryptographically protected message has been
received from the other side recently, unprotected notifications MAY
be ignored. Implementations MUST limit function of SK_d established during the rate at which they
generate responses to unprotected messages.

Numbers establishment of retries the
IKE-SA, the nonces exchanged during the CREATE_CHILD_SA exchange, and lengths of timeouts are not covered
the Diffie-Hellman value (if KE payloads are included in this
specification because they do not affect interoperability. It is
suggested that messages be retransmitted at least a dozen times over
a period the
CREATE_CHILD_SA exchange).

In the child-SA created as part of at least several minutes before giving up on an SA, but
different environments may require different rules. An exception to
this rule is that a Responder who has not received the phase 1 exchange, a
cryptographically protected message on an IKE-SA second KE
payload MUST eventually time
it out and delete it. Note that consuming state on an IKE Responder
by setting up large numbers of half-open IKE-SAs is a likely denial
of service attack, so the policy for timing these out NOT be used, and limiting the resources they consume should Nonces are not transmitted but are
assumed to be considered carefully.

There is a Denial of Service attack on the same as the phase 1 nonces.

The CREATE_CHILD_SA request contains:

Initiator of an IKE Responder
----------- -----------
HDR, SK {SA, Ni, [KEi],
[TSi, TSr]} -->

The Initiator sends SA
that can be avoided if offer(s) in the Initiator takes SA payload, a nonce in the proper care. Since Ni
payload, optionally a Diffie-Hellman value in the KEi payload, and
the proposed traffic selectors in the TSi and TSr payloads. If the
first two messages of an SA setup are not cryptographically
protected,
offers include different Diffie-Hellman groups, KEi must be an attacker could respond to
element of the Initiator's first group offered.

The message
before past the genuine Responder header is encrypted and poison the connection setup attempt.
To prevent this, message including
the Initiator SHOULD be willing to accept multiple
responses to its first message, treat each as potentially legitimate,
respond to it, and then discard all the invalid half open connections
when she receives a valid cryptographically header is integrity protected using the cryptographic algorithms
negotiated in Phase 1.

The CREATE_CHILD_SA response contains:

<-- HDR, SK {SA, Nr, [KEr],
[TSi, TSr]}

The Responder replies (using the same Message ID to any
one of her responses.

Note that respond) with these rules, there is no reason to negotiate and agree
upon the
accepted offer in an SA lifetime. If IKE presumes payload, a Diffie-Hellman value in the partner is dead, based on
repeated lack of acknowledgment to an IKE message, then KEr
payload if KEi was included in the IKE SA request and all child-SAs set up through the selected
cryptographic suite includes that IKE-SA are deleted.

An IKE endpoint MAY delete inactive Child-SAs to recover resources
used to hold their state. group. If an IKE endpoint the responder chooses to do so, a
cryptographic suite with a different group, it
MUST send Delete payloads must reject the
request and have the initiator make another one.

The traffic selectors for traffic to be sent on that SA are specified
in the other end notifying it TS payloads, which may be a subset of what the
deletion. It MAY similarly time out Initiator of
the IKE-SA. Closing child-SA proposed. Traffic selectors are omitted if this
CREATE_CHILD_SA request is being used to change the IKE-SA
implicitly closes all associated Child-SAs. An IKE endpoint SHOULD

Harkins Kaufman Kent Kivinen Perlman key of the IKE-

IKEv2 [Page 10] 8]

INTERNET DRAFT April October 2002

send a Delete payload indicating that it has closed the IKE-SA.

2.5 Version Numbers and Forward Compatibility

This document describes version 2.0 of IKE, meaning the major version
number is

SA.

3.3 Informational (Phase 2) Exchange

At various points during an IKE-SA, peers may desire to convey
control messages to each other regarding errors or notifications of
certain events. To accomplish this IKE defines a (reliable)
Informational exchange. Usually Informational exchanges happen
during phase 2 and are cryptographically protected with the minor version number is zero. It is likely IKE
exchange.

Control messages that
some implementations will want pertain to support both version 1.0 and
version 2.0, and in the future, other versions.

The major version number should only be incremented if the packet
formats or required actions have changed so dramatically that an
older version node would not IKE-SA MUST be able sent under that
IKE-SA. Control messages that pertain to interoperate with a newer
version node if it simply ignored Child-SAs MUST be sent under
the fields it did not understand
and took protection of the actions specified in IKE-SA which generated them (or its successor
if the older specification. The minor
version number indicates new capabilities, and MUST be ignored by a
node with a smaller minor version number, but used IKE-SA is replaced for informational
purposes by the node with purpose of rekeying).

There are two cases in which there is no IKE-SA to protect the larger minor version number. For
example, it might indicate
information. One is in the ability response to process a newly defined
notification message. The node with an IKE_SA_init_request to
refuse the larger minor version number
would simply note that its correspondent SA proposal. This would not be able to
understand that message and therefore would not send it.

If you receive conveyed in a message with a higher major version number, you MUST
drop Notify payload of
the message and SHOULD send an unauthenticated notification
message containing IKE_SA_init_response.

The other case in which there is no IKE-SA to protect the highest version number you support. If you
support major version n, and major version m, you MUST support all
versions between n and m. If you receive a message with information
is when a major
version that you support, you MUST respond packet is received with that version number. an unknown SPI. In order to prevent two nodes from being tricked into corresponding
with a lower major version number than the maximum that they both
support, IKE has a flag that indicates that case the node
notification of this condition will be sent in an informational
exchange that is capable not cryptographically protected.

Messages in an Informational Exchange contain zero or more
Notification or Delete payloads. The Recipient of
speaking a higher major version number.

Thus an Informational
Exchange request MUST send some response (else the major version number Sender will assume
the message was lost in the IKE header indicates network and will retransmit it). That
response can be a message with no payloads. Actually, the version
number of request
message in an Informational Exchange can also contain no payloads.
This is the message, not expected way an endpoint can ask the highest version number other endpoint to
verify that the
transmitter supports. If A it is capable of speaking versions n, n+1,
and n+2, alive.

ESP, AH, and B IPcomp SAs always exist in pairs, with one SA in each
direction. When an SA is capable of speaking versions n and n+1, closed, both members of the pair MUST be
closed. When SAs are nested, as when data is encapsulated first with
IPcomp, then they
will negotiate speaking n+1, where A will set with ESP, and finally with AH between the flag indicating
ability same pair of
endpoints, all of the SAs (up to speak a higher version. If they mistakenly (perhaps
through six) must be deleted together. To
delete an active attacker sending error messages) negotiate SA, an Informational Exchange with one or more delete
payloads is sent listing the SPIs (as known to
version n, then both will notice that the other side can support a
higher version number, and they recipient) of the
SAs to be deleted. The recipient MUST break close the connection and
reconnect using version n+1.

Note that v1 does not follow these rules, because there is no way designated SAs.
Normally, the reply in
v1 the Informational Exchange will contain delete
payloads for the paired SAs going in the other direction. There is
one exception. If by chance both ends of noting that you are capable a set of speaking SAs independently
decide to close them, each may send a higher version
number. So an active attacker can trick delete payload and the two v2-capable nodes into
speaking v1. Given
requests may cross in the design of v1, there is no way of preventing

Harkins Kaufman Kent Kivinen Perlman network. If a node receives a delete

IKEv2 [Page 11] 9]

INTERNET DRAFT April October 2002

this, but this version number discipline will prevent such problems
in future versions. When a v2-capable node negotiates down to v1,

request for SAs that it
SHOULD note that fact in its logs.

ISSUE: The SSLv2 to SSLv3 upgrade handled this issue in has already issued a very clever
way, delete request for, it
MUST delete the incoming SAs while processing the request and we could copy it. SSLv3 specified the
outgoing SAs while processing the response. In that certain octets case, the
responses MUST NOT include delete payloads for the deleted SAs, since
that would result in v2 were randomly generated values be set to a constant when a v3
capable duplicate deletion and could in theory delete
the wrong SA.

A node negotiated down SHOULD regard half open connections as anomalous and audit
their existence should they persist. Note that this specification
nowhere specifies time periods, so it is up to v2. We could, for example, choose a
constant value for part of the IKEv1 cookie individual endpoints
to decide how long to wait. A node MAY refuse to indicate IKEv2
capability. Alternatively, we could define a new IKEv1 cipher suite
that no IKEv1 implementation could accept incoming data
on half open connections but which could be used as
such a flag.

Also for forward compatibility, all fields marked RESERVED MUST be
set to zero by a version 2.0 implementation NOT unilaterally close them and their content MUST be
ignored by
reuse the SPIs. If connection state becomes sufficiently messed up, a version 2.0 implementation ("Be conservative in what you
send and liberal in what you receive"). In this way, future versions
of
node MAY close the protocol IKE-SA which will implicitly close all SAs
negotiated under it. It can use those fields in then rebuild the SA's it needs on a way that is guaranteed to
be ignored by implementations that do not understand them.
Similarly, payload types that are not clean
base under a new IKE-SA.

The Informational Exchange is defined are reserved for future
use and implementations as:

Initiator Responder
----------- -----------
HDR, SK {N, ..., D, ...} -->
<-- HDR, SK {N, ..., D, ...}

The processing of version 2.0 MUST skip over those payloads an Informational Exchange is determined by its
component payloads.

4 IKE Protocol Details and ignore their contents.

IKEv2 adds Variations

IKE runs over UDP port 500. Since UDP is a "critical" flag to each payload header for further
flexibility for forward compatibility. If the critical flag datagram (unreliable)
protocol, IKE includes in its definition recovery from transmission
errors, including packet loss, packet replay, and packet forgery. IKE
is set designed to function so long as at least one of a series of
retransmitted packets reaches its destination before timing out and
the payload type channel is unsupported, the message MUST be rejected not so full of forged and replayed packets so as to
exhaust the response network or CPU capacities of either endpoint. Even in the
absence of those minimum performance requirements, IKE is designed to
fail cleanly (as though the network were broken).

4.1 Use of Retransmission Timers

All messages in IKE exist in pairs: a request containing that payload MUST include and a notify payload UNSUPPORTED-CRITICAL-PAYLOAD, indicating response. The
setup of an
unsupported critical payload was included. If IKE SA normally consists of two request/response pairs.
Once the critical flag IKE SA is
not set and the payload type is unsupported, that payload is simply
skipped. While new payload types up, either end of a security association may be added in the future
initiate requests at any time, and may
appear interleaved with the fields defined in this specification,
implementations MUST send the payloads defined in this specification
in the stated order there can be many requests and implementations SHOULD reject as invalid a
responses "in flight" at any given moment. But each message with payloads in an unexpected order.

2.6 Cookies

The term "cookies" originates with Karn and Simpson [RFC 2522] in
Photurus, an early proposal for key managment with IPsec. It has
persisted because the IETF has never rejected an offer involving
cookies. In IKEv2, the cookies serve two purposes. First, they are
used is
labelled as IKE-SA identifiers in the headers of IKE messages. As with
ESP and AH, in IKEv2 the recipient of either a message chooses an IKE-SA
identifier that uniquely defines that SA to that recipient. For this
purpose (IKE-SA identifiers), it might be convenient for the cookie
value to be chosen so as to be request or a table index response and for fast lookups each
request/response pair one end of SAs.
But this conflicts with the second purpose of security association is the cookies (to be

Harkins Kaufman Kent Kivinen Perlman

IKEv2 [Page 12] 10]

INTERNET DRAFT April October 2002

explained shortly).

Unlike ESP

Initiator and AH where only the recipient's SA identifier appears in
the message, in IKE, the sender's IKE SA identifier other is also sent in
every message. In IKEv1 the IKE-SA identifier consisted of the Responder.

For every pair
(Initiator cookie, Responder cookie), whereas in IKEv2, of messages, the SA Initiator is
uniquely defined by the recipient's SA identifier even though both
are included responsible for
retransmission in the IKEv2 header.

The second use event of cookies in IKEv2 is for a limited protection from
denial of service attacks. Receipt of timeout. The Responder will never
retransmit a request to start an SA can
consume substantial resources. A likely denial of service attack
against IKE is to overwhelm response unless it receives a system with large numbers retransmission of SA
requests from forged IP addresses. This can consume CPU resources
doing the crypto, and memory resources remembering the state of
request. In that event, the
"half open" connections until they time out. A robust design would
limit Responder MUST either ignore the resources
retransmitted request except insofar as it is willing to devote to new connection
establishment, but even so the denial triggers a retransmission
of service attack could
effectively prevent any new connections.

This attack can be rendered more difficult by requiring that the
Responder to an SA request do minimal computation and allocate no
memory until response OR if processing the Initiator request a second time has proven that it can receive messages at no
adverse effects, the address it claims Responder may choose to be sending from. This process the request
again and send a semantically equivalent reply.

IKE is done in a stateless
way by computing the cookie reliable protocol, in a way that the Responder can recompute the same value, but sense that the Initiator can't guess it. A recommended
strategy is to compute the cookie as MUST
retransmit a cryptographic hash of the
Initiator's IP address, request until either it receives a corresponding reply
OR it deems the Initiator's cookie value (its chosen IKE security identifier), and a secret known only to the Responder. That
secret should be changed periodically association to prevent the "cookie jar"
attack where an attacker accumulates lots of cookies from lots of IP
addresses over time have failed and then replays them it
discards all at once to overwhelm
the Responder.

In ISAKMP and IKEv1, state associated with the term cookie was used IKE-SA and any Child-SAs
negotiated using that IKE-SA.

4.2 Use of Sequence Numbers for the connection
identifier, but the protocol did not permit their use against this
particular denial Message ID

Every IKE message contains a Message ID as part of service attack. To avoid the cookie exchange
adding extra messages to the protocol in the common case where the
Responder its fixed header.
This Message ID is not under attack, IKEv2 goes back used to the approach in
Oakley (RFC 2412) where the cookie challenge is optional. Upon
receipt match up requests and responses, and to
identify retransmissions of an IKE_SA_init, messages.

The Message ID is a Responder may either proceed with
setting up 32 bit quantity, which is zero for the first IKE
request in each direction. The IKE SA or may tell the Initiator to send another
IKE_SA_init, this time providing a supplied cookie.

It may initial setup messages will
always be convenient for numbered 0 and 1. Each endpoint in the IKE-SA identifier IKE Security
Association maintains two "current" Message IDs: the next one to be an index into a
table. It is not difficult
used for the Initiator to choose an IKE-SA
identifier that is convenient as a table identifier, since the
Initiator does not need to use request it as an anti-clogging token, initiates and is

Harkins Kaufman Kent Kivinen Perlman [Page 13]

INTERNET DRAFT April 2002

keeping state. IKEv2 allows the Responder to initially choose a
stateless anti-clogging type cookie by responding next one it expects to an IKE_SA_init
with a cookie request, and then upon receipt of an IKE_SA_init with a
valid cookie, change his cookie value see
from the computed anti-clogging
token to a more convenient value, by sending a different value for
his cookie in the IKE_SA_init_response. This will not confuse other end. These counters increment as requests are
generated and received. Responses always contain the
Initiator (Alice), because she will have chosen a unique cookie value
A, so if her SA state for same message ID
as the partially set up IKE-SA says corresponding request. That means that Bob's
cookie for after the SA that Alice knows initial
exchange, each integer n may appear as "A" is B, and she receives a
response from Bob with cookies (A,C), that means that Bob wants to
change his value the message ID in four
distinct messages: The nth request from B to C for the SA that Alice knows uniquely as
"A".

Another reason why Bob might want to change his cookie value is that
it is possible (though unlikely) that Bob will choose original IKE Initiator,
the same cookie
for multiple SAs if corresponding response, the hash of nth request from the Initiator cookie, Initiator IP
address, original IKE
Responder, and whatever other information might be included happens to
hash to the same value.

In IKEv2, like IKEv1, both 8-octet cookies appear in the message, but
in IKEv2 (unlike v1), corresponding response. If the value chosen by two ends make very
different numbers of requests, the message recipient
always appears first Message IDs in the message. This change eliminates a flaw two directions
can be very different. There is no ambiguity in
IKEv1, as well as having other advantages (allowing the recipient messages,
however, because each packet contains enough information to
look up determine
which of the SA based on a small, conveniently chosen value rather
than four messages a 16-octet pseudorandom value.)

The flaw in IKEv1 is particular one is.

Note that it was possible (though unlikely) Message IDs are cryptographically protected and provide
protection against message replays.

4.3 Window Size for two
connections overlapping requests

In order to have the same set maximize IKE throughput, an IKE endpoint MAY issue
multiple requests before getting a response to any of cookies. them. For instance, if Alice
chose A as the Initiator cookie when initiating a connection

IKEv2 [Page 11]

INTERNET DRAFT October 2002

simplicity, an IKE implementation MAY choose to Bob,
she might subsequently receive process requests
strictly in order and/or wait for a connection request from Carol, and
Carol might also have chosen A as the Initiator cookie. Whatever
value Alice responds response to Carol, say B, might be selected as the
Responder cookie by Bob for the Alice-Bob SA. Then Alice would one request before
issuing another. Certain rules must be
involved in two IKE sessions, both of which had Initiator cookie=A
and Responder cookie=B. To minimize, but not eliminate, followed to assure
interoperability between implementations using different strategies.

After an IKE-SA is set up, either end can initiate one or more
requests. These requests may pass one another over the
probability of this happening, version 1 network. An
IKE recommended that cookies endpoint MUST be chosen at random.

The cookies are one of the inputs into the function that computes the
keying material. If the Responder initially sends prepared to accept and process a stateless cookie
value request while
it has a request outstanding in its IKE_SA_init_reject, and changes order to avoid a different value
when it sends its IKE_SA_init_response, it is the cookie value deadlock in the
IKE_SA_init_response that is the input for generating the keying
material.

Note that one of the denial of service attacks that cookies are
designed to thwart is exhaustion of state at the target by creating
half-open connections. This defense would be ineffective if there

Harkins Kaufman Kent Kivinen Perlman [Page 14]

INTERNET DRAFT April 2002

were another equally easy way for an attacker to consume state at the
target. this
situation. An IKE runs over UDP, and may send messages sufficiently large
that they must endpoint SHOULD be fragmented. But accumulating fragments of UDP
packets consumes state at the target, so if an IKE responder were
required prepared to accept and reassemble UDP packets from unknown sources,
another equally easy denial process
multiple requests while it has a request outstanding.

An IKE endpoint MUST wait for a response to each of service attack would be possible.

To thwart its messages
before sending a subsequent message unless it has received a Notify
message from its peer informing it that the UDP reassembly buffer attack, peer is prepared to
maintain state for multiple outstanding messages in order to allow
greater throughput.

An IKE endpoint MUST NOT exceed the peer's stated window size (see
section 5.3.2) for transmitted IKE responder SHOULD,
when it detects that it requests. In other words, if Bob
stated his window size is under attack, have N, then when Alice needs to make a mechanism request
X, she MUST wait until she has received responses to inform
IP reassembly all requests up
through request X-N. An IKE endpoint MUST keep a copy of (or be able
to only accept UDP fragments from IP addresses from
which regenerate exactly) each request it has received sent until it receives the
corresponding response. An IKE endpoint MUST keep a valid cookie and copy of (or be
able to refuse regenerate with semantic equivalence) the number of previous
responses equal to accept UDP
fragments from all other IP addresses. To faccilitate this, its contracted window size in case its response
was lost and the
IKE_SA_init message Initiator requests its retransmission by
retransmitting the request.

An IKE endpoint SHOULD be kept under 500 octets and responders
MAY reject fragmented IKE_SA_init messages.

Harkins Kaufman Kent Kivinen Perlman [Page 15]

INTERNET DRAFT April 2002

2.7 Cryptographic Algorithm Negotiation

The payload type known as "SA" indicates a proposal for a set capable of
choices processing incoming requests out
of protocols (e.g., IKE, ESP, AH, and/or IPcomp) for order to maximize performance in the SA
as well as cryptographic algorithms associated with each protocol. In
IKEv1 it was extremely complex, and required a separate proposal for
each possible combination. If there were n algorithms event of one type
(say encryption) that were acceptable network failures or
packet reordering.

4.4 State Synchronization and worked with any one of m
algorithms of another type (say integrity protection), then it would
take space proportional to n*m Connection Timeouts

An IKE endpoint is allowed to express forget all of its state associated with
an IKE-SA and the possibilities.

IKEv2 has simplified the format collection of corresponding child-SAs at any time.
This is the SA payload somewhat, but anticipated behavior in
addition to simplifying the format, solves event of an endpoint crash
and restart. It is important when an endpoint either fails or
reinitializes its state that the exponential explosion other endpoint detect those
conditions and not continue to waste network bandwidth by allowing, within sending
packets over those SAs and having them fall into a proposal, multiple algorithms black hole.

Since IKE is designed to operate in spite of the same type.
If more than one algorithm Denial of Service (DoS)
attacks from the same type (say encryption) appears
in a proposal, network, an endpoint MUST NOT conclude that means that the sender of that SA proposal is
willing to accept the proposal with
other endpoint has failed based on any of those choices, and the
recipient when it accepts the proposal selects exactly one of each of
the types of algorithms from the choices offered within routing information (e.g. ICMP
messages) or IKE messages that
proposal. arrive without cryptographic

IKEv2 [Page 12]

INTERNET DRAFT October 2002

protection (e.g., notify messages complaining about unknown SPIs). An SA consists of one or more proposals. Each proposal
endpoint MUST conclude that the other endpoint has failed only when
repeated attempts to contact it have gone unanswered for a number
(so timeout
period. An endpoint SHOULD suspect that the recipient can specify which proposal other endpoint has been accepted), failed
based on routing information and contains a protocol (IKE, ESP, AH, or IPcomp), initiate a SPI request to identify see whether
the SA for ESP or AH or IPcomp, and set of transforms. Each transform
consists of a type (e.g., encryption, integrity protection,
authentication, Diffie-Hellman group, compression) and a transform ID
(e.g., DES, IDEA, HMAC-MD5). other endpoint is alive. To negotiate check whether the other side is
alive, IKE specifies an SA empty Informational message that does ESP,
IPcomp, and AH, the SA will contain three proposals with the same
proposal number, one proposing ESP, (like all
IKE requests) requires an acknowledgment. If a 4 octet SPI to cryptographically
protected message has been received from the other side recently,
unprotected notifications MAY be used with
ESP, and a set ignored. Implementations MUST limit
the rate at which they take actions based on unprotected messages.

Numbers of transforms; one proposing AH, a 4-octet SPI to be
used with AH, retries and a set lengths of transforms; and one proposing IPcomp, a
2-octet SPI to be used with IPcomp, and timeouts are not covered in this
specification because they do not affect interoperability. It is
suggested that messages be retransmitted at least a set dozen times over
a period of transforms. at least several minutes before giving up on an SA, but
different environments may require different rules. If the
recipient selects that proposal number, there is
outgoing traffic on an SA, it means is essential to confirm liveness of
that SAs will SA to avoid black holes. If no cryptographically protected
messages have been received on an IKE-SA or any of its child-SAs
recently, a liveness check MUST be
created for all performed. Receipt of ESP, AH, a fresh
cryptographically protected message on an IKE-SA or any of its
child-SAs assures liveness of the IKE-SA and IPcomp.

In IKEv2, since all of its child-SAs.

There is a Denial of Service attack on the Initiator sends her Diffie-Hellman value in the
IKE_SA_init, she must guess at the Diffie-Hellman group that Bob will
select from her list of supported groups. Her guess MUST an IKE-SA
that can be avoided if the first
in Initiator takes the list to allow Bob to unambiguously identify which group proper care. Since the
accompanying KE payload is from. If her guess is incorrect then Bob's
response informs her
first two messages of the group he would choose, and notifies her
that her offer is invalid because the KE payload is an SA setup are not from cryptographically
protected, an attacker could respond to the
desired group. In this case Alice will send a new IKE_SA_init, with Initiator's message
before the same original choices in genuine Responder and poison the list (this is important to prevent
an active attacker from tricking them into using a weaker group than
they would have agreed upon) but with Bob's preferred group first, connection setup attempt.
To prevent this, the Initiator SHOULD be willing to accept multiple
responses to its first message, treat each as potentially legitimate,
respond to it, and a KE payload containing an exponential from that group.

Harkins Kaufman Kent Kivinen Perlman [Page 16]

INTERNET DRAFT April 2002

If none of Alice's options are acceptable, then Bob notifies her
accordingly.

2.8 Rekeying

Security associations negotiated in both phase 1 and phase 2 contain
secret keys which may only be used for a limited amount of time. This
determines the lifetime of the entire security association. When discard all the
lifetime invalid half open connections
when she receives a valid cryptographically protected response to any
one of her requests. Once a security association expires the security association
MUST NOT cryptographically valid response is
received, all subsequent responses should be used. If ignorred whether or not
they are cryptographically valid.

Note that with these rules, there is demand, new security associations can
be established. Reestablishment of security associations no reason to take negotiate and agree
upon an SA lifetime. If IKE presumes the
place of ones which expire partner is referred dead, based on
repeated lack of acknowledgment to as "rekeying".

To rekey a child-SA, create a new, equivalent an IKE message, then the IKE SA (see section 4 and
4.1 below),
and when the new one is established, all child-SAs set up through that IKE-SA are deleted.

An IKE endpoint MAY delete the old one.
To rekey inactive Child-SAs to recover resources
used to hold their state. If an IKE-SA, establish a new equivalent IKE-SA (see section 4
and 4.2 below) with the peer IKE endpoint chooses to do so, it
MUST send Delete payloads to whom the old IKE-SA is shared using a
Phase 2 negotiation within the existing IKE-SA. An IKE-SA so created
inherits all other end notifying it of the original IKE-SA's child SAs. Use
deletion. It MAY similarly time out the IKE-SA. Closing the new IKE-SA
for
implicitly closes all control messages needed to maintain the child-SAs created by
the old IKE-SA, and delete the old IKE-SA.

SAs associated Child-SAs. An IKE endpoint SHOULD be rekeyed proactively, i.e., the new SA should be
established before
send a Delete payload indicating that it has closed the old one expires IKE-SA.

IKEv2 [Page 13]

INTERNET DRAFT October 2002

4.5 Version Numbers and becomes unusable. Enough
time should elapse between Forward Compatibility

This document describes version 2.0 of IKE, meaning the time major version
number is 2 and the new SA minor version number is established zero. It is likely that
some implementations will want to support both version 1.0 and
version 2.0, and in the
old one becomes unusable future, other versions.

The major version number should only be incremented if the packet
formats or required actions have changed so dramatically that traffic can an
older version node would not be switched over able to interoperate with a newer
version node if it simply ignored the
new SA.

A difference between IKEv1 fields it did not understand
and IKEv2 is that in IKEv1 SA lifetimes
were negotiated. In IKEv2, each end of took the SA is responsible for
enforcing its own lifetime policy on actions specified in the SA and rekeying the SA when
necessary. If the two ends have different lifetime policies, older specification. The minor
version number indicates new capabilities, and MUST be ignored by a
node with a smaller minor version number, but used for informational
purposes by the end node with the shorter lifetime will end up always being larger minor version number. For
example, it might indicate the one ability to request process a newly defined
notification message. The node with the rekeying. larger minor version number
would simply note that its correspondent would not be able to
understand that message and therefore would not send it.

If you receive a message with a higher major version number, you MUST
drop the message and SHOULD send an unauthenticated notification
message containing the highest version number you support. If you
support major version n, and major version m, you MUST support all
versions between n and m. If you receive a message with a major
version that you support, you MUST respond with that version number.
In order to prevent two ends have nodes from being tricked into corresponding
with a lower major version number than the same lifetime policies, it is possible maximum that they both will initiate
support, IKE has a rekeying at flag that indicates that the same time (which will result node is capable of
speaking a higher major version number.

Thus the major version number in
redundant SAs). To reduce the probability IKE header indicates the version
number of this happening, the
timing message, not the highest version number that the
transmitter supports. If A is capable of rekeying requests should be jittered (delayed by a random
amount of time).

This form speaking versions n, n+1,
and n+2, and B is capable of rekeying speaking versions n and n+1, then they
will temporarily result in multiple similar SAs
between negotiate speaking n+1, where A will set the same pairs of nodes. When there are two SAs eligible flag indicating
ability to
receive packets, speak a node MUST accept incoming packets higher version. If they mistakenly (perhaps
through either
SA. The node an active attacker sending error messages) negotiate to
version n, then both will notice that initiated the rekeying SHOULD delete the older SA
after other side can support a
higher version number, and they MUST break the new one connection and
reconnect using version n+1.

Note that IKEv1 does not follow these rules, because there is established.

Harkins Kaufman Kent Kivinen Perlman no way
in v1 of noting that you are capable of speaking a higher version
number. So an active attacker can trick two v2-capable nodes into
speaking v1. When a v2-capable node negotiates down to v1, it SHOULD
note that fact in its logs.

IKEv2 [Page 17] 14]

INTERNET DRAFT April October 2002

2.9 Traffic Selector Negotiation

When an IP packet is received

Also for forward compatibility, all fields marked RESERVED MUST be
set to zero by an RFC2401 compliant IPsec subsystem a version 2.0 implementation and matches their content MUST be
ignored by a "protect" selector version 2.0 implementation ("Be conservative in its SPD, what you
send and liberal in what you receive"). In this way, future versions
of the subsystem MUST
protect protocol can use those fields in a way that packet with IPsec. When no SA exists yet it is the task
of IKE guaranteed to create it. Information about the traffic
be ignored by implementations that needs
protection is transmitted to the IKE subsystem in a manner outside
the scope of this document (see [PFKEY] for an example). This
information is negotiated between the two IKE endpoints using TS
(Traffic Selector) payloads.

The TS do not understand them.
Similarly, payload consists of a set of individual traffic selectors.
The selector from the SPD has "source" and "destination" components
and these types that are represented in IKE as a pair of TS payloads, TSi
(traffic selector-initiator) and TSr (traffic selector-responder).
TSi describes the addresses not defined are reserved for future
use and ports that the Initiator will send
from implementations of version 2.0 MUST skip over the SA those payloads
and which it will accept packets for. TSr describes ignore their contents.

IKEv2 adds a "critical" flag to each payload header for further
flexibility for forward compatibility. If the addresses critical flag is set
and ports that the Initiator will sent to over payload type is unsupported, the SA message MUST be rejected and which it will accept packets from.

The Responder is allowed
the response to narrow the choices by selecting IKE request containing that payload MUST include
a subset
of the traffic, for instance by eliminating one or more members of
the set of traffic selectors provided notify payload UNSUPPORTED-CRITICAL-PAYLOAD, indicating an
unsupported critical payload was included. If the set does critical flag is
not become set and the
NULL set.

Note payload type is unsupported, that payload is simply
skipped. While new payload types may be added in the traffic selectors apply to both child-SAs (from the
Initiator to the Responder future and from may
appear interleaved with the Responder to the Initiator),
but the Responder does not change the order of the TS payloads. An
address within the selector of TSi would appear as a source address fields defined in this specification,
implementations MUST send the child-SA from payloads defined in this specification
in the Initiator, stated order and would appear implementations SHOULD reject as invalid a destination
address
message with payloads in traffic on the child-SA to the Initiator (from the
Responder).

IKEv2 is more flexible than IKEv1. IKEv2 allows sets of ranges of
both addresses and ports, an unexpected order.

4.6 Cookies

The term "cookies" originates with Karn and allows Simpson [RFC 2522] in
Photuris, an early proposal for key management with IPsec. It has
persisted because the Responder to choose IETF has never rejected a subset
of the requested traffic rather than simply responding "not
acceptable".

2.10 Nonces proposal involving
cookies. The IKE_SA_init_request ISAKMP fixed message header includes two eight octet
fields titled "cookies", and the IKE_SA_init_response each contain a
nonce. These nonces that syntax is used by both IKEv1 and
IKEv2. Those eight octet fields are used as inputs to cryptographic functions.
The child-create-request and an SPI or connection
identifier at the child-create-response beginning of IKE packets. They were also contain a
nonce. These nonces are intended
to be used as Karn/Simpson "anti-clogging" tokens in IKEv1, but
certain aspects of that design prevented them from being used as
such. IKEv2 was carefully constructed to add freshness allow an implementation to
implement these anti-clogging tokens, either using the key derivation
technique used fields titled
"cookies" or by creative choices of nonces.

While IKE implementations SHOULD implement anti-clogging tokens to obtain keys for child SAs. Nonces used
protect themselves from denial of service attacks, the algorithms and
syntax they use in IKEv2
MUST therefore have strong pseudo-random properties (see RFC1715).

Harkins Kaufman Kent Kivinen Perlman [Page 18]

INTERNET DRAFT April 2002

2.11 Address and Port Agility

IKE runs over UDP port 500, and implicitly sets up ESP, AH, and
IPcomp associations for the same IP addresses it runs over. The IP
addresses and ports in the outer header are, however, cookies and/or nonces does not themselves
cryptographically protected, affect
interoperability and IKE hence is designed to work even through
Network Address Translation (NAT) boxes. An implementation MUST
accept incoming connection requests even if not received from UDP
port 500, and specified here. The following
should respond to be interpreted as an explanation of why the address and port from which protocol has the
request was received. An implementation MUST, however, accept
incoming requests only on UDP port 500
fields it does and send all responses from
UDP port 500. IKE functions identically over IPv4 or IPv6.

2.12 Reuse as an example of Diffie-Hellman Exponentials

IKE generates keying material using how an ephemeral Diffie-Hellman
exchange implementation could
implementing anti-clogging tokens.

In IKEv2, the cookies are used as IKE-SA identifiers in order to gain the property headers
of "perfect forward secrecy".
This means that once a connection is closed IKE messages. As with ESP and its corresponding
keys are forgotten, even someone who has recorded all of AH, in IKEv2 the data
from recipient of a

IKEv2 [Page 15]

INTERNET DRAFT October 2002

message chooses an IKE-SA identifier that uniquely defines that SA to
that recipient. For this purpose (IKE-SA identifiers), it might be
convenient for the connection and gets access cookie value to all be chosen so as to be a table
index for fast lookups of SAs. But this conflicts with the long term keys second use
of the two endpoints cannot reconstruct the keys used to protect the
conversation.

Achieving perfect forward secrecy requires that when a connection is
closed, each endpoint must forget not cookies.

Unlike ESP and AH where only the keys used by recipient's SA identifier appears in
the
connection but any information that could be used to recompute those
keys. message, in IKE the sender's IKE SA identifier is also sent in
every message. In particular, it must forget IKEv1 the secrets used IKE-SA identifier consisted of the pair
(Initiator cookie, Responder cookie), whereas in IKEv2, the Diffie-
Hellman calculation and any state that may persist SA is
uniquely defined by the recipient's SA identifier even though both
are included in the IKEv2 header.

An expected attack against IKE is state of a
pseudo-random number generater that could be used to recompute the
Diffie-Hellman secrets.

Since and CPU exhaustion, where the computing of Diffie-Hellman exponentials
target is computationally
expensive, flooded with session initiation requests from forged IP
addresses. This attack can be made less effective if an endpoint may find it advantageous
implementation of a responder uses minimal CPU and commits no state
to reuse those
exponentials for multiple connection setups. There are several
reasonable strategies for doing this. An endpoint could choose a new
exponential periodically though this could result in less-than-
perfect forward secrecy if some connection lasts for less than until it has received the
lifetime third message of the exponential. Or
protocol. That third message repeats information from the second
message, and hence proves that the initiator can receive packets at
the address it could keep track claims to be sending from.

Since all of which
exponential was used for each connection and delete the information
associated with the exponential only when some corresponding
connection was closed. This would allow the exponential to be reused
without losing perfect forward secrecy at the cost of maintaining
more state.

Decisions as to whether and when to reuse Diffie-Hellman exponentials from message 1 is a private decision repeated in message 3,
the sense that it will responder need not affect
interoperability. An implementation store any of that reuses exponentials may
choose to remember information. What the exponential used by
responder must be able to do is: (1) assure itself that the other endpoint on past

Harkins Kaufman Kent Kivinen Perlman [Page 19]

INTERNET DRAFT April 2002

exchanges and if one Nr
returned in message 3 is reused to avoid fresh and (2) assure that message 3 came
from the second half of same IP address as message 1. If the
calculation.

3 The Phase 1 Exchange

The base Phase responder uses multiple
KEr's during the period of message 1 exchange & 3, it must encode in message 2
some way to figure out which KEr applies to this exchange.

A good way to do this is to set the IKE-SA identifier to be:

SPIr = Hash(KEr | Nr | IPi | <secret>)

where <secret> is a four message exchange (two
request/response pairs). The first pair of messages, randomly generated secret known only to the IKE_SA_init
exchange, negotiate cryptographic algorithms, (optionally) indicate
trusted CA names, exchange nonces,
responder and do a Diffie-Hellman exchange. periodically changed. This pair might value can be repeated if recomputed when
message 3 arrives and compared to the response indicates SPIr in message 3. If it
matches, the responder knows that none of Nr was generated since the cryptographic proposals are acceptable, or last
change to <secret> and that IPi must be the Diffie-Hellman
group chosen by same as the Initiator for sending her Diffie-Hellman value is
not source
address it saw in message 1.

To prevent replays of message 3 without remembering all the group Nr's that
were used, the Responder would responder must keep a list of all of the Nr's that
have chosen, been returned in a message 3 since <secret> was last changed.
If this list becomes long enough to be cumbersome, the responder can
change <secret> and forget all of if the
Responder used values.

If a new value for <secret> is under attack and will only answer IKE_SA_init requests
containing chosen while there are connections in

IKEv2 [Page 16]

INTERNET DRAFT October 2002

the process of being initialized, a valid message 3 might be returned cookie value.

The second pair where
the responder does not know which of messages, its values for <secret> were
used in generating message 2. Using the IKE_auth formula above, the responder
could compute SPIr with each candidate <secret> and accept message 3
if any of the IKE_auth_response,
authenticate values match. A similar situation occurs if the previous messages, exchange identities and
certificates,
responder uses multiple values of KEr. An alternative implementation
would be to take a few bits of SPIr as indices of <secret>s and establish KEr's
(where the first child_SA. This pair rest of messages SPIr is encrypted with a key established through the IKE_SA_init exchange,
so the identities are hidden from eavesdroppers.

In computed as the following description, above hash).

If the payloads contained responder wants to keep other forms of state without tying up
its memory, it can encode that state in the message
are indicated by names such as SA. nonce. The details of nonce can be
up to 256 octets long, and the contents of
each payload protocol is secure so long as values
are described later. Payloads which may optionally
appear will not reused, so the responder can put state there (possibly
encrypted) and be shown in brackets, such as [CERTREQ], would indicate
that optionally a certificate request payload can be included.

The Phase 1 exchange is as follows:

Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->

The SAi1 payload states the cryptographic algorithms the Initiator
supports for the IKE SA. The KE payload sends the Initiator's
Diffie-Hellman value. Ni is the Initiator's nonce.

<-- HDR, SAr1, KEr, Nr, [CERTREQ]

The Responder chooses among the Initiator's cryptographic algorithms
and expresses guaranteed that choice in the SAr1 payload, completes the Diffie-
Hellman exchange it will come back with message 3.
For subtle cryptographic reasons, the KEr payload, and sends its nonce in SHOULD contain some
random bits - at least as many random bits as the Nr
payload.

At this point in time each party generates SKEYSEED and its
derivatives. The following two messages, size of the SA_auth and
SA_auth_response, are encrypted and integrity protected (as indicated

Harkins Kaufman Kent Kivinen Perlman [Page 20]

INTERNET DRAFT April 2002
strongest key be generated by the '*' following the IKE header) and the encryption bit in exchange.

It may be convenient for the
IKE header IKE-SA identifier to be an index into a
table. It is set. The keys used not difficult for the encryption and integrity
protection are derived from SK_a and SK_e as described below.

HDR*, IDi, [CERT,] [CERTREQ,] [IDr,] AUTH,
SAi2, TSi, TSr -->

The Initiator identifies herself with to choose an IKE-SA
identifier that is convenient as a table identifier, since the IDi payload and
authenticates herself
Initiator does not need to use it as an anti-clogging token, and is
keeping state. IKEv2 allows the Responder with the AUTH payload, and
begins negotiation of to initially choose a child-SA using the SAi2 payload. The fields
starting
stateless anti-clogging type cookie by responding to an IKE_SA_init
with SAi2 are described in the description of Phase 2.

There are optional fields where the Initiator can provide
certificates [CERT] the Responder might find useful in validating
AUTH, her list of preferred root certifiers [CERTREQ], a cookie request, and the name then upon receipt of the entity an IKE_SA_init with which she is trying to open a connection [IDr]
(for
valid cookie, change his cookie value from the case where multiple named entities exist at computed anti-clogging
token to a single IP
address).

<-- HDR*, IDr, [CERT,] AUTH,
SAr2, TSi, TSr

The Responder identifies himself with an ID payload optionally sends
one or more certificates, authenticates himself with the AUTH
payload, and completes negotiation of convenient value, by sending a child-SA with the additional
fields described below different value for
his cookie in the phase 2 exchange.

3.1 Generating Keying Material IKE_SA_auth_response. This will not confuse the
Initiator (Alice), because she will have chosen a unique cookie value
A, so if her SA state for the partially set up IKE-SA

The shared secret information is computed says that Bob's
cookie for the SA that Alice knows as follows. A quantity
called SKEYSEED "A" is calculated from the nonces exchanged during the
IKE_SA_init exchange, B, and the Diffie-Hellman shared secret
established during she receives a
response from Bob with cookies (A,C), that exchange. SKEYSEED is used means that Bob wants to calculate
three other secrets: SK_d used for deriving new keys for the child-
SAs established with this IKE-SA; SK_a used
change his value from B to C for authenticating the
component messages of subsequent exchanges; and SK_e used for
encrypting (and of course decrypting) all subsequent exchanges.
SKEYSEED and its derivatives are computed SA that Alice knows uniquely as follows:

Harkins Kaufman Kent Kivinen Perlman [Page 21]

INTERNET DRAFT April 2002

SKEYSEED = prf(Ni | Nr, g^ir)
SK_d = prf(SKEYSEED, g^ir | Ni | Nr | CKY-I | CKY-R | 0)
SK_a = prf(SKEYSEED, SK_d | g^ir | Ni | Nr | CKY-I | CKY-R | 1)
SK_e = prf(SKEYSEED, SK_a | g^ir | Ni | Nr | CKY-I | CKY-R | 2)

CKY-I and CKY-R are the Initiator's and Responder's cookies,
respectively, from the IKE header. g^ir
"A".

Another reason why Bob might want to change his cookie value is that
it is possible (though unlikely) that Bob will choose the shared secret from the
ephemeral Diffie-Hellman exchange. Ni and Nr are same cookie
for multiple SAs if the nonces,
stripped hash of any headers. 0, 1, the Initiator IP address, Nr, and 2 are represented by a single
octet containing
whatever other information might be included happens to hash to the value 0, 1, or 2 (the values, not
same value.

In IKEv2, like IKEv1, both 8-octet cookies appear in the ASCII
representation of message, but
in IKEv2 (unlike v1), the digits). prf is value chosen by the "pseudo-random"
cryptographic function negotiated message recipient
always appears first in the IKE-SA-init exchange. message.

The two directions cookies are one of flow use different keys. Keys used to protect
messages from the original initiator are taken from inputs into the first bits of
SK_a and SK_e. Keys used to protect messages in function that computes the other direction
are taken from subsequent bits. Each algorithm takes a fixed number
of bits of
keying material, which is specified as part of the
algorithm. material. If the total number of key bits needed responder changes its cookie to a different
value when it sends its IKE_AUTH_response, it is greater than the
size of cookie value in

IKEv2 [Page 17]

INTERNET DRAFT October 2002

the output of IKE_SA_init_response that is the prf function, input for generating the keying material must be
expanded.

For situations where
material.

4.7 Cryptographic Algorithm Negotiation

The payload type known as "SA" indicates a proposal for a set of
choices of protocols (IKE, ESP, AH, and/or IPcomp) for the amount SA as well
as cryptographic algorithms associated with each protocol. In IKEv1
it was extremely complex, and was one of keying material desired is greater
than that supplied by the prf, KEYMAT is expanded by feeding motivations for revising
the
results spec.

An SA consists of the prf back into itself one or more proposals. Each proposal includes a
Suite-ID, which implies one or more protocols and concatenating results until the required keying material has been reached. associated
cryptographic algorithms.

In other words,

KEYMAT = K1 | K2 | K3 | ...
where:
K1 = prf(SK_x, 0)
K2 = prf(SK_x, K1)
K3 = prf(SK_x, K2)
etc.

where 0 is represented by a single octet containing IKEv2, since the Initiator sends her Diffie-Hellman value 0 (the
value, not in the ASCII representation of
IKE_SA_init, she must guess at the digit), and SK_x is either
SK_e or SK_a depending on which keying material needs expansion.

3.2 Authentication Diffie-Hellman group that Bob will
select from her list of supported groups. Her guess MUST be the IKE-SA

The peers are authenticated by having each sign (or MAC using a
shared secret as the key) the concatenation of their own first
message and
in the other peer's nonce. The octets list to be signed start
with the first octet of allow Bob to unambiguously identify which group the header and end with the last octet of the
last payload. The octets
accompanying KE payload is from. If her guess is incorrect then Bob's
response informs her of the nonce are only the content group he chose, and not includes his KE from
his chosen group. In this case, Alice MUST choose a KE from Bob's
chosen group, compute keys based on her and Bob's values and send the header.

Note that all of payloads of
new KE in message 3.

You might wonder why Alice includes KE in the peer's own first message are

Harkins Kaufman Kent Kivinen Perlman [Page 22]

INTERNET DRAFT April 2002

included under the signature, including payload types not defined in
this document. It is possible given
that some other payloads defined in
the future might appropriately be zeroed before signing, but such a
possibility is not supported by this version of IKE.

Optionally, messages Bob doesn't need it until message 3 and 4 MAY include a certificate, or
certificate chain providing evidence that the key used to compute a
digital signature belongs it could change in
message 3. The reason is to the name allow an optional optimization in Bob.
Bob MAY start his Diffie-Hellman computation as soon as he receives
message 1 and likely complete it by the ID payload. The
signature or MAC time he receives message 3.
This will be computed using algorithms dictated by minimize latency of connection setup in the
type common case
where Alice correctly guesses the Diffie-Hellman group that Bob will
choose. If Bob accepts Alice's first choice of key used by Diffie-Hellman group,
Alice MUST send the signer, an RSA-signed PKCS1-padded-SHA1-hash same value for KE in message 3 as she sent in
message 1.

Note that an RSA digital signature, a DSS-signed SHA1-hash for implementation cannot simultaneously exploit this
optimization and protect itself from a DSA
digital signature, or denial of service attack using
cookies. But an implementation could alternate between the two based
on load.

If none of Alice's options are acceptable, then Bob notifies her
accordingly.

4.8 Rekeying

Security associations negotiated PRF function in both phase 1 and phase 2 contain

IKEv2 [Page 18]

INTERNET DRAFT October 2002

secret keys which may only be used for a pre-shared
key. There is no requirement that the Initiator limited amount of time and Responder sign
with the same cryptographic algorithms. The choice
to protect a limited amount of cryptographic
algorithms depends on data. This determines the type lifetime of key each has. This type is either
indicated in
the certificate supplied or, if entire security association. When the keys were exchanged
out lifetime of band, a security
association expires the key types must have been similarly learned. It will
commonly security association MUST NOT be used. If
there is demand, new security associations can be established.
Reestablishment of security associations to take the case, but it place of ones
which expire is not required that if referred to as "rekeying".

To rekey a shared secret
is used for authentication that child-SA, create a new, equivalent SA (see section 4.17
below), and when the same key new one is used in both
directions. In particular, established, delete the initiator may be using old one. To
rekey an IKE-SA, establish a new equivalent IKE-SA (see section 4.18
below) with the peer to whom the old IKE-SA is shared key
derived from using a password while Phase 2
negotiation within the responder may have a public
signature key and certificate.

4 The CREATE-CHILD-SA (Phase 2) Exchange

A phase 2 exchange is one request/response pair, and can be used to
create or delete a child-SA, delete or rekey existing IKE-SA. An IKE-SA so created inherits
all of the IKE-SA, check original IKE-SA's child SAs. Use the
liveness of new IKE-SA for all
control messages needed to maintain the child-SAs created by the old
IKE-SA, or deliver information such as error
conditions. It is encrypted and integrity protected using the keys
negotiated during delete the creation of old IKE-SA. The Delete payload to delete
itself MUST be the last request sent over an IKE-SA.

Messages are cryptographically protected using

SAs SHOULD be rekeyed proactively, i.e., the cryptographic
algorithms new SA should be
established before the old one expires and keys negotiated in becomes unusable. Enough
time should elapse between the first two messages of time the IKE
exchange using a syntax described in Appendix B. Encryption uses
keys derived from SK_e, one in each direction; Integrity uses keys
derived from SK_a, new SA is established and the
old one in each direction.

Either endpoint may initiate a phase 2 exchange, becomes unusable so in this section
the term Initiator refers that traffic can be switched over to the endpoint initiating this exchange.
When relevant, the Initiator
new SA.

A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
were negotiated. In IKEv2, each end of the IKE SA will be referred to as
such.

A child-SA is created by sending a CREATE_CHILD_SA request. If PFS responsible for
enforcing its own lifetime policy on the child-SA is desired, SA and rekeying the CREATE_CHILD_SA request contains KE
payloads for an additional Diffie-Hellman exchange. The keying
material for the child-SA is a function of SK_d established during
the establishment of SA when
necessary. If the IKE-SA, two ends have different lifetime policies, the nonces exchanged during end
with the
CREATE_CHILD_SA exchange, and shorter lifetime will end up always being the Diffie-Hellman value (if KE

Harkins Kaufman Kent Kivinen Perlman [Page 23]

INTERNET DRAFT April 2002

payloads are included in one to request
the CREATE_CHILD_SA exchange).

In rekeying.

If the child-SA created as part of two ends have the phase 1 exchange, same lifetime policies, it is possible that
both will initiate a second KE
payload MUST NOT be used, and the Nonces are not transmitted but are
assumed to be rekeying at the same as the phase 1 nonces.

The CREATE_CHILD_SA request contains:

Initiator Responder
----------- -----------
HDR*, SA, Ni, [KEi],
TSi, TSr -->

The Initiator sends SA offer(s) time (which will result in
redundant SAs). To reduce the SA payload(s), a nonce in probability of this happening, the
Ni payload, optionally
timing of rekeying requests should be jittered (delayed by a Diffie-Hellman value in the KE payload, and
the proposed traffic selectors random
amount of time).

This form of rekeying will temporarily result in multiple similar SAs
between the TSi and TSr payloads. same pairs of nodes. When there are two SAs eligible to
receive packets, a node MUST accept incoming packets through either
SA. The message past node that initiated the header is encrypted and rekeying SHOULD delete the message including older SA
after the header new one is integrity protected using the cryptographic algorithms
negotiated established.

4.9 Traffic Selector Negotiation

When an IP packet is received by an RFC2401 compliant IPsec subsystem
and matches a "protect" selector in Phase 1.

The CREATE_CHILD_SA response contains:

<-- HDR*, SA, Nr, [KEr],
TSi, TSr

The Responder replies (using its SPD, the same Message ID to respond) subsystem MUST
protect that packet with IPsec. When no SA exists yet it is the
accepted offer task

IKEv2 [Page 19]

INTERNET DRAFT October 2002

of IKE to create it. Information about the traffic that needs
protection is transmitted to the IKE subsystem in an SA payload, a Diffie-Hellman value manner outside
the scope of this document (see [PFKEY] for an example). This
information is negotiated between the two IKE endpoints using TS
(Traffic Selector) payloads.

Two TS payloads appear in each of the KE messages in the exchange that
creates a child-SA pair. Each TS payload if contains one or more Traffic
Selectors. Each Traffic Selector consists of an address range (IPv4
or IPv6), a port range, and only if the Initiator included one, a protocol ID.

IKEv2 is more flexible than IKEv1. IKEv2 allows sets of ranges of
both addresses and ports, and allows the traffic
selectors for traffic responder to be sent on that SA in the TS payloads, which
may be choose a subset
of what the Initiator requested traffic rather than simply responding "not
acceptable". This could happen when the configuration of the child-SA proposed.

4.1 Generating Keying Material for IPsec SAs

Child-SAs two
endpoints are created either by being piggybacked on updated but only one end has received the phase 1
exchange, or new
information. Since the two endpoints may be configured by different
people, the incompatibility may persist for an extended period even
in a phase 2 CREATE_CHILD_SA exchange. Keying material the absense of errors. It allows for them is generated intentionally different
configurations, as follows:

KEYMAT = prf(SK_d, protocol | SPI | Nin | Nout )

For phase 2 exchanges with PFS when one end is configured to tunnel all addresses
and depends on the keying material other end to have the up to date list.

The first of the two TS payloads is defined as:

KEYMAT = prf(SK_d, g(p2)^ir | protocol | SPI | Nin | Nout )

where g(p2)^ir known as TSi (Traffic Selector-
initiator). The second is known as TSr (Traffic Selector-responder).
TSi specifies the shared secret source address of traffic forwarded from (or the ephemeral Diffie-Hellman
exchange
destination address of this phase 2 exchange,

In either case, "protocol", and "SPI", are from traffic forwarded to) the SA payload that

Harkins Kaufman Kent Kivinen Perlman [Page 24]

INTERNET DRAFT April 2002

contained initiator of the negotiated (and accepted) proposal, Nin is
child-SA pair. TSr specifies the body destination address of the sender's (inbound using thie SPI) nonce payload minus traffic
forwarded from (or the generic
header, and Nout is source address of the traffic forwarded to)
the body responder of the destination's (outbound using
this SPI) nonce payload minus child-SA pair. For example, if Alice initiates
the creation of the generic header.

A single child-SA negotiation results in two security associations--
one inbound and one outbound. Different Nonces pair from Alice to Bob, and SPIs for wishes to
tunnel all traffic from subnet 10.2.16.* on Alice's side to subnet
18.16.*.* on Bob's side, Alice would include a single traffic
selector in each SA
(one chosen by TS payload. TSi would specify the Initiator, address range
(10.2.16.0 - 10.2.16.255) and TSr would specify the other by address range
(18.16.0.0 - 18.16.255.255). Assuming that proposal was acceptable to
Bob, he would send identical TS payloads back.

The Responder is allowed to narrow the Responder) guarantee choices by selecting a
different key subset
of the traffic, for each direction. The SPI chosen instance by eliminating or narrowing the destination range of
one or more members of the SA and set of traffic selectors, provided the Nonces (ordered source followed by destination) are
used to derive KEYMAT set
does not become the NULL set.

It is possible for that SA.

This keying material (whether with PFS or without) MUST be used the Responder's policy to contain multiple smaller
ranges, all encompassed by the Initiator's traffic selector, and with
the negotiated Responder's policy being that each of those ranges should be sent
over a different SA. In Continuing the case example above, Bob might have a
policy of being willing to tunnel those addresses to and from Alice,
but might require that each address pair be on a separately

IKEv2 [Page 20]

INTERNET DRAFT October 2002

negotiated child-SA. If Alice generated her request in response to an ESP SA needing two keys
incoming packet from 10.2.16.43 to 18.16.2.123, there would be no way
for
encryption and authentication, the encryption key Bob to determine which pair of addresses it is taken from most urgent to
tunnel, and he would have to make his best guess or reject the
first octets
request with a status of KEYMAT and SINGLE-PAIR-REQUIRED.

To enable Bob to choose the authentication key is taken from appropriate range in this case, if Alice
has initiated the
next octets. Each cryptographic algorithm takes SA due to a fixed number of
bits of keying material specified data packet, Alice MAY include as part the
first traffic selector in each of TSi and TSr a very specific traffic
selector including the algorithm.

For situations where addresses in the amount of keying material desired is greater
than that supplied by packet triggering the prf, KEYMAT is expanded by feeding
request. In the
results of example, Alice would include in TSi two traffic
selectors: the prf back into itself first containing the address range (10.2.16.43 -
10.2.16.43) and concatenating results until the required keying material has been reached. In other words,

KEYMAT = K1 | K2 | K3 | ...
where:
K1 = prf(SK_d, [ g(p2)^ir | ] protocol | SPI | Nin | Nout)
K2 = prf(SK_d, K1 | [ g(p2)^ir | ] protocol | SPI | Nin | Nout)
K3 = prf(SK_d, K2 | [ g(p2)^ir | ] source port and protocol | SPI | Nin | Nout)
etc.

4.2 Generating Keying Material for IKE-SAs from a create-child exchange

The create-child exchange can be used to re-key an existing IKE-SA
(see section 2.8). New Initiator and Responder cookies are supplied
in the SPI fields. The ID packet and TS payloads are omitted when rekeying
an IKE-SA. SKEYSEED for the new IKE-SA is computed using SK_d from
the existing IKE-SA as follows:

SKEYSEED = prf(SK_d (old), [g(p2)^ir] | 0 | CKY-I | CKY-R | Ni |
Nr)

where g(p2)^ir is the shared secret from
second containing (10.2.16.0 - 10.2.16.255) with all ports and
protocols. She would similarly include two traffic selectors in TSr.

If Bob's policy does not allow him to accept the ephemeral Diffie-Hellman
exchange entire set of this phase 2 exchange, CKY-I is the 8-octet "SPI" from
the SA payload
traffic selectors in the CREATE_CHILD_SA Alice's request, CKY-R is but does allow him to accept
the 8-octet
"SPI" from first selector of TSi and TSr, then Bob MUST narrow the SA payload traffic
selectors to a subset that includes Alice's first choices. In this
example, Bob might respond with TSi being (10.2.16.43 - 10.2.16.43)
with all ports and protocols.

If Alice creates the child-SA pair not in response to an arriving
packet, but rather - say - upon startup, then there may be no
specific data packet to describe. In that case, the CREATE_CHILD_SA response, and Ni first values in
TSi and
Nr TSr are the two nonces stripped of any headers. "0" is ranges rather than specific values, and Bob chooses a single octet
containing the value zero (the protocol ID
subset of IKE).

Harkins Kaufman Kent Kivinen Perlman [Page 25]

INTERNET DRAFT April 2002

The new IKE SA MUST reset its message counters to 1.

SK_d, SK_a, Alice's TSi and SK_e TSr that are computed from SKEYSEED as specified in
section 3.1.

5 Informational (Phase 2) Exchange

At various points during an IKE-SA, peers may desire to convey
control messages acceptable to each other regarding errors or notifications of
certain events. To accomplish this IKE defines a (reliable)
Informational exchange. Usually Informational exchanges happen
during phase 2 him. If more
than one subset is acceptable but their union is not, Bob MUST accept
some subset and are cryptographically protected with the IKE
exchange.

Control messages that pertain MAY include a NOTIFY payload of type ADDITIONAL-TS-
POSSIBLE to an IKE-SA MUST be sent under that
IKE-SA. Control messages indicate that pertain Alice might want to Child-SAs MUST be sent under
the protection of the IKE-SA which generated them (or its successor
if try again.

4.10 Nonces

The IKE_SA_init and the IKE-SA keys are rolled over).

There IKE_SA_init_response each contain a nonce.
These nonces are two cases in which there is no IKE-SA used as inputs to protect the
information. One is in cryptographic functions. The
CREATE_CHILD_SA request and the CREATE_CHILD_SA response also contain
nonces. These nonces are used to an IKE_SA_init_request to
request a cookie or add freshness to refuse the SA proposal. This would be conveyed key derivation
technique used to obtain keys for child SAs. Nonces used in a Notify payload IKEv2
MUST therefore be unique (either deterministically by use of the IKE_SA_init_response.

The other case in which there is no IKE-SA to protect the information
is when a packet is received with an unknown SPI. In that case the
notification
timestamps and sequence numbers or probabilistically by use of this condition will be sent in an informational
exchange that is cryptographically unprotected.

Messages in an Informational Exchange contain zero or more
Notification or Delete payloads. The Recipient of an Informational
Exchange request MUST send some response (else the Sender will assume
the message was lost in the network and will retransmit it). That
response can be a message with no payloads. Actually, the request
message in an Informational Exchange can also contain no payloads.
This is the expected way an endpoint can ask the other endpoint to
verify that it is alive.
strong pseudo-random number generator).

4.11 Address and Port Agility

IKE runs over UDP port 500, and implicitly sets up ESP, AH, and
IPcomp SAs always exist in pairs, with one SA in each
direction. When an SA is closed, both members of the pair MUST be
closed. When SAs are nested, as when data is encapsulated first with
IPcomp, then with ESP, and finally with AH between associations for the same pair of
endpoints, all of the SAs (up to six) must be deleted together. To
delete an SA, an Informational Exchange with one or more delete
payloads is sent listing the SPIs (as known to the recipient) of the
SAs to be deleted. IP addresses it runs over. The recipient MUST close the designated SAs.
Normally, the reply in the Informational Exchange will contain delete
payloads for the paired SAs going IP
addresses and ports in the other direction. There is

Harkins Kaufman Kent Kivinen Perlman outer header are, however, not themselves

IKEv2 [Page 26] 21]

INTERNET DRAFT April October 2002

one exception. If by chance both ends of a set of SAs independently
decide

cryptographically protected, and IKE is designed to close them, each may send a delete payload work even through
Network Address Translation (NAT) boxes. An implementation MUST
accept incoming connection requests even if not received from UDP
port 500, and should respond to the two address and port from which the
request was received. An implementation MUST, however, accept
incoming requests may cross only on UDP port 500 and send all responses from
UDP port 500. IKE functions identically over IPv4 or IPv6.

4.12 Reuse of Diffie-Hellman Exponentials

IKE generates keying material using an ephemeral Diffie-Hellman
exchange in order to gain the network. If a node receives a delete
request for SAs property of "perfect forward secrecy".
This means that it has already issued once a delete request for, it
MUST delete connection is closed and its corresponding
keys are forgotten, even someone who has recorded all of the incoming SAs while processing data
from the request connection and gets access to all of the
outgoing SAs while processing long term keys of
the response. In two endpoints cannot reconstruct the keys used to protect the
conversation.

Achieving perfect forward secrecy requires that case, when a connection is
closed, each endpoint must forget not only the
responses MUST NOT include delete payloads for keys used by the deleted SAs, since
connection but any information that would result in duplicate deletion and could be used to recompute those
keys. In particular, it must forget the secrets used in theory delete the wrong SA.

A node SHOULD regard half open connections as anomalous Diffie-
Hellman calculation and audit
their existence should they persist. Note any state that this specification
nowhere specifies time periods, so it is up to individual endpoints
to decide how long to wait. A node MAY refuse to accept incoming data
on half open connections but MUST NOT unilaterally close them and
reuse may persist in the SPIs. If connection state becomes sufficiently messed up, of a
node MAY close
pseudo-random number generater that could be used to recompute the IKE-SA which will implicitly close all SAs
negotiated under it. It can then rebuild
Diffie-Hellman secrets.

Since the SA's it needs on a clean
base under a new IKE-SA.

The Informational Exchange is defined as:

Initiator Responder
----------- -----------
HDR*, N, ..., D, ... -->
<-- HDR*, N, ..., D, ...

The processing computing of an Informational Exchange Diffie-Hellman exponentials is determined by its
component payloads.

6 Error Handling computationally
expensive, an endpoint may find it advantageous to reuse those
exponentials for multiple connection setups. There are many kinds of errors that can occur during IKE processing.
If a request is received that is badly formatted or unacceptable several
reasonable strategies for
reasons of policy (e.g. no matching cryptographic algorithms), the
response MUST contain doing this. An endpoint could choose a Notify payload indicating the error. If an
error occurs outside new
exponential periodically though this could result in less-than-
perfect forward secrecy if some connection lasts for less than the context
lifetime of an IKE request (e.g. the node is
getting ESP messages on a non-existent SPI), exponential. Or it could keep track of which
exponential was used for each connection and delete the node SHOULD initiate
an Informational Exchange information
associated with a Notify payload describing the
problem.

Errors that occur before a cryptographically protected IKE-SA is
established must be handled very carefully. There is a trade-off
between wanting exponential only when some corresponding
connection was closed. This would allow the exponential to be helpful in diagnosing a problem and responding reused
without losing perfect forward secrecy at the cost of maintaining
more state.

Decisions as to it whether and wanting when to avoid being reuse Diffie-Hellman exponentials
is a dupe private decision in a denial of service attack
based on forged messages.

If a node receives a message the sense that it will not affect
interoperability. An implementation that reuses exponentials may
choose to remember the exponential used by the other endpoint on UDP port 500 outside past
exchanges and if one is reused to avoid the context second half of

Harkins Kaufman Kent Kivinen Perlman the
calculation.

4.13 Generating Keying Material

IKEv2 [Page 27] 22]

INTERNET DRAFT April October 2002

an IKE-SA (and not a request to start one), it may be

In the result context of a
recent crash. If the message is marked as a response, the node MAY
audit the suspicious event but MUST NOT respond. If the message is
marked as IKE SA, three cryptographic algorithms are
negotiated: an encryption algorithm, a request, the node MAY audit the suspicious event Diffie-Hellman group, and MAY
send a response. If a response
pseudo-random function (prf). The pseudo-random function is sent, the response MUST be sent to used both
for integrity protection of the IP address IKE payloads and port from whence it came with for the IKE cookies
reversed construction
of keying material for all of the cryptographic algorithms used in
both the header IKE SA and the Message ID copied. The response MUST
NOT be cryptographically protected Child-SAs.

We assume that each cryptographic algorithm accepts a fixed size key,
and MUST contain that any randomly chosen value of that fixed size can serve as an
appropriate key. For functions that accept a notify payload
indicating INVALID-COOKIE.

A node receiving such variable length key, a message MUST NOT respond and
fixed key size MUST NOT change be specified as part of the state cryptographic suite
negotiated. For prf functions based on HMAC, the fixed key size is
the size of any existing SAs. The message might be a forgery or
might be a response the genuine correspondent was tricked into
sending. A node SHOULD treat such a message (and also a network
message like ICMP destination unreachable) as a hint that there might output of the HMAC.

Keying material will always be problems with SAs to that IP address and SHOULD initiate a
liveness test for any such IKE-SA. An implementation SHOULD limit derived as the
frequency output of such tests to avoid being tricked into participating in
a denial the
negotiated prf algorithm. If the amount of service attack.

A node receiving a suspicious message from an IP address with which
it has an IKE-SA MAY send an IKE notify payload in an IKE
Informational exchange over that SA. The recipient MUST NOT change keying material is greater
than the state size of any SA's as a result but SHOULD audit the event to aid
in diagnosing malfunctions. A node MUST limit output of the rate at which it prf algorithm, we will send messages in response to unprotected messages.

7 Header and Payload Formats

7.1 The IKE Header

IKE messages use UDP port 500, with one IKE message per UDP datagram.
Information from the UDP header is largely ignored except that prf
iteratively. We will use the IP
addresses and UDP ports from terminology prf+ to describe the headers
function that outputs a pseudo-random stream based on the inputs to a
prf as follows:

prf+ (K,S) = T1 | T2 | T3 | T4 | ...

where:
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)

as needed to compute all required keys. The keys are reversed and used for
return packets. Each IKE message begins with taken from the IKE header, denoted
HDR in this memo. Following
output string without regard to boundaries (e.g. if the header required keys
are one or more IKE payloads
each identified by a "Next Payload" field in 256 bit AES key and a 160 bit HMAC key, and the preceding payload.
Payloads are processed in prf function
generates 160 bits, the order in which they appear in an IKE
message by invoking AES key will come from T1 and the appropriate processing routine according to beginning
of T2, while the "Next Payload" field in HMAC key will come from the IKE header rest of T2 and subsequently according
to the "Next Payload" field in the IKE payload itself until a "Next
Payload" field
beginning of zero indicates that no payloads follow. T3).

The Recipient SPI in constant concatenated to the header identifies an instance end of an IKE
security association. It each string feeding the prf
is therefore possible for a single instance
of IKE to multiplex distinct sessions with multiple peers.

Harkins Kaufman Kent Kivinen Perlman [Page 28]

INTERNET DRAFT April 2002

The format octet. prf+ in this document is not defined beyond 255
times the size of the IKE header is shown in Figure 1.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Recipient !
! SPI (aka Cookie) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sender !
! SPI (aka Cookie) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Message ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Initialization Vector ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: IKE Header Format

o Recipient SPI (aka Cookie) (8 octets) - A value chosen by prf output.

4.14 Generating Keying Material for the
recipient to identify a unique IKE security association.
[NOTE: this IKE-SA

The shared keys are computed as follows. A quantity called SKEYSEED
is a deviation calculated from ISAKMP and IKEv1, where the
cookies were always sent with the Initiator of nonces exchanged during the IKE-SA's
cookie first IKE_SA_init
exchange and the Responder's second. See section 2.6.]

o Sender SPI (aka Cookie) (8 octets) - A value chosen by the
sender Diffie-Hellman shared secret established during that
exchange. SKEYSEED is used to identify calculate three other secrets: SK_d
used for deriving new keys for the child-SAs established with this
IKE-SA; SK_a used as a unique IKE security association.

o Next Payload (1 octet) - Indicates key to the type of payload that
immediately follows prf algorithm for authenticating

IKEv2 [Page 23]

INTERNET DRAFT October 2002

the header. The format component messages of subsequent exchanges; and value SK_e used for
encrypting (and of each
payload is defined below.

o Major Version (4 bits) - indicates the major version course decrypting) all subsequent exchanges.
SKEYSEED and its derivatives are computed as follows:

SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d, SK_ai, SK_ar, SK_ei, SK_er}
= prf+ (SKEYSEED, Ni | Nr | CKY-I | CKY-R)

g^ir is the shared secret from the ephemeral Diffie-Hellman exchange.
Ni and Nr are the nonces, stripped of any headers.

The two directions of flow use different keys. The keys used to
protect messages from the IKE
protocol original initiator are SK_ai and SK_ei. The
keys used to protect messages in use. Implementations based on this version the other direction are SK_ar and
SK_er. Each algorithm takes a fixed number of bits of keying
material, which is specified as part of IKE
MUST set the Major Version to 2. Implementations algorithm. For integrity
algorithms based on
previous versions of IKE and ISAKMP MUST set HMAC, the Major Version key size is always equal to 1. Implementations based on this version the length
of IKE MUST reject the underlying hash function.

4.15 Authentication of the IKE-SA

The peers are authenticated by having each sign (or ignore) messages containing MAC using a version number greater than
2.

o Minor Version (4 bits) - indicates
shared secret as the minor version key) a block of data. For the
IKE protocol in use. Implementations based on this version of
IKE MUST set responder, the Minor Version
octets to 0. They MUST ignore be signed start with the minor
version number first octet of received messages.

o Exchange Type (1 octet) - indicates the type header of exchange being

Harkins Kaufman Kent Kivinen Perlman [Page 29]

INTERNET DRAFT April 2002

used. This dictates the payloads sent in each
second message and
message orderings end with the last octet of the last payload in the exchanges.

Exchange Type Value

RESERVED 0
Reserved for ISAKMP 1 - 31
Reserved for IKEv1 32 - 33
Phase One 34
CREATE-CHILD-SA 35
Informational 36
Reserved for IKEv2+ 37-239
Reserved for private use 240-255

o Flags (1 octet) - indicates specific options that are set for
the
second message. Presence Appended to this (for purposes of options are indicated by computing the
appropriate bit in
signature) is the flags field being set. initiator's nonce Ni (just the value, not the
payload containing it). The bits are
defined LSB first, so bit 0 would be initiator signs the least significant
bit unencrypted part of
message 3, starting with the Flags octet. In the description below, a bit
being 'set' means its value is '1', while 'cleared' means
its value is '0'.

-- E(ncryption) (bit 0 first octet of Flags) - If set, all payloads
following the IKE header are encrypted and integrity
protected using ending
with the algorithms negotiated during
session establishment and a key derived during last octet of the last unencrypted payload. Note that
message 3 includes Nr, so it does not need to be appended in order to
be included under the signature. It is critical to the security of
the key exchange portion that each side sign the other side's nonce.

Note that all of IKE. If cleared, the payloads are included under the signature,
including any payload types not protected. All payloads MUST be protected if defined in this document.

Optionally, messages 3 and 4 MAY include a certificate, or
certificate chain providing evidence that the key
has been negotiated and any unprotected payload may
only be used to establish compute a new session
digital signature belongs to the name in the ID payload. The
signature or indicate a
problem.

-- C(ommit) (bit 1 of Flags) - This bit is defined by
ISAKMP but not used by IKEv2. Implementations of IKEv2
MUST clear this bit when sending and SHOULD ignore
it in incoming messages.

-- A(uthentication Only) (bit 2 of Flags) - This bit is
defined by ISAKMP but not used by IKEv2. Implementations
of IKEv2 MUST clear this bit when sending and SHOULD
ignore it in incoming messages.

-- I(nitiator) (bit 3 of Flags) - This bit MUST MAC will be set in
messages sent computed using algorithms dictated by the original Initiator
type of the IKE
exchange and MUST be cleared in messages sent key used by the original Responder. It signer, an RSA-signed PKCS1-padded-hash for
an RSA digital signature, a DSS-signed SHA1-hash for a DSA digital
signature, or the negotiated PRF function for a pre-shared key.
There is
used by no requirement that the recipient to determine whether Initiator and Responder sign with
the message
number should be interpreted in same cryptographic algorithms. The choice of cryptographic
algorithms depends on the context type of its

Harkins Kaufman Kent Kivinen Perlman key each has. This type is either
indicated in the certificate supplied or, if the keys were exchanged

IKEv2 [Page 30] 24]

INTERNET DRAFT April October 2002

initiating state or its responding state.

-- V(ersion) (bit 4

out of Flags) - This bit indicates that band, the transmitter key types must have been similarly learned. It will
commonly be the case (but it is capable of speaking not required) that if a higher major
version number of the protocol than shared secret
is used for authentication that the one indicated same key is used in both
directions. In particular, the major version number field.

-- R(eserved) (bits 5-7 of Flags) - These bit MUST initiator may be
cleared in messages sent using a shared key
while the responder may have a public signature key and received messages with
these bits set MUST be rejected.

o Message ID (4 octets) - Message identifier used certificate.
Note that it is a common but insecure practice to control
retransmission of lost packets and matching of requests and
responses. See section 2.2. have a shared key
derived from a user chosen password. This is insecure because user
chosen passwords are unlikely to have sufficient randomness to resist
dictionary attacks. The pre-shared key SHOULD contain as much
randomness as the strongest key being negotiated. In the first message case of a Phase 1
negotiation,
pre-shared key, the AUTH value MUST is computed as:

AUTH = prf(Shared Secret | "Key Pad for IKEv2", <message bytes>)
where the string "Key Pad for IKEv2" is ASCII encoded and not null
terminated. The shared secret can be set to 0. variable length. The response to pad string
is added so that
message MUST also have if the shared secret is derived from a Message ID of 0.

o Length (4 octets) - Length password,
this exchange will not compromise use of total message (header + payloads) the same password in octets. Session encryption can expand other
protocols.

Note that the size of an IKE
message and requirement that is reflected in the total length of responder sign the
message.

o Initialization Vector (variable) - random octets used to
provide
initialization to an encryption mode-- e.g.
cipher block chaining (CBC) mode. This field MUST be present content of
message 2 in message 4 introduces some special challenges when the encryption bit
responder is set in the flags field (see below) not maintaining state between messages 2 and MUST NOT be present otherwise. The length of 4 (see
Section 4.6). Either the
Initialization Vector is cipher and mode dependent.

7.2 Generic Payload Header

Each IKE payload defined in sections 7.3 through 7.13 begins with a
generic header, shown in Figure 2. Figures for each payload below
will include the generic payload header but responder must be able to regenerate message
2 octet for brevity a repeat of octet from the description of each field will information in message 3, or it must
encode in its nonce enough information to be omitted. The construction and
processing of able to construct the generic payload header is identical for each
payload and will similarly be omitted.

1 2 3
0 1 2 3 4 5 6 7 8 9 0 1
signature on message 2 after message 3 4 5 6 7 8 9 0 is returned.

4.16 Generating Keying Material for CHILD-SAs

Child-SAs are created either by being piggybacked on the phase 1
exchange, or in a phase 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Generic Payload Header

The Generic Payload Header fields are defined CREATE_CHILD_SA exchange. Keying material
for them is generated as follows:

Harkins Kaufman Kent Kivinen Perlman [Page 31]

INTERNET DRAFT April 2002

o Next Payload (1 octet) - Identifier for the payload type of the
next payload in

KEYMAT = prf+(SK_d, Ni | Nr)

Where Ni and Nr are the message. If Nonces from the current payload IKE_init exchange if this
request is the last
in first CHILD-SA created or the message, then fresh Ni and Nr from the
CREATE_CHILD_SA exchange if this field will be 0. This field provides
a "chaining" capability whereby additional payloads can be
added to is a message by appending it to subsequent creation.

For phase 2 exchanges with PFS the end of keying material is defined as:

KEYMAT = prf+(SK_d, g^ir (ph2) | Ni | Nr )

where g^ir (ph2) is the message
and setting shared secret from the "Next Payload" field ephemeral Diffie-
Hellman exchange of the preceding payload
to indicate the new payload's type.

o Critical (1 bit) - MUST this phase 2 exchange,

A single child-SA negotiation may result in multiple security
associations. ESP, AH, and IPcomp SAs exist in pairs (one in each

IKEv2 [Page 25]

INTERNET DRAFT October 2002

direction), and six SAs could be set to zero created in a single child-SA
negotiation if a combination of ESP, AH, and IPcomp is being
negotiated. KEYMAT is generated as described in section 4.13.

Keying material is taken from the sender wants expanded KEYMAT in the recipient to skip this payload if he does not
understand following
order:

All keys for SAs carrying data from the payload type code. MUST be set initiator to one if the
sender wants the recipient to reject this entire message
if he does not understand this payload type. MUST be ignored
by recipient if responder
are taken before SAs going in the recipient understands reverse direction.

If multiple protocols are negotiated, keying material is taken in
the payload type
code. MUST be set to zero for payload types defined order in this
document. Note that which the critical bit applies to protocol headers will appear in the current
payload rather than
encapsulated packet.

If a single protocol has both encryption and authentication keys,
the "next" payload whose type code
appears in encryption key is taken from the first octet. The reasoning behind not setting
the critical bit for payloads defined in this document is
that all implementations MUST understand all payload types
defined in this document and therefore must ignore its value.

o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored.

o Payload Length (2 octets) - Length in octets of KEYMAT and
the current
payload, including the generic payload header.

7.3 Security Association Payload

The Security Association Payload, denoted SA in this memo, authentication key is used to
negotiate attributes of taken from the next octets.

Each cryptographic algorithm takes a security association. Assembly fixed number of Security
Association Payloads requires great peace bits of mind. An SA may contain
multiple proposals. Each proposal may contain multiple protocols
(where keying
material specified as part of the algorithm.

4.17 Rekeying IKE-SAs using a protocol is IKE, ESP, AH, or IPCOMP), each protocol may
contain multiple transforms, and each transform may contain multiple
attributes. When parsing CREATE_CHILD_SA exchange

The CREATE_CHILD_SA exchange can be used to re-key an SA, existing IKE-SA
(see section 4.8). New Initiator and Responder cookies are supplied
in the SPI fields. The TS payloads are omitted when rekeying an implementation MUST check that IKE-
SA. SKEYSEED for the
total Payload Length new IKE-SA is consistent with computed using SK_d from the payload's internal
lengths
existing IKE-SA as follows:

SKEYSEED = prf(SK_d (old), [g^ir (ph2)] | Ni | Nr)

where g^ir (ph2) is the shared secret from the ephemeral Diffie-
Hellman exchange of this phase 2 exchange and counts. Proposals, Transforms, Ni and Attributes each have
their own variable length encodings. They Nr are nested such that the
Payload Length two
nonces stripped of an any headers.

The new IKE SA includes the combined contents of the SA,
Proposal, Transform, MUST reset its message counters to 0.

SK_d, SK_ai, SK_ar, and Attribute information. The length SK_ei, and SK_er are computed from SKEYSEED
as specified in section 4.14.

4.18 Error Handling

There are many kinds of errors that can occur during IKE processing.
If a
Proposal includes the lengths of all Transforms and Attributes it
contains. The length request is received that is badly formatted or unacceptable for
reasons of policy (e.g. no matching cryptographic algorithms), the
response MUST contain a Transform includes Notify payload indicating the lengths of all
Attributes it contains.

The syntax error. If an
error occurs outside the context of Security Associations, Proposals, Transforms, and
Attributes an IKE request (e.g. the node is based
getting ESP messages on ISAKMP, however the semantics are somewhat
different. The reason for the complexity and a non-existent SPI), the hierarchy is to

Harkins Kaufman Kent Kivinen Perlman node SHOULD initiate

IKEv2 [Page 32] 26]

INTERNET DRAFT April October 2002

allow for multiple possible combinations of algorithms

an Informational Exchange with a Notify payload describing the
problem.

Errors that occur before a cryptographically protected IKE-SA is
established must be handled very carefully. There is a trade-off
between wanting to be encoded helpful in diagnosing a single SA. Sometimes there is problem and responding
to it and wanting to avoid being a choice dupe in a denial of multiple algorithms,
while other times there is service attack
based on forged messages.

If a combination node receives a message on UDP port 500 outside the context of algorithms. For example,
an Initiator might want IKE-SA (and not a request to propose using (AH w/MD5 and ESP w/3DES) OR
(ESP w/MD5 and 3DES).

One of the reasons start one), it may be the semantics result of a
recent crash. If the SA payload has changed from
ISAKMP and IKEv1 message is to make the encodings more compact in common
cases.

The Proposal structure contains within it a Proposal # and marked as a
Protocol-id. Each structure response, the node MAY
audit the suspicious event but MUST have NOT respond. If the same Proposal # message is
marked as a request, the
previous one or one greater. The first Proposal MUST have node MAY audit the suspicious event and MAY
send a Proposal
# of one. response. If two successive structures have a response is sent, the same Proposal number,
it means that response MUST be sent to
the proposal consists of IP address and port from whence it came with the first structure AND IKE cookies
reversed in the
second. So a proposal of AH AND ESP would have two proposal
structures, one for AH header and one for ESP the Message ID copied. The response MUST
NOT be cryptographically protected and both would have Proposal
#1. MUST contain a notify payload
indicating INVALID-COOKIE.

A proposal of AH OR ESP would have two proposal structures, one
for AH with proposal #1 node receiving such a message MUST NOT respond and one for ESP with proposal #2.

Each Proposal/Protocol structure is followed by one or more transform
structures. The number MUST NOT change
the state of different transforms is generally
determined by any existing SAs. The message might be a forgery or
might be a response the Protocol. AH generally has genuine correspondent was tricked into
sending. A node SHOULD treat such a single transform: an
integrity check algorithm. ESP generally has two: an encryption
algorithm AND an integrity check algorithm. IKE generally has five
transforms: message (and also a Diffie-Hellman group, an authentication algorithm, an
integrity check algorithm, network
message like ICMP destination unreachable) as a PRF algorithm, and an encryption
algorithm. For each Protocol, the set of permissible transforms are
assigned transform ID numbers, which appear in the header of each
transform.

If hint that there are multiple transforms with the same Transform Type, the
proposal is an OR of those transforms. If there are multiple
Transforms might
be problems with different Transform Types, the proposal is an AND of
the different groups. For example, SAs to propose ESP with (3DES or IDEA)
and (HMAC-MD5 or HMAC-SHA), the ESP proposal would contain two
Transform Type 1 candidates (one for 3DES and one for IDEA) and two
Transform Type 2 candidates (one for HMAC-MD5 that IP address and one SHOULD initiate a
liveness test for HMAC-SHA).
This effectively proposes four combinations of algorithms. If any such IKE-SA. An implementation SHOULD limit the
Initiator wanted
frequency of such tests to propose only avoid being tricked into participating in
a subset denial of those - say (3DES and
HMAC-MD5) or (IDEA and HMAC-SHA), there is no way to encode that as
multiple transforms within service attack.

A node receiving a single Proposal/Protocol. Instead, the
Initiator would have to construct two different Proposals, each suspicious message from an IP address with
two transforms.

A given transform which
it has an IKE-SA MAY have one or more Attributes. Attributes are
necessary when the transform can be used send an IKE notify payload in more than one way, as
when an encryption algorithm has a variable key size. The transform

Harkins Kaufman Kent Kivinen Perlman [Page 33]

INTERNET DRAFT April 2002

would specify the algorithm and the attribute would specify the key
size. Most transforms do not have attributes.

Note IKE
Informational exchange over that SA. The recipient MUST NOT change
the semantics state of Transforms and Attributes are quite
different than in IKEv1. In IKEv1, a single Transform carried
multiple algorithms for any SA's as a protocol with one carried in the Transform
and result but SHOULD audit the others carried event to aid
in diagnosing malfunctions. A node MUST limit the Attributes.

1 2 3
0 1 2 3 4 5 6 7 rate at which it
will send messages in response to unprotected messages.

5 Header and Payload Formats

5.1 The IKE Header

IKE messages use UDP port 500, with one IKE message per UDP datagram.
Information from the UDP header is largely ignored except that the IP
addresses and UDP ports from the headers are reversed and used for
return packets. Each IKE message begins with the IKE header, denoted
HDR in this memo. Following the header are one or more IKE payloads
each identified by a "Next Payload" field in the preceding payload.
Payloads are processed in the order in which they appear in an IKE

IKEv2 [Page 27]

INTERNET DRAFT October 2002

message by invoking the appropriate processing routine according to
the "Next Payload" field in the IKE header and subsequently according
to the "Next Payload" field in the IKE payload itself until a "Next
Payload" field of zero indicates that no payloads follow. If a
payload of type "Encrypted" is found, that payload is decrypted and
its contents parsed as additional payloads. An Encrypted payload must
be the last payload in a packet and an encrypted payload may not
contain another encrypted payload.

The Recipient SPI in the header identifies an instance of an IKE
security association. It is therefore possible for a single instance
of IKE to multiplex distinct sessions with multiple peers.

The format of the IKE header is shown in Figure 1.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED Recipient ! Payload Length
! SPI (aka Cookie) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sender !
~ <Proposals> ~
! SPI (aka Cookie) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Security Association Payload

o Proposals (variable) - one or more proposal substructures.

The payload type for the Security Association Payload is one (1).

7.3.1 Proposal Substructure

1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 (last) or 2
! RESERVED Next Payload ! Proposal Length MjVer !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MnVer ! Proposal # Exchange Type ! Protocol-Id Flags ! SPI Size !# of Transforms!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Message ID !
~ <Transforms> ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Proposal Substructure 1: IKE Header Format

o 0 (last) or 2 (more) (1 octet) Recipient SPI (aka Cookie) (8 octets) - Specifies whether this is A value chosen by the
last Proposal Substructure in
recipient to identify a unique IKE security association. For
the SA. This syntax first packet of an IKE_SA_init, this value MUST be zero.
It MUST NOT be zero for any other packet.
[NOTE: this is inherited a deviation from ISAKMP, but is unnecessary because ISAKMP and IKEv1, where the last Proposal
could be identified from
cookies were always sent with the length Initiator of the SA. The value (2)
corresponds to a Payload Type of Proposal, IKE-SA's
cookie first and the first
four octets of Responder's second. See section 3.6.]

o Sender SPI (aka Cookie) (8 octets) - A value chosen by the Proposal structure are designed
sender to look

Harkins Kaufman Kent Kivinen Perlman [Page 34]

INTERNET DRAFT April 2002

somewhat like the header of identify a Payload.

o RESERVED (1 octet) - unique IKE security association. This
value MUST NOT be sent as zero; MUST be ignored. zero.

o Proposal Length (2 octets) Next Payload (1 octet) - Length Indicates the type of this proposal,
including all transforms and attributes payload that follow.
immediately follows the header. The format and value of each
payload is defined below.

IKEv2 [Page 28]

INTERNET DRAFT October 2002

o Proposal # (1 octet) Major Version (4 bits) - When a proposal is made, indicates the first
proposal major version of the IKE
protocol in an SA MUST be #1, and subsequent proposals use. Implementations based on this version of IKE
MUST either be the same as set the Major Version to 2. Implementations based on
previous proposal (indicating
an AND versions of IKE and ISAKMP MUST set the two proposals) or one more than the previous
proposal (indicating an OR Major Version
to 1. Implementations based on this version of the two proposals). When IKE MUST reject
(or ignore) messages containing a
proposal is accepted, all version number greater than
2.

o Minor Version (4 bits) - indicates the minor version of the proposal numbers
IKE protocol in use. Implementations based on this version of
IKE MUST set the
SA must be the same and must match Minor Version to 0. They MUST ignore the minor
version number on the
proposal sent that was accepted. of received messages.

o Protocol-Id Exchange Type (1 octet) - Specifies the protocol identifier
for the current negotiation. During phase 1 negotiation
this field MUST be zero (0). During phase 2 it will be indicates the
protocol type of the SA exchange being established as assigned by IANA,
for example, 50 for ESP, 51 for AH,
used. This dictates the payloads sent in each message and 108 for IPComp.

o SPI Size (1 octet) - During phase 1 negotiation this field
MUST be zero. During phase 2 negotiation it is equal to the
size,
message orderings in octets, of the SPI of the corresponding protocol
(8 exchanges.

Exchange Type Value

RESERVED 0
Reserved for IKE, 4 ISAKMP 1 - 31
Reserved for ESP and AH, 2 IKEv1 32 - 33
IKE_SA_init 34
IKE_SA_AUTH 35
CREATE_CHILD_SA 36
Informational 37
Reserved for IPcomp). IKEv2+ 38-239
Reserved for private use 240-255

o # of Transforms Flags (1 octet) - Specifies indicates specific options that are set
for the number message. Presence of
transforms options are indicated by the
appropriate bit in this proposal.

o SPI (variable) - the flags field being set. The sending entity's SPI. Even if bits are
defined LSB first, so bit 0 would be the SPI
Size is not a multiple least significant
bit of 4 octets, there is no padding
applied to the payload. When Flags octet. In the SPI Size field description below, a bit
being 'set' means its value is zero,
this field '1', while 'cleared' means
its value is not present '0'.

-- R(eserved) (bits 0-2) - These bits MUST be cleared
when sending and MUST be ignored on receipt.

-- I(nitiator) (bit 3 of Flags) - This bit MUST be set in
messages sent by the Security Association
payload. This case occurs when negotiating original Initiator of the IKE-SA
(but not during IKE SA
and MUST be cleared in messages sent by the rekeying original
Responder. It is used by the recipient to determine
whether the message ID should be interpreted
in the context of an IKE-SA).

o Transforms (variable) - one its initiating state or more transform substructures.

Harkins Kaufman Kent Kivinen Perlman its responding
state.

IKEv2 [Page 35] 29]

INTERNET DRAFT April October 2002

7.3.2 Transform Substructure

1 2

-- V(ersion) (bit 4 of Flags) - This bit indicates that
the transmitter is capable of speaking a higher major
version number of the protocol than the one indicated
in the major version number field. Implementations of
IKEv2 must clear this bit when sending and MUST ignore
it in incoming messages.

-- R(eserved) (bits 5-7 of Flags) - These bits MUST be
cleared when sending and MUST be ignored on receipt.

o Message ID (4 octets) - Message identifier used to control
retransmission of lost packets and matching of requests and
responses. See section 4.2. In the first message of a Phase 1
negotiation, the value MUST be set to 0. The response to that
message MUST also have a Message ID of 0.

o Length (4 octets) - Length of total message (header + payloads)
in octets. Session encryption can expand the size of an IKE
message and that is reflected in the total length of the
message.

5.2 Generic Payload Header

Each IKE payload defined in sections 5.3 through 5.14 begins with a
generic header, shown in Figure 2. Figures for each payload below
will include the generic payload header but for brevity the
description of each field will be omitted. The construction and
processing of the generic payload header is identical for each
payload and will similarly be omitted.

1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 (last) or 3 ! Next Payload !C! RESERVED ! Transform Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!Transform Type ! RESERVED ! Transform ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Transform Attributes ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: Transform Substructure

o 0 (last) or 3 (more) (1 octet) 2: Generic Payload Header

The Generic Payload Header fields are defined as follows:

o Next Payload (1 octet) - Specifies whether this is Identifier for the
last Transform Substructure payload type of the
next payload in the Proposal. This syntax is
inherited from ISAKMP, but message. If the current payload is unnecessary because the last
Proposal could be identified from the length of
in the SA. The
value (3) corresponds message, then this field will be 0. This field provides
a "chaining" capability whereby additional payloads can be
added to a Payload Type message by appending it to the end of Transform, the message
and setting the first four octets "Next Payload" field of the Transform structure are designed preceding payload
to look somewhat like indicate the header new payload's type. For an Encrypted payload,
which must always be the last payload of a Payload. message, the Next

IKEv2 [Page 30]

INTERNET DRAFT October 2002

Payload field is set to the payload type of the first contained
payload.

o RESERVED Critical (1 bit) - MUST be sent as zero; set to zero if the sender wants
the recipient to skip this payload if he does not
understand the payload type code. MUST be ignored.

o Transform Length - The length (in octets) of set to one if the Transform
Substructure including Header and Attributes.

o Transform Type (1 octet) - The type of transform being specified
in this transform. Different protocols support different
transform types. For some protocols, some of
sender wants the transforms
may recipient to reject this entire message
if he does not understand this payload type. MUST be optional.

o Transform-ID (1 octet) - The specific instance of ignored
by the recipient if the transform recipient understands the payload type being proposed.

Harkins Kaufman Kent Kivinen Perlman [Page 36]

INTERNET DRAFT April 2002

Transform Type Values

Transform Used In
Type
Encryption Algorithm 1 (IKE and ESP)
Pseudo-random Function 2 (IKE)
Authentication Method 3 (IKE)
Integrity Algorithm 4 (IKE, AH, and optional in ESP)
Diffie-Hellman Group 5 (IKE and optional in AH and ESP)
Compression 6 (IPcomp)
Window Size 7 (IKE)

values 8-240 are reserved
code. SHOULD be set to IANA. Values 241-255 are zero for
private use among mutually consenting parties.

For Transform Type 1 (Encryption Algorithm), payload types defined Transform-IDs
are:

Name Number Defined In
RESERVED 0
ENCR_DES_IV64 1 (RFC1827)
ENCR_DES 2 (RFC2405)
ENCR_3DES 3 (RFC2451)
ENCR_RC5 4 (RFC2451)
ENCR_IDEA 5 (RFC2451)
ENCR_CAST 6 (RFC2451)
ENCR_BLOWFISH 7 (RFC2451)
ENCR_3IDEA 8 (RFC2451)
ENCR_DES_IV32 9
ENCR_RC4 10
ENCR_NULL 11 (RFC2410)
ENCR_AES_128 12

values 12-240 are reserved in this
document. Note that the critical bit applies to IANA. Values 241-255 are the current
payload rather than the "next" payload whose type code
appears in the first octet. The reasoning behind not setting
the critical bit for
private use among mutually consenting parties.

For Transform Type 2 (Pseudo-random Function), payloads defined Transform-IDs
are:

Name Number Defined In
RESERVED 0
PRF_HMAC_MD5 1 (RFC2104)
PRF_HMAC_SHA 2 (RFC2104)
PRF_HMAC_TIGER 3 (RFC2104)

values 3-240 are reserved to IANA. Values 241-255 are for
private use among mutually consenting parties.

Harkins Kaufman Kent Kivinen Perlman [Page 37]

INTERNET DRAFT April 2002

For Transform Type 3 (Authentication Method), in this document is
that all implementations MUST understand all payload types
defined Transform-IDs
are:

Name Number Defined In
RESERVED 0 in this document and therefore must ignore the
Critical bit's value.

o RESERVED for IKEv1 1 (7 bits) - 5 (RFC2409)
Authenticated Diffie-Hellman 6 (this memo)

values 7-240 are reserved to IANA. Values 241-255 are for
private use among mutually consenting parties.

For Transform Type 4 (Integrity Algorithm), defined Transform-IDs
are:

Name Number Defined In
RESERVED 0
AUTH_HMAC_MD5 1 (RFC2403)
AUTH_HMAC_SHA 2 (RFC2404)
AUTH_DES_MAC 3
AUTH_KPDK_MD5 4 (RFC1826)

For Transform Type 5 (Diffie-Hellman Group), defined Transform-IDs
are:

Name Number
RESERVED 0
Pre-defined (see section 8) 1 MUST be sent as zero; MUST be ignored.

o Payload Length (2 octets) - 5
RESERVED 6 - 200
MODP (exponentiation) 201 (w/attributes)
ECP (elliptic curve over GF[P] 202 (w/attributes)
EC2N (elliptic curve over GF[2^N]) 203 (w/attributes)

values 6-200 are reserved to IANA for new MODP, ECP or EC2N
groups. Values 204-255 are for private use among mutually
consenting parties. Specification of values 201, 202 or 203
allow peers to define a new Diffie-Hellman group in-line as
part Length in octets of the exchange. Private use of values 204-255 may entail
complete definition current
payload, including the generic payload header.

5.3 Security Association Payload

The Security Association Payload, denoted SA in this memo, is used to
negotiate attributes of a group or security association. An SA may require attributes to
accompany them. Attributes MUST NOT accompany groups using
values between 6 and 200.

Harkins Kaufman Kent Kivinen Perlman [Page 38]

INTERNET DRAFT April 2002

For Transform Type 6 (Compression), defined Transform-IDs are:

Name Number Defined In
RESERVED 0
IPCOMP_OUI 1 (w/attributes)
IPCOMP_DEFLATE 2
(RFC2394)
IPCOMP_LZS 3
(RFC2395)

values 4-240 are reserved to IANA. Values 241-255 are for
private use among mutually consenting parties.

For Transform Type 7 (Window Size), the Transform-ID specifies the
window size contain
multiple proposals. Each proposal may propose multiple protocols
(where a peer protocol is contracting to support IKE, ESP, AH, or IPcomp), along with a suite of
cryptographic algorithms to handle overlapping
requests (see section 2.3).

7.3.3 Mandatory Transform Types be used by the protocols. The number
protocol(s), cryptographic algorithms, and type of transforms that accompany an SA payload any associated parameters
are
dependent on the protocol in determined by the SA itself. suite number. An SA payload proposing
the establishment of an SA has the following mandatory MAY contain
proposals for different protocols. For example, one suite might
contain AH, ESP, and optional
transform types. A compliant implementation MUST support all
mandatory IPcomp, while another might contain only ESP and optional types for each protocol it supports. Whether
the optional types are present in
a particular proposal depends
solely on the discretion of the sender.

Protocol Mandatory Types Optional Types
IKE 1, 2, 3, 5, 7 third ESP 1 4, 5
AH 4 5
IPCOMP 6

7.3.4 Mandatory Transform-IDs

Each transform type has corresponding transform IDs to specify the
specific transform. Some transforms are mandatory to support and
others are optional to support. IPcomp.

The mandatory transform IDs for AH,
ESP, and IPCOMP are left to their respective RFCs, RFC2402, RFC2406, Proposal structure contains within it a Proposal # and RFC2393. The transform IDs that are mandatory to support for
IKEv2 are:

Name TransType Mandatory Transform-ID
Encryption Algorithm 1 12 (ENCR_AES_128)
Pseudo-Random Function 2 2 (PRF_HMAC_SHA)
Authentication Method 3 6 (signed D-H)
Diffie-Hellman Group 5 5 (1536 bit MODP)
Window Size 7 1

Harkins Kaufman Kent Kivinen Perlman [Page 39]

INTERNET DRAFT April 2002

All other transform-IDs for a given transform type are optional to
support. While implementations Suite-
ID. The first proposal MUST support a window size of have Proposal # = 1, they
SHOULD support a window size of at least 10 and MAY support larger
window sizes.

7.3.5 Transform Attributes

Each transform in a Security Association payload may include
attributes that modify or complete the specification of the
transform. These attributes are type/value pairs and are defined in
Appendix A. For example, if an encryption algorithm has a variable
length key, the key length to be used may be specified as an
attribute. Attributes can second MUST
have a value with a fixed two octet length
or a variable length value. For the latter Proposal # = 2, etc. If the attribute is proposals are misnumbered, the form
responder MUST reject all of type/length/value. them.

1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!A! Attribute Type ! AF=0 Attribute Length
!
!F! Next Payload !C! RESERVED ! AF=1 Attribute Value Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! AF=0 Attribute Value !
~ <Proposals> ~

IKEv2 [Page 31]

INTERNET DRAFT October 2002

! AF=1 Not Transmitted !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: Data Attributes 3: Security Association Payload

o Attribute Type (2 octets) Proposals (variable) - Unique identifier for each type of
attribute. The identifiers for IKE are defined in Appendix A. one or more proposal substructures.

The most significant bit of this field is payload type for the Attribute Format
bit (AF). It indicates Security Association Payload is one (1).

5.3.1 Proposal Substructure

1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! 0 (last) or 2 ! RESERVED ! Proposal Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal # ! RESERVED-MBZ ! Suite-ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI(S) (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Proposal Substructure

o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the data attributes follow the
Type/Length/Value (TLV) format or a shortened Type/Value (TV)
format. If
last Proposal Substructure in the AF bit SA. This syntax is zero (0), then inherited
from ISAKMP, but is unnecessary because the Data Attributes
are of last Proposal
could be identified from the Type/Length/Value (TLV) form. If length of the AF bit is SA. The value (2)
corresponds to a
one (1), then Payload Type of Proposal, and the Data Attributes are first
four octets of the Type/Value form. Proposal structure are designed to look
somewhat like the header of a Payload.

o Attribute RESERVED (1 octet) - MUST be sent as zero; MUST be ignored.

o Proposal Length (2 octets) - Length in octets of this proposal,
including the Attribute
Value. SPI

o Proposal # (1 octet) - When the AF bit is a one (1), the Attribute Value proposal is
only 2 octets made, the first
proposal in an SA MUST be #1, and subsequent proposals
MUST be one greater than the Attribute Length field previous proposal. When a
proposal is not present.

o Attribute Value (variable length) - Value of accepted, the Attribute
associated with the Attribute Type. If the AF bit is a
zero (0), this field has SA MUST contain a variable length defined by single proposal
and the
Attribute Length field. If proposal number MUST match the AF bit accepted proposal
from the Initiator.

o RESERVED-MBZ (1 octet) - This field is reserved for
possible use in specifying different kinds of proposals.
This field MUST be sent as zero and a one (1), the
Attribute Value has proposal containing
a length of 2 octets.

Harkins Kaufman Kent Kivinen Perlman non-zero value MUST NOT be accepted.

IKEv2 [Page 40] 32]

INTERNET DRAFT April October 2002

7.3.6 Attribute Negotiation

During security association negotiation Initiators present offers to
Responders. Responders MUST select

o Suite-ID (2 octets) - This field specifies a single complete set suite of
parameters from the offers (or reject all offers if none are
acceptable).
protocols and cryptographic algorithms. See table below.

o SPI(S) (variable) - The sending entity's SPI(s). If there are multiple proposals, the Responder MUST
choose a single proposal number and return all of
suite proposed includes more than one protocol, the Proposal
substructures with that Proposal number. If there SPIs
are multiple
Transforms with the same type concatenated together in the Responder MUST choose a single one.
Any attributes of order in which they would
appear in a selected transform MUST be returned unmodified.
The Initiator of an exchange MUST check that packet sent using the accepted offer suite (i.e. AH followed
by ESP followed by IPcomp. When an initial IKE SA is
consistent with one of its proposals, being
proposed, SPIs are implicit from the IKE header and are not
repeated here. Even if the SPI
Size is not that response MUST
be rejected.

Negotiating Diffie-Hellman groups presents some special challenges.
Diffie-Hellman groups are specified either using a defined group
description (section 5) or by defining all attributes multiple of a group (see
Appendix A) in an IKE policy offer. Group attributes, such as group
type or prime number MUST NOT be offered in conjunction with a
previously defined group. SA offers include proposed attributes and a
Diffie-Hellman public number (KE) in the same message. If the
Initiator offers to use one of several Diffie-Hellman groups, it
SHOULD pick the one the Responder 4 octets, there is most likely to accept and
include a KE corresponding to that group. If the guess turns out no padding
applied to
be wrong, the Responder will indicate payload. When the correct group SPI Size field is zero,
this field is not present in the
response and Security Association
payload.

For Suite-ID, the Initiator SHOULD start over this time using a
different group (see section 2.7).

Implementation Note:

Certain negotiable attributes can have ranges or could have
multiple acceptable values. These following values are the Diffie-Hellman group and
the key length of a variable key length symmetric cipher. To
further interoperability defined:

Name Number Algorithms
IKE_CLASSIC 0 DH-Group #5 (1536 bits)
3DES encryption
HMAC-SHA1 integrity and to support upgrading endpoints
independently, implementers of this protocol SHOULD accept prf

ESP_CLASSIC 1 3DES encryption
HMAC-SHA1 integrity

<some AES variants, ESP+IPcomp, AH (?))

values
which they deem to supply greater security. For instance if a peer
is configured to accept a variable lengthed cipher with a key
length of X bits and is offered that cipher with a larger key
length an implementation SHOULD accept the offer.

Support of this capability allows an implementation 2-65000 are reserved to express a
concept of "at least" a certain level of security-- "a key length
of _at least_ X bits IANA. Values 65501-65533 are
for cipher foo".

7.4 private use among mutually consenting parties.

5.4 Key Exchange Payload

The Key Exchange Payload, denoted KE in this memo, is used to
exchange Diffie-Hellman public numbers as part of a Diffie-Hellman

Harkins Kaufman Kent Kivinen Perlman [Page 41]

INTERNET DRAFT April 2002
key exchange. The Key Exchange Payload consists of the IKE generic
header followed by the Diffie-Hellman public value itself.

IKEv2 [Page 33]

INTERNET DRAFT October 2002

Figure 7: Key Exchange Payload Format

A key exchange payload is constructed by copying one's Diffie-Hellman
public value into the "Key Exchange Data" portion of the payload.
The length of the Diffie-Hellman public value MUST be equal to the
length of the prime modulus over which the exponentiation was
performed, prepending zero bits to the value if necessary.

A key exchange payload is processed by first checking whether the
length of the key exchange data (the "Payload Length" from the
generic header minus the size of the generic header) is equal to the
length of the prime modulus over which the exponentiation was
performed.

The payload type for the Key Exchange payload is four (4).

7.5

5.5 Identification Payload

The Identification Payload, denoted ID in this memo, allows peers to
identify themselves to each other. In Phase 1, the ID Payload names
the identity to be authenticated with the signature. In Phase 2, the
ID Payload is optional and if present names an identity asserted to
be responsible for this SA. An example use would be a shared computer
opening an IKE-SA to a server and asserting the name of its logged in
user for the Phase 2 SA. If missing, this defaults to the Phase 1
identity.

NOTE: In IKEv1, two ID payloads were used in each direction in Phase
2 to hold Traffic Selector information for data passing over the SA.
In IKEv2, this information is carried in Traffic Selector (TS)
payloads (see section 7.13). 5.13).

The Identification Payload consists of the IKE generic header
followed by identification fields as follows:

Harkins Kaufman Kent Kivinen Perlman [Page 42]

INTERNET DRAFT April 2002

1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Identification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: Identification Payload Format

IKEv2 [Page 34]

INTERNET DRAFT October 2002

o ID Type (1 octet) - Specifies the type of Identification being
used.

o RESERVED - MUST be sent as zero; MUST be ignored.

o Identification Data (variable length) - Value, as indicated by
the Identification Type. The length of the Identification Data
is computed from the size in the ID payload header.

The payload type for the Identification Payload is five (5).

The following table lists the assigned values for the Identification
Type field, followed by a description of the Identification Data
which follows:

ID Type Value
------- -----
RESERVED 0

ID_IPV4_ADDR 1

A single four (4) octet IPv4 address.

ID_FQDN 2

A fully-qualified domain name string. An example of a
ID_FQDN is, "lounge.org". The string MUST not contain any
terminators (e.g. NULL, CR, etc.).

ID_RFC822_ADDR 3

A fully-qualified RFC822 email address string, An example of
a ID_RFC822_ADDR is, "lizard@lounge.org". The string MUST
not contain any terminators.

Harkins Kaufman Kent Kivinen Perlman [Page 43]

INTERNET DRAFT April 2002

ID_IPV6_ADDR 5

A single sixteen (16) octet IPv6 address.

ID_DER_ASN1_DN 9

The binary DER encoding of an ASN.1 X.500 Distinguished Name
[X.501].

ID_DER_ASN1_GN 10

The binary DER encoding of an ASN.1 X.500 GeneralName
[X.509].

IKEv2 [Page 35]

INTERNET DRAFT October 2002

ID_KEY_ID 11

An opaque octet stream which may be used to pass vendor-
specific information necessary to do certain proprietary
forms of identification.

7.6

5.6 Certificate Payload

The Certificate Payload, denoted CERT in this memo, provides a means
to transport certificates or other certificate-related information
via IKE. Certificate payloads SHOULD be included in an exchange if
certificates are available to the sender.

The Certificate Payload is defined as follows:

Figure 9: Certificate Payload Format

o Certificate Encoding (1 octet) - This field indicates the type
of certificate or certificate-related information contained
in the Certificate Data field.

Harkins Kaufman Kent Kivinen Perlman [Page 44]

INTERNET DRAFT April 2002

Certificate Encoding Value
-------------------- -----
NONE 0
PKCS #7 wrapped X.509 certificate 1
PGP Certificate 2
DNS Signed Key 3
X.509 Certificate - Signature 4
Kerberos Token 6
Certificate Revocation List (CRL) 7
Authority Revocation List (ARL) 8
SPKI Certificate 9
X.509 Certificate - Attribute 10
RESERVED 11 - 255

IKEv2 [Page 36]

INTERNET DRAFT October 2002

o Certificate Data (variable length) - Actual encoding of
certificate data. The type of certificate is indicated
by the Certificate Encoding field.

The payload type for the Certificate Payload is six (6).

7.7

5.7 Certificate Request Payload

The Certificate Request Payload, denoted CERTREQ in this memo,
provides a means to request preferred certificates via IKE and can
appear in the first, second, or third message of Phase 1.
Certificate Request payloads SHOULD be included in an exchange
whenever the peer may have multiple certificates, some of which might
be trusted while others are not. If multiple root CA's are trusted,
then multiple Certificate Request payloads SHOULD be transmitted.

Empty (zero length) CA names MUST NOT be generated and SHOULD be
ignored.

The Certificate Request Payload is defined as follows:

Figure 10: Certificate Request Payload Format

Harkins Kaufman Kent Kivinen Perlman [Page 45]

INTERNET DRAFT April 2002

o Certificate Encoding (1 octet) - Contains an encoding of the type
of certificate requested. Acceptable values are listed in
section 7.6. 5.6.

o Certification Authority (variable length) - Contains an encoding
of an acceptable certification authority for the type of
certificate requested.

The payload type for the Certificate Request Payload is seven (7).

The Certificate Request Payload is constructed by setting the "Cert
Encoding" field to be the type of certificate being desired and the
"Certification Authority" field to a proper encoding of a
certification authority for the specified certificate. For example,

IKEv2 [Page 37]

INTERNET DRAFT October 2002

for an X.509 certificate this field would contain the Distinguished
Name encoding of the Issuer Name of an X.509 certification authority
acceptable to the sender of this payload.

The Certificate Request Payload is processed by inspecting the "Cert
Encoding" field to determine whether the processor has any
certificates of this type. If so the "Certification Authority" field
is inspected to determine if the processor has any certificates which
can be validated up to the specified certification authority. This
can be a chain of certificates. If a certificate exists which
satisfies the criteria specified in the Certificate Request Payload
it MUST be sent back to the certificate requestor; if a certificate
chain exists which goes back to the certification authority specified
in the request the entire chain SHOULD be sent back to the
certificate requestor. If no certificates exist then no further
processing is performed-- this is not an error condition of the
protocol. There may be cases where there is a preferred CA, but an
alternate might be acceptable (perhaps after prompting a human
operator).

7.8

5.8 Authentication Payload

The Authentication Payload, denoted AUTH in this memo, contains data
used for authentication purposes. The only authentication method
defined in this memo is digital signatures and therefore the contents
of this payload when used with this memo will be the output generated
by a digital signature function.

Harkins Kaufman Kent Kivinen Perlman [Page 46]

INTERNET DRAFT April 2002

The Authentication Payload is defined as follows:

Figure 11: Authentication Payload Format

o Authentication Data (variable length) - Data that results from
applying the digital signature function to the IKE state
(see section 3).

The payload type for the Authentication Payload is nine (9).

IKEv2 [Page 38]

INTERNET DRAFT October 2002

The Authentication Payload is constructed by computing a digital
signature (or secret key MAC) over the concatenation part of one of the sender's
first IKE message and the other peer's nonce.
messages (see section 4.15). The result is placed in the
"Authentication Data" portion of the payload. The encoding depends
on the type of key being used to authenticate (see section
3.2). 4.2). The
payload length is the size of the generic header plus the size of the
"Authentication Data" portion of the payload which depends on the
specific authentication method being used.

The Authentication Payload is processed by extracting the
"Authentication Data" from the payload and verifying it according to
the specific authentication method being used. If authentication
fails a NOTIFY Error message of AUTHENTICATION-FAILED MUST be sent
back to the peer and the connection closed.

7.9

5.9 Nonce Payload

The Nonce Payload, denoted Ni and Nr in this memo for the Initiator's
and Responder's nonce respectively, contains random data used to
guarantee liveness during an exchange and protect against replay
attacks.

Harkins Kaufman Kent Kivinen Perlman [Page 47]

INTERNET DRAFT April 2002

The Nonce Payload is defined as follows:

Figure 12: Nonce Payload Format

o Nonce Data (variable length) - Contains the random data generated
by the transmitting entity.

The payload type for the Nonce Payload is ten (10).

The Nonce Payload is constructed by computing a pseudo-random value
and copying it into the "Nonce Data" field. The size of a Nonce MUST
be between 8 and 256 octets inclusive.

7.10 Nonce values MUST NOT be
reused. They MAY be as long as 256 octets to support there use in
carrying state when defending against certain denial of service
attacks (see Section 4.6).

IKEv2 [Page 39]

INTERNET DRAFT October 2002

5.10 Notify Payload

The Notify Payload, denoted N in this document, is used to transmit
informational data, such as error conditions and state transitions to
an IKE peer. A Notify Payload may appear in a response message
(usually specifying why a request was rejected), or in an
Informational Exchange (to report an error not in an IKE request).

The Notify Payload is defined as follows:

1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Notification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Harkins Kaufman Kent Kivinen Perlman [Page 48]

INTERNET DRAFT April 2002

Figure 13: Notification Payload Format

o Protocol-Id (1 octet) - Specifies the protocol about which
this notification is being sent. For phase 1 notifications,
this field MUST be zero (0). For phase 2 notifications
concerning IPsec SAs this field will contain an IPsec
protocol (either ESP, AH, or IPcomp). For notifications
for which no protocol ID is relevant, this field MUST be
sent as zero and MUST be ignored.

o SPI Size (1 octet) - Length in octets of the SPI as defined by
the Protocol-Id or zero if no SPI is applicable. For phase 1
notification concerning the IKE-SA, the SPI Size MUST be zero.

o Notify Message Type (2 octets) - Specifies the type of
notification message.

o SPI (variable length) - Security Parameter Index.

o Notification Data (variable length) - Informational or error data
transmitted in addition to the Notify Message Type. Values for
this field are message specific, see below.

IKEv2 [Page 40]

INTERNET DRAFT October 2002

The payload type for the Notification Payload is eleven (11).

7.10.1

5.10.1 Notify Message Types

Notification information can be error messages specifying why an SA
could not be established. It can also be status data that a process
managing an SA database wishes to communicate with a peer process.
For example, a secure front end or security gateway may use the
Notify message to synchronize SA communication. The table below
lists the Notification messages and their corresponding values. The
number of different error statuses was greatly reduced from IKE V1
both for simplication and to avoid giving configuration information
to probers.

NOTIFY MESSAGES - ERROR TYPES Value
----------------------------- -----
UNSUPPORTED-CRITICAL-PAYLOAD 1

Sent if the payload has the "critical" bit set and the
payload type is not recognised. Notification Data contains
the one octet payload type.

INVALID-COOKIE 4

Indicates an IKE message was received with an unrecognized
destination cookie. This usually indicates that the
recipient has rebooted and forgotten the existence of an
IKE-SA.

Harkins Kaufman Kent Kivinen Perlman [Page 49]

INTERNET DRAFT April 2002

INVALID-MAJOR-VERSION 5

Indicates the recipient cannot handle the version of IKE
specified in the header. The closest version number that the
recipient can support will be in the reply header.

INVALID-EXCHANGE-TYPE

INVALID-SYNTAX 7

Notification Data contains

Indicates the one octet Exchange Type.

INVALID-FLAGS 8

Notification Data contains one octet with IKE message was received was invalid because
some type, length, or value was out of range or because the unacceptable
flag bits set.

INVALID-MESSAGE-ID 9

Sent when
request was rejected for policy reasons. To avoid a denial
of service attack using forged messages, this status may
only be returned for and in an IKE MESSAGE-ID outside encrypted packet if the negotiated window is
received. This Notify
MESSAGE-ID and cryptographic checksum were valid. To avoid
leaking information to someone probing a node, this status
MUST NOT be sent in a response; response to any error not covered by one of
the
invalid request other status codes. To aid debugging, more detailed
error information SHOULD be written to a console or log.

IKEv2 [Page 41]

INTERNET DRAFT October 2002

INVALID-MESSAGE-ID 9

Sent when an IKE MESSAGE-ID outside the negotiated window is
received. This Notify MUST NOT be sent in a response; the
invalid request MUST NOT be acknowledged. Instead, inform
the other side by initiating an Informational exchange with
Notification data containing the four octet invalid MESSAGE-
ID.

INVALID-PROTOCOL-ID 10

Notification Data contains the one octet invalid protocol
ID.
MESSAGE-ID.

INVALID-SPI 11

MAY be sent in an IKE Informational Exchange when a node
receives an ESP or AH packet with an invalid SPI. address
as The
Notification Data contains the source address in SPI of the invalid packet.
This usually indicates a node has rebooted and forgotten an
SA. This If this Informational Message is sent outside the
context of an IKE-
SA, and therefore IKE-SA, it should only be used by the
recipient as a "hint" that something might be wrong (because
it could easily be forged).

INVALID-TRANSFORM-ID 12

Notification Data contains the one octet invalid transform
ID.

ATTRIBUTES-NOT-SUPPORTED 13

The "Notification Data" for this type are the attribute or

Harkins Kaufman Kent Kivinen Perlman [Page 50]

INTERNET DRAFT April 2002

attributes that are not supported.

NO-PROPOSAL-CHOSEN 14

BAD-PROPOSAL-SYNTAX 15

PAYLOAD-MALFORMED 16

INVALID-KEY-INFORMATION 17

The KE field is the wrong length.

INVALID-ID-INFORMATION 18

INVALID-CERT-ENCODING 19

The "Notification Data" for this type are

None of the "Cert
Encoding" field from proposed crypto suites was acceptable.

SINGLE-PAIR-REQUIRED 34

This error indicates that a Certificate Payload or Certificate
Request Payload.

INVALID-CERTIFICATE 20

The "Notification Data" for this type are Phase 2 SA request is
unacceptable because the "Certificate
Data" field from Responder is willing to accept
traffic selectors specifying a Certificate Payload.

INVALID-CERT-AUTHORITY 22 single pair of addresses.
The "Notification Data" Initiator is expected to respond by requesting an SA for this type are
only the "Cert
Encoding" field from specific traffic he is trying to forward.

NO-ADDITIONAL-SAS 35

This error indicates that a Certificate Payload or Certificate
Request Payload.

AUTHENTICATION-FAILED 24

INVALID-SIGNATURE 25

UNSUPPORTED-EXCHANGE-TYPE 29

The "Notification Data" for this type are the Exchange Type
field from Phase 2 SA request is
unacceptable because the IKE header.

UNEQUAL-PAYLOAD-LENGTHS 30

The "Notification Data" for Responder is unwilling to accept
any more Child-SAs on this type are the entire message IKE-SA. Some minimal
implementations may only accept a single Child-SA setup in which
the unequal lengths were observed.

UNSUPPORTED-NOTIFY-TYPE 31

The "Notification Data" for this type is the two octet

Harkins Kaufman Kent Kivinen Perlman [Page 51]

INTERNET DRAFT April 2002

Notify Type that was not supported.

IKE-SA-INIT-REJECT 32

This notification is sent in an IKE-SA-RESPONSE to request
that the Initiator retry the request with the supplied
cookie (and optionally the supplied Diffie-Hellman group).
This is not really an error, but is processed like one in
that it indicates that the connection request was rejected.
The Notification Data, if present, contains the Transform
Substructure describing the preferred Diffie-Hellman group.

SINGLE-PAIR-REQUIRED 34

This error indicates that a Phase 2 SA request is
unacceptable because the Responder requires a separate SA
for each source / destination address pair. The Initiator is
expected to respond by requesting context of an SA for only the
specific traffic he is trying initial IKE exchange and reject any
subsequent attempts to forward. add more.

RESERVED TO IANA - Errors 35 36 - 8191

Private Use - Errors 8192 - 16383

NOTIFY MESSAGES - STATUS TYPES Value

IKEv2 [Page 42]

INTERNET DRAFT October 2002

------------------------------ -----

RESERVED 16384 - 24577

INITIAL-CONTACT 24578

This notification asserts that this IKE-SA is the only IKE-
SA currently active between the authenticated identities. It
MAY be sent when an IKE-SA is established after a crash, and
the recipient MAY use this information to delete any other
IKE-SAs it has to the same authenticated identity without
waiting for a timeout if those IKE-SAs reside at the IP
address from which this notification arrived. This
notification MUST NOT be sent by an entity that may be
replicated (e.g. a roaming user's credentials where the user
is allowed to connect to the corporate firewall from two
remote systems at the same time).

SET-WINDOW-SIZE 24579

This notification asserts that the sending endpoint is
capable of keeping state for multiple outstanding Phase 2
exchanges, permitting the recipient to send multiple Phase 2
requests before getting a response to the first. The data
associated with a SET-WINDOW-SIZE notification MUST be 4
octets long an contain the big endian represention of the
number of messages the sender promises to keep.

ADDITIONAL-TS-POSSIBLE 24580

This notification asserts that the sending endpoint narrowed
the proposed traffic selectors but that other traffic
selectors would also have been acceptable, though only in a
separate SA. There is no data associated with this notify
type. It may only be sent as an additional payload in a
message including accepted TSs.

RESERVED 24578 24581 - 40959

Private Use - STATUS 40960 - 65535

Harkins Kaufman Kent Kivinen Perlman [Page 52]

INTERNET DRAFT April 2002

7.11

5.11 Delete Payload

The Delete Payload, denoted D in this memo, contains a protocol-
specific security association identifier that the sender has removed
from its security association database and is, therefore, no longer
valid. Figure 14 shows the format of the Delete Payload. It is

IKEv2 [Page 43]

INTERNET DRAFT October 2002

possible to send multiple SPIs in a Delete payload, however, each SPI
MUST be for the same protocol. Mixing of Protocol Identifiers MUST
NOT be performed with the Delete payload. It is permitted, however,
to include multiple Delete payloads in a single Informational
Exchange where each Delete payload lists SPIs for a different
protocol.

Deletion of the IKE-SA is indicated by a Protocol-Id of 0 (IKE) but
no SPIs. Deletion of a Child-SA, such as ESP or AH, will contain the
Protocol-Id of that protocol (e.g. ESP, AH) and the SPI is the
receiving entity's SPI(s).

NOTE: What's the deal with IPcomp SAs. This mechanism is probably not
appropriate for deleting them!!

The Delete Payload is defined as follows:

1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-Id ! SPI Size ! # of SPIs !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index(es) (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 14: Delete Payload Format

o Protocol-Id (1 octet) - Must be zero for an IKE-SA, 50 for
ESP, 51 for AH, and 108 for IPcomp.

o SPI Size (1 octet) - Length in octets of the SPI as defined by
the Protocol-Id. Zero for IKE (SPI is in message header),
four for AH and ESP, two for IPcomp.

o # of SPIs (2 octets) - The number of SPIs contained in the Delete
payload. The size of each SPI is defined by the SPI Size field.

o Security Parameter Index(es) (variable length) - Identifies the

Harkins Kaufman Kent Kivinen Perlman [Page 53]

INTERNET DRAFT April 2002
specific security association(s) to delete.
The length of this field is
determined by the SPI Size and # of SPIs fields.

The payload type for the Delete Payload is twelve (12).

7.12

IKEv2 [Page 44]

INTERNET DRAFT October 2002

5.12 Vendor ID Payload

The Vendor ID Payload contains a vendor defined constant. The
constant is used by vendors to identify and recognize remote
instances of their implementations. This mechanism allows a vendor
to experiment with new features while maintaining backwards
compatibility.

The Vendor ID payload is not an announcement from the sender that it
will send private payload types but rather an announcement of the
sort of private payloads it is willing to accept. The implementation
sending the Vendor ID MUST not make any assumptions about private
payloads that it may send unless a Vendor ID of like stature is
received as well. Multiple Vendor ID payloads MAY be sent. An
implementation is NOT REQUIRED to send any Vendor ID payload at all.

A Vendor ID payload may be sent as part of any message. Reception of
a familiar Vendor ID payload allows an implementation to make use of
Private USE numbers described throughout this memo-- private
payloads, private exchanges, private notifications, etc. Unfamiliar
Vendor ID's IDs MUST be ignored.

Writers of Internet-Drafts who wish to extend this protocol MUST
define a Vendor ID payload to announce the ability to implement the
extension in the Internet-Draft. It is expected that Internet-Drafts
which gain acceptance and are standardized will be given "magic
numbers" out of the Future Use range by IANA and the requirement to
use a Vendor ID will go away.

Harkins Kaufman Kent Kivinen Perlman [Page 54]

INTERNET DRAFT April 2002

The Vendor ID Payload fields are defined as follows:

Figure 15: Vendor ID Payload Format

o Vendor ID (variable length) - It is the responsibility of
the person choosing the Vendor ID to assure its uniqueness
in spite of the absence of any central registry for IDs.
Good practice is to include a company name, a person name
or some such. If you want to show off, you might include

IKEv2 [Page 45]

INTERNET DRAFT October 2002

the latitude and longitude and time where you were when
you chose the ID and some random input. A message digest
of a long unique string is preferable to the long unique
string itself.

The payload type for the Vendor ID Payload is thirteen (13).

7.13

5.13 Traffic Selector Payload

The Traffic Selector Payload, denoted TS in this memo, allows peers
to identify packet flows for processing by IPsec security services.
The Traffic Selector Payload consists of the IKE generic header
followed by selector information fields individual traffic selectors as follows:

1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Number of TSs ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ <Traffic Selectors> ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 16: Traffic Selectors Payload Format

Harkins Kaufman Kent Kivinen Perlman [Page 55]

INTERNET DRAFT April 2002

o Number of TSs (1 octet) - Number of traffic selectors
being provided.

o RESERVED - This field MUST be sent as zero and MUST be ignored.

o Traffic Selectors (variable length) - one or more individual
traffic
selector substructures.
selectors.

The length of the Traffic Selector payload includes the TS header and
all the traffic selector substructures. selectors.
The payload type for the Traffic Selector payload is fourteen (14).

7.13.1

5.13.1 Traffic Selector Substructure

1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! TS Type ! Protocol ID | Selector Length |

IKEv2 [Page 46]

INTERNET DRAFT October 2002

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Port | End-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Starting Address ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Ending Address Selector Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 17: Traffic Selector Substructure

o TS Type (one octet) - Specifies the type of traffic selector.

o Protocol ID (1 octet) - Value specifying an associated IP
protocol ID (e.g. UDP/TCP). A value of zero means that the
Protocol ID is not relevant to this traffic selector--
the SA can carry all protocols.

o Selector Length - Specifies the length of this Traffic
Selector Substructure including the header.

o Start-Port (2 octets) - Value specifying the smallest port
number allowed by this Traffic Selector. For protocols for
which port is undefined, or if all ports are allowed by
this Traffic Selector, this field MUST be zero.

o End-Port (2 octets) - Value specifying the largest port
number allowed by this Traffic Selector. For protocols for
which port is undefined, or it all ports are allowed by
this Traffic Selector, this field MUST be 65535.

Harkins Kaufman Kent Kivinen Perlman [Page 56]

INTERNET DRAFT April 2002

o Starting Address - The smallest address included in this
Traffic Selector Data (length determined by TS type).

o Ending Address - a specification of one or more
addresses The largest address included in this
Traffic Selector with format (length determined by TS type. type).

The following table lists the assigned values for the Traffic
Selector Type field and the corresponding Address Selector Data.

TS Type Value
------- -----
RESERVED 0

TS_IPV4_ADDR 1

A four (4) octet IPv4 address

TS_IPV4_ADDR_SUBNET 4

An IPv4 subnet represented by a pair of four (4) octet
values. The first value is an IPv4 address. The second is
an IPv4 network mask. Note that ones (1s) in the network
mask indicate that the corresponding bit in the address is
fixed, while zeros (0s) indicate a "wildcard" bit.

TS_IPV6_ADDR 5

A sixteen (16) octet IPv6 address

TS_IPV6_ADDR_SUBNET 6

An IPv6 subnet represented by a pair sixteen (16) octet
values. The first value is an IPv6 address. The second is
an IPv6 network mask. Note that ones (1s) in the network
mask indicate that the corresponding bit in the address is
fixed, while zeros (0s) indicate a "wildcard" bit.

TS_IPV4_ADDR_RANGE 7

IKEv2 [Page 47]

INTERNET DRAFT October 2002

A range of IPv4 addresses, represented by two four (4) octet
values. The first value is the beginning IPv4 address
(inclusive) and the second value is the ending IPv4 address
(inclusive). All addresses falling between the two specified
addresses are considered to be within the list.

TS_IPV6_ADDR_RANGE 8

A range of IPv6 addresses, represented by two sixteen (16)
octet values. The first value is the beginning IPv6 address
(inclusive) and the second value is the ending IPv6 address

Harkins Kaufman Kent Kivinen Perlman [Page 57]

INTERNET DRAFT April 2002
(inclusive). All addresses falling between the two specified
addresses are considered to be within the list.

7.14 Other Payload Types

5.14 Encrypted Payload type values 15-127 are reserved to IANA for future assignment

The Encrypted Payload, denoted SK{...} in IKEv2 (see section 10). Payload type values 128-255 are for
private use among mutually consenting parties.

8 Diffie-Hellman Groups

There are 5 groups different Diffie-Hellman groups defined for use this memo, contains other
payloads in
IKE. These groups were generated by Richard Schroeppel at encrypted form. The Encrpted Payload, if present in a
message, must be the
University of Arizona. Properties of these primes are described last payload in
[Orm96]. the message. Often, it is the
only payload in the message.

The strength supplied by group one may not be sufficient algorithms for encryption and integrity protection are negotiated
during IKE-SA setup, and the
mandatory-to-implement keys are computed as specified in
sections 4.14 and 4.17.

The encryption algorithm and is here for historic
reasons.

8.1 Group 1 - 768 Bit MODP integrity protection algorithms are modelled after
the ESP algorithms described in RFCs 2104, 2406, 2451. This document
completely specifies the cryptographic processing of IKE implementations MAY support data, but
those documents should be consulted for design rationale. We assume a MODP group
block cipher with the following prime a fixed block size and generator. This group an integrity check algorithm
that computes a fixed length checksum over a variable size message.
The mandatory to implement algorithms are AES-128-CBC and HMAC-SHA1.

The Payload Type for an Encrypted payload is assigned id 1 (one). fifteen (15). The prime is: 2^768 -
Encrypted Payload consists of the IKE generic header followed by
individual fields as follows:

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

The generator is 2.

8.2 Group 2 - 1024 Bit MODP

IKE implementations SHOULD support a MODP group with the following
prime and generator. This group is assigned id 3 4 5 6 7 8 9 0 1 2 (two).

Harkins Kaufman Kent Kivinen Perlman 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initialization Vector !
! (length is block size for encryption algorithm) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encrypted IKE Payloads !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! Padding (0-255 octets) !

IKEv2 [Page 58] 48]

INTERNET DRAFT April October 2002

The prime is 2^1024 - 2^960

+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
! ! Pad Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: Encrypted Payload Format

o Next Payload - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its hexadecimal value is:

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
49286651 ECE65381 FFFFFFFF FFFFFFFF The generator payload type of the first embedded payload.
Since the Encrypted payload must be last in a message, there
is 2.

8.3 Group 3 - 155 Bit EC2N

IKE implementations MAY support no need to specify a EC2N group with payload type for a payload beyond it.

o Payload Length - Includes the following
characteristics. This group is assigned id 3 (three). The curve is
based on lengths of the Galois Field GF[2^155]. The field size IV, Padding, and
Authentication data.

o Initialization Vector - A randomly chosen value whose length
is 155. The
irreducible polynomial for equal to the field is:
u^155 + u^62 + 1.
The equation for block length of the elliptic curve is:
y^2 + xy = x^3 + ax^2 + b.

Field Size: 155
Group Prime/Irreducible Polynomial:
0x0800000000000000000000004000000000000001
Group Generator One: 0x7b
Group Curve A: 0x0
Group Curve B: 0x07338f
Group Order: 0x0800000000000000000057db5698537193aef944

The data in the KE payload when using underlying encryption
algorithm. Recipients MUST accept any value. Senders SHOULD
either pick this group is the value x from pseudo-randomly and independently for
each message or use the solution (x,y), final ciphertext block of the point on previous
message sent. Senders MUST NOT use the curve same value for each
message, use a sequence of values with low hamming distance
(e.g. a sequence number), or use ciphertext from a received
message.

o IKE Payloads are as specified earlier in this section. This
field is encrypted with the negotiated cipher.

o Padding may contain any value chosen by taking the
randomly chosen secret Ka sender, and computing Ka*P, where * is must
have a length that makes the
repetition combination of the group addition Payloads, the
Padding, and double operations, P is the
curve point with x coordinate equal Pad Length to generator 1 and be a multiple of the y
coordinate determined from encryption
block size. This field is encrypted with the defining equation. negotiated
cipher.

o Pad Length is the length of the Padding field. The equation sender
SHOULD set the Pad Length to the minimum value that makes
the combination of
curve is implicitly known by the Group Type and Payloads, the A Padding, and B
coefficients. There are two possible values for the y coordinate;
either one can be used successfully (the two parties need not agree
on Pad
Length a multiple of the selection).

Harkins Kaufman Kent Kivinen Perlman [Page 59]

INTERNET DRAFT April 2002

8.4 Group 4 - 185 Bit EC2N

IKE implementations MAY support a EC2N group with block size, but the following
characteristics. recipient MUST
accept any length that results in proper alignment. This group is assigned id 4 (four). The curve
field is
based on encrypted with the Galois Field GF[2^185]. The field size negotiated cipher.

o Integrity Checksum Data is 185. The
irreducible polynomial for the field is:
u^185 + u^69 + 1.

The equation for cryptographic checksum of
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: 0x0
Group Curve B: 0x1ee9
Group Order: 0x01ffffffffffffffffffffffdbf2f889b73e484175f94ebc

The data in entire message starting with the KE payload when using this group will Fixed IKE Header
through the Pad Length. The checksum MUST be identical computed over
the encrypted message.

5.15 Other Payload Types

IKEv2 [Page 49]

INTERNET DRAFT October 2002

Payload type values 16-127 are reserved to IANA for future assignment
in IKE. Payload type values 128-255 are for private use among
mutually consenting parties.

6 Conformance Requirements

In order to assure that as when using Oakley Group 3 (three).

8.5 Group 5 - 1536 Bit MODP

IKE all implementations of IKEv2 can
interoperate, there are MUST support requirements in addition to
those listed elsewhere. Of course, IKEv2 is a MODP group with the following
prime security protocol, and generator. This group is assigned id 5 (five).

The prime is 2^1536 - 2^1472 - 1 + 2^64 * {[2^1406 pi] + 741804}.
Its hexadecimal value
one of its major functions is

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF

The generator preventing the bad guys from
interoperating with one's systems. So a particular implementation may
be configured with any of a number of restrictions concerning
algorithms and trusted authorities that will prevent universal
interoperability. For an implementation to be called conforming to
this specification, it MUST be possible to configure it to accept the
following:

X.509 certificates containing and signed by RSA keys of size 512,
768, 1024, and 2048 bits. (It SHOULD accept RSA keys of any multiple
of 8 bits in size from 512 bits to 4092 bits, and MAY accept RSA keys
of any size). If there is 2.

9 a limit on the size of an X.509
certificate, it MUST be at least 8K. If there is a limit on the
length of a certificate chain, it MUST be at least 10.

X.509 certificates containing and signed by DSS keys of size 512,
768, 1024, and 2048 bits. (It MAY accept DSS keys of any size).

An implementation MUST be capable of accepting a shared key for
authentication of any size from 1 - 255 bytes.

An implementation MUST be capable of accepting IKE messages with
sizes up to 16K bytes and SHOULD be capable of accepting IKE messages
up to 64K bytes.

An implementation MUST be capable of establishing an IKE-SA and a
single CHILD-SA in the initial four message exchange. An
implementation MAY reject subsequent requests to establish a CHILD-
SA. An implementation MUST respond to valid phase 2 messages, but MAY
otherwise ignore all such messages other than DELETE. There is no
requirement that an implementation be capable of initiating phase 2
exchanges.

The above paragraph allows for a minimal implementation to only do
the initial 4 message IKE exchange and respond to phase 2 pings and
still interoperate with any compliant implementation. In support of
this, and implementation that tries to rekey the IKE-SA by means of a
CREATE_CHILD_SA exchange MUST be prepared to tear down the IKE-SA and
establish a new one if the rekeying operation fails.

IKEv2 [Page 50]

INTERNET DRAFT October 2002

7 Security Considerations

Repeated re-keying using Phase 2 without PFS can consume the entropy
of the Diffie-Hellman shared secret. Implementers should take note of
this fact and set a limit on Phase 2 Exchanges between
exponentiations. This memo does not prescribe such a limit.

Harkins Kaufman Kent Kivinen Perlman [Page 60]

INTERNET DRAFT April 2002

The strength of a key derived from a Diffie-Hellman exchange using
any of the groups defined here depends on the inherent strength of
the group, the size of the exponent used, and the entropy provided by
the random number generator used. Due to these inputs it is difficult
to determine the strength of a key for any of the defined groups.
Diffie-Hellman group number two when used with a strong random number
generator and an exponent no less than 160 bits is sufficient to use
for 3DES. Groups three through five provide greater security. Group
one is for historic purposes only and does not provide sufficient
strength to the required cipher (although it is sufficient for use
with DES, which is also for historic use only). Implementations
should make note of these conservative estimates when establishing
policy and negotiating security parameters.

Note that these limitations are on the Diffie-Hellman groups
themselves. There is nothing in IKE which prohibits using stronger
groups nor is there anything which will dilute the strength obtained
from stronger groups. In fact, the extensible framework of IKE
encourages the definition of more groups; use of elliptical curve
groups will may greatly increase strength using much smaller numbers.

It is assumed that the Diffie-Hellman exponents in this exchange are
erased from memory after use. In particular, these exponents MUST NOT
be derived from long-lived secrets like the seed to a pseudo-random
generator that is not erased after use.

The security of this protocol is critically dependent on the
randomness of the Diffie-Hellman exponents, which should be generated
by a strong random or properly seeded pseudo-random source (see
RFC1715). While the protocol was designed to be secure even if the
Nonces and other values specified as random are not strongly random,
they should similarly be generated from a strong random source as
part of a conservative design.

8 IANA Considerations

This document contains many "magic numbers" to be maintained by the
IANA. This section explains the criteria to be used by the IANA to
assign additional numbers in each of these lists.

10.1 Transform Types and Attribute Values

10.1.1 Attributes

8.1.2 Encryption Algorithm Transform attributes are uses to modify or complete the specification
of a particular transform. Requests for new transform attributes MUST
be accompanied by an RFC which defines the transform which it
modifies or completes and the method in which it does so.

Harkins Kaufman Kent Kivinen Perlman Type

IKEv2 [Page 61] 51]

INTERNET DRAFT April October 2002

10.1.2 Encryption Algorithm Transform Type

Values of the Encryption Algorithm define an encryption algorithm to
use when called for in this document. Requests for assignment of new
encryption algorithm values must be accompanied by a reference to an
RFC that describes how to use this algorithm with ESP.

10.1.3 Pseudo-random function Transform Type

Values for the pseudo-random function define which pseudo-random
function is used in IKE for key generation and expansion. Requests
for assignment of a new pseudo-random function MUST be accompanied by
a reference to an RFC describing this function.

10.1.4

8.1.4 Authentication Method Transform Type

The only Authentication method defined in the memo is for digital
signatures. Other methods of authentication are possible and MUST be
accompanied by an RFC which defines the following:

- the cryptographic method of authentication.
- content of the Authentication Data in the Authentication
Payload.
- new payloads, their construction and processing, if needed.
- additions of payloads to any messages, if needed.

10.1.5

8.1.5 Diffie-Hellman Groups

Values of the Diffie-Hellman Group Transform types define a group in
which a Diffie-Hellman key exchange can be completed. Requests for
assignment of a new Diffie-Hellman group type MUST be accompanied by
a reference to an RFC which fully defines the group.

10.2

8.2 Exchange Types

This memo defines three exchange types for use with IKEv2. Requests
for assignment of new exchange types MUST be accompanied by an RFC
which defines the following:

- the purpose of and need for the new exchange.
- the payloads (mandatory and optional) that accompany
messages in the exchange.
- the phase of the exchange.
- requirements the new exchange has on existing
exchanges which have assigned numbers.

Harkins Kaufman Kent Kivinen Perlman [Page 62]

INTERNET DRAFT April 2002

10.3

8.3 Payload Types

Payloads are defined in this memo to convey information between
peers. New payloads may be required when defining a new
authentication method or exchange. Requests for new payload types
MUST be accompanied by an RFC which defines the physical layout of
the payload and the fields it contains. All payloads MUST use the
same generic header defined in Figure 2.

9 Acknowledgements

We would like to thank the many members

IKEv2 [Page 52]

INTERNET DRAFT October 2002

This document is a collaborative effort of the entire IPsec working group
that provided helpful and constructive suggestions on improving IKE.
Special thanks go WG. If
there were no limit to those the number of you who've implemented it!

This protocol is built authors that could appear on an
RFC, the shoulders of many designers who came
before. While they following, in alphabetical order, would have not necessarily reviewed or endorsed this
version and should not be blamed been listed:
Bill Aiello, Steve Bellovin, Sara Bitan, Matt Blaze, Ran Canetti, Dan
Harkins, Paul Hoffman, J. Ioannidis, Steve Kent, Angelos Keromytis,
Tero Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, O.
Reingold. Many other people contributed to the design. Hugh Daniel
suggested the feature of having the initiator, in message 3, specify
a name for any defects, they deserve much
of the credit for its design. We would like to acknowledge Oakley,
SKEME responder, and their authors, Hilarie Orman (Oakley), Hugo Krawczyk
(SKEME). Without gave the hard work feature the cute name "You
Tarzan, Me Jane". David Faucher and Valery Smyzlov helped refine the
design of Doug Maughan, Mark Schertler, Mark
Schneider, Jeff Turner, Dave Carrel, and Derrell Piper, this memo
would not exist. Their contributions to the IPsec WG have been
considerable and critical.

12 traffic selector negotiation.

10 References

[CAST] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
May 1997.

[BLOW] Schneier, B., "The Blowfish Encryption Algorithm", Dr.
Dobb's Journal, v. 19, n. 4, April 1994.

[Bra96] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.

[Bra97] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[Ble98] Bleichenbacher, D., "Chosen Ciphertext Attacks against
Protocols Based on RSA Encryption Standard PKCS#1", Advances
in Cryptology Eurocrypt '98, Springer-Verlag, 1998.

[BR94] Bellare, M., and Rogaway P., "Optimal Asymmetric
Encryption", Advances in Cryptology Eurocrypt '94,
Springer-Verlag, 1994.

[DES] ANSI X3.106, "American National Standard for Information

Harkins Kaufman Kent Kivinen Perlman [Page 63]

INTERNET DRAFT April 2002
Systems-Data Link Encryption", American National Standards
Institute, 1983.

[DH] Diffie, W., and Hellman M., "New Directions in
Cryptography", IEEE Transactions on Information Theory, V.
IT-22, n. 6, June 1977.

[DSS] NIST, "Digital Signature Standard", FIPS 186, National
Institute of Standards and Technology, U.S. Department of
Commerce, May, 1994.

[HC98] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.

[IDEA] Lai, X., "On the Design and Security of Block Ciphers," ETH
Series in Information Processing, v. 1, Konstanz: Hartung-
Gorre Verlag, 1992

[Ker01] Keronytis, A., Sommerfeld, B., "The 'Suggested ID' Extension

IKEv2 [Page 53]

INTERNET DRAFT October 2002

for IKE", draft-keronytis-ike-id-00.txt, 2001

[KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.

[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", from IEEE Proceedings of the 1996
Symposium on Network and Distributed Systems Security.

[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
April 1992.

[MSST98] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, J.
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.

[Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC
2412, November 1998.

[PFKEY] McDonald, D., Metz, C., and Phan, B., "PFKEY Key Management
API, Version 2", RFC2367, July 1998.

[PKCS1] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2", September 1998.

[PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key
exchange Standard", WET-ICE Security Conference, MIT, 2001,
http://sec.femto.org/wetice-2001/papers/radia-paper.pdf.

[Pip98] Piper, D., "The Internet IP Security Domain Of

Harkins Kaufman Kent Kivinen Perlman [Page 64]

INTERNET DRAFT April 2002
Interpretation for ISAKMP", RFC 2407, November 1998.

[RC5] Rivest, R., "The RC5 Encryption Algorithm", Dr. Dobb's
Journal, v. 20, n. 1, January 1995.

[RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for
Obtaining Digital Signatures and Public-Key Cryptosystems",
Communications of the ACM, v. 21, n. 2, February 1978.

[Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms,
and Source Code in C", 2nd edition.

[SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institute
of Standards and Technology, U.S. Department of Commerce,
May 1994.

[TIGER] Anderson, R., ACM, v. 21, n. 2, February 1978.

[SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institute
of Standards and Technology, U.S. Department of Commerce,
May 1994.

IKEv2 [Page 54]

INTERNET DRAFT October 2002

Appendix B: Diffie-Hellman Groups

There are 5 groups different Diffie-Hellman groups defined for use in
IKE. These groups were generated by Richard Schroeppel at the
University of Arizona. Properties of these primes are described in
[Orm96].

The strength supplied by group one may not be sufficient for the
mandatory-to-implement encryption algorithm and is here for historic
reasons.

B.1 Group 1 - 768 Bit MODP

IKE implementations MAY support a MODP group with the following 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 is:

The generator is 2.

B.2 Group 2 - 1024 Bit MODP

IKE implementations SHOULD support a MODP group with the following
prime and Biham, E., "Fast Software Encryption",
Springer LNCS v. 1039, 1996.

Harkins Kaufman Kent Kivinen Perlman generator. This group is assigned id 2 (two).

IKEv2 [Page 65] 55]

INTERNET DRAFT April October 2002

Appendix A

Attribute Assigned Numbers

Certain transforms negotiated in an SA payload can have associated
attributes. Attribute types can be either Basic (B) or Variable-
length (V). Encoding of these attributes

The prime is defined as Type/Value
(Basic) and Type/Length/Value (Variable). See section 7.3.3.

Attributes described as basic MUST NOT be encoded as variable.
Variable length attributes MUST NOT be encoded as basic even if their 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its hexadecimal value can fit into two octets. NOTE: This is:

The generator is 2.

B.3 Group 3 - 155 Bit EC2N

IKE implementations MAY support a change from IKEv1,
where increased flexibility may have simplified EC2N group with the composer of
messages but certainly complicated following
characteristics. This group is assigned id 3 (three). The curve is
based on the parser.

Attribute Classes

class value type
--------------------------------------------------------------
RESERVED 0-5 Galois Field GF[2^155]. The field size is 155. The
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 6 V
Group Generator One 7 V Polynomial:
0x0800000000000000000000004000000000000001
Group Generator Two 8 V One: 0x7b
Group Curve A 9 V A: 0x0
Group Curve B 10 V
RESERVED 11-13
Key Length 14 B
Field Size 15 B
Group Order 16 V
Block Size 17 B

values 0-5, 11-13, and 18-16383 are reserved to IANA. Values
16384-32767 are for private use among mutually consenting parties.

- B: 0x07338f
Group Prime/Irreducible Polynomial Order: 0x0800000000000000000057db5698537193aef944

The prime number of a MODP Diffie-Hellman data in the KE payload when using this group or is the value x from
the solution (x,y), the point on the irreducible
polynomial of an elliptic curve when specifying a private Diffie-
Hellman group.

- Generator One, Generator Two

The X- chosen by taking the
randomly chosen secret Ka and Y-coordinate computing Ka*P, where * is the
repetition of a point on an elliptic curve. When the
Y-coordinate (generator two) group addition and double operations, P is not given it can be computed with the X-coordinate
curve point with x coordinate equal to generator 1 and the definition y
coordinate determined from the defining equation. The equation of
curve is implicitly known by the curve.

- Curve A, Curve Group Type and the A and B

Harkins Kaufman Kent Kivinen Perlman
coefficients. There are two possible values for the y coordinate;
either one can be used successfully (the two parties need not agree
on the selection).

IKEv2 [Page 66] 56]

INTERNET DRAFT April October 2002

Coefficients from the definition of an elliptic curve:

y^2 + xy = x^3 + (curve A)x^2 + (curve B)

B.4 Group 4 - Key Length

When using an Encryption Algorithm that has 185 Bit EC2N

IKE implementations MAY support a variable length key,
this attribute specifies EC2N group with the key length in bits. (MUST use network
byte order). following
characteristics. This attribute MUST NOT be used when the specified
Encryption Algorithm uses a fixed length key.

- group is assigned id 4 (four). The curve is
based on the Galois Field Size GF[2^185]. The field size, in bits, of a Diffie-Hellman group.

- Group Order size is 185. The group order of an
irreducible polynomial for the field is:
u^185 + u^69 + 1.

The equation for the elliptic curve group. Note is:
y^2 + xy = x^3 + ax^2 + b.

The data in the length of KE payload when using this attribute depends on the field size. group will be identical to
that as when using Oakley Group 3 (three).

B.5 Group 5 - Block Size

The number of bits per block of 1536 Bit MODP

IKE implementations MUST support a cipher MODP group with a variable block
length.

Harkins Kaufman Kent Kivinen Perlman the following
prime and generator. This group is assigned id 5 (five).

The prime is 2^1536 - 2^1472 - 1 + 2^64 * {[2^1406 pi] + 741804}.
Its hexadecimal value is

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF

The generator is 2.

IKEv2 [Page 67] 57]

INTERNET DRAFT April October 2002

Appendix B: Cryptographic Protection of IKE Data

With the exception of the IKE-SA-INIT-REQUEST, IKE-SA-INIT-RESPONSE,
and Informational Exchange error notifications when no IKE-SA exists,
all IKE messages are encrypted and integrity protected. The
algorithms for encryption and integrity protection are negotiated
during IKE-SA setup, and

Change History

H.1 Changes from IKEv2-00 to IKEv2-01 February 2002

1) Changed Appendix B to specify the keys are computed as specified in
sections 3 and 4.2.

The encryption and integrity protection algorithms are modelled after
the ESP algorithms described in RFCs 2104, 2406, 2451. This appendix
completely specifies the cryptographic authentication
processing of for IKE data, but
those documents should be consulted rather than referencing ESP. Simplified the format
by removing idiosyncracies not needed for design rationale. This
appendix assumes a block cipher with a fixed block size and an
integrity check algorithm that computes a fixed length checksum over IKE.

2) Added option for authentication via a variable size message. The mandatory to implement algorithms are
AES-128 and HMAC-SHA1.

Harkins Kaufman Kent Kivinen Perlman [Page 68]

INTERNET DRAFT April 2002

The format shared secret key.

3) Specified different keys in the two directions of an IKE message is shown messages.
Removed requirement of different cookies in Figure 18.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Fixed IKE Header - 28 octets !
! (including cookies, message ID, Length) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initialization Vector !
! (length is block size for encryption algorithm) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IKE Payloads !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! Padding (0-255 octets) !
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
! ! Pad Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 18: IKE message with cryptographic protection

o Initialization Vector - A randomly chosen value whose length
is equal the two directions since
now no longer required.

4) Change the quantities signed by the two ends in AUTH fields to
assure the block length two parties sign different quantities.

5) Changed reference to AES to AES_128.

6) Removed requirement that Diffie-Hellman be repeated when rekeying
IKE SA.

7) Fixed typos.

8) Clarified requirements around use of port 500 at the underlying encryption
algorithm. Recipients MUST accept any value. Senders SHOULD
either pick this value pseudo-randomly and independently remote end in
support of NAT.

9) Clarified required ordering for
each message or use payloads.

10) Suggested mechanisms for avoiding DoS attacks.

11) Removed claims in some places that the final ciphertext block of first phase 2 piggybacked
on phase 1 was optional.

H.2 Changes from IKEv2-01 to IKEv2-02 April 2002

1) Moved the previous Initiator CERTREQ payload from message sent. Senders MUST NOT use the same value for each
message, use a sequence of values with low hamming distance
(e.g. 1 to message 3.

2) Added a sequence number), or use ciphertext from second optional ID payload in message 3 for the Initiator
to name a received
message.

o IKE Payloads desired Responder to support the case where multiple named
identities are as served by a single IP address.

3) Deleted the optimization whereby the Diffie-Hellman group did not
need to be specified in Section 7. This field is
encrypted with phase 2 if it was the negotiated cipher.

o Padding may contain any value chosen by same as in phase 1 (it
complicated the sender, and must
have design with no meaningful benefit).

4) Added a length that makes section on the combination implications of reusing Diffie-Hellman
expontentials

IKEv2 [Page 58]

INTERNET DRAFT October 2002

5) Changed the Payloads, the
Padding, specification of sequence numbers to being at 0 in
both directions.

6) Many editorial changes and corrections, the Pad Length to be most significant being
a multiple global replace of the encryption
block size. This field is encrypted "byte" with "octet".

H.3 Changes from IKEv2-02 to IKEv2-03 October 2002

1) Reorganized the negotiated
cipher.

o Pad Length is the length of the Padding field. The sender
SHOULD set the Pad Length document moving introductory material to the minimum value that makes
front.

2) Simplified the combination specification of Traffic Selectors to allow only
IPv4 and IPv6 address ranges, as was done in the Payloads, JFK spec.

3) Fixed the Padding, and problem brought up by David Faucher with the Pad
Length a multiple of fix
suggested by Valery Smyslov. If Bob needs to narrow the block size, selector
range, but has more than one matching narrower range, then if Alice's
first selector is a single address pair, Bob chooses the recipient MUST
accept any length range that results in proper alignment. This
field is encrypted
encompasses that.

4) To harmonize with the negotiated cipher.

o Authentication Data is JFK spec, changed the cryptographic checksum of exchange so that the

Harkins Kaufman Kent Kivinen Perlman [Page 69]

INTERNET DRAFT April 2002

entire message starting with
initial exchange can be completed in four messages even if the Fixed IKE Header through
responder must invoke an anti-clogging defense and the Pad Length. The checksum MUST be computed over initiator
incorrectly anticipates the responder's choice of Diffie-Hellman
group. This required changing the syntax of encrypted message.

Authors' Addresses

Dan Harkins
dharkins@trpz.com
Trapeze Networks messages to
allow messages that are partially encrypted.

5) Replaced the hierarchical SA payload with a simplified version
that only negotiates suites of cryptographic algorithms. Separated
out negotiation of window size. Removed specifications of large
numbers of rarely used algorithms.

6) Changed the formulas for key derivation as proposed by Hugo
Krawczyk.

7) Added Comformance Requirements section.

Author's Address

Charlie Kaufman
ckaufman@iris.com charlie_kaufman@notesdev.ibm.com IBM

Steve Kent
kent@bbn.com
BBN Technologies

Tero Kivinen
kivinen@ssh.com
SSH Communications Security

Radia Perlman
radia.perlman@sun.com
Sun Microsystems

Harkins Kaufman Kent Kivinen Perlman

IKEv2 [Page 70] 59]

----