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