IEEE MEDIA INDEPENDENT HANDOVER DCN: srho Title: Merging Plan for Pull Key Distribution Date Submitted: Presented at IEEE Authors or Source(s): Yoshihiro Ohba, Rafa Marin Lopez, Fernando Bernal, Antonio de la Oliva, Abstract: Merging plan for proactive pull key distribution mechanism into IEEE c srho1

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

Motivation In November 2011 Plenary, the group agreed on supporting proactive pull key distribution for c (DCN ) Referred to as PPKD There was a question about relationship between the proactive pull key distribution scheme and the optimization scheme described in Section 9.7 “Securing Single-Radio messages using SFF” of the working c draft (DCN ) Referred to as SFF We compare PPKD and SFF to see if the two schemes can be merged srho3

PPKD Scheme (1/2) Identity bootstrap (from TPoS) and MNMSRK installation into the TPoS (AAA) srho4

PPKD Scheme (2/2) MN to tPoA authentication srho5 based on MNnetworkAccessId

SFF Scheme srho6 K_hsffkey between MN and HSFF K_osffkey between MN and OSFF K_tsffkey between MN and TSFF K_hosffkey between HSFF and OSFF K_htsffkey between HSFF and TSFF K_otsffkey between OSFF and TSFF KDF_hosffkey distribution function between HSFF and OSFF KDF_otsffkey distribution function between OSFF and TSFF

Common Functionality A key (K) to establish a security association between the MN and C-GW is transferred from an anchor node in the source network to the C-GW The key is used for the C-GW to authenticate the MN during pre-registration without interacting with the MN’s home network srho7

Differences between PPKD and SFF The name of the anchor node in the source network In PPKD: sPoS (serving PoS) In SFF: OSFF (Originating SFF) Identifier of MN used by C-GW In PPKD: MNnetworkacccesId In SFF: MNaddr Name of K and method to generate K In PPKD: MIRK derived from a key derivation key shared between MN and sPoS In SFF: K_tsff generated by OSFF and distributed to MN and TSFF Message and target node(s) to distribute K In PPKD: message: MIH_N2N_LL_Auth, target node: C-GW In SFF: message: undefined, target nodes: MN and C-GW Key or SA to protect message used for distributing K In PPKD: MIH_SA between sPoS and tPoS In SFF: K_otsff and K_osff srho8

Conclusions PPKD and SFF are functionally equivalent and therefore can be merged into a single solution Considering consistency with a, use PPKD conventions as much as possible srho9