1 Lecture 16: IPsec IKE history of IKE Photurus IKE phases –phase 1 aggressive mode main mode –phase 2

2 History of IKE Early contenders: –Photuris: Authenticated D-H with cookies & identity hiding –SKIP: Auth. D-H with long-term public exponents known to the other party ISAKMP: –a protocol specifying only payload formats & exchanges (i.e., an empty protocol) –adopted by the IPsec working group Oakley: modified Photuris; can work with ISAKMP IKE: a particular Oakley-ISAKMP combination

3 Photuris C A : Alice’s cookie; for connection identification (in case she initiates multiple connections to Bob) C B : Bob’s cookie, stateless; against DoS (why?) Alice Bob CACA C A,C B, crypto offered C A,C B, g a mod p, crypto selected C A,C B, g b mod p C A,C B, K{“Alice”, signature on previous messages} (K = g ab mod p) C A,C B, K{“Bob”, signature on previous messages}

4 IKE/ISAKMP Phases Phase 1 : –does authenticated D-H, establishes session key & “ISAKMP SA or IKE SA” (security association, what’s that again?) –two possible modes: Main & Aggressive –two keys are derived from the session key: SKEYID_e: to encrypt Phase 2 messages SKEYID_a: to authenticate Phase 2 messages Phase 2: –IPsec (AH or ESP) SA established; messages encrypted & authenticated with Phase 1 keys –optional additional D-H exchange for PFS why two phases? –ISAKMP may possibly used for other things besides IPsec –may have different conversations on top of same phase 1 (with different security characteristics) –key rollover is easier on phase 2 rather than repeating phase 1

5 Phase 1 Modes two possible modes: –main mode: 6 rounds; provides identity hiding –aggressive mode: 3 rounds types of authentication: –MAC with pre-shared secret key –digital signatures –public key encryption original: all public key encryption revised: public + secret key encryption

6 Phase 1 – Aggressive Mode previous messages are used to compose the proof, what else? one problem – if Bob does not support any of the Alice’s crypto choices it just has to terminate the connection without informing Alice (why?) Alice Bob g a mod p, “Alice”, crypto offered g b mod p, crypto selected, proof I’m Bob proof I’m Alice

7 Phase 1 – Main Mode Alice Bob crypto offered crypto selected g a mod p g b mod p K{“Alice”, proof I’m Alice} (K = g ab mod p) K{“Bob”, proof I’m Bob}

8 Phase 1 Issues crypto parameters: Alice presents all algorithm combinations she can support – may be too costly – what if she supports any combination proof of identity: –certain fields of the previous messages are hashed & signed/encrypted in the final rounds –not included: Bob’s accepted parameters (problematic) cookies: –similar to Photuris cookies –yet cookies include the crypto parameters Alice offered, Bob is no longer stateless (why? why is this a problem?)

9 Phase 2 X: pair of cookies generated in Phase 1 Y: session identifier within Phase 1 (could be multiple sessions) each message is encrypted/authenticated with Phase 1 keys traffic: optional description of acceptable traffic key generation: based on Phase 1 key, SPI, nonces what’s SPI (security parameter index)? Alice Bob X, Y, CP, SPI A, nonce A, [traffic], [g a mod p] X, Y, CPA, SPI B, nonce B, [traffic], [g b mod p] X, Y, ack Phase1 SA