IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN: 21-07-xxxx-00-0000
Title: MIH security issues
Date Submitted: July, 02, 2007
Presented at IEEE 802.21 session #NN in City
Authors or Source(s): Maryna Komarova
Abstract: This document discusses security problems related to the
handover preparation and to the authentication in a new
administrative domain.
21-07-xxxx-00-0000
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
outlined
in in
Section
Section
6 of
6.3the
of
the IEEE-SA
IEEE-SA
Standards
Standards
Board
Board
bylaws
Operations Manual
<http://standards.ieee.org/guides/opman/sect6.html#6.3> and
<http://standards.ieee.org/guides/bylaws/sect6-7.html#6>
and in
in
Understanding Patent Issues During IEEE Standards Development
http://standards.ieee.org/board/pat/guide.html>
http://standards.ieee.org/board/pat/faq.pdf>
21-07-xxxx-00-0000
When authentication is needed
• Handover preparation:
• A MN should be able to obtain IEEE 802.21 information
before being authenticated to the point of attachment.
• Communication with Information Service is not
authenticated and the received information is not reliable.
• Any messages exchanged between two MIHF must be
integrity and reply protected over secure transport. – The
authentication between two MIHF is not discussed.
• Authenication between the target acces network and the MN:
• Mutual authentication is strongly required;
• The confidentiality of communication must be assured: key
material must be created as a result of the authentication;
21-07-xxxx-00-0000
Problems
• For intra-technology handovers IEEE 802.21 believes that the
expected interruption time should not exceed 100 ms for real
time services [document 21-07-0190-00-0000-3GPP-LSResponse];
• Mutual authentication introduces significant delay to the overall
handover latency (more than 100 ms);
• Pre-authentication is a costly process when a transition to many
networks is possible;
• Each administrative domain implements its own authentication
methods;
• Authentication methods and type of credentials either should
be negotiated between the MN and the Authenticator or they
should be unified.
21-07-xxxx-00-0000
Usage scenario:
Handover preparation
• The Information Service belongs to the administrative domain
where the MN is authenticated:
•Key hierarchy approach may be used;
• The Information Service is located in another network:
•Authentication is needed;
Information DB 1
Authentication
Home Core Network
Access Network 1
Key hierarchy
Internet
Information DB 2
Operator 1 Core Network
Access Network 2
Information DB 3
Operator 2 Core Network
Access Network 3
21-07-xxxx-00-0000
MN
Usage scenario:
Authentication in the target domain
• A mobile device can make a transition between two LANs
deployed by different administrative domains;
• There is no trust between the mobile device and the target
network;
• The mobile device trusts some entity that has established trust
relationships with the target network.
21-07-xxxx-00-0000
Presence of trust relationships
Home Core
Network
Trust
Operator 2
Core Network
Home Core
Network
Operator 2
Core Network
t
t
us
Tr
us
Tr
Operator 1
Core Network
us
r
T
Operator 1
Core Network
MN
MN
Security broker
Trust
s
Tru
Home Core
Network
Operator 2
Core Network
t
us
Tr
t
Operator 1
Core Network
MN
21-07-xxxx-00-0000
t
Proposals:
authentication-based transition
• Decompose the authentication into
• Pre-authentication signaling and
• Fast re-authentication in the target network.
• The authentication must be independent of:
• Transport;
• Technology;
• The authentication method used previously;
• Provide key material generation for future key establishment;
• Deploy an extension of EAP:
• EAP is extensible;
• EAP is mode and media independent;
• EAP is used in 802.11, 802.16 and 3GPP standards;
21-07-xxxx-00-0000
Pre-authentication signalling
• Aim: provide a user with credentials (proofs of his identity) and
enable him to verify the identity of the target network;
• Use the fact that the MN was successfully authenticated by an
entity trusted by the target domain;
• Decide what entities are responsible for issuing credentials in
different scenarios of trust/roaming agreements presence;
• Signaling optimization: Combine location update to the home
network/broker with the request for credentials;
• Envisage proactive and reactive modes of signaling
• Proactive mode: after transition to a new network the MN
asks credentials for all access networks reachable from the
current location;
• Reactive mode: the MN asks credentials when it decides to
handover to a new network.
21-07-xxxx-00-0000
Fast Re-Authentication
• Aim: reduce the latency of mobile node’s authentication in a
new administrative domain;
• Use credentials acquired as a result of pre-authentication
signaling;
• Identity management issues:
• Network identity: as the same operator can manage different
access networks (802.11, 802.16), authentication should not
be bound to a particular technology. The MN should be able
to map a seen network name to the network identity;
• User identity: for privacy reasons the identity of a user
should be hidden from a visited network, but there should be
a way to bound the credentials to a particular user.
21-07-xxxx-00-0000
Comments/Q&A
21-07-xxxx-00-0000