IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN: 21-09-0017-02-0sec
Title: Security TG Call For Proposals (DRAFT)
Date Submitted: February 24, 2009
Presented at IEEE 802.21a teleconference on Feb 11, 2009
Authors or Source(s):
Yoshihiro Ohba (Toshiba), Lily Chen (NIST) and
Shubhranshu Singh (Samsung)
Abstract: This document describes a draft Call For Proposals for
802.21a and the down-selection process.
21-09-0017-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-09-0017-02-0sec
2
802.21a Call For 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: May 3rd (Sun), 2009, end of day AOE (Anywhere On Earth)
• After the submission deadline, no new revision of proposal is allowed until the end of May
meeting
• For questions, please contact to Yoshihiro Ohba <yohba@tari.toshiba.com>, Chair of 802.21a
Task Group
21-09-0017-02-0sec
3
Proposal Presentation & Down-Selection Process
The proposal presentation & down-selection process
addresses the following issues:
1) giving enough buffer time between presentations in
order to work out details and build consensus
2) providing material to group ahead of time to allow for
more thorough review and allow focused discussion
3) having a rule to sunset unpopular proposals in terms of
number of votes after three times of proposal
presentations
21-09-0017-02-0sec
4
Timeline
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
Proposal Presentation III (September 2009)
Proposals with detailed text must be submitted 1-week prior to meeting
Harmonization
Down-Selection (November 2009)
Down-Selection fails
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-0017-02-0sec
Regrouping
5
Proposal Presentation
1. Proposals are made available one week prior to presentation time in
order to allow for sufficient review time
2. No draft text needed at Proposal Presentation I , but detailed text is needed
at Proposal Presentations II and III
3. Each proposal should use security TR document (21-08-0172-02-0sec)
as design guidelines and requirements
4. Each proposal should follow the proposal guidelines (see Slides 12 – 17)
5. A proposal may cover work item #1 or #2 or both
•
A submitter may submit separate proposal(s) for each work item
6. A procedural motion may take place at the end of a presentation in
Proposal Presentations I and II in order to provide feedback on a
proposal
•
Any revised proposal for Proposal Presentations II and III should address the
received feedback, comments
7. New proposal is allowed in Proposal Presentation II, only if
•
•
It is extension of presentation in Proposal Presentation I , or
It addresses (part of) work item not yet already covered or presented in proposal
presentation I but described in TR document
8. Only revised proposals are allowed and No new proposal is allowed in
Proposal Presentation III
21-09-0017-02-0sec
6
Proposal Presentation (cont’d)
• Revised Proposal
•
An updated proposal that captures any comments/feedbacks received during its
earlier presentation
• New Proposal
• The proposal which is either
– an extension (with entirely new thoughts e.g to capture any newly
agreed requirement captured during previous presentation) of
presentation in earlier Proposal Presentation , or
– it addresses (part of) work item not yet already covered or presented
in proposal presentation I but listed in the TR document or Proposal
Characterization List
21-09-0017-02-0sec
7
Down-Selection
1. Authors provide Draft Text for review two weeks prior to
presentation
2. Written questions for clarifications to be submitted to groups 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 Task Group 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 working group
6. All motions are carried out at the end of all presentations
7. Time allocated for motions is advertised in the opening meeting of
each session
8. A technical motion at Down-Selection requires 75% to pass
9. One member can vote on multiple motions
21-09-0017-02-0sec
8
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 Working Group
• 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 WG 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 WG to vote on
• Failed proposals are eliminated from further consideration
12. In case no proposal is approved at the end of Down-Selection, the
Task Group 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-0017-02-0sec
9
Down-Selection Flowchart
*There could be several proposals under consideration in order to cover
different work items
**Overlap is identified by Editing Committee, WG members, and/or
proposers; contention in resolving overlap is brought to WG for vote.
Vote on all proposals available
Any
proposal
gets 75% Approval ?
Yes
Authors work w/ Editing
Committee to integrate
text into draft specifications
No
No
Proposal(s)* getting highest votes are
subject to confirmation vote
75% Approval?
Yes
Any
contentious
overlap**?
Yes
Options are provided
for each overlap
area; WG votes on
options available for
overlap
Inclusion in draft
specifications
No
Yes
Proposal(s) are broken up
into several technical items;
WG votes on each technical item
21-09-0017-02-0sec
Technical item gets No
75% Approval?
Yes
Option gets
75% Approval?
No
Elimination from further
consideration
10
General Presentation Rule
1. Proposals are categorized into the three groups
Presentation Group 1: Work Item #1
Presentation Group 2: Work Item #2
Presentation Group 3: Work Items #2 and #3 combined
2. Presentation order is random within each Presentation
Group as determined by the Chair
3. Time allocated to each presentation is evenly distributed
among all presentations in the same Presentation Group
21-09-0017-02-0sec
11
Proposal Guidelines
21-09-0017-02-0sec
12
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-09-0017-02-0sec
13
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-020sec) to create a Proposal Characterization List
An Example Proposal Characterization List
Work Item
#
Supported Functionality
1
Proactive Re-Authentication
1
EAP Pre-authentication
1
Key Hierarchy and Derivation 1
1
Higher-Layer Transport for MN-CA, MN-SA and SA-CA signaling
1
Link-Layer Transport for MN-SA signaling
1
Authenticator Discovery Mechanism
1
Context Binding Mechanism
2
Access Authentication
2
MIH-Specific Authentication
2
Key Hierarchy and Derivation 2
2
MIH-Specific Protection
2
Protection by MIH Transport Protocol
2
Visited Domain Access
21-09-0017-02-0sec
14
Proposal Guideline –
Refer to 802.21
• Each proposal is expected to make a clear reference to 802.21
with regard to
•
Network entities: If a new network entity is introduced for
proposed security solutions, then address the relation,
location, and interface with other 802.21 network entities.
•
Protocol interfaces: if new interfaces are introduced, then
discuss the feasibility with the current 802.21.
•
Data fields: if for protected messages, new data fields are
introduced, then specify them in 802.21 data format.
21-09-0017-02-0sec
15
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-09-0017-02-0sec
16
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 against;
•
Security performance tradeoffs;
•
Comparisons with other solutions, if any;
•
Current standards (re-use);
•
Etc.
21-09-0017-02-0sec
17