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

ISAKMP 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 Exchange Types Basic = 1 Authentication Key Exchange Saturation protection Identity Protection = 2 (Main mode IKE) Protects users identities Authentication Only = 3 Authentication Aggressive = 4 (Aggressive Mode IKE) Key exchange No saturation protection Informational = 5 Information only

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

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

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)

Example ISAKMP Header & Payload Key Exchange Payload Nonce Payload

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)

IKE Phase 1: Aggressive Mode ga mod p, “Alice”, supported crypto Alice Bob 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.

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

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.

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

Example of a “BADH” protocol (Basic Authenticated DH) gx mod p Alice Bob gy mod p, B, signB(gx, gy) A, signA(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.

Key Binding Inconsistency gx mod p Alice Bob gy mod p, B, signB(gx, gy) E, signE(gy, gx) 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.

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

ISO Key Exchange Does not provide identity protection. A, gx mod p Alice Bob gy mod p, B, signB(gx, gy, A) signA(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.

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

SIGMA-I Identity of the sender is protected against gx mod p Alice Bob gy mod p, Ke{B, signB(gx, gy), MACKm(B)} Ke{A, signA(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.

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

IKE Phase 2 quick mode X, Y are session-identifiers for this flow: X, Y, {CP, SPIA, nonceA, [ga mod p]} Alice Bob X, Y, {CPA, SPIB, nonceB, [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.