Lecture 16: IPsec IKE

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 CA: Alice’s cookie; for connection identification (in case she initiates multiple connections to Bob) CB: Bob’s cookie, stateless; against DoS (why?) CA CA,CB, crypto offered CA,CB, ga mod p, crypto selected Alice Bob CA,CB, gb mod p (K = gab mod p) CA,CB, K{“Alice”, signature on previous messages} CA,CB, 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 messagesSKEYID_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?) ga mod p, “Alice”, crypto offered gb mod p, crypto selected, proof I’m Bob Alice Bob proof I’m Alice

7. Phase 1 – Main Mode crypto offered crypto selected ga mod p Alice Bob gb mod p (K = gab mod p) K{“Alice”, proof I’m Alice} 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 Phase1 SA • X: pair of cookies generated in Phase 1Y: 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)? X, Y, CP, SPIA, nonceA, [traffic], [ga mod p] Alice Bob X, Y, CPA, SPIB, nonceB, [traffic], [gb mod p] X, Y, ack