xxx IEEE MEDIA INDEPENDENT HANDOVER DCN: xxx Title: Proposal for adding a key hierarchy based approach in the security requirement document Date Submitted: November 4, 2007 Presented at IEEE session #23 in Atlanta Authors or Source(s): Lily Chen, Katrin Hoeper, Antonio Izquierdo, Nada Golmie Abstract: This presentation is to propose a key hierarchy-based approach for optimizing the security signaling in media independent handovers. Companion text for the SSG requirements document is included in xxx doc)

xxx IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. This is a contribution by the National Institute of Standards and Technology and is not subject to copyright in the US. The contributors do not have the authority to override the NIST policy in favor of the IEEE policy. The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws and in Understanding Patent Issues During IEEE Standards Development Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6

xxx Abstract Applicable scenarios Why take a key hierarchy based approach How to use HOKEY key hierarchy for re-authentication Example message flow

xxx Applicable scenarios Intra-tech Intra-domain* Inter-domain Inter-tech EAP to EAP Inter-tech EAP to non-EAP As defined in the tech specific key hierarchy, like r or 3GPP Hokey key hierarchy based (in this contribution) May need to establish mapping between different key hierarchies (For future study) * It includes inter-domain with agreements The is the scenario discussed in this proposal Pre-authentication as proposed in contribution (# tbd)

xxx Applicable scenarios – Intra-domain and Inter-tech MN SA TA Authentication Server – for the domain EAP

xxx Why use a key hierarchy based approach? Using the HOKEY key hierarchy and re-authentication optimize the security signallings of handover (See presentation xxx ). The advantages include Reduce the authentication latency. Execute as needed with potentially an target authenticator instead of multiple authenticators. Save the computation costs and power consumption. Independent to EAP-method chosen. EAP has been adopted as an access authentication and also key establishment protocol by commonly implemented wireless technologies, e.g and IETF HOKEY group has developed key hierarchy for handover (see and the status of the key hierarchy is stable. Are there any reasons for excluding such an approach?

xxx EAP key derivation EAP Peer Authenticator AS MSK EMSK

xxx Use Hokey key hierarchy for Re-authentication Assume re-authentication root key (rRK) is derived from EMSK*. The integrity key (rIK) is used for integrity protection in re- authentication exchange (and also for implicit authentication). Re-authentication MSK (rMSK) is delivered to target authenticator and used as new MSK upon successful re-authentication rRK-1rRK-2 rMSK-2rMSK-1 EMSK rIK-1rIK-2 *It may be derived from DSRK (domain specific root key).

xxx Re-authentication triggers rMSK delivery Peer Target Authenticator EAP ReAuth Server (ERS) rRK-1 rMSK-1 Re-Authentication (use rRK-1) rMSK-1 Peer - new location rIK-1 For intra-authenticator handover, it will follow the intra-technology scenario.

xxx Example message flow MNTAERS* [EAP Request/Identity] [EAP Initiate/Reauth-start] EAP Initiate/Reauth-start rMSK EAP Finish/Reauth EAP Finish/Reauth *ERS could be a local authentication server, which holds DS-rRK.

xxx Summary Key hierarchy based approach is applicable to inter-technology (EAP -> EAP) and intra-domain handovers. Re-authentication can be conducted with either the EAP server or a local server which has obtained a rRK. Re-authentication optimizes security signaling during handovers. Re-authentication can be conducted with the target authenticator, instead of multiple candidate authenticators, so that it reduces time and power consumption for handover.