Presentation is loading. Please wait.

Presentation is loading. Please wait.

Proposed 1x Device Binding Solution Based on SX40-20130321-002 & SX40-20130321-004 3GPP2 TSG-SX WG4 SX40-20130321-008 Source(s): Qualcomm Incorporated.

Similar presentations


Presentation on theme: "Proposed 1x Device Binding Solution Based on SX40-20130321-002 & SX40-20130321-004 3GPP2 TSG-SX WG4 SX40-20130321-008 Source(s): Qualcomm Incorporated."— Presentation transcript:

1 Proposed 1x Device Binding Solution Based on SX40-20130321-002 & SX40-20130321-004 3GPP2 TSG-SX WG4 SX40-20130321-008 Source(s): Qualcomm Incorporated Alcatel-Lucent (TBC) Contact(s): Anand Palanigounder, apg@qti.qualcomm.comapg@qti.qualcomm.com Aram Perez, aramp@qti.qualcomm.comaramp@qti.qualcomm.com Simon Mizikovsky, simon.mizikovsky@alcatel-lucent.com (TBC)simon.mizikovsky@alcatel-lucent.com Recommendation: For Discussion & Agreement Notice The contributors grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include all or portions of this contribution; and at the Organizational Partner’s sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner’s standards publication. The contributors are also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by the contributors to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on the contributors. The contributors specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of the contributors other than provided in the copyright statement above.

2 Background This proposal attempts to merge key concepts from proposals in SX40-20130321-002 & SX40- 20130321-004 for 1x Device Binding – This is a based on offline discussions among the contributors of these proposals We propose that WG4 discuss and approve the solution concepts – This concept solution will be used as a baseline for further discussions & contributions 2

3 1x Device Binding Message Flow Adapted from SX40-20130321-004 & modified 3

4 Description of New Terms (1) MEID_SIG_REQ: this new item is an indication to the MS to return validated MEID ( MEID_SIG) – Whether it is a new record type in the 1x Status Request or a new IE is FFS If a new IE, can it include a nonce from MSC is FFS; In no new IE, then the 1x RAND is used in MEID_SIG calculation 4

5 Description of New Terms (2) MEID_SIG: this new IE contains digital signature / HMAC – If MS has K ME (a key shared between MS & HLR)provisioned, MEID_SIG should contain HMAC – If MS has a certificate (private / public key pairs) provisioned, MEID_SIG should contain digital signature FFS: Is there a need to indicate to MS whether to use K ME / certificate for MEID_SIG calculation? Profile for digital signature/HMAC calculation is FFS ECC is a likely candidate for digital signature because of its size 5

6 Assumptions An MSC that supports device binding will always include MEID_SIG_REQ in the Status Request (MEID_ME) message irrespective of whether the binding check is required for a given MS An MS that does not support device binding will ignore the MEID_SIG_REQ field and only return MEID_ME in the (Extended) Status Response 6

7 Open Issues If the MNO is known, K ME can be pre-provisioned at manufacturing time and the MNO provisions it in their network – Whether there is a need to specify OTA K ME provisioning / change after ME manufacturing is FFS A certificate, associated with the MEID, is pre-provisioned at manufacturing time – How HLR gets the MS’s certificate for MEID_SIG validation is FFS HLR can obtain it based on the MEID – e.g., from a database MS could include it in the MEID_SIG along with digital signature – introduces additional overhead in message size If TSG-SX WG2 does not prefer adding new IE to X.S0008, then message flow in Fig. 1 of 20130321-004 needs to be reconsidered 7

8 Proposal Discuss & Adopt 8


Download ppt "Proposed 1x Device Binding Solution Based on SX40-20130321-002 & SX40-20130321-004 3GPP2 TSG-SX WG4 SX40-20130321-008 Source(s): Qualcomm Incorporated."

Similar presentations


Ads by Google