1. 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
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 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
xx-00-sec

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

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

5. 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-sec

6. MIH Service and Initiation
Three services are specified in IEEE
Information service;
Command service;
Event service.
xx-00-sec

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

8. MIN Function Relationship
xx-00-sec

9. MIH Communication Interface
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.
xx-00-sec

10. 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-sec

11. 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-sec

12. 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-sec

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

14. 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-sec

15. 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-sec

16. Next Step – General suggestions
Focus on IEEE a scope;
Generate tentative text to see how each proposal fits in.
xx-00-sec