IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-08-0083-00-0sec-8021-joint-meeting Title: 802.21 approaches to reduce latency in authentication and key establishment signaling for handover Date Submitted: March 18, 2008 Presented at IEEE 802.21 session #25 in Orlando Authors or Source(s):  Yoshihiro Ohba (Toshiba) Abstract: This document describes potential approaches being considered in 802.21 Security Study Group to reduce latency in authentication and key establishment signaling for handover. 21-08-0083-00-0sec

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 stated in Section 6 of the IEEE-SA Standards Board bylaws <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf>  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 <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html>  21-08-0083-00-0sec

Outline Problem description Potential approaches Issues that require further study 21-08-0083-00-0sec

What is the problem? Security-related signaling can add significant delays to seamless handover efforts and in many cases service continuity can not be met, in particular, for real-time applications This becomes even more problematic when handovers occur between heterogeneous networks (e.g. inter-technology, inter-AAA domains scenarios) 21-08-0083-00-0sec

Security Signaling Latency Approximately 90% of the latency originates from the EAP signaling during network access authentication (full authentication) EAP authentication takes on average 100s of ms, while the layer 2 key management (4-way handshake (HS) in 802.11 and 3-way handshake in 802.16) takes on average less than 10ms. 802.11 802.16 MN: Mobile Node AP: Access Point BS: Base Station AAA: AAA server 21-08-0083-00-0sec

Potential Approach for Intra-AAA-domain Handover – Key Hierarchy-based Transition (1/3) Establish a key hierarchy through full authentication upon entry into the AAA domain The key hierarchy may span multiple link-layer technologies Network access authentication is based on exchanging proof of possession of the root key between MN and the root key holder through the PoA Root Key Session Key for PoA_1 Session Key for PoA_2 … Session Key for PoA_N 21-08-0083-00-0sec

Re-authentication Server Potential Approach for Intra-AAA-domain Handover – Key Hierarchy-based Transition (2/3) ERP (EAP Extensions for EAP Re-authentication Protocol) is defined in IETF for Key Hierarchy-based Transition The server for ERP can be in a visited domain ERP requires one AAA message roundtrip AAA domain X Re-authentication Server (AAA server/proxy) ERP signaling 21-08-0083-00-0sec

Potential Approach for Intra-domain Handover – Key Hierarchy-based Transition (2/3) [cont’d] ERP requires modification to existing lower layer such as IEEE 802.1X to support: Peer-initiated EAP messaging with advertisement of HOKEY domain Re-authentication DoS attack mitigation schemes such as: A mechanism to keep any authorization state (established by an initial EAP run) when ERP bootstrapping fails Support for two concurrent link-layer SAs between a pair of peer and authenticator, one for initial EAP and another for bootstrapping ERP An alternative re-authentication mechanism to ERP has been proposed, i.e., EAP-KDE (Key Distribution Exchange) Works as standalone authenticator mode http://www.ietf.org/internet-drafts/draft-ohba-eap-kde-01.txt Does not require modification to existing lower-layer specifications Provides almost the same performance (one AAA roundtrip) as ERP 21-08-0083-00-0sec

Comparison of Re-authentication Schemes EMSK DSRK rRK rMSK rIK ERP Peer) Authenticator ER Server [EAP Initiate /Re-Auth Start or EAP-Request/Identity] EAP Initiate /Re-Auth AAA{EAP Initiate /Re-Auth} EAP Initiate /Finish AAA{EAP Initiate /Finish, rMSK) EAP-KDE Peer Standalone Authenticator KDE Server EMSK EAP-Request/KDE{KDE0} EAP-Response/KDE{KDE1} AAA{KDE2} Kps EAP-Request/KDE{KDE4} AAA{KDE3} EAP-Response/KDE{} IK Kpt (carried in KDE3) EAP-Success 21-08-0083-00-0sec

Re-authentication Server Proactive re-authentication Potential Approach for Intra-AAA-domain Handover – Key Hierarchy-based Transition (3/3) In this approach, ERP is proactively performed (proactive re-authentication) No AAA roundtrip after switching to the target PoA AAA domain X Re-authentication Server (AAA server/proxy) Proactive re-authentication Secure Association 21-08-0083-00-0sec

Potential Approach for Inter-AAA-Domain Handover – Authentication-based Transition Since networks are in different AAA domains, in general full authentication can not be avoided There is no reason for the new domain to “trust” keys from the old domain, and no reason for mobile device to “trust” the new domain with keys it used with its old domain Roaming agreements (SLAs) may exist between the two networks, but home operator might still require the user to authenticate with the home network (AAA) because of security or policy reasons A pre-authentication solution is needed that works across multiple AAA domains EAP server EAP (RFC 3748) signaling AAA domain X AAA domain Y Secure Association 21-08-0083-00-0sec

Proposed Direction Proactive authentication is the promising approach to reduce authentication and key establishment signaling latency Needed for secure service continuity across different link-layer technologies, AAA domains Use existing media-specific Secure Association mechanisms Proactive authentication can be based on proactive re-authentication, and pre-authentication Proactive authentication requires an EAP transport The solution that works independent of link-layer technologies Our main scope is IEEE 802 technologies, but solution could be applied to handovers to other technologies 21-08-0083-00-0sec

Issues that require further study (Feedback?) 21-08-0083-00-0sec

Network Discovery Proactive authentication requires a candidate PoA to be discovered before handover Issues How can PoAs in different networks be discovered? Use 802.21 Information Service (IS) How PoA discovery can be secured? The information exchanged over the MIH protocol can be protected by MIH transport protocol security. If MIH transport protocol security is unavailable, (e.g., 802.21 IS usage for 802.11 State 1 STA): One possible approach: the information can only be used as a hint 21-08-0083-00-0sec

Context Binding “Proactive authentication requires an EAP transport . The solution that works independent of link-layer technologies” Implications Proactive authentication will create a session key cache on the target PoA prior to handover The identifiers of MN and PoA that are used for media-independent proactive authentication may be different from those used for media-specific secure association Issue: The session key needs to be bound to the identifiers of MN and PoA that will be used for media-specific secure association  Context Binding issue 21-08-0083-00-0sec

Distributed Authenticator and Key Distribution If the MIH protocol is the transport of proactive authentication, PoS (Point of Service) and Authenticator are co-located in the same node (PoS/Authenticator) On the other hand, PoS/Authenticator and PoA may be separate entities for some link-layers with “distributed authenticator” architecture Is there a need for a new key distribution protocol? Proactive authentication over MIH protocol PoS/Authenticator Key Distribution PoA MN Secure Association Protocol 21-08-0083-00-0sec