Security Association Establishment for Handover Protocols

1. Security Association Establishment for Handover Protocols Jari Arkko Ericsson Research NomadicLab

2. Outline • Scope • Problem • Solutions

3. AAA AP AP AP AP R R R R AR AR MN Scope -- Movements

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

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

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

7. AAA AP AP AP AP R R R R AR AR MN Scope -- Movements 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

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

9. 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?

10. 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 (?)

11. 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?

12. 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?

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

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