Ikev2 extension mobike
This presentation is the property of its rightful owner.
Sponsored Links
1 / 14

IKEv2 extension: MOBIKE PowerPoint PPT Presentation


  • 138 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

IKEv2 extension: MOBIKE

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Ikev2 extension mobike

CS 259

IKEv2 extension: MOBIKE

Faisal Memon

Erik Weathers


Mobike

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

MOBIKE Init and AUTH Exchanges

HDR, KEi, Ni

HDR, KEr, Nr

I

R

HDR, {IDi, AUTH, MOBIKE}KIR

HDR, {IDr, AUTH, MOBIKE}KIR

Typical IKEv2 init exchange, with notify declaring support for MOBIKE.


Mobike address change exchange

MOBIKE Address Change Exchange

HDR, {UpdateSA_Address}KIR

HDR, {ACK}KIR

I2

R

HDR, {Cookie}KIR

HDR, {Cookie}KIR

Initiator IP address changed to I2.

Cookie exchange is for optional return routability verification.


Ikev2 general attacks

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

IKEv2 Exchanges

{HDR, {Payload}KIR-E}KIR-A

I

R

{HDR, {Payload}KIR-E}KIR-A

  • All IKEv2 requests are ACKed.

  • After the IKE_INIT exchange, all messages are encrypted and MACed.


Ikev2 mitm attack

IKEv2 MITM Attack

HDR, KEi, Ni

HDR, KEa, Ni

I

A

R

HDR, KEa, Nr

HDR, KEr, Nr

Typical IKEv2 init exchange, with attacker A attempting MITM attack by substituing his own DH values.


Ikev2 mitm attack prevention

IKEv2 MITM Attack Prevention

HDR, IDA, {AUTH}KAR

HDR, IDI, {AUTH}KIA

I

A

R

HDR, IDR, {AUTH}KAR

  • 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

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 attacks1

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.


Return routability prevents attack

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 doesn’t know session key


Mobike modeling

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 modeling1

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

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.


  • Login