IKE message flow

IKE message flow always consists of a

request followed by a response.
It is the responsibility of the requester
to ensure reliability.
If the response is not received within a
timeout interval, the requestor will
retransmit the request or abandon the
connection.

SA terminology
IKE-SA
used to secure IKE communication.
CHILD-SA
Created by the IKE to be used in ESP or
AH security.

The two IKE phases

Phase 1
Establishment of an IKE-SA
Mutual authentication
Creation of the first CHILD-SA.
(An expensive process which is done rarely)
Phase 2
establishing additional CHILD-SAs
and performing housekeeping functions

Phase 1
Establishes an IKE-SA that includes
shared secret information that can be
used to efficiently establish Child-SAs.
Performs mutual authentication
Creates the first Child-SA
Consists of two stages

Stage 1 - INIT
Negotiates cryptographic algorithms
Exchanges nonces
Performs a Diffie-Hellman exchange
Note: messages are not protected

INIT request
The initiator sends the following message:
HDR, SAi1, KEi, Ni
HDR header contains SPI, version, flags
SAi1 states the cryptographic algorithms
the initiator supports
KEi initiators DH value.
Ni initiators nonce.

INIT response
The responder sends the following message:
HDR, SAr1, KEr, Nr [CERTREQ]
SAr1 states the cryptographic algorithms
the responder selected.
KEr responders Difie-Hellman value.
Nr responders nonce.
CERTREQ optional certificate request

SKEYSEED generation
Each party generates the SKEYSEED
which is used to derive the keys used in
IKE-SA.
Notice: separate keys are computed for
each direction

Authentication stage
Authenticates the previous messages
Exchanges and proves identities
Establishes the first CHILD-SA

Messages are protected using the keys

derived at the INIT stage.
Identity protection is achieved

Authentication request
HDR, SK{ IDi, [CERT,] [CERTREQ,] [IDr,] AUTH,
SAi2, TSi, TSr }
IDi initiators identity
CERT, CERTREQ optionally presenting or
requesting certificates
IDr specifiying the responders desired identity
* SK{} indicates encription and integrity protection using SK_e and
SK_a

Authentication request
HDR, SK{ IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr }
AUTH authenticates the previous
message and the initiators identity.
(a digital signature over the first message)
SAi2, TSi, TSr needed for first CHILD-SA

Authentication response
HDR, SK{ IDr, [CERT,] AUTH, SAr2, TSi,
TSr}
IDr responders identity
CERT presenting certificates
AUTH - authenticates the previous
message and the resonders identity.
SAr2, TSi, TSr - needed for first CHILD-SA

End of phase 1
Signatures are verified
First CHILD-SA is established

Possible DOS attack

The response to the first Phase 1
message involves expensive
computations
This can be exploited in a DOS attack
where the attacker use IP Spoofing to
flood the victim with requests to open
connection.
Can be solved using cookies

Cookies
A Cookie is a field which is sent to the
connection initiator.
The initiator is expected to return the
cookie.
A returned cookie is a proof that the
initiator can receive packets destined to
the IP address he declared.

The use of cookies

When a responder detects many half-open
connections, a new policy is used.
Each new connection request that does
not contain a valid cookie is rejected.
The rejection message contains a cookie
and a demand for this cookie in a future
connection request.

Cookie demands
No one but the creator can construct a
valid cookie
Cheap to create
No resources needs to be allocated to
handle each cookie

Cookie creation
Cookie = HASH(<secret> | IPi | SPI | TS)

<secret> - a secret known only to the responder

IPi IP address of the initiator
SPI included in the request
TS time stamp

(A possible problem )

Phase 2
Creating a new CHILD-SA:
Relatively cheap operation
Can be initiated by either endpoints
Provides optional perfect-forward-secrecy
All other information flow:
Will be discussed later

CHILD-SA request
A CREATE_CHILD_SA request:
HDR, SK{ SA, Ni, [KEi,] [TSi, TSr] }

SA The initiators offers for the new SA

Ni - Initiators nonce
KEi a new DH value
TSi, TSr proposed traffic selectors

CHILD-SA response
A CREATE_CHILD_SA response:
HDR, SK{ SA, Nr, [KEr,] [TSi, TSr] }
SA The responder chosen SA offer
Nr - Responders nonce
KEr A new DH value
(if the request had a Kei)
TSi, TSr selected traffic selectors

PFS in IKE
Reminder:
Perfect forward secrecy means that once a
connection is closed and its keys are
forgotten, even someone who recorded all
the data from the connection, and gets
access to the long term keys used to
protect it, cannot reconstruct the keys of a
CHILD-SA that was created during the
connection.

Achieving CHILD-SA PFS

The optional KE field in the establishment
of a new CHILD-SA indicates that the keys
created depend on a unique DH key
exchange. Such keys achieve the PFS
quality.
Expensive procedure.
Depends on two conditions

Generating keying material

In the establishment of the IKE-SA a
pseudo-random function (prf) is
negotiated.
The keying material for all SAs is derived
from the output string of the prf.

Prf usage
Usually the amount of keying material
needed is greater then the prf output.
The prf is used iteretively:
Prf+ (K , S) = T1 | T2 | T3 |
where:
T1 = prf (K , S | 0x01)
T2 = prf (K , T1 | S | 0x02)
T3 = prf (K , T2 | S | 0x03)

IKE-SA keying material

After INIT (in Phase 1),
SKEYSEED is calculated:
SKEYSEED = prf (Ni | Nr , g^ir)
Ni, Nr nonces of both parties
G^ir the DH key

IKE-SA keys derived

Five keys are derived.
SK_d used in deriving CHILD-SA keys
SK_ai, SK_ar authentication keys
SK_ei, SK_er encryption keys
Notice: different keys for each direction

IKE-SA keys deriviation

{ SK_d , SK_ai , SK_ar , SK_ei , SK_er } =
Prf+ (SKEYSEED ,
g^ir | Ni | Nr | CKY-I | CKY-R)
CKY-I , CKY-R the cookie of both parties

CHILD-SA keying material

Creation without PFS:
KEYMAT = prf+ (SK_d, Ni | Nr)
Creation with PFS:
KEYMAT = prf+ (sk_d, g^ir | Ni | Nr )
g^ir is the DH key established for this
CHILD_SA

CHILD-SA keying derivation

All keys needed for the SA created are
derived from the KEYMAT
(depends on the needs of the algorithms
using this SA)
Multiple SAs can be created at a single
CHILD_SA negotiation.