Security Association Establishment for Handover Protocols Jari Arkko Ericsson Research NomadicLab

Outline l Scope l Problem l Solutions

Scope -- Movements AR AP AAA MN AR AP RRRR

Scope -- Movements AR AP AAA MN AR AP RRRR As it moves to a new place, the MN needs to talk to (1) Access points

Scope -- Movements AR AP AAA MN AR AP RRRR As it moves to a new place, the MN needs to talk to (1) Access points (2) AAA

Scope -- Movements AR AP AAA MN AR AP RRRR As it moves to a new place, the MN needs to talk to (1) Access points (2) AAA (3) Access routers

Scope -- Movements AR AP AAA MN AR AP RRRR 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 zThe focus of this presentation is the communication with the access router zCurrent general case is that no security is used for this communication, plain forwarding/ND/ICMP is just used zThis does not hold for all protocols -- many mobility protocols need a security association between the MN and the AR yExamples: Context Transfer, Fast Handover, CARD yDifferent types of security associations are needed in different cases

The Problem zCurrent mobility protocols themselves do not provide security association establishment zConfiguration of pair-wise security associations between all MNs and ARs is not practical zReliance 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?) zWhat are the options?

Options for SA establishment 1/2 zIKE? yIssue 1: Shared key provisioning between MN and an arbitrary visited network router yIssue 2: Authorization? zKey derivation as side effect of network access AAA yFor instance, branch off new key hierarchy from EAP reserved keys yCan be defined for network access purposes, needs a new system-level security design draft in EAP WG yIssue 1: may require a new node to be involved in addition to the AAA and AP -- how to send keys to that? yIssue 2: theoretical vs. practical availability of an underlying AAA run -- e.g. likelihood of UAM vs X authentication -- though maybe not an issue if you are doing fast movements (?)

Options for SA establishment 2/2 zKey derivation as side effect of network access AAA cont’d yIssue 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 zSEND-like solution? yOne-sided certificates for routers (SEND RS/RA part) -- used in CARD yIssue: certificate revokation checks? yAddress ownership (IPR may apply) -- used in draft-kempf- mobopts-handover-key-00.txt zA single mechanism vs. allowing multiple?

Framework - Fundamentals zSource of trust -- pairwise config vs. trusted 3rd party (CA or AAA) vs. intrinsic proofs such as address ownership zDeployment -- need per mobile node configuration or not? zAuthorization -- what can you do with the AR?

Framework - Protocol Design Issues zReuse -- independent vs. reuse of security for another purpose zLayering -- interaction with a lower layer vs. independent yUsing a branch of EAP AMSK vs. rerunning EAP zSeparation of SA establishment and use -- but what about authorization? zType of an SA? yLikely “application” specific yBut ability to use MIPv6 BAD would often be useful zEfficiency -- look at the # messages and timing of the whole flow

Tentative Proposal zRely on router certificates whenever possible yExample: CARD, SEND yManufacturing and configuring MNs is easy yWorked well for the web yApplicable when no trust for the MN is needed zUse “application specific” security for MN if really needed yExample: draft-kempf-handover-key-00.txt yMay not need any configuration! zSeparate certs/ownership vs. use of this yBetter separation than assuming a kmgmt protocol that provides a shared secret