IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN: 21-10-0067-02-0sec
Title: Security TG Revised Timeline
Date Submitted: March 18, 2010
Presented at IEEE 802.21 session #37 in Orlando
Authors or Source(s):
Yoshihiro Ohba (Toshiba)
Abstract: This document describes revised TG timeline. This is an
update of the previous timeline described in 21-09-0186-00-0sec.
21-10-0067-02-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-10-0067-02-0sec
2
802.21a Call For Revised Proposals
•
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: June 28th (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-10-0067-02-0sec
3
Timeline
Call for Proposal (March 2009)
Proposal Presentation I (May 2009)
Proposals must be submitted 1-week prior to meeting
Done
Harmonization
Proposal Presentation II (July 2009)
Proposals with detailed text must be submitted 1-week prior to meeting
Done
Harmonization
Proposal Presentation III (September 2009)
Harmonization
Discussion
(November 2009
to May 2010)
Proposals with detailed text must be submitted 1-week prior to meeting
Done
Harmonization
Presentation & Down-Selection
(July 2010)
Down-Selection fails
Proposals with Draft Text must be submitted 2-week prior to meeting
Down-Selection succeeds
Draft Specification
Text is contributed to
802.21a draft speficiation
21-10-0067-02-0sec
Regrouping
4
Presentation & Down-Selection
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-10-0067-02-0sec
5
Presentation & Down-Selection (cont’d)
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-10-0067-02-0sec
6
Down-Selection Flowchart
TG vote on all proposals available
Any
proposal
gets 75% Approval ?
*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.
Yes
Authors work w/ Editing
Committee to integrate
text into draft specifications
No
No
Proposal(s)* getting highest votes are
subject to TG confirmation vote
75% Approval?
Yes
Any
contentious
overlap**?
Yes
Options are provided
for each overlap
area; TG votes on
options available for
overlap
Inclusion in draft
specifications
No
Yes
Proposal(s) are broken up
into several technical items;
TG votes on each technical item
21-10-0067-02-0sec
Technical item gets No
75% Approval?
Yes
Option gets
75% Approval?
No
Elimination from further
consideration
7
General Presentation Rule
1. Proposals may be 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-10-0067-02-0sec
8
Proposal Guidelines
21-10-0067-02-0sec
9
Remark
• 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-10-0067-02-0sec
10
Proposal Guideline Proposal Characterization List
• 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
An Example Proposal Characterization List
Work
Item #
Supported Functionality
Reference to
TR section(s)
1
Proactive Re-Authentication
2.3.3
1
EAP Pre-authentication
2.3.2
1
Key Hierarchy and Derivation 1
2.3.3.1
1
Higher-Layer Transport for MN-CA, MN-SA and SACA signaling
2.3.2.3
1
Link-Layer Transport for MN-SA signaling
2.3.2.3
1
Authenticator Discovery Mechanism
2.3.2.3, 2.3.3.4
1
Context Binding Mechanism
2.3.2.3, 2.3.3.4
2
Access Authentication
3.6.1
2
MIH-Specific Authentication
3.6.2
2
Key Hierarchy and Derivation 2
3
2
MIH-Specific Protection
3.6.1.1, 3.6.2.1
2
Protection by MIH Transport Protocol
3.6.1.2, 3.6.2.2
2
Visited Domain Access
3.6.3.1
21-10-0067-02-0sec
Note
Visited MIH services have the same
security policies
11
Proposal Guideline –
Refer to 802.21
• 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-10-0067-02-0sec
12
Proposal Guideline –
Assumptions
• 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-10-0067-02-0sec
13
Proposal Guideline –
Rationale
• 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-10-0067-02-0sec
14