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

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

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

4. August 2, 2005draft-vidya-mipshop-fast-handover-aaa-00 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

5. August 2, 2005draft-vidya-mipshop-fast-handover-aaa-00 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

6. August 2, 2005draft-vidya-mipshop-fast-handover-aaa-00 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

7. August 2, 2005draft-vidya-mipshop-fast-handover-aaa-00 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

8. August 2, 2005draft-vidya-mipshop-fast-handover-aaa-00 HK Derivation via Network Access (Open Issues/Questions) Involves a 4 th 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?

9. August 2, 2005draft-vidya-mipshop-fast-handover-aaa-00 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

10. August 2, 2005draft-vidya-mipshop-fast-handover-aaa-00 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?