1. IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN:
Title: MIH transport in secured network
Date Submitted: May, 2008
Present at IEEE May , Jacksonville.
Authors or Source(s):
  H Anthony Chan (Huawei Technologies); Yoshihiro Ohba (Toshiba)
Abstract: The problem of MIH transport in secured network is explained and possible approaches including the proposal in DCN from David Johnston are discussed. This analysis is in response to comment #2142 in P802.21v9 from Tony Jeffree.

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 outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual < and in Understanding Patent Issues During IEEE Standards Development

3. From: Comment #2142
In comment #650 on the initial ballot, I made the comment: "The draft pays lip service to security, yet a large part of the discussion within and ongoing as part of P802.1af is concerned with optimizing the number of exchanges involved and rapidly obtaining the necessary information to re-establish prior security associations/and or make use of previously distributed keys. The separation of handoff/handover/roaming/discovery concerns from those of security is unrealistic and calls into question issues that range from the architectural placement of the handoff function to the detailed design of messages and information elements. It is completely unclear how the functions and information provided by this draft would fit within the framework of the established 802.1X standard, the EAPOL protocol and its use of EAP, and the P802.1af amendment. Security of information transfer is required, but a major issue in handover/roaming/discovery in secured networks is determining the policy for making tentative decisions on unsecured information and confirming those decisions later.“The response to this was "The security sub-clause in section 5 has been deleted. All security related issues will be handled by the security Study Group in a future revision of the standard." I consider this response to be totally inadequate; without a clear statement in the standard of how it fits within the 802 architecture and with existing/developing security mechanisms such as 802.1X, 802.1AE, and P802.1af, I believe that the standard will be unusable.

4. From: Comment #2142: Proposed Resolution from Commenter
The standard must address the issue of how it fits within the 802 architecture and with existing/developing security mechanisms such as 802.1X, 802.1AE, and P802.1af. In order to achieve that, it will be necessary for the WG to engage in a dialogue with the security task group in The fact that this dialogue has not taken place, and yet the project is already at Sponsor ballot, is a major concern.

5. DCN 21-08-0086-00-0000 proposed the following headings (among others)
MIHF reference model for IEEE 802 MAC service
The generic MAC service with 802.1X and/or 802.1AE,af
using PKMv2 & negotiated cipher suite
Before and RNG-REQ/RSP After RNG-REQ/RSP but before authentication
After authentication.
802.11
Before “open system” association
Before not “open system” association (I.E. WEP needed)
After not “open system” association (I.E. post WEP)
After association, before 4 way handshake completion
After 4 way handshake completion
Transport

6. Background: L2 or L3 transport of MIH protocol
The logical connection for the transport between peer MIHF is enabled by the abstract MIH_NET_SAP, which uses L2 or L3 transport in the data plane as well as transport via the management plane (not shown).

7. Link layer transport for MIH
The link layer security for and are described in their own standard.
For other 802 networks, such as 802.3, 802.5, , and , use of port access security and MAC security described in IEEE Std 802.1X Rev and 802.1AE are expected. The MACsec layer is on top of media dependent MAC sublayer and below LLC

8. LSAP transport for MIH
When MIH_NET_SAP uses LSAP, MIH messages are encapsulated to LLC with the proper MIH Ethertype

9. LSAP transport for MIHF with P802.1XRev
After authentication, incoming packets through controlled port at LSAP are switched to the proper protocol (MIHF or other MAC clients) according to the EtherType.

10. LSAP over EAPOL
Incoming packets at LSAP are switched to the proper protocol (MIHF or other MAC clients) according to the EtherType.

11. Comparing LSAP and IP
In both cases, transport is only possible after authentication and establishing secure connection association.
Message size limit and filtering are needed with LSAP
IP transport already provides fragmentation.

12. MIH transport options prior to / during authentication
Recommend to revise 802.1X-Rev to carry MIH over EAPOL
MIH transport via management plane: use SAP between MIHF and management plane. Yet management plane in turns needs to employ link layer data plane. The SAP between management plane and MAC is neither MAC_SAP nor LSAP and has therefore bypassed link security. (This SAP was probably originally intended for local traffic not subject to port access control, except for EAP over PKMv2 in e, which allows EAP messages exchanged with backend authentication server)

13. MIH transport via management plane: requirements before authentication
A limited set of MIH message exchanges with IS is needed before authentication and association in wireless networks ( and ) only.
No MIH exchanges are enabled for wireline network (e.g., 802.3) before authentication:
If the user has connection only, it does not hurt to have no network/vendor selection capability before authentication. You get whatever network/vendor according to the network line you plug into!

14. MIH transport via management plane in 802.11/16
Using SAP between MIHF and management plane will bypassed security implemented at LSAP and MAC_SAP. Yet it should be reasonable to allow the essential information needed for network selection etc before authentication.
Need to require filtering the MIH messages to selectively allow only these essential MIH messages prior to authentication.

15. L2 or L3 transport of MIH protocol
802.11
802.16
802.3 and other 802 wireline networks
After authentication
IP with same security as other IP IP
and association
LSAP
New EtherType
Size limit
Is this needed?
over controlled port
During authentication
LSAP over EAPOL
Size limit and filtering
over uncontrolled port
N/A
before authentication
via management plane
bypassing security 
Filter No

16. Verification of Information advertised before/during authentication
The information advertised before/during authentication may need to be verified before completing authentication
Regardless of how MIH is carried before/during authentication, this verification is possible based on EAP Channel Binding feature
EAP Channel Binding is to be a work item in IETF EMU WG