Handover%20Keys%20using%20AAA%20(draft-vidya-mipshop-fast-handover-aaa-01.txt)

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

• Vidya Narayanan
• Narayanan Venkitaraman
• Hannes Tschofenig
• Gerardo Giaretta
• Julien Bournelle

2
Example Topology
AR2
MN
AAAH Server
AR1
MN
Objective is to create a shared key between MN
and AR using AAA
3
Protocol Overview
AAA Server
MN
AR1
AR2
HMK Generated
HMK Generated
HKReq
RADIUS Access Request
(MN ID, Msg ID, Seq , CoA, MN-AAA Auth Option)
Validate MAC Generate HK1
(MN ID, Msg ID, Seq , CoA, MN-AAA MAC, NAS
IP, AR-AAA MAC)
RADIUS Access Accept
(Nonce, Lifetime MN-AAA Auth Option, HK1,
ARn-AAA Key)
HKResp
Decrypt HK1
(Nonce, Lifetime MN-AAA Auth Option)
Generate HK1
MN Handoff To AR2
FNA(FBU, HK1)
FBU, HK1
Validate FBU
FBAck
FBAck
4
Protocol Overview Salient Points

• Handover Master Key (HMK) shared between MN and
  AAAH
• May be derived using EAP AMSK at time of power-up
  or first network access
• HMK derived at the MN and AAA (EAP) Server
• Not transported anywhere else
• May be a pre-shared key between MN and AAAH
• Handover Key (HK) Derivation
• HK HMAC-SHA1(HMK, AR ID MN ID AAA-MN Nonce,
  Handover Key)
• HK derived with each AR
• AR verifies MN CoA and binds it to the HK
• HK may be derived indirectly with another AR
  through current AR
• May be needed to derive a new key with a given AR
  after lifetime expires
• E.g. pre-authentication before handoff
• 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
• The protocol is similar to the MIP-AAA model

5
Additions/Changes since last version

• Moved from UDP-based to Mobility Header type
• HKReq and HKResp are now new MH types
• Allows re-use of many already defined mobility
  options
• Follows the model of FMIP control messages
• Address Validation/Binding
• Added details on CoA validation
• Highlights of the procedure
• AR performs NDP upon receiving HKReq with a
  non-NULL CoA
• Message ID from HKReq added in the NS from AR as
  an option
• MN that sent HKReq MUST NOT respond with NA
• Address validated if no other response is
  received for the NS
• Procedure similar to AR performing PND upon
  receiving HI or FNA
• The AR may use other available means of address
  validation (as it may do so for the HI/FNA
  processing)

6
To-Dos

• Derivation of Handover Master Key using EAP Key
  Hierarchy
• Targeting separate I-D on the topic (use Appendix
  A in draft as basis)
• Need EAP WG to solidify AMSK definition
• RADIUS Attributes Definition
• Targeting separate I-D on the topic (use Appendix
  B in draft as basis)
• Diameter AVPs/Application Definition
• Need to investigate possible re-use of NASREQ
  application
• Targeting separate I-D on the topic (use Appendix
  C in draft as basis)

7
MN-AR Authentication Option(draft-narayanan-mn-ar
-auth-option-00)

• Defines a new Mobility Sub-option for carrying
  MN-AR Authentication Data
• Based on the Authentication Protocol for MIP6
• Protocol Gist
• Authentication Data First (96, HMAC_SHA1(MN-AR
  Shared key, Mobility Data))
• Mobility Data care-of address home address
  MH Data
• Used in draft-vidya-handover-keys-aaa-01 to
  include MN-AR Auth Data in HKReq/HKResp
• Also suitable for carrying MN-AR Auth Data in
  FBU/FBAck in FMIPv6
• Concerns on the dependency on information
  document
• Raised on ML
• Technically, the re-use makes sense
• Integrate into 4068bis?

8

• Accept as WG item?
• QUESTIONS?