Network Working Group R. Atarius Internet-Draft Qualcomm Technologies, Inc. Intended status: Experimental June 16, 2014 Expires: December 18, 2014 A Uniform Resource Name Namespace for the Device Identity and the Mobile Equipment Identity (MEID) draft-atarius-dispatch-meid-urn-05 Abstract This document allows a Mobile Equipment Identity (MEID) to be used as a Uniform Resource Name (URN) by registering a URN namespace for MEIDs. The structure of an MEID is 15 hexadecimal encoded digits long and is defined in 3GPP2 to uniquely identify each individual mobile equipment (e.g., a handset or mobile phone). The Third Generation Partnership Project 2 (3GPP2) has a requirement to be able to use an MEID as a URN. This document fulfills that requirement. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 18, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Atarius Expires December 18, 2014 [Page 1] Internet-Draft MEID Based URN June 2014 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Namespace Registration Template . . . . . . . . . . . . . . . 3 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. MEID Parameters . . . . . . . . . . . . . . . . . . . . . 6 4.2. MEID Format . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Manufacturer Code . . . . . . . . . . . . . . . . . . 7 4.2.2. Serial Number . . . . . . . . . . . . . . . . . . . . 7 4.2.3. Check Digit . . . . . . . . . . . . . . . . . . . . . 7 4.2.4. Hexadecimal Encoding . . . . . . . . . . . . . . . . 7 5. Community considerations . . . . . . . . . . . . . . . . . . 8 6. Namespace considerations . . . . . . . . . . . . . . . . . . 8 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security considerations . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction This document specifies a URN namespace for 3GPP2 and a Namespace Specific String (NSS) for the MEID as per the namespace registration requirement in [RFC3406]. The Namespace Identifier (NID) '3gpp2' is for identities used in 3GPP2 networks. The MEID is managed by the 3GPP2, so this NID is managed by the 3GPP2. Whilst this specification currently specifies only the MEID NSS under the '3gpp2' NID, additional NSS under the '3gpp2' NID may be specified in the future by the 3GPP2 using the procedure for URN NSS changes and additions (currently through the publication of future Informational RFCs approved by IETF conensus). The MEID is 15 hexadecimal digits long and includes a manufacturer code of 8 hexadecimal digits and the serial number of 6 hexadecimal digits plus a hexadecimal digit as a check digit. The manufacturer code identifies the mobile equipment manufacturer. A manufacturer can be assigned more that one manufacturer code. The serial number uniquely identifies each mobile equipment within the manufacturer code. The check digit is used as assurance of integrity in error-prone operations, e.g. when used with certain types of Atarius Expires December 18, 2014 [Page 2] Internet-Draft MEID Based URN June 2014 readers during inventory management operations. The check digit is not transmitted. The information here is meant to be a concise guide for those wishing to use the MEID as a URN. Nothing in this document should be construed to override [S.R0048-A] that defines the MEID. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Namespace Registration Template Namespace ID: '3gpp2' requested Registration Information: Registration version number: 1 Registration date: 2014-05-31 Declared registrant of the namespace: Registration organization: Name: 3GPP2 Address: 2500 Wilson Boulevard, Suite 300, Arlington, Virginia 22201 (USA) Declaration of syntactic structure: The identifier is expressed in American Standard Code for Information Interchange (ASCII) characters and has a hierarchical expression using the Augmented Backus-Naur Form (ABNF) defined in [RFC5234], as follows: Atarius Expires December 18, 2014 [Page 3] Internet-Draft MEID Based URN June 2014 3gpp2-urn = "urn:" 3gpp2-NID ":" 3gpp2-NSS 3gpp2-NID = "3gpp2" 3gpp2-NSS = meid-specifier / future-3gpp2-specifier meid-specifier = "meid:" ( meidval / ext-meid) ext-meid = 3gpp2-defined-nonempty ;3GPP2 defined and ;IETF consensus ;required future-3gpp2-specifier = future-specifier *( ";" future-param ) future-specifier = 3gpp2-defined-nonempty ;3GPP2 defined and ;IETF consensus ;required future-param = par-name [ EQUAL par-value ] par-name = 3gpp2-defined-nonempty par-value = 3gpp2-defined-nonempty EQUAL = "=" 3gpp2-defined-nonempty = 1*3gpp2-urn-char 3gpp2-urn-char = Alpha / DIGIT / "-" / "." / "_" / "%" / ":" An NSS for the MEID is defined under the '3gpp2' NID. An MEID is an identifier under the '3gpp2' NID that uniquely identifies mobile equipment used in 3GPP2 defined networks. The representation of the MEID is a specific number of hexadecimal digits, as described in [S.R0048-A]. The formal definition of a URN with 'meid' NSS contains one meidval with the formal definition according to the following ABNF [RFC5234]: meidval = Manufacturer Code "-" Serial Number Manufacturer Code = 8HEX Serial Number = 6HEX and <3gpp2-defined-nonempty> can comprise any ASCII characters compliant with URN syntax in [RFC5234]. The 3GPP2 will take responsibility for the '3gpp2' namespace, including the 'meid' NSS. Additional NSS may be added for future identifiers needed by the 3GPP2, at their discretion. Only URNs with the 'meid' NSS are considered to be "3GPP2 MEID URNs", and use in IETF protocols of other NSS that might be defined in the future will require IETF consensus. Atarius Expires December 18, 2014 [Page 4] Internet-Draft MEID Based URN June 2014 Relevant ancillary documentation: See 3G Mobile Equipment Identifier [S.R0048-A]. Identifier uniqueness considerations: Identifiers in the '3gpp2' NID are defined and assigned by the 3GPP2 or an agency appointed by 3GPP2 after ensuring that the URNs to be assigned are unique. Uniqueness is achieved by checking against the IANA registry of previously assigned names. Procedures are in place to ensure that each MEID is uniquely assigned by the mobile equipment manufacturer so that it is guaranteed to uniquely identify that particular mobile equipment. Identifier persistence considerations: The 3GPP2 is committed to maintaining uniqueness and persistence of all resources identified by assigned URNs. As the NID sought is '3gpp2', and 3GPP2 is the long standing acronym for the standards organization which includes the mobile phone operators, the URN should also persist indefinitely (at least as long as there is a need for its use). The assignment process guarantees that names are not reassigned. The binding between the name and its resource is permanent. The Manufacturer Code and Serial Number portions of the MEID are permanently stored in the mobile equipment so they remain persistent as long as the mobile equipment exists. The process for Manufacturer Code and Serial Number assignment is documented in [SC.R4002-0] and the Manufacturer Code and Serial Number values once assigned are not re-assigned to other mobile equipments. Process of identifier assignment: The 3GPP2 or its approved agency will manage the (including '3gpp2'), and identifier resources to maintain uniqueness. The process for MEID assignment is documented in [SC.R4002-0]. Process for identifier resolution: Since the '3gpp2' NSS is not currently globally resolvable, this is not applicable. Atarius Expires December 18, 2014 [Page 5] Internet-Draft MEID Based URN June 2014 Rules for Lexical Equivalence: Two 3GPP2 MEID URNs are equivalent if they have the same 'meidval' and the same parameter values in the same sequential order. All of these comparisons are to be case-insensitive. Any identifier in '3gpp2' NSS can be compared using the normal mechanisms for percent-encoded UTF-8 strings (see [RFC3629]). Conformance with URN Syntax: The string representation of the '3gpp2' NID and of the MEID NSS is fully compatible with the URN syntax (see [RFC2141]). Validation Mechanism: The MEID can be validated using the mechanism defined in [S.R0048-A]. Scope: 3GPP2 URN is global in scope. 4. Specification 4.1. MEID Parameters The optional 'ext-meid' field in the ABNF are included for extensibility of the 'meid' NSS. For example, if the MEID format is extended in the future (such as with additional hex digits). In this case the 'ext-meid' would be further defined to represent the syntax of the extended MEID format. Any change to the format of the 'meid' NSS requires the use of the procedure for URN NSS changes and additions (currently through the publication of a future Informational RFCs approved by IETF consensus). [draft-atarius-dispatch-meid-urn-as-instanceid] specifies how the IMEI URN can be used as an instance ID as specified in [RFC5626]. Any further additional parameters that are intended to be used as part of an instance ID, will require an update to [draft-atarius-dispatch-meid-urn-as-instanceid]. An example of 3GPP2 MEID URN is: urn:3gpp2:meid:A04B0D56-02A7E3; Atarius Expires December 18, 2014 [Page 6] Internet-Draft MEID Based URN June 2014 4.2. MEID Format 4.2.1. Manufacturer Code The manufacturer code is an 8 hexadecimal digit value. The manufacturer code identifies the mobile equipment manufacturer. The manufacturer code is chosen from a range of values allocated to the mobile equipment manufacturer in order to uniquely identify the mobile equipment. 4.2.2. Serial Number The serial number is a 6 hexadecimal digit value. The serial number identifies equipment within the manufacturer code. 4.2.3. Check Digit This is a single hexadecimal digit (bits 1-4 of octet 8) and is used as assurance of integrity in error-prone operations, e.g. when used with certain types of readers during inventory management operations. The check digit is not transmitted by the mobile equipment. 4.2.4. Hexadecimal Encoding The MEID format is 15 hexadecimal digits encoded in 8 octets as defined in [S.R0048-A]. The following figure is an abstract representation of a hexadecimal encoded MEID stored in memory (the actual storage format in memory is implementation specific). In this figure, the most significant digit of the Manufacturer Code is encoded in the bits 1-4 of octet 1. Bits 5-8 of octet 8 are zero- padded, since the bits 1-4 are only needed to encode the Check Digit. The most significant digit of the Serial Number is encoded in the bits 1-4 of octet 5. When MEID is included in a cellular signaling message, the Check Digit is omitted and the first 7 Octets in the following figure are only transmitted. 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Hexadecimal +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Digits | | | | | | | | | Manufacturer Code | Serial Number |CD| | | | | | | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 2 3 4 5 6 7 8 Octets Atarius Expires December 18, 2014 [Page 7] Internet-Draft MEID Based URN June 2014 5. Community considerations 3GPP2 defined mobile equipment will be interoperating with Internet devices for a variety of voice and data communication services. To do this, they need to make use of Internet protocols that will operate end to end between mobile equipments in 3GPP2 networks and devices in the general Internet. Some of these protocols require the use of URNs as identifiers. Within the 3GPP2 networks, mobile equipments are identified by their MEID. Internet users will need to be able to receive and include the 3GPP2 URN in various Internet protocol elements to facilitate communication between pure Internet- based devices and 3GPP2 mobile equipments. Thus the existence and syntax of these namespaces needs to be available to the general Internet community and the namespace needs to be reserved with IANA in order to guarantee uniqueness and prevent potential namespace conflicts both within the Internet and within 3GPP2 networks. Conversely, Internet implementations will not generally possess MEID identifiers. The identifiers generated by such implementations will typically be URNs within namespaces other than '3gpp2', and may, depending on context, even be non-URN URIs. Implementations are advised to be ready to process URIs other than '3gpp2' namespaced URNs, so as to aid in interoperability. 6. Namespace considerations A URN was considered the most appropriate URI to represent the MEID as this identifier may be used and transported similarly to the Universally Unique Identifier (UUID) which is defined as a URN in [RFC4122]. Since specifications for protocols that are used to transport device identifiers often require the device identifier to be globally unique and in the URN format, it is necessary that the URN formats are defined to represent the MEID. 7. IANA considerations In accordance with BCP 66 [RFC3406], IANA is asked to register the Formal URN namespace '3gpp2' in the "Uniform Resource Name (URN) Namespaces" registry, using the registration template presented in Section 3 of this document. 8. Security considerations MEIDs (but with the check digit) are displayable on most 3GPP2 mobile equipments and in many cases are printed on the case within the battery compartment. Anyone with brief physical access to the mobile device can therefore easily obtain the MEID. Therefore MEIDs MUST NOT be used as security capabilities (identifiers whose mere possession grants access). Unfortuantely there are currently Atarius Expires December 18, 2014 [Page 8] Internet-Draft MEID Based URN June 2014 examples of some applications which are using the MEID for authorization. Also some service provider's customer service departments have been known to use knowledge of the MEID as "proof" that the caller is the legitimate owner of the mobile device. Both of these are inappropriate uses of the MEID. Since the MEID is permanently assigned to the mobile equipment and is not modified when the ownership of the mobile equipment changes, (even upon a complete software reload of the mobile equipment), the MEID URN MUST NOT be used as a user identifier or user address by an application. Using the MEID to identify a user or as a user address could result in communications destined for a previous owner of a device being received by the new device owner or could allow the new device owner to access information or services owned by the previous device owner. Additionally, since the MEID identifies the mobile equipment, it potentially could be used to identify and track users for the purposes of survellience and call data mining if sent in the clear. Since the MEID is personally identifiable information, uses of the MEID URN with IETF protocols require a specification and IETF expert review [RFC5226] in order to ensure that the privacy concerns are appropriately addressed. Protocols carrying the MEID URN SHOULD at a minimum use strongly hop-by-hop encrypted channels and that it is RECOMMENDED that end-to-end encryption is used. 9. Acknowledgements This document draws heavily on the 3GPP2 work on Numbering, Addressing and Identification in [S.R0048-A] and also on the style and structure used in [RFC7254] and [RFC4122]. The author thanks for the detailed comments, provided by Ramachandran Subramanian, Alex Gogic, and Randall Gellens. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. Atarius Expires December 18, 2014 [Page 9] Internet-Draft MEID Based URN June 2014 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [S.R0048-A] 3GPP2, "S.R0048-A: 3G Mobile Equipment Identifier (MEID) - Stage 1, Version 4.0", 3GPP2 TS S.R0048-A 4.0, June 2005. [SC.R4002-0] 3GPP2, "SC.R4002-0: GHA (Global Hexadecimal Administrator) Assignment Guidelines and Procedures for Mobile Equipment Identifier (MEID) and Short Form Expanded UIM Identifier (SF_EUIMID), Version 10.0", 3GPP2 TS SC.R4002-0 10.0, December 2013. [draft-atarius-dispatch-meid-urn-as-instanceid] Atarius, R., "S.R0048-A: Using the Mobile Equipment Identity (MEID) Uniform Resource Name (URN) as an Instance ID", Internet Draft draft-atarius-dispatch-meid-urn-as- instanceid, June 2014. 10.2. Informative References [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009. [RFC7254] Montemurro, M., Allen, A., McDonald, D., Gosden, P.,, "A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI)", Internet Draft RFC7254, May 2014. Author's Address Atarius Expires December 18, 2014 [Page 10] Internet-Draft MEID Based URN June 2014 Roozbeh Atarius Qualcomm Technologies, Inc. 5775 Morehouse Drive San Diego, CA 92121 USA Phone: +1 858 845 1341 Email: ratarius@qti.qualcomm.com Atarius Expires December 18, 2014 [Page 11]