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

2. IEEE 802.21 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 stated in Section 6 of the IEEE-SA Standards Board bylaws < and in Understanding Patent Issues During IEEE Standards Development
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
sec

3. Outline Problem description Potential approaches
Issues that require further study
sec

4. 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)
sec

5. 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 and 3-way handshake in ) takes on average less than 10ms.
802.11
802.16
MN: Mobile Node
AP: Access Point
BS: Base Station
AAA: AAA server
sec

6. 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
sec

7. 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
sec

8. 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
Does not require modification to existing lower-layer specifications
Provides almost the same performance (one AAA roundtrip) as ERP
sec

9. 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
sec

10. 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
sec

11. 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
sec

12. 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
sec

13. Issues that require further study (Feedback?)
sec

14. Network Discovery
Proactive authentication requires a candidate PoA to be discovered before handover
Issues
How can PoAs in different networks be discovered?
Use 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., IS usage for State 1 STA):
One possible approach: the information can only be used as a hint
sec

15. 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
sec

16. 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
sec