1 lecture 14 isakmp / ike internet security association and key management protocol / internet key...
TRANSCRIPT
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.