Presentation on theme: "IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-09-00xx-00-sec Title: Initiate An Exercise for Generating a 21a Document Date Submitted: September 21, 2009."— Presentation transcript:
IEEE MEDIA INDEPENDENT HANDOVER DCN: xx-00-sec Title: Initiate An Exercise for Generating a 21a Document Date Submitted: September 21, 2009 Present at IEEE meeting in September of 2009 Authors: Lily Chen (NIST) Abstract: This document is intent to be a part of harmonization of different proposals for IEEE a to exercise how to use the current existing proposals to generate a 21a document. The purpose of the exercise is to understand in which way, we can accommodate the different proposals and at the same time to see which restrictions we may have in including the proposals as they are today xx-00-sec
2 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 IEEEs name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEEs 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 Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6http://standards.ieee.org/board/pat/faq.pdf
The Basic Outline for 21a Document 21a is an Amendment of IEEE Everything we include must be in the scope of and along the basic logic flow of 21.
Work Item 1 - Background IEEE does not include security mechanisms in handover. Each media has its own secure connection approach. E.g. IEEE – 4-way handshake, assuming that MN and PoA share a common key (through EAP or other protocols/mechanisms, which is out of scope of IEEE ). Authentication protocols, such as, EAP or AAA, are specified in IETF, which are defined on specific layer using network identifiers.
Work Item 1 – Proposals Some proposals suggest that 21a may add security information to information service, such as Where the authenticator is located – Authenticator discovery; What authentication options are – Security IEs. Other proposals recommend that 21a may Define key distribution to make sure that the keys are ready for PoA so that it can make a secure connection quickly. Media independent authenticator to distribute the keys to media specific handover – New network entity. Specify transport for authentication protocol with Existing messages; New messages. Introduce new authentication method (EAP-FRM) A new EAP method xx-00-sec5
MIN Service and Initiation xx-00-sec6 Three services are specified in IEEE Information service; Command service; Event service.
Work Item 1 – Basic Task Key task: update MIH services when consider security signaling in a handover. Key question: What should be added or modified? xx-00-sec7
MIN Function Relationship xx-00-sec8
MIH Communication Interface xx-00-sec9 Notice that Authenticator is not an entity. Therefore interface with authenticator will be a new interface, unless consider that authenticator is co-located with PoA.
Challenges for Work Item 1 Use syntax: If using messages to transport authentication signals, then, we may have to either Include EAP peer or EAP sever function to MIHF; or Add an interface between MIHF function and the EAP peer (or EAP server). Stay in the scope: Can we convert the current study to 21a services without handle EAP messages? Do we have to handle specific authentication methods such as re- authentication, pre-authentication, or specific EAP method? If we do, then we may have a complete but specific solution for handover. However, if any authentication protocol changes or new protocol emerges, then 21a may be obsolete xx-00-sec10
Exercise for Work Item 1 Add modifications to each existing clause. E.g Terminologies (Clause 3); New IEs and services (Clause 6); New primitives (Clause 7); MIH function and new messages (Clause 8); New interface(?) xx-00-sec11
Suggestion to Work Item 1 Proposers For each proposal, it will be a good exercise to identify the changes needed for each clause in IEEE to accommodate the proposed mechanisms. To see which way a given proposal can be included xx-00-sec12
Work Item 2-Background and Proposals IEEE does not include security protections for protocols. IEEE message can be carried (transported) over different protocols, layer 2 or layer 3. 21a may add security protections (encryption and integrity protection). Define MIH specific protection; or Depend on transport layer protections.
Exercise for Work Item 2 Add a new clause Security to cover MIH security. May need to introduce some new terminologies in Clause 3. For protecting MIH (remote) message, multiple options may be included with specific recommendations, depending on the deployment environment. E.g. Define MIH specific protections (with MIH specific authentication); With or without MIH specific authentication or Integrity and/or confidentiality. Peer to peer model or cache/distribute model. Recommend transport layer protection such as TLS xx-00-sec14
Suggestion to Work Item 2 Proposers Generate text for the Security clause; and Identify Terminologies; Data format; Etc. To be added or modified in other clauses xx-00-sec15
Next Step – General suggestions Focus on IEEE a scope; Generate tentative text to see how each proposal fits in xx-00-sec16