IEEE MEDIA INDEPENDENT HANDOVER DCN: sec Title: Security TG Call For Proposals Date Submitted: March 11, 2009 Presented at IEEE session #31 in Vancouver Authors or Source(s): Yoshihiro Ohba (Toshiba), Lily Chen (NIST) and Shubhranshu Singh (Samsung) Abstract: This document describes Call For Proposals for a and the down-selection process 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

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 Work Item #2: Mechanisms to provide data integrity, replay protection, confidentiality and data origin authentication to IEEE MIH protocol exchanges and enable authorization for MIH services Proposals must be submitted to Document Repository ( Group: Security Document Title: TGa_Proposal_Firstname_Lastname (e.g.,TGa_Proposal_Yoshihiro_Ohba) Submission Deadline: May 3 rd (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, Chair of a Task Group sec3

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 select suitable and proper proposals after three times of proposal presentations sec4

Timeline sec Harmonization Draft Standard Text is contributed to a draft standard Call for Proposal (March 2009) Presentation & Down-Selection (November 2009) Proposals with Draft Text must be submitted 2-week prior to meeting Proposal Presentation I (May 2009) Proposals must be submitted 1-week prior to meeting Down-Selection fails Regrouping Harmonization Proposal Presentation III (September 2009) Proposals with detailed text must be submitted 1-week prior to meeting Proposal Presentation II (July 2009) Proposals with detailed text must be submitted 1-week prior to meeting Harmonization Down-Selection succeeds 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 ( sec) 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 sec6

Proposal Presentation (contd) 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 sec7

Presentation & Down-Selection sec8 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 a 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

Presentation & Down-Selection (contd) 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 down- selection criteria, (3) reissuing a new call for proposals sec9

Down-Selection Flowchart sec10 TG vote on all proposals available Proposal(s)* getting highest votes are subject to TG confirmation vote Proposal(s) are broken up into several technical items; TG votes on each technical item Options are provided for each overlap area; TG votes on options available for overlap 75% Approval? Any proposal gets 75% Approval ? Yes No Inclusion in draft specifications Authors work w/ Editing Committee to integrate text into draft specifications No Yes Any contentious overlap**? Option gets 75% Approval? Yes No Elimination from further consideration No Technical item gets 75% Approval? Yes No *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.

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 #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 sec11

Proposal Guidelines sec12

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 sec

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 ( sec) to create a Proposal Characterization List sec14 Work Item # Supported FunctionalityReference to TR section(s) Note 1Proactive Re-Authentication EAP Pre-authentication Key Hierarchy and Derivation 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 23 2MIH-Specific Protection , Protection by MIH Transport Protocol , Visited Domain Access Visited MIH services have the same security policies An Example Proposal Characterization List

Proposal Guideline – Refer to Each proposal is expected to make a clear reference to with regard to entities: If a new entity is introduced for proposed security solutions, then address the relation, location, and interface with other 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 spec. Data fields: if for protected messages, new data fields are introduced, then specify them in data format sec15

Proposal Guideline – Assumptions If a proposal relies on assumptions which are not described in the 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 sec16

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 sec17