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
– Key Exchange
– Protects users
identities
• Authentication Only = 3
– Authentication
• Aggressive = 4
(Aggressive Mode IKE)
– Authentication
– Key exchange
– No saturation protection
• Informational = 5
– Information only
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 <SA attribute>
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
KE
Key
Exchange
Payload
Nonce
Nonce
Payload
0
Initiator Cookie
Responder Cookie
Version Exchange Flags
Message ID
Total Message Length
0
KE payload length
KE Payload Data
0
Nonce payload Length
Nonce Payload Data
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, 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.
13
Key Binding Inconsistency
gx mod p
Bob
Alice
E
gy mod p, B, signB(gx, gy)
E, signE(gy, gx)
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.
14
STS Protocol
gx mod p
Bob
Alice
gy mod p, B, K{signB(gx, gy)}
K derived
from gxy
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
15
ISO Key Exchange
A, gx mod p
Bob
Alice
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.
16
Sigma Protocol (Basic)
gx mod p
Bob
Alice
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
17
SIGMA-I
gx mod p
Bob
Alice
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.
18
Phase 1: Main mode,
(shared secret authentication)
supported crypto suites
Pre-shared
secret J
chosen crypto suite
ga mod p, nonce nA
K{“Alice”, proof I’m Alice}
Bob
Alice
gb mod p, nonce nB
K=
f(J, gab mod p,
nA, nB, cA, cB)
K{“Bob”, proof I’m Bob}
19
IKE Phase 2
quick mode
X, Y, {CP, SPIA, nonceA, [ga mod p]}
Bob
Alice
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.
20