21-08-0054-01-0sec

IEEE 802.21 MEDIA INDEPENDENT HANDOVER

DCN: 21-08-0054-01-0sec-mih-level-security-considerations

Title: MIH-level Security Considerations

Date Submitted: March 14, 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-01-0sec

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> 

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 stated in Section 6 of the IEEE-SA Standards Board bylaws <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf> 

21-08-0054-01-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)

• Using the same requirement notation as 802.21 PICS proforma• M mandatory• O optional• O.<n> optional, but support of at least one of the group of

options labeled by the same numeral <n> is required• pred: conditional symbol, including predicate identification

• MIH1 (ES), MIH2 (CS), MIH3 (IS)

21-08-0054-01-0sec

Security Goals

• Data origin authentication• Mutual authentication• Unilateral authentication

• Message authentication

• Replay protection

• Confidentiality

21-08-0054-01-0sec

Use Cases

• Post-attachment use case• MIH entity communicates with another MIH entity after

network access authentication• Used for all services and service management

• Pre-attachment use case• MIH entity communicates with another MIH entity before

network access authentication• Used for MIHF Discovery and Information Service

• Suggestions on Section 3 of TR• Merge Use Cases 1 to 4 into a single use case “Post-

Attachment Use Case”• Rename “Use Case 5” to “Pre-Attachment Use Case”

21-08-0054-01-0sec

Goals and Requirements(Post-attachment Use Case)

Security Goals Requirement Note

Data origin authentication

Mutual authentication M

Unilateral authentication O Should it be MIH3:O?

Message authentication M

Replay protection M

Confidentiality O

The requirements are taken from Section 10.4 of draft-ietf-mipshop-mis-ps-05.txt(Note: the requirements will be removed from the draft and hence need to be owned by the SSG TR)

21-08-0067-01-0000-security-section.doc has a proposal for the base specification to add text related to post-attachment use case:

• Use MIHF identifier for peer authentication to establish a security association for MIH transport protocol and rely on MIH transport protocol security

If the proposal is accepted, what issues remain unsolved?

21-08-0054-01-0sec

Goals and Requirements (Pre-attachment Use Case)

Security Goals Requirement Note

Data origin authentication

Mutual authentication TBD

Unilateral authentication TBD

Message authentication TBD

Replay protection TBD

Confidentiality TBD

• 21-08-0067-01-0000-security-section.doc has a proposal for the base specification to add text about pre-attachment use case:• It is up to the policy decision entity to prepare for handover based on

the information obtained with the use of unsecured MIH protocol• At a later stage, after attaching to the target point of attachment, verify

the same information obtained with the use of secured MIH protocol

• Is this remedy reasonably sufficient to address pre-attachment security issue or do we need additional work to protect MIH messaging during pre-attachment phase?

21-08-0054-01-0sec

Consideration on MIHF discovery

• MIHF discovery is performed outside the MIH protocol except when combined with MIH capability discovery

• Suggestion:• Make it clear in the TR that security of MIHF discovery

performed outside the MIH protocol is outside the scope of MIH protocol security

21-08-0054-01-0sec

Consideration on end-to-end communication

• Does end-to-end communication model need to be supported?

• End-to-end communication: Two MIH entities and A and B communicate with each other via another MIH entity C, with knowing the identity of the peer MIH entity each other

• If YES, then:

• MIH protocol will need to be modified to support the end-to-end communication model

• If NO, then:

• We don’t need to include end-to-end communication support in the TR

A C B

E2E communication

21-08-0054-01-0sec

Question?

• If 21-08-0067-00-0000-security-section.doc is accepted to fix MIH protocol security issue, is the following work item in our security PAR needed?

• “Define mechanisms that provide data integrity, replay protection, confidentiality and data origin authentication to MIH (Media-Independent Handover) protocol exchanges and enable authorization for the MIH services based on a security association that is bound to authenticated peer MIH entities.”

21-08-0054-01-0sec

Back Up

21-08-0054-01-0sec

More 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

AP-Y (legitimate)AP-X (lying) IS serverMN

Operator X’snetwork

Operator Y’snetwork

(1) MN discovers AP-X (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.

(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-01-0sec

More 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

• Does the benefit of securing pre-attachment use case pay to its deployment cost?