IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Proposal for IEEE Study Group on Security Signaling Optimization during Handover Date Submitted: November 16, 2006 Presented at IEEE session in Dallas Authors or Source(s): Yoshihiro Ohba (Toshiba), Subir Das (Telcordia), Madjid Nakhjiri (Huawei), Qiaobing Xie (Motorola), Junghoon Jee (ETRI), Soohong Daniel Park (Samsung) Abstract: This document proposes IEEE Study Group on Security Signaling Optimization during Handover

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

Objectives Identify use cases in which security related signaling can add major delay to seamless handover Identify the security related handover issues and scenarios that can be addressed within IEEE Investigate the feasibility of defining security signaling and primitives in a media independent manner and can be executed both pre-handoff and post-handoff stages, e.g., A command to turn media-independent keys from higher-layer mechanism, such as those from IETF, into media-specific keys and distribute the keys from authenticator to AP/BS A command for communication between the mobile node and a target authenticator to carry security signaling messages. Security-related events

Objectives (cont ’ d) Investigate the feasibility of defining new security-related IEs to be used by security signaling Investigate the feasibility of defining a new functional element that involves in security signaling across multiple access technologies

Potential Scope of the Proposed Project The intended study will first identify use cases for proactive and reactive security signaling optimization that can potentially improve the handover performance. The specification will then specify the signaling and primitives in a media independent manner (as much as possible) so that it can be integrated within the base MIH framework. It will apply to scenarios whereby seamless handover is required between two security domains (e.g., AAA domains) and/or with multiple heterogeneous network access technologies Activities required for accomplishing the above work items (see next slide)

Develop a draft PAR if found appropriate by the Study Group Proposed study group will identify the security related issues that are critical for handover optimization Proposed study group will discuss and understand the IETF requirements and can satisfy the requirements MIH needs to work along with IETF to extend the IETF L3+ security procedures to cover L2 security needs. Proposed study group will be interested to hold joint meeting with IEEE r, e, etc. to discuss and define the scope appropriately Proposed Activities

What is available? IEEE r fast roaming with security Optimized security signaling only within ESS No support for inter ESS 802.1X requires to run a new EAP session while changing the point of attachment IEEE MIH protocol does not have support for security Access authentication and key management is carried outside of MIH protocol IETF HOKEY (Handover Keying) WG is working on specific secure handover optimization issues (see next slide) IETF will not define primitives IETF work needs to be extended with L2 mechanisms to provide complete handover security solution

IETF HOKEY WG Handover keying Define EAP key hierarchy used for handover Define AAA or other protocols for reactive or proactive distribution or retrieval of keys by the proper entities Re-authentication EAP authentication exchange that is based on keys derived upon a preceding full authentication exchange Requirements: (a) Low-latency, (b) Independent of EAP method Modification to EAP may be needed Pre-authentication The use of EAP to pre-establish EAP keying material on an authenticator prior to arrival of the peer at the access network managed by that authenticator Originally defined in i Define a general solution that works across ESSes and across different media

Use Case 1: Intra-authenticator handover A single authenticator may be serving multiple networks of the same or different media After initial authentication, no additional EAP run is needed for transitions under the authenticator Authenticator MN AAA domain 1 WiFi, WiMAX or Cellular AAA server Home AAA domain AP/ BS

Use Case 2: Inter-authenticator handover across AAA domains Case 2: Two authenticators belong to different AAA domains The handover can be intra- technology or inter-technology MN may use the same AAA server or different AAA servers for different AAA domains MN needs to go through EAP authentication all the way to its AAA server EAP may performed either proactively or reactively Authenticator1 Authenticator2 AAA server AAA domain 1AAA domain 2 Home AAA domain WiFi, WiMAX and/or Cellular MN AP/ BS

Use Case 3: Inter-authenticator handover in the same AAA domain Case 3: Two authenticators belong to the same AAA domains The handover can be intra- technology or inter-technology MN would need to run EAP all the way to the home AAA server Alternatively visited domain’s AAA server may perform authentication if it has MN’s credentials transferred from the home AAA server EAP may performed either proactively or reactively Authenticator1 Authenticator2 AAA domain 2 WiFi, WiMAX and/or Cellular AAA server Home AAA domain MN WiFi, WiMAX and/or Cellular AAA server AP/ BS

Comments in Sept. Meeting Comment: Technical analysis shows that sudden drop in the transitions between WiFi and cellular is less than 1% Answers Underlying assumption of the analysis is not clear For example, if MN is moving very fast, then sudden drop rate may be more There are other types of transitions to consider as well WiFi to WiFi (inter-ESS), WiFi to WiMAX or WiMAX to WiMAX

Comments in Sept. Meeting (cont’d) Comment: In 3GPP networks, when a terminal is authenticated to different AAA servers, the AAA server will shut down the 1st connection. You will lose the first connection while you are connecting to the 2nd one Answers In such a case, only reactive handover would be possible There are many other cases where proactive handover is feasible Both proactive and reactive security signaling optimization should be considered

References [RFC3748] B. Aboba, et al., “ Extensible Authentication Protocol (EAP) ”, RFC 3748, June [HOKEY-PS] M. Nakhjiri, et al., “ AAA based Keying for Wireless Handovers: Problem Statement ”, Internet-Draft, draft-nakhjiri-aaa-hokey- ps-03, Work in Progress, June [EAPEXT-PS] L. Dondeti and V. Narayanan, “ EAP Extensions Problem Statement ”, draft-dondeti-eapext-ps-00.txt, Work in Progress, June [PREAUTH-PS] Y. Ohba, et al., “ Pre-authentication Problem Statement ”, Internet-Draft, draft-ohba-preauth-ps-00, Work in Progress, October 2006.