1

Lecture 14

ISAKMP / IKE

Internet Security Association and Key Management Protocol / Internet Key Exchange

CIS 4362 - CIS 5357

Network Security

2

ISAKMP

• Policy Negotiation• ISAKMP Protocols are

constructed by chaining together ISAKMP payloads to an ISAKMP header

• Two Phases1. Establish a key-exchange SA2. Negotiate security services

3

ISAKMP Exchange Types• 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

4

ISAKMP Data Exchange Phases

1. Establish a secure channel

2. Use the secure channel to exchange information for a protocol (such as IPSEC)

5

ISAKMP Payload Types

1. Initiate SA

2. Protocol [cipher] Proposal

3. Transform <SA attribute>

4. Key Exchange

5. Identification

6. Certificate

7. Certificate request

8. Hash

9. Signature

10.Nonce

11.Notification

12.Delete SA

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

KE Version Exchange Flags

Nonce 0

0 0

Initiator CookieResponder Cookie

Message IDTotal Message Length

KE payload lengthKE Payload Data

Nonce payload LengthNonce Payload Data

Key Exchange Payload

Nonce Payload

ISAKMP Header

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

IKE Phase 1: Aggressive Mode

Alice

Bob

ga mod p, “Alice”, supported crypto

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 secretgab mod p, which can be used to derive keys for the symmetric cryptoprotocols.

10

IKE Phase 1: Main Mode

Alice

Bob

ga mod p

supported crypto suites

chosen crypto suite

gb mod p

K{“Alice”, proof I’m Alice}

K{“Bob”, proof I’m Bob}

K= gab mod 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

Example of a “BADH” protocol(Basic Authenticated DH)

Alice

Bob

gx mod p

gy mod p, B, signB(gx, gy)

A, signA(gy, gx)

K derivedfrom gxy

The inclusion of both exponentials in each signatureprevents replay attacks, but does not provide for key binding consistency.

14

Key Binding Inconsistency

EE, signE(gy, gx)

Alice B

ob

gx mod p

gy mod p, B, signB(gx, gy)

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 violateauthentication and/or secrecy.

15

STS Protocol

Alice

Bob

gx mod p

gy mod p, B, K{signB(gx, gy)}

A, K{signA(gy, gx)}

K derivedfrom 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

ISO Key Exchange

Alice

Bob

A, gx mod p

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.

17

Sigma Protocol (Basic)

Alice

Bob

gx mod p

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

18

SIGMA-I

Alice

Bob

gx mod p

gy mod p, Ke{B, signB(gx, gy), MACKm(B)}

Ke{A, signA(gy, gx), MACKm(A)}

Identity of the sender is protected againstboth passive and active attacks. The identityof the receiver is protected against passiveattacks.

19

Phase 1: Main mode, (shared secret authentication)

Alice

Bob

ga mod p, nonce nA

supported crypto suites

chosen crypto suite

gb mod p, nonce nB

K{“Alice”, proof I’m Alice}

K{“Bob”, proof I’m Bob}

K= f(J, gab mod p,nA, nB, cA, cB)

Pre-sharedsecret J

20

IKE Phase 2quick mode

Alice

Bob

X, Y, {CP, SPIA, nonceA, [ga mod p]}

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 identifythe type of traffic to be sent.