1 / 20

Lecture 14

Lecture 14. ISAKMP / IKE Internet Security Association and Key Management Protocol / Internet Key Exchange CIS 4362 - CIS 5357 Network Security. Policy Negotiation ISAKMP Protocols are constructed by chaining together ISAKMP payloads to an ISAKMP header Two Phases

mya
Download Presentation

Lecture 14

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 14 ISAKMP / IKE Internet Security Association and Key Management Protocol / Internet Key Exchange CIS 4362 - CIS 5357 Network Security

  2. Policy Negotiation ISAKMP Protocols are constructed by chaining together ISAKMP payloads to an ISAKMP header Two Phases Establish a key-exchange SA Negotiate security services ISAKMP

  3. Basic = 1 Authentication Key Exchange Saturation protection Identity Protection = 2 (Main mode IKE) Authentication Key Exchange Protects users identities Authentication Only = 3 Authentication Aggressive = 4 (Aggressive Mode IKE) Authentication Key exchange No saturation protection Informational = 5 Information only ISAKMP Exchange Types

  4. Establish a secure channel Use the secure channel to exchange information for a protocol (such as IPSEC) ISAKMP Data Exchange Phases

  5. Initiate SA Protocol [cipher] Proposal Transform <SA attribute> Key Exchange Identification Certificate Certificate request Hash Signature Nonce Notification Delete SA ISAKMP Payload Types

  6. ISAKMP Fixed Header Format • Initiator Cookie (64 bits) • Responder Cookie (64 bits) (null in message from the originator • Next Payload (8 bits) • Major ISAKMP Version (4 bits) • Minor ISAKMP Version (4 bits) • Exchange Type (8 bits) • Flags (8 bits) • Message ID (32 bits) • Message length (32 bits)

  7. Example ISAKMP Header & Payload ISAKMP Header Key Exchange Payload Nonce Payload

  8. IKE Phases • In a design similar to Kerberos, IKE performs a phase 1 mutual authentication based on public keys and phase 2 re-authentication based on shared secrets (from phase 1). • This allows multiple SAs to re-use the same handshake. • Phase 1 has two modes: • Aggressive mode (3 messages) • Main mode (6 messages)

  9. ga mod p, “Alice”, supported crypto gb mod p, choice crypto, proof(“I’m Bob”) proof(“I’m Alice”) IKE Phase 1: Aggressive Mode Alice Bob In aggressive mode, Alice chooses some Elgamal context (p, g). Bob may not support it, and reject the connection. If that happens, Alice should try and connect to Bob using main mode. Aggressive mode provides mutual authentication, and a shared secretgab mod p, which can be used to derive keys for the symmetric crypto protocols.

  10. supported crypto suites chosen crypto suite ga mod p gb mod p K{“Alice”, proof I’m Alice} K{“Bob”, proof I’m Bob} IKE Phase 1: Main Mode Alice Bob K= gabmod p

  11. Reasoning about IKE • The SIGn-and-MAc (SIGMA) family of key exchange protocols. • Introduced by Krawczyk to the IPsec working group (1995), replaced Photuris. • Several interesting properties, tried to plug certain holes in existing Key Exchange Protocols.

  12. Security Goals of SIGMA • Mutual Authentication • Key-binding Consistency: • If honest A establishes a key K, believing that B is the other session peer, and B establishes the same key K, it should believe that A is the peer in this exchange • Secrecy (of the computed key) • Optional: • Identity Protection, providing anonymity against eavesdroppers for the two parties in a communication

  13. gx mod p gy mod p, B, signB(gx, gy) A, signA(gy, gx) Example of a “BADH” protocol(Basic Authenticated DH) Alice Bob K derived from gxy The inclusion of both exponentials in each signature prevents replay attacks, but does not provide for key binding consistency.

  14. gx mod p gy mod p, B, signB(gx, gy) E, signE(gy, gx) Key Binding Inconsistency Alice Bob E Outcome: Alice thinks she shares key K with Bob, while Bob thinks that he shares the same K with Eve. Eve does not know the key, so this does not violate authentication and/or secrecy.

  15. gx mod p gy mod p, B, K{signB(gx, gy)} A, K{signA(gy, gx)} STS Protocol Alice Bob K derived from gxy • Intuitively this solves the consistency problem, but no proof exists. • What if Eve registers Alice’s public key on her name? • Even if Eve does not know Alice’s secret key, she may be able to perform replay attacks to violate consistency of key binding

  16. A, gx mod p gy mod p, B, signB(gx, gy, A) signA(gy, gx), B ISO Key Exchange Alice Bob • Does not provide identity protection. • Could be “fixed” by having Alice send an “alias” • A’ = h(A, r), which is revealed later, and have the other • messages be encrypted under the DH key.

  17. gx mod p gy mod p, B, signB(gx, gy), MACKm(B) A, signA(gy, gx), MACKm(A) Sigma Protocol (Basic) Alice Bob Output from DH-value gxy: encryption key Ke, mac key Km

  18. gx mod p gy mod p, Ke{B, signB(gx, gy), MACKm(B)} Ke{A, signA(gy, gx), MACKm(A)} SIGMA-I Alice Bob Identity of the sender is protected against both passive and active attacks. The identity of the receiver is protected against passive attacks.

  19. supported crypto suites chosen crypto suite ga mod p, nonce nA gb mod p, nonce nB K{“Alice”, proof I’m Alice} K{“Bob”, proof I’m Bob} Phase 1: Main mode, (shared secret authentication) Alice Bob Pre-shared secret J K= f(J, gabmod p, nA, nB, cA, cB)

  20. X, Y, {CP, SPIA, nonceA, [ga mod p]} X, Y, {CPA, SPIB, nonceB, [gb mod p] B} X, Y, ack IKE Phase 2quick mode Alice Bob • X, Y are session-identifiers for this flow: • X contains the cookies of the corresponding phase 1, • Y is 32-bit to identify this particular connection. • Optionally some tags may be included to identify • the type of traffic to be sent.

More Related