Security Association Establishment for Handover Protocols

1
Security Association Establishment for Handover
Protocols

• Jari Arkko
• Ericsson Research NomadicLab

2
Outline

• Scope
• Problem
• Solutions

3
Scope -- Movements
4
Scope -- Movements
As it moves to a new place, the MN needs to talk
to (1) Access points
5
Scope -- Movements
As it moves to a new place, the MN needs to talk
to (1) Access points (2) AAA
6
Scope -- Movements
As it moves to a new place, the MN needs to talk
to (1) Access points (2) AAA (3) Access routers
7
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 contd
• 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