1 / 8

Handover Keys Using AAA (draft-vidya-mipshop-handover-keys-aaa-03.txt)

Handover Keys Using AAA (draft-vidya-mipshop-handover-keys-aaa-03.txt). vidyan@qualcomm.com narayanan.venkitaraman@motorola.com gerardo.giaretta@telecomitalia.it hannes.tschofenig@siemens.com julien.bournelle@int-evry.fr. Draft Status. No current open issues

jkessler
Télécharger la présentation

Handover Keys Using AAA (draft-vidya-mipshop-handover-keys-aaa-03.txt)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Handover Keys Using AAA(draft-vidya-mipshop-handover-keys-aaa-03.txt) vidyan@qualcomm.com narayanan.venkitaraman@motorola.com gerardo.giaretta@telecomitalia.it hannes.tschofenig@siemens.com julien.bournelle@int-evry.fr

  2. Draft Status • No current open issues • Reviews received from MOBDIR; a requested SECDIR review received; comments incorporated • Technical work is mostly complete • Transport over AAA needs to be defined • Not a normative reference to the draft • Needed for practical deployments • Hence the need for RADEXT input IETF 67, RADEXT

  3. AP2.1 AP2.2 AP1.1 AP1.2 Example Topology AR2 MN AAAH Server AR1 MN IETF 67, RADEXT

  4. Solution Goals • Facilitate FMIP deployment in systems with a AAA infrastructure • Establish a handover key between MN and AR to secure FMIP signaling • Use of AAA infrastructure to enable this • Simple, single roundtrip protocol IETF 67, RADEXT

  5. Protocol Overview AAA Server MN AR1 AR2 HMK Generated HMK Generated HKReq RADIUS Access Request ([MN ID, Msg ID, Seq #, MN Nonce], MN-AAA MAC) ([HKReq, NAS IP], AR-AAA MAC) Validate MAC Generate HK1 RADIUS Access Accept ([AAA Nonce, Lifetime] AAA-MN MAC, [HK1], ARn-AAA Key) HKResp Decrypt HK1 ([AAA Nonce, Lifetime] AAA-MN MAC) Generate HK1 MN Handoff To AR2 FNA([FBU], HK1) [FBU], HK1 Validate FBU FBAck FBAck IETF 67, RADEXT

  6. Message Exchange MN AR AAA ---- ---- ----- MSGID, PRF, CoA, N1, ID, [T], MN-AAA MAC --> AAA (MSGID, PRF, CoA, N1,ID, [T], MAC) --> <-- AAA (N2, [MN-AAA MAC]) <-- MSGID, PRF, Code, SPI, N2, [MN-AAA MAC], [T], MN-AR MAC IETF 67, RADEXT

  7. Handover Key Hierarchy HMK (Handover Master Key) … HK1 HIK (Handover Integrity Key) HKn HIK = gprf+ (HMK, "Handover Integrity Key") HK = gprf+ (HMK, MN Nonce | AAA Nonce | MN ID | AR ID | "Handover Key") gprf+ (K, S) = T1 | T2 | T3 | T4 ... where: T1 = PRF (K, S | Y) T2 = PRF (K, T1 | S | Y+1) T3 = PRF (K, T2 | S | Y+2) T4 = PRF (K, T3 | S | Y+3) • No relation to EAP key material • HMK may be a PSK • Future specification of HMK as an EAP USRK feasible • Current document assumes that the HMK is a PSK for FMIP authentication • HMK Key hierarchy has no dependency on EAP IETF 67, RADEXT

  8. Next Steps • Feasibility of using RADIUS as the AAA protocol? • If feasible, is RADEXT willing to review and sponsor the draft? IETF 67, RADEXT

More Related