Lecture 16 ipsec ike
This presentation is the property of its rightful owner.
Sponsored Links
1 / 9

Lecture 16: IPsec IKE PowerPoint PPT Presentation


  • 37 Views
  • Uploaded on
  • Presentation posted in: General

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:

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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

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


Photuris

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}


Ike isakmp phases

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


  • Phase 1 modes

    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


    Phase 1 aggressive mode

    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


    Phase 1 main mode

    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}


    Phase 1 issues

    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?)


    Phase 2

    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


  • Login