IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN: 21-09-0186-00-0sec
Title: Security TG Revised Timeline
Date Submitted: November 19, 2009
Presented at IEEE 802.21 session #35 in Atlanta
Authors or Source(s):
Yoshihiro Ohba (Toshiba)
Abstract: This document describes revised TG timeline
21-09-0186-00-0sec 1

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 stated in Section 6 of the IEEE-SA Standards
Board bylaws < http://standards.ieee.org/guides/bylaws/sect6-7.html#6 > and in Understanding
Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf
>
21-09-0186-00-0sec 2

•
Scope of proposals
• Work Item #1: Mechanisms to reduce the latency during authentication and key establishment for handovers between heterogeneous access networks that support IEEE 802.21
• Work Item #2: Mechanisms to provide data integrity, replay protection, confidentiality and data origin authentication to IEEE 802.21 MIH protocol exchanges and enable authorization for MIH services
•
Proposals must be submitted to 802.21 Document Repository
( https://mentor.ieee.org/802.21/documents )
•
• Group: Security
Document Title: TGa_Proposal_ Firstname _ Lastname (e.g.,TGa_Proposal_Yoshihiro_Ohba)
•
Submission Deadline: March 1 st (Mon), 2010 , end of day AOE (Anywhere On Earth)
•
Only revised proposals are allowed
• Revised Proposal: An updated proposal that captures any comments/feedbacks received during its earlier presentation or earlier TGa discussions
•
Use http://mentor.ieee.org/802.21/dcn/09/21-09-0179-01-0sec-tentative-ieee-802-21a-documentstructure.doc as the guideline on document structure
•
After the submission deadline, no new revision of proposal is allowed
•
For questions, please contact to Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>, Chair of 802.21a
Task Group
21-09-0186-00-0sec 3

Call for Proposal (March 2009)
Proposal Presentation I (May 2009)
Proposals must be submitted 1-week prior to meeting
Harmonization
Proposal Presentation II (July 2009)
Proposals with detailed text must be submitted 1-week prior to meeting
Harmonization
Discussion
(November 2009
& January 2010)
Harmonization
Proposal Presentation III (September 2009)
Proposals with detailed text must be submitted 1-week prior to meeting
Harmonization
Presentation & Down-Selection
(March 2010)
Proposals with Draft Text must be submitted 2-week prior to meeting
Down-Selection succeeds
Draft Standard
Text is contributed to
802.21a draft standard
21-09-0186-00-0sec
Done
Done
Done
Down-Selection fails
Regrouping
4

1.
Authors provide Draft Text for review two weeks prior to presentation
2.
Written questions for clarifications to be submitted to the Task
Group one week in advance
 Answers to these questions submitted within 3 days thereafter
3.
A technical motion to approve Draft Text provided by the proposal and make it part of the IEEE 802.21a draft specification is brought forward to the TG at presentation time
4.
A proposal containing multiple components can lead to multiple motions
5.
Authors must indicate at presentation time how many motions they intend to bring forward to the TG
6.
All motions are carried out at the end of all presentations
7.
Time allocated for presentations and motions is advertised in the opening meeting
8.
A technical motion at Down-Selection requires 75% to pass
9.
One member can vote on multiple motions
21-09-0186-00-0sec 5

10. In case no motion passes by 75%, the proposal receiving the most number of votes is selected for another round of confirmation vote by the TG
• More than one proposal can be selected at this stage in case the most popular proposal does not cover all work items specified in the CFP
• Proposals are selected in decreasing order of popularity (# votes) received
• If this confirmation vote fails, Proposal(s) are broken up into several technical items and TG votes on each technical item
11. In case multiple proposals are approved by more than 75% they are integrated into the Draft Text
• Proposers work with the Editing Committee which consists of the Editor and the TG Chair in order to combine proposals
• Conflict and overlaps are brought back to the TG to vote on
• Failed proposals are eliminated from further consideration
12. In case no proposal is approved at the end of Down-Selection, the
TG may need to regroup. The options include (1) refining the requirements document, (2) refining the evaluation and downselection criteria, (3) reissuing a new call for proposals
21-09-0186-00-0sec 6

TG vote on all proposals available
*There could be several proposals under consideration in order to cover different work items
**Overlap is identified by Editing Committee, TG participants, and/or proposers; contention in resolving overlap is brought to TG for vote.
Any proposal gets 75% Approval ?
Yes
Authors work w/ Editing
Committee to integrate text into draft specifications
No
Proposal(s)* getting highest votes are subject to TG confirmation vote
No
Any contentious overlap**?
Yes
75% Approval?
Yes
Inclusion in draft specifications
Options are provided for each overlap area; TG votes on options available for overlap
No
Proposal(s) are broken up into several technical items;
TG votes on each technical item
Yes
Technical item gets
75% Approval?
No
Yes Option gets
75% Approval?
No
21-09-0186-00-0sec
Elimination from further consideration
7

1. Proposals are categorized into the two groups
Presentation Group 1: Work Item #1
Presentation Group 2: Work Item #2
Presentation Group 3: Work Items #1 and #2 combined
2. Presentation order is random within each Presentation
Group as determined by the TG Chair
3. Time allocated to each presentation is evenly distributed among all presentations in the same Presentation Group
21-09-0186-00-0sec 8

21-09-0186-00-0sec
9

• The purpose of Proposal Guidelines is to help submitters to make a good proposal so that it can convince the group to adopt it.
• The Proposal Guidelines shall not limit creative ideas and proposals.
• A proposal will not be disqualified for not following the
Proposal Guidelines.
• On the other hand, a proposal is unlikely to be adopted if it cannot be evaluated or cannot fit in 802.21.
21-09-0186-00-0sec 10

• Each presentation is expected to contain a Proposal Characterization
List to help characterizing the proposal
•
Please refer to security TR document (21-08-0172-02-0sec) to create a Proposal Characterization List
2
2
2
1
2
2
2
1
1
Work
Item #
1
1
1
1
An Example Proposal Characterization List
Supported Functionality Reference to
TR section(s)
Note
Proactive Re-Authentication
EAP Pre-authentication
Key Hierarchy and Derivation 1
Higher-Layer Transport for MN-CA, MN-SA and SA-
CA signaling
Link-Layer Transport for MN-SA signaling
Authenticator Discovery Mechanism
Context Binding Mechanism
Access Authentication
MIH-Specific Authentication
Key Hierarchy and Derivation 2
MIH-Specific Protection
Protection by MIH Transport Protocol
Visited Domain Access
2.3.3
2.3.2
2.3.3.1
2.3.2.3
2.3.2.3
2.3.2.3, 2.3.3.4
2.3.2.3, 2.3.3.4
3.6.1
3.6.2
3
3.6.1.1, 3.6.2.1
3.6.1.2, 3.6.2.2
3.6.3.1
Visited MIH services have the same security policies
21-09-0186-00-0sec 11

• Each proposal is expected to make a clear reference to 802.21 with regard to
•
802.21 entities: If a new 802.21 entity is introduced for proposed security solutions, then address the relation, location, and interface with other 802.21 entities.
•
Reference points: if new reference point(s) are introduced, then define and identify the reference point(s) w.r.t the
MIHF communication model specified in the 802.21 spec.
•
Data fields: if for protected messages, new data fields are introduced, then specify them in 802.21 data format.
21-09-0186-00-0sec 12

• If a proposal relies on assumptions which are not described in the 802.21 standard, then explicitly state them to avoid any confusion and long debate, for example,
• if a proposal relies on transport protocols to apply security protection for MIH information, then include the transport protocols and security protections assumed for the protocols;
• if AAA server is employed, then state it;
•
If a cryptographic key is used, then state how the key is established, etc
21-09-0186-00-0sec 13

• Provide clear rationale and discussions about the proposed content to help the evaluation and acceptance. This may include but not limited to:
•
Security objectives;
•
Attacks to protect against;
•
Security performance tradeoffs;
•
Comparisons with other solutions, if any;
•
Current standards (re-use);
•
Etc.
21-09-0186-00-0sec 14