Transcript Key Exchange Protocols

CS 259
IKEv2 extension: MOBIKE
Faisal Memon
Erik Weathers
MOBIKE
IKEv2 Mobility and Multihoming Protocol
• As defined in draft-ietf-mobike-protocol-07.txt
• Main purpose
– For roaming devices (devices which move and hence have
changing IP addresses), that want to keep the existing IKE
and IPsec SAs in place despite the IP address changing, and
without requiring a full rekey.
• Secondary purpose
– Multihomed (multiple interface) device which decides to
change its IKE endpoint IP. Could be a result of link failure
or other conditions.
MOBIKE Init and AUTH Exchanges
HDR, KEi, Ni
I
HDR, KEr, Nr
HDR, {IDi, AUTH, MOBIKE}KIR
HDR, {IDr, AUTH, MOBIKE}KIR
Typical IKEv2 init exchange, with
notify declaring support for MOBIKE.
R
MOBIKE Address Change Exchange
HDR, {UpdateSA_Address}KIR
I2
HDR, {ACK}KIR
HDR, {Cookie}KIR
HDR, {Cookie}KIR
Initiator IP address changed to I2.
Cookie exchange is for optional return
routability verification.
R
IKEv2 General Attacks
• Replay Attack
• Prevented by nonces and also by message IDs in the
cryptographically protected IKE header (HDR)
• MITM Attack
• Prevented by AUTH payload in IKE_AUTH exchange
• DoS
• Very difficult to handle, but an optional cookie exchange
prior to DH exponentiation is included in IKEv2 to prevent
spoof attacks from forcing expensive exponentiation.
IKEv2 Exchanges
I
{HDR, {Payload}KIR-E}KIR-A
{HDR, {Payload}KIR-E}KIR-A
• All IKEv2 requests are ACKed.
• After the IKE_INIT exchange, all
messages are encrypted and MACed.
R
IKEv2 MITM Attack
HDR, KEi, Ni
I
HDR, KEa, Nr
HDR, KEa, Ni
A
HDR, KEr, Nr
Typical IKEv2 init exchange, with
attacker A attempting MITM attack
by substituing his own DH values.
R
IKEv2 MITM Attack Prevention
HDR, IDI, {AUTH}KIA
I
HDR, IDA, {AUTH}KAR
A
HDR, IDR, {AUTH}KAR
R
Typical IKEv2 AUTH exchange, thwarting A’s MITM attack
when AUTH payload is checked by responder. The AUTH
payload is an integrity checksum defined as 1 of:
• AUTH = MAC({1st msg we sent, ID’, Nonce of partner},
key derived from shared secret)
• AUTH = SIG({1st msg we sent, ID’, Nonce of partner},
our private key)
MOBIKE Possible Attacks
• IKEv2 general attacks are still prevented by same
mechanisms.
• Traffic Redirection and DoS of 3rd parties
• NATs are permitted (general case)
• Layer 3 & 4 headers are unprotected and unauthenticated (so NATs
can work)
• Thus allowing DoS is allowed
• IPSec SAs are switched to the source IP in
UPDATE_SA_ADDRESS request
• Seems attacker can just replace source IP with arbitrary one
• 2 mechanisms help limit attacks to simple DoSes
• Return routability exchange
• attacker cannot generate reply unless he knows the IKE session
keys.
• IKEv2 request ACKing
• if the UPDATE_SA_ADDRESS request isn’t ACKed, the client will
resend it.
MOBIKE Possible Attacks
• When NATs are not allowed (e.g. site-tosite situation with controlled path) the
overwriting of source IP by an attacker
is detected by inclusion of the new
address in the protected portion of the
UPDATE_SA_ADDRESS request.
Return Routability Prevents Attack
NAT
I1
UPDATE_SA_ADDRESS
UPDATE_SA_ADDRESS
ACK
ACK
I2
UPDATE_SA_ADDRESS
NAT
ACK
A
R
COOKIE2
COOKIE2
Attacker cannot send COOKIE2 reply since
he doesn’t know session key
MOBIKE Modeling
• Modeled in Murφ
• 4 agents involved
• Initiator
• Initiator-prime (post address change)
• Responder
• Intruder
• Intruder controls network
• Acts as sink for network messages, forwarding
them out to all possible recipients from all
possible sources.
• Cannot modify protected portions of IKE
messages.
MOBIKE Modeling
• Modeled as state machine with 8 states
• 8 messages types
• IP addresses are modeled with agent IDs
• ID payloads are modeled with the corresponding
agent ID
• Nonces are random numbers
• Cookies are random numbers
• AUTH payload is made up of shared secret known
only to the initiator and the responder.
• IKE HDR is modeled as a message id (one field in the
actual IKE HDR).
MOBIKE Modeling cont.
• Message is a union of all 8 IKE messages. Not all
fields will be used in all messages.
• SA’s and TS’s (traffic selector) are not modeled.
• NAT detection is not modeled.
• Invariants
• Check that both the responder and initiator
correctly authenticate with each other and complete
the state machine.
• Message correctness
• Verify the AUTH payload
• Verify the ID is equal to the source.
• Verify the cookie for the return routability test.