Security Association Establishment for Handover Protocols

Jari ArkkoEricsson Research NomadicLab

Outline

Scope Problem Solutions

Scope -- Movements

ARAP

AAA

MN

ARAP

AP

AP

R

R

RR

Scope -- Movements

ARAP

AAA

MN

ARAP

AP

AP

R

R

RR

As it moves to a new place, the MN needs to talk to(1) Access points

Scope -- Movements

ARAP

AAA

MN

ARAP

AP

AP

R

R

RR

As it moves to a new place, the MN needs to talk to(1) Access points(2) AAA

Scope -- Movements

ARAP

AAA

MN

ARAP

AP

AP

R

R

RR

As it moves to a new place, the MN needs to talk to(1) Access points(2) AAA(3) Access routers

Scope -- Movements

ARAP

AAA

MN

ARAP

AP

AP

R

R

RR

As it moves to a new place, the MN needs to talk to(1) Access points(2) AAA(3) Access routers(4) Possibly other routers

Scope - The Access Router

The focus of this presentation is the communication with the access router

Current general case is that no security is used for this communication, plain forwarding/ND/ICMP is just used

This does not hold for all protocols -- many mobility protocols need a security association between the MN and the AR Examples: Context Transfer, Fast Handover, CARD Different types of security associations are needed in different

cases

The Problem

Current mobility protocols themselves do not provide security association establishment

Configuration of pair-wise security associations between all MNs and ARs is not practical

Reliance to a trusted 3rd party might not answer to important authorization questions (e.g., can *this* node request *that* stream to be moved with FMIP?)

What are the options?

Options for SA establishment 1/2

IKE? Issue 1: Shared key provisioning between MN and an arbitrary

visited network router Issue 2: Authorization?

Key derivation as side effect of network access AAA For instance, branch off new key hierarchy from EAP reserved

keys Can be defined for network access purposes, needs a new

system-level security design draft in EAP WG Issue 1: may require a new node to be involved in addition to the

AAA and AP -- how to send keys to that? Issue 2: theoretical vs. practical availability of an underlying AAA

run -- e.g. likelihood of UAM vs. 802.1X authentication -- though maybe not an issue if you are doing fast movements (?)

Options for SA establishment 2/2

Key derivation as side effect of network access AAA cont’d Issue 3: inter-admin handovers -- e.g. from my home AR

to the city AR, no roaming may be involved if I just have two credentials

SEND-like solution? One-sided certificates for routers (SEND RS/RA part) --

used in CARD Issue: certificate revokation checks? Address ownership (IPR may apply) -- used in draft-

kempf-mobopts-handover-key-00.txt

A single mechanism vs. allowing multiple?

Framework - Fundamentals

Source of trust -- pairwise config vs. trusted 3rd party (CA or AAA) vs. intrinsic proofs such as address ownership

Deployment -- need per mobile node configuration or not?

Authorization -- what can you do with the AR?

Framework - Protocol Design Issues

Reuse -- independent vs. reuse of security for another purpose

Layering -- interaction with a lower layer vs. independent Using a branch of EAP AMSK vs. rerunning EAP

Separation of SA establishment and use -- but what about authorization?

Type of an SA? Likely “application” specific But ability to use MIPv6 BAD would often be useful

Efficiency -- look at the # messages and timing of the whole flow

Tentative Proposal

Rely on router certificates whenever possible Example: CARD, SEND Manufacturing and configuring MNs is easy Worked well for the web Applicable when no trust for the MN is needed

Use “application specific” security for MN if really needed Example: draft-kempf-handover-key-00.txt May not need any configuration!

Separate certs/ownership vs. use of this Better separation than assuming a kmgmt protocol that

provides a shared secret