Lecture 14 ISAKMP IKE Internet Security Association

Lecture 14 ISAKMP / IKE Internet Security Association and Key Management Protocol / Internet Key Exchange CIS 4362 - CIS 5357 Network Security 1

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

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

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

ISAKMP Payload Types 1. 2. 3. 4. 5. 6. Initiate SA Protocol [cipher] Proposal Transform Key Exchange Identification Certificate 7. Certificate request 8. Hash 9. Signature 10. Nonce 11. Notification 12. Delete SA 5

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

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

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

IKE Phase 1: Aggressive Mode ga mod p, “Alice”, supported crypto Bob Alice gb mod p, choice crypto, proof(“I’m Bob”) proof(“I’m Alice”) 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 secret gab mod p, which can be used to derive keys for the symmetric crypto protocols. 9

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

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. 11

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 12

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

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

STS Protocol gx mod p Bob Alice gy mod p, B, K{sign. B(gx, gy)} K derived from gxy A, K{sign. A(gy, gx)} • 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 15

ISO Key Exchange A, gx mod p Bob Alice gy mod p, B, sign. B(gx, gy, A) sign. A(gy, gx), B • 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. 16

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

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

Phase 1: Main mode, (shared secret authentication) supported crypto suites Pre-shared secret J chosen crypto suite ga mod p, nonce n. A K{“Alice”, proof I’m Alice} Bob Alice gb mod p, nonce n. B K= f(J, gab mod p, n. A, n. B, c. A, c. B) K{“Bob”, proof I’m Bob} 19

IKE Phase 2 quick mode X, Y, {CP, SPIA, nonce. A, [ga mod p]} Bob Alice X, Y, {CPA, SPIB, nonce. B, [gb mod p] B} X, Y, ack • 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. 20