IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN: 21-08-0054-00-0sec-mih-level-security-considerations
Title: MIH-level Security Considerations
Date Submitted: February 10, 2008
Presented at IEEE 802.21 session #25 in Orlando
Authors or Source(s):
Yoshihiro Ohba (Toshiba)
Abstract: This document describes security goals, use cases and
considerations on MIH-level security.
21-08-0054-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
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-08-0054-00-0sec
Purpose
• Identify security goals for each service and use case
• Determine the level of requirement for each goal
• Levels of requirement
•
•
•
M (Mandatory requirement)
O (Optional requirement)
- (Not required)
21-08-0054-00-0sec
Security Goals
• Data origin authentication
• Mutual authentication
• Unilateral authentication
• Message authentication
• Replay protection
• Confidentiality
21-08-0054-00-0sec
Use Cases
• Pre-attachment use case
• MIH entity communicates with another MIH entity before
network access authentication
• Used for MIHF Discovery and Information Service
• Post-attachment use case
• MIH entity communicates with another MIH entity after
network access authentication
• Used for all services and service management
21-08-0054-00-0sec
Goals and Requirements
(Pre-attachment Use Case)
Security Goals
Requirement
(M/O/-)
Mutual authentication
Data origin
authentication Unilateral authentication
Message authentication
Replay protection
Confidentiality
21-08-0054-00-0sec
Note
Goals and Requirements
(Post-attachment Use Case)
Security Goals
Requirement
(M/O/-)
Mutual authentication
Data origin
authentication Unilateral authentication
Message authentication
Replay protection
Confidentiality
21-08-0054-00-0sec
Note
Considerations on Pre-attachment Use Case (1/2)
• Pre-attachment use case is vulnerable to man-in-the-middle (MiTM) attack
• Scenario: An attacker AP-X resides between MN and AP-Y and bridges
MIH discovery and MIH messages back and forth
(1) MN discovers AP-X
MN
(2) MN establishes an SA with IS server of operator Y, and perform
IS query over the SA. The IS server responds to the MN with
operator-id “Y” and other information associated with operator Y.
AP-X (lying)
Operator X’s
network
AP-Y (legitimate)
IS server
Operator Y’s
network
(3) MN performs network access authentication with AP-X. If both operators X and Y have a roaming
relationship with MN’s home operator, MN will be authorized for access to operator X’s network
even if it thinks that it is attaching to operator Y’s network. One day, the user of the MN will receive a
bill from the home operator about the use of operator X, which may be more expensive than expected.
21-08-0054-00-0sec
Considerations on Pre-attachment Use Case (2/2)
• The MiTM attack is possible even with (mutual or unilateral)
data origin authentication at MIH-level
• To detect the MiTM attack, Channel Binding [RFC3748] needs
to be provided for MIHF ID of PoS during network access
authentication in step (3)
• However, Channel Binding is optional in all known link-layer
technologies that use EAP, and no standard Channel Binding
solution exists
• On the other hand, only limited types and amount of
information will be provided to unauthenticated MN for
security and resource reasons
• Question: Does the benefit of securing pre-attachment use case
pay to its deployment cost?
21-08-0054-00-0sec