Presentation on theme: "21-07-0xxx-00-00001 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0xxx-00-0000 Title: Proposal for adding a key hierarchy based approach in the security."— Presentation transcript:
21-07-0xxx-00-00001 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0xxx-00-0000 Title: Proposal for adding a key hierarchy based approach in the security requirement document Date Submitted: November 4, 2007 Presented at IEEE 802.21 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 21-07-0xxx-00-0000.doc)
21-07-0xxx-00-00002 IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 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 802.21. 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 http://standards.ieee.org/board/pat/guide.html> Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 http://standards.ieee.org/board/pat/guide.html IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 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 802.21 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 http://standards.ieee.org/board/pat/faq.pdf> Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6 http://standards.ieee.org/board/pat/faq.pdf
21-07-0xxx-00-00003 Abstract Applicable scenarios Why take a key hierarchy based approach How to use HOKEY key hierarchy for re-authentication Example message flow
21-07-0xxx-00-00004 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 802.11r 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)
21-07-0xxx-00-00005 Applicable scenarios – Intra-domain and Inter-tech MN SA TA Authentication Server – for the domain EAP
21-07-0xxx-00-00006 Why use a key hierarchy based approach? Using the HOKEY key hierarchy and re-authentication optimize the security signallings of handover (See presentation 21-07-0xxx-00-0000). 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. 802.11 and 802.16. IETF HOKEY group has developed key hierarchy for handover (see http://www.ietf.org/internet-drafts/draft-ietf-hokey-emsk-hierarchy-01.txt) and the status of the key hierarchy is stable. http://www.ietf.org/internet-drafts/draft-ietf-hokey-emsk-hierarchy-01.txt Are there any reasons for excluding such an approach?
21-07-0xxx-00-00008 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).
21-07-0xxx-00-00009 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.
21-07-0xxx-00-000010 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.
21-07-0xxx-00-000011 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.