21-07-0xxx-00- 0000 1 IEEE 802.21 MEDIA INDEPENDENT HANDOVER Title: Security Optimization During Handovers Date Submitted: July, 2007 Presented at IEEE 802.21 session #21, San Francisco Authors or Source(s): Yoshihiro Ohba (Toshiba), Subir Das (Telcordia), Marc Meylemans (Intel), Suman Sharma (Intel), Madjid Nakhjiri (Huawei), Qiaobing Xie (Motorola), Junghoon Jee (ETRI), Soohong Daniel Park (Samsung), Robert Hsieh (Deutsche Telekom), Srinivas Sreemanthula (Nokia), Michael Williams (Nokia), Ajay Rajkumar (Alcatel-Lucent) Abstract: 802.21 Security Study Group proposal
27
Embed
21-07-0xxx-00-00001 IEEE 802.21 MEDIA INDEPENDENT HANDOVER Title: Security Optimization During Handovers Date Submitted: July, 2007 Presented at IEEE 802.21.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
21-07-0xxx-00-0000 1
IEEE 802.21 MEDIA INDEPENDENT HANDOVER
Title: Security Optimization During Handovers
Date Submitted: July, 2007
Presented at IEEE 802.21 session #21, San Francisco
Authors or Source(s): Yoshihiro Ohba (Toshiba),
Subir Das (Telcordia), Marc Meylemans (Intel),
Suman Sharma (Intel), Madjid Nakhjiri (Huawei),
Qiaobing Xie (Motorola), Junghoon Jee (ETRI),
Soohong Daniel Park (Samsung), Robert Hsieh (Deutsche Telekom), Srinivas Sreemanthula (Nokia), Michael Williams (Nokia), Ajay Rajkumar (Alcatel-Lucent)
Abstract: 802.21 Security Study Group proposal
21-07-0xxx-00-0000 2
IEEE 802.21 presentation release statementsThis 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>
• PAR says: “The purpose is to improve the user experience of mobile devices by facilitating handover between 802 networks whether or not they are of different media types, including both wired and wireless, where handover is not otherwise defined and to make it possible for mobile devices to perform seamless handover where the network environment supports it. These mechanisms may also be useable for handovers between 802 networks and non 802 networks.”
• IEEE 802.21 WG decided not to address the security aspect of handovers as part of the current project (see 5 Criteria document)
• Due to lack of a well defined problem space for security
21-07-0xxx-00-0000 5
Problem Scope
• Problem 1: Security Signaling Optimization during Handover
• Problem 2: MIH level security mechanism
Related contributions: 21-06-0727-01-0000-Security_StudyGroup_proposal.ppt 21-07-0024-00-0000-Security_Issues_in_Transition.ppt 21-07-0127-00-0000-Hokey_802.21.ppt 21-07-0085-00-0000-mih-security.ppt
21-07-0xxx-00-0000 6
Problem 1: Security Signaling Optimization during
Handovers
21-07-0xxx-00-0000 7
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-administrative domains with single or dual radio scenarios)
21-07-0xxx-00-0000 8
Usage Scenario 1
• Example: A mobile device can make a transition between two different networks within the same administrative domain
• Transition between two different subnets based on the same media, e.g. 802.11
• Transition between two different subnets based on different media, e.g. 802.11 and 802.16
Authenticator1 Authenticator2
WiFi, WiMAX and/or Cellular
AAA/EAP server
MN
WiFi, WiMAX and/or Cellular
Subnet 1 Subnet 2
Single Administrative Domain*
* An administrative domain is a logical network that is administered by a single authority using its own authentication and authorization mechanisms
21-07-0xxx-00-0000 9
Potential Solution Approach
• Key Hierarchy-based Transition• Since in the same administrative domain, no intrinsic reason
to authenticate again on transition• An already established key hierarchy is all that is needed to support
transition• Re-key is still needed between mobile device and the new point of
attachment
– New context (e.g., association parameters between mobile device and the new point of attachment) must be bound to the new key
21-07-0xxx-00-0000 10
Usage Scenario 2
• Example: A mobile device can make a transition between two networks deployed by different administrative domains
• Transition between two administrative domains based on the same media, e.g. 802.11
• Transition between two administrative domains based on different media, e.g. 802.11 and 802.16 Authenticator1 Authenticator2
AAA/EAP server
WiFi, WiMAX and/or Cellular
WiFi, WiMAX and/or Cellular
MN
AAA/EAP server
Domain1 Domain2
Multiple Administrative Domains
21-07-0xxx-00-0000 11
Potential Solution Approach
• Authentication-based Transition• Since different administrative domains, in general
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
• Some administrative domains may have “roaming agreements”
– We can’t always assume appropriate “roaming agreements” that allow key hierarchy based transition across administrative domains
21-07-0xxx-00-0000 12
What’s Available Today?
• In principle, the Key Hierarchy-based transition problem is being addressed by IETF HOKEY WG
• HOKEY is defining a key hierarchy meant to support transitions across subnet boundaries; focus is on transitions within the same administrative domain
• HOKEY will not define any protocol or mechanism, if required, between Point of Attachments and mobile devices to effect this
• No standards group seems chartered to work on the Authentication-based transition problem
• Some variant pre-authentication scheme (e.g., doc 21-06-0727-01) seems like one plausible approach to this problem
21-07-0xxx-00-0000 13
Proposed Direction for Problem 1• Different 802 (e.g. 11r) and 3G (e.g. UMTS AKA) technologies
have addressed (or are addressing) latency caused by L2 security signaling in handovers (fast roaming, pre-auth etc.) but these are focused on intra-technology handover scenarios
• Needs to be looked at from a wider perspective given that • Seamless heterogeneous handovers are becoming a reality
(inter-technology and inter-administrative domains with single/dual radio operation)
• E.g., Wi-Fi - 3G, Wi-Fi – WiMAX • Each access technology has its own way of managing the
security aspect
A media independent approach to reduce the security latency during handovers seems to be more appropriate
21-07-0xxx-00-0000 14
Problem 2: MIH Level Security Mechanism
21-07-0xxx-00-0000 15
What is the Problem?• IEEE 802.21 services affects user mobility
• Service providers need to ensure users receive best user experience and satisfaction
• Mutual confidence in exchange of MIH services is a necessary requirement
• Mobile nodes must be confident when• Receiving reliable information (IS) from trusted network sources• Receiving/sending events/commands only from trusted network nodes
• Network must be confident that • MIH events/commands are in fact originated from the “said” user• MIH info/events/commands are delivered to destination reliably
(without tampering)
• Security becomes an essential ingredient for deployment
21-07-0xxx-00-0000 16
MIH Access Control
• Network operator may apply subscription policies to the user for customization, e.g.
• User can only use certain access technologies => can only query about certain access technologies
• Various roaming plans/info depending on subscription plans• Addressed in 21-07-0035-00-0000-AccessControlIEs.ppt
• MIH access control is not network access control• access level control determines whether and how user can
access the link resources• MIH access control is what the MIH services users can receive
• Related to MIH security since the policy control is based on authentication
21-07-0xxx-00-0000 17
Policy Based MIH Services
MIH IS/ECS
• Policy is about customizing service specific to the user, usually derived from• subscription relation with the user• Network operation policies• Roaming considerations etc
• Policy setup is either online or offline and enforced in MIHF for that user
• For MIH, policy impacts on a user basis• what information is provided• what events and commands can be generated or processed
• Need to verify the authenticity of the MN for policy-based services
MobileNode
Policy functions
21-07-0xxx-00-0000 18
Hijacking/Replay Issues
MIH IS/ECS
• An ongoing session with one MIHF can be hijacked by providing the response or future packets from a different node
• A certain packet for an event or command can be replayed later to the same node
• Not having the means to verify the authenticity of the MIHF service provider or not having replay protection can lead to negative effects
Bad GuyMIHF
MobileNode
21-07-0xxx-00-0000 19
Denial of Service
MIHF
Good GuyMobileNode
• MIH events or commands can be originated by spoofing the MIHF node ID
• A mobile node and a network node MIHF can be spoofed
• Any event or command can be triggered falsely to negatively affect the mobility somehow
• Link-Going-Down, Link-Down and Handover-commit
• Not having the means to verify the authenticity of the MIHF of a MN or service provider can lead to negative effects
Bad GuyMobileNode
MIH source same as otherMobile nodes
MIHF
Good GuyMobileNode
MIH source same as MIHF
Bad GuyMIHF
Yoshihiro Ohba
What does this sentence mean?
21-07-0xxx-00-0000 20
Message Modification by 3rd party
Good GuyMIH IS/ECS
Bad GuyMIHF
MobileNode
Modify the request and/or response
• Some intermediate node is capable of snooping, altering and forwarding the MIHF packets
• IE in Information services could be altered in request or response
• MIH events can be modified e.g. to change threshold values or even event IDs and parameters
• Handover-candidate response or Handover-commit from MN or network could be modified to affect mobility (packets buffered/rerouted)
• Not having the means for data protection (integrity and encryption) from the originating MIHF can lead to negative effects
21-07-0xxx-00-0000 21
Discovery Issues
MIHF
• MIHF discovery may lead to finding MIHF that may not be trustworthy
• L2 broadcast discovery is a good example, any one can respond that they are MIHF capable
• Not having the means to verify the authenticity of the MIHF service provider can lead to negative effects
MobileNode
Bad GuyMIHF
21-07-0xxx-00-0000 22
Requirements
• Need mutual authentication• Network needs to authenticate the user to establish the user privileges to
provide and process any information• Mobile nodes need to authenticate the network to establish the network
node is trustworthy
• Need integrity protection (message authentication)• Network needs to ensure that the user who claims to send the
events/commands is in fact the actual source• Mobile nodes need to ensure that the network node who claims to send the
events/commands is, in fact the actual source• Can also take care of replay attacks (w/ new transaction numbers)
• Need replay protection
21-07-0xxx-00-0000 23
Relation to Transport security
• MIH should be independent of the underlying transport
• Transport has no knowledge of MIH semantics• Transport is opaque to MIH data, has no way to verify the MIH packet data
is authentic
• MIH can utilize one or more links/transports at the same time • E.g. state-1 query in 802.11 and 802.16 while on a serving network
• Identities used at the two layers for secure associations are different
• If an end-to-end MIH communication path is split into a sequence of hop-by-hop MIH transports and lose the info about the origination point
• Transport layer security will accordingly not be present in some cases, or at least not end-to-end
• Initial recommendations for base specification• Least impact to spec, without loss of functionality• utilize existing mechanisms from other SDO (e.g. IETF)
21-07-0xxx-00-0000 25
Study Group Objectives
• Identify use cases and investigate issues concerning the 2 identified security areas
• The SG will work on a PAR defining the scope and requirements to cover the security areas as identified that can lead to a security Task Group under 802.21 WG
Make sure that all work identified is within the scope of 802.21 WG and does not attempt to solve a problem that is being worked in other standards forum
21-07-0xxx-00-0000 26
Q & A?
21-07-0xxx-00-0000 27
802.21 Security SG Motion
• Motion to get 802.21 WG approval to form an 802.21 security Study Group in July 2007 to work on a PAR defining the scope and requirements of the two identified security areas