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 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 IEEEs name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEEs 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 scenario 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 contributions (#390, #403, etc.)

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

xxx Assumptions and Clarifications Assumptions: A full EAP authentication has been conducted with an authentication server. A key hierarchy has been established based on HOKEY key hierarchy. Re-authentication Use established key in the key hierarchy; Shorter message exchanges; Can be conducted either proactively or reactively; Proactively –before a signal loss. Reactively –after a signal loss. With multiple or single candidate authenticators; Can be direct or indirect Can be done over a pre-authentication transport Work to be done in Security SG Provide network information, e.g. location of candidate authenticators Same work is required for pre-authentication. Indication of re-authentication capability support in 21 signaling.

xxx Why take 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 rIK-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.