IKEv2 extension: MOBIKE

1
IKEv2 extension MOBIKE
CS 259

• Faisal Memon
• Erik Weathers

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

3
MOBIKE Init and AUTH Exchanges

• HDR, KEi, Ni

HDR, KEr, Nr
I
R
HDR, IDi, AUTH, MOBIKEKIR
HDR, IDr, AUTH, MOBIKEKIR
Typical IKEv2 init exchange, with notify
declaring support for MOBIKE.
4
MOBIKE Address Change Exchange

• HDR, UpdateSA_AddressKIR

HDR, ACKKIR
I2
R
HDR, CookieKIR
HDR, CookieKIR
Initiator IP address changed to I2. Cookie
exchange is for optional return routability
verification.
5
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.

6
IKEv2 Exchanges

HDR, PayloadKIR-EKIR-A
I
R
HDR, PayloadKIR-EKIR-A

• All IKEv2 requests are ACKed.
• After the IKE_INIT exchange, all messages are
  encrypted and MACed.

7
IKEv2 MITM Attack

• HDR, KEi, Ni

HDR, KEa, Ni
I
R
A
HDR, KEa, Nr
HDR, KEr, Nr
Typical IKEv2 init exchange, with attacker A
attempting MITM attack by substituing his own DH
values.
8
IKEv2 MITM Attack Prevention

• HDR, IDI, AUTHKIA

HDR, IDA, AUTHKAR
I
R
A
HDR, IDR, AUTHKAR

• Typical IKEv2 AUTH exchange, thwarting As 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)

9
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 isnt ACKed, the
  client will resend it.

10
MOBIKE Possible Attacks

• When NATs are not allowed (e.g. site-to-site
  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.

11
Return Routability Prevents Attack
I1
R
NAT
UPDATE_SA_ADDRESS
UPDATE_SA_ADDRESS
UPDATE_SA_ADDRESS
NAT
I2
A
ACK
ACK
ACK
COOKIE2
COOKIE2
Attacker cannot send COOKIE2 reply since he
doesnt know session key
12
MOBIKE Modeling

• Modeled in Murf
• 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.

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

14
MOBIKE Modeling cont.

• Message is a union of all 8 IKE messages. Not
  all fields will be used in all messages.
• SAs and TSs (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.