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

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

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

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

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

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

10. 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}

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

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

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

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

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

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

19. 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}

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