IKE message flow IKE message flow always consists of a request followed by a response. It is the...
-
date post
20-Dec-2015 -
Category
Documents
-
view
218 -
download
0
Transcript of IKE message flow IKE message flow always consists of a request followed by a response. It is the...
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-SA’s
and performing “housekeeping functions”
Phase 1
• Establishes an IKE-SA that includes shared secret information that can be used to efficiently establish Child-SA’s.
• 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 – initiator’s DH value.• Ni – initiator’s nonce.
INIT response
The responder sends the following message: HDR, SAr1, KEr, Nr [CERTREQ]
• SAr1 – states the cryptographic algorithms the responder selected.
• KEr – responder’s Difie-Hellman value.• Nr – responder’s 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 – initiator’s identity• CERT, CERTREQ – optionally presenting or
requesting certificates• IDr – specifiying the responder’s 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 initiator’s 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 – responder’s identity
• CERT – presenting certificates
• AUTH - authenticates the previous message and the resonder’s identity.
• SAr2, TSi, TSr - needed for first CHILD-SA
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 initiator’s offers for the new SA
• Ni - Initiator’s 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 - Responder’s 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 SA’s 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