Handover Keys using AAA (draft-vidya-mipshop-fast-handover-aaa-00.txt)

1. Handover Keys using AAA(draft-vidya-mipshop-fast-handover-aaa-00.txt) Vidya Narayanan Narayanan Venkitaraman Hannes Tschofenig Gerardo Giaretta Julien Bournelle draft-vidya-mipshop-fast-handover-aaa-00

2. AP2.1 AP2.2 AP1.1 AP1.2 Example Topology AR2 MN AAAH Server AR1 MN draft-vidya-mipshop-fast-handover-aaa-00

3. Protocol Overview AAA Server MN AR1 AR2 HMK Generated HMK Generated HKReq RADIUS Access Request ([MN ID, Msg ID, Seq #], MN-AAA MAC) ([[MN ID, Msg ID, Seq #], MN-AAA MAC, NAS IP], AR-AAA MAC) Validate MAC Generate HK1 RADIUS Access Accept ([Nonce, Lifetime] AAA-MN MAC, [HK1], , ARn-AAA Key) HKResp Decrypt HK1 ([Nonce, Lifetime] AAA-MN MAC) Generate HK1 MN Handoff To AR2 FNA([FBU], HK1) [FBU], HK1 Validate FBU FBAck FBAck draft-vidya-mipshop-fast-handover-aaa-00

4. Protocol Overview – Salient Points • Handover Master Key (HMK) Derivation • Done using EAP AMSK at time of power-up or first network access • As defined in the EAP Key Management Framework • HMK derived at the MN and AAA (EAP) Server • Not transported anywhere else • Handover Key (HK) Derivation • HK = HMAC-SHA1(HMK, AR ID | MN ID | AAA-MN Nonce, “Handover Key”) • HK derived with each AR • HK may be derived with target ARs through current AR (i.e., pre-authentication before handoff) • When AR list is available through proxy router advertisements or L2 • Useful when MN changes subnets rather quickly • Lifetime value provided by AAA server; enforced by AR and MN • MN verifies HK with AR after handoff if pre-authentication was used • Used to bind HK to CoA of MN and to verify key is valid at AR • Need not be a “MUST” if an SPI can be used in the FBU draft-vidya-mipshop-fast-handover-aaa-00

5. Protocol Pros and Cons • Pros: • Lightweight and simple single roundtrip protocol • Clients already doing EAP/AAA need no other pre-configured keys • HMK derived using EAP key hierarchy; HKs from HMK • AR receives key from AAA server directly (3-party model preserved) • No messages introduced during critical handoff path • No dependency on L2 protocol for handoffs • MN can handoff to networks not doing EAP as well (limited use case?) • Cons: • New protocol required on MN • Can’t avoid having functionality either as extension of an existing protocol or a new one draft-vidya-mipshop-fast-handover-aaa-00

6. Mailing List Discussions • Approach in draft Vs. tying HK derivation to network access EAP • Integrating HMK derivation into the protocol • Need for allowing pre-shared HMK? • Issue when EAP server is not co-located with AAA server • EAP server will derive AMSK (HMK) – must be sent to the AAA server • Alternately, EAP server may implement the handover key protocol • Minor issues; HMK derivation can be made part of the protocol • Clarification on retransmissions and lifetimes • Text will be clarified in the next revision • Separate key for MAC (avoid using HMK for MAC) • Will be revised to allow this in the next revision • Other minor editorial comments • Will be fixed in the next revision draft-vidya-mipshop-fast-handover-aaa-00

7. HK Derivation via Network Access • Derive HK as EAP AMSK upon handoff • Transport HK from EAP NAS to AR • Option 1: Send HK to AR immediately • Option 2: AR can request HK when needed (upon receiving FBU) • Pros • Closely tied to network access EAP/AAA • No new protocol required on the MN • Clients already doing EAP/AAA need no other pre-configured keys draft-vidya-mipshop-fast-handover-aaa-00

8. HK Derivation via Network Access(Open Issues/Questions) • Involves a 4th entity (NAS) in the protocol • NAS-AR protocol required to transfer HK • Extensions to RADIUS/Diameter/PANA/SNMP? • Does not fit into the AAA protocol model • Use of SNMP similar to PAA-EP communication in PANA • PANA-based approach only works when PANA is used • Option 1 – sending HK from NAS to AR immediately • Puts HK derivation in critical handoff path • Must not require steps during handoff (increases delay) • Option 2 – AR requests HK when needed from NAS • AR needs to know which NAS to request HK from • May need to find a way to explicitly send this info from MN to AR • NAS must cache HK until request is received for the key • Key caching already an issue in 802.11 and 802.16 devices even just at L2 • NAS does not know the lifetime of the key – how long should it cache the key? • NAS and AR don’t share an SA – how does NAS handle rogue requests for the key? draft-vidya-mipshop-fast-handover-aaa-00

9. HK Derivation via Network Access(Open Issues/Questions - Continued) • Every L2 NAS MUST support this protocol (802.1x, 802.16, PANA, etc.) • MN cannot handoff to legacy L2 NAS-es that don’t support this protocol • Issues when MN is using GPRS • Need different approach if L2 is using 802.11r or 802.11s or even 802.16 • With 802.11r, a full EAP method exchange is not done unless handing off across R0 key holders • 802.11s uses EAP slightly differently while hopping through multiple nodes to get to infrastructure • 802.16 considering creating a “Decision Point” (DP) between BS and AAA server (similar to R0 key holder in 802.11r) for faster handoffs • Need to see what security ADs feel about using EAP-AMSKs for sessions • Needs further analysis to resolve issues • Presently, seems to increase protocol complexity draft-vidya-mipshop-fast-handover-aaa-00

10. Other Points • An alternative to SEND-based approach • Useful when MN already shares SA with AAA server and AAA-based infrastructure is already being used • Can be used for security MN-AR communication in other protocols as well – CxTP, CARD, IPv4 fast handoffs, etc. QUESTIONS? draft-vidya-mipshop-fast-handover-aaa-00