Upload
takoda
View
22
Download
0
Embed Size (px)
DESCRIPTION
Security Association Establishment for Handover Protocols. Jari Arkko Ericsson Research NomadicLab. Outline. Scope Problem Solutions. AAA. AP. AP. AP. AP. R. R. R. R. AR. AR. MN. Scope -- Movements. AAA. AP. AP. AP. AP. R. R. R. R. AR. AR. MN. Scope -- Movements. - PowerPoint PPT Presentation
Citation preview
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