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

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( | IPi | SPI | TS) - 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

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 SA’s can be created at a single CHILD_SA negotiation.