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- 402-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 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 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 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 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 contributions (#390, #403, etc.)
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 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 802.21 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.
21-07-0xxx-00-00007 Why take 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-00009 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-000010 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.
21-07-0xxx-00-000011 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-000012 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.