IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-08-0135-00-0000 Title: MIH transport in secured network Date Submitted: May, 2008 Present at IEEE 802.21 May 12-15 2008, 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 21-08-0086-00-0000 from David Johnston are discussed. This analysis is in response to comment #2142 in P802.21v9 from Tony Jeffree.

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 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> 

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 802.11 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 802.21 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 802.21 standard will be unusable.

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 802.21 WG to engage in a dialogue with the security task group in 802.21. The fact that this dialogue has not taken place, and yet the project is already at Sponsor ballot, is a major concern.

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 802.16 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

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).

Link layer transport for MIH The link layer security for 802.11 and 802.16 are described in their own standard. For other 802 networks, such as 802.3, 802.5, 802.15, and 802.17, 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

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

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.

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

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.

MIH transport options prior to / during authentication Recommend 802.1 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 802.16e, which allows EAP messages exchanged with backend authentication server)

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 (802.11 and 802.16) only. No MIH exchanges are enabled for wireline network (e.g., 802.3) before authentication: If the user has 802.3 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!

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.

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

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