Transcript PPT Version

Handover Keys using AAA
(draft-vidya-mipshop-fast-handover-aaa-00.txt)
Vidya Narayanan
Narayanan Venkitaraman
Hannes Tschofenig
Gerardo Giaretta
Julien Bournelle
August 2, 2005
draft-vidya-mipshop-fast-handover-aaa-00
Example Topology
AP2.1
AR2
MN
AP2.2
AAAH
Server
AP1.1
AR1
MN
AP1.2
August 2, 2005
draft-vidya-mipshop-fast-handover-aaa-00
Protocol Overview
MN
AR1
AR2
AAA
Server
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)
RADIUS Access Accept
([Nonce, Lifetime] AAA-MN MAC, [HK1], , ARn-AAA Key)
HKResp
Generate HK1
MN Handoff
To AR2
Decrypt HK1
([Nonce, Lifetime] AAA-MN MAC)
FNA([FBU], HK1)
[FBU], HK1
Validate FBU
FBAck
FBAck
August 2, 2005
draft-vidya-mipshop-fast-handover-aaa-00
Validate MAC
Generate HK1
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
August 2, 2005
draft-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
August 2, 2005
draft-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
August 2, 2005
draft-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
August 2, 2005
draft-vidya-mipshop-fast-handover-aaa-00
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?
August 2, 2005
draft-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
August 2, 2005
draft-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?
August 2, 2005
draft-vidya-mipshop-fast-handover-aaa-00