1. IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN: sec-mih-security
Title: Media-Independent Handover Security Issues For Discussion
Date Submitted: March 20, 2008
Presented at IEEE session #25 in Orlando
Authors or Source(s):
 Subir Das (Telcordia Technologies), Marc Meylemans (Intel),
Shubhranshu Singh (Samsung)
Abstract: This document provides Media-Independent Handover Protocol security issues for discussion
sec

2. IEEE 802.21 presentation release statements
This document has been prepared to assist the IEEE 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
The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws < and in Understanding Patent Issues During IEEE Standards Development
IEEE presentation release statements
This document has been prepared to assist the IEEE 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
The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual < and in Understanding Patent Issues During IEEE Standards Development
sec

3. What is MIH Protocol?
Collection of all MIHF messages sent between peer MIHF entities
Includes Events, Commands and Information services message exchange
Messages are REQUEST, RESPONSE and INDICATION
Common message payload across different media
802.3, , , and others…
Media specific Transport
Use Management plane when Data plane is not available
E.g., Management Frames in State 1 for
Media Independent Transport
Use IP whenever data plane is available
E.g., In State 3 for
sec

4. Who is doing What?
MIH Protocol (MAC independent messages) defined in
Container for MIH messages for defined in u
Container for MIH messages for defined in g
Transport for MIH Protocol defined in IETF (MIPSHOP)
sec

5. MIH Security
IEEE defines services that peer MIHF entities can use via the MIH protocol
Peer MIHF entity address may be preconfigured or needs to be discovered
Since MIH Services impact the mobility and its performance, it is essential that the message exchanges happen over a secure link
For media specific transport, the security is provided by respective link layers
Exception: management Frames in State 1 for , management frame in pre-attachment for (?)
For IP transport, IETF MIPSHOP WG recommends to use the transport security to protect MIH messages
sec

6. What is the Problem?
The case where media specific transport is not secured
For example, management frames in State 1 for
Nothing much we can do here… w even does not address this..
The case where security is not enabled or supported for IP transport
Security for UDP or TCP is either not available or enabled
Current Specification does not define an explicit indication mechanism to propagate the transport security information at the MIH layer
Neither the MIH user nor MIHF peer entities have any knowledge that messages are transported over a secure channel
Identities used at transport and MIH layers for establishing security associations may be different
Transport can be split hop-by-hop and lose the info about the origination point
sec

7. Discussion Points Recommendations or guidelines for MIH security
Current draft specification is addressing on this issue
Address the issue on how to provide the information about transport security to the MIH layer
Address the issue for unsecured higher layer transports
Is this a valid scenario?
MIPSHOP recommends to use only TCP and UDP
For both cases transport security exists today and is recommended by MIPSHOP (e.g., TLS, DTLS, IPSec)
sec