1 / 9

Lecture 16: IPsec IKE

Lecture 16: IPsec IKE. history of IKE Photurus IKE phases phase 1 aggressive mode main mode phase 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:

nita
Download Presentation

Lecture 16: IPsec IKE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related