idnits 2.17.1 draft-atarius-dispatch-meid-urn-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 13, 2018) is 2287 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Atarius 3 Internet-Draft January 13, 2018 4 Intended status: Informational 5 Expires: July 17, 2018 7 A Uniform Resource Name Namespace for the Device Identity and the Mobile 8 Equipment Identity (MEID) 9 draft-atarius-dispatch-meid-urn-15 11 Abstract 13 This document defines a Uniform Resource Name (URN) namespace for the 14 Third Generation Partnership Project (3GPP2) and a Namespace Specific 15 String (NSS) for the Mobile Equipment Identity (MEID). The structure 16 of an MEID is 15 hexadecimal encoded digits long and is defined in 17 the Third Generation Partnership Project 2 (3GPP2) (see [S.R0048-A]) 18 to uniquely identify each individual mobile equipment (e.g., a 19 handset or mobile phone). The 3GPP2 has a requirement to be able to 20 use an MEID as a URN. This document fulfills that requirement. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 17, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Namespace Registration Template . . . . . . . . . . . . . . . 3 59 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. MEID Parameters . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. MEID Format . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.2.1. Manufacturer Code . . . . . . . . . . . . . . . . . . 7 63 4.2.2. Serial Number . . . . . . . . . . . . . . . . . . . . 7 64 4.2.3. Check Digit . . . . . . . . . . . . . . . . . . . . . 7 65 4.2.4. Hexadecimal Encoding . . . . . . . . . . . . . . . . 7 66 5. Community considerations . . . . . . . . . . . . . . . . . . 8 67 6. Namespace considerations . . . . . . . . . . . . . . . . . . 8 68 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 69 8. Security and privacy considerations . . . . . . . . . . . . . 8 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 10.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 A single mode 3GPP mobile equipment which uses only 3GPP technology 79 to transmit and receive voice or data, or a dual mode 3GPP/3GPP2 80 mobile equipment which uses either 3GPP or 3GPP2 technology to 81 transmit and receive voice or data has an International Mobile 82 station Equipment Identity (IMEI) to identify the mobile equipment. 83 Document [RFC7254] defines a URN Namespace and an NSS for the IMEI. 84 For cases where the mobile equipment uses decimal values (i.e., IMEI) 85 as an identity for dual mode 3GPP/3GPP2 access the IMEI urn as 86 defined in [RFC7254] can be used to identify the mobile equipment. 88 However, single mode 3GPP2 mobile equipment which supports only 3GPP2 89 access technology to transmit and receive voice or data has a 90 hexadecimal MEID. Since there are fundamental differences between 91 MEID and IMEI, i.e. in encoding, format and the ownership, [RFC7254] 92 cannot be employed to represent the hexadecimal MEID. 94 This document specifies a URN namespace for 3GPP2 and an NSS for the 95 MEID as per the namespace registration requirement in [RFC8141]. The 96 structure of an MEID is 15 hexadecimal encoded digits long and is 97 defined by 3GPP2 (see [S.R0048-A]) to uniquely identify each 98 individual mobile equipment (e.g., a handset or mobile phone). The 99 3GPP2 has a requirement to be able to use an MEID as a URN. This 100 document fulfills that requirement. The Namespace Identifier (NID) 101 '3gpp2' is for identities used in 3GPP2 networks. The MEID is 102 managed by the 3GPP2, so this NID is managed by the 3GPP2. Whilst 103 this specification currently specifies only the MEID NSS under the 104 '3gpp2' NID, additional NSS under the '3gpp2' NID may be specified in 105 the future by the 3GPP2. 107 The hexadecimal MEID is 15 hexadecimal digits long and includes a 108 manufacturer code of 8 hexadecimal digits and the serial number of 6 109 hexadecimal digits plus a hexadecimal digit as a check digit. 111 The manufacturer code identifies the mobile equipment manufacturer. 112 A manufacturer can be assigned more than one manufacturer code. The 113 serial number uniquely identifies each mobile equipment within the 114 manufacturer code. The check digit is used as assurance of integrity 115 in error-prone operations, e.g. when used with certain types of 116 readers during inventory management operations. The check digit is 117 not transmitted. 119 The information here is meant to be a concise guide for those wishing 120 to use the hexadecimal MEID as a URN. Nothing in this document 121 should be construed to override [S.R0048-A] that defines the MEID. 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 3. Namespace Registration Template 131 Namespace ID: '3gpp2' requested 133 Registration Information: 135 Registration version number: 1 137 Registration date: 2018-01-13 139 Declared registrant of the namespace: 141 Registration organization: 143 Name: 3GPP2 144 Address: 146 John Derr, MEID Global Hexadecimal Administrator, JDerr@tiaonline.org 147 Gary Pellegrino, TIA TR-45 EUMAG Chair, gary@commflowresources.com 148 c/o Telecommunications Industry Association 149 1320 N. Courthouse Rd. Suite 200, 150 Arlington, Virginia 22201 USA 152 Declaration of syntactic structure: 154 The identifier is expressed in American Standard Code for Information 155 Interchange (ASCII) characters and has a hierarchical expression 156 using the Augmented Backus-Naur Form (ABNF) defined in [RFC5234], as 157 follows: 159 pp2-urn = "urn:" pp2-NID ":" pp2-NSS 160 pp2-NID = "3gpp2" 161 pp2-NSS = meid-specifier / future-pp2-specifier 162 meid-specifier = "meid:" meidval 163 future-pp2-specifier = future-specifier *( ";" future-param ) 164 future-specifier = pp2-defined-nonempty ;3GPP2 defined 165 future-param = par-name [ EQUAL par-value ] 166 par-name = pp2-defined-nonempty 167 par-value = pp2-defined-nonempty 168 EQUAL = "=" 169 pp2-defined-nonempty = 1*pp2-urn-char 170 pp2-urn-char = ALPHA / DIGIT / "-" / "." / "_" / "%" / ":" 171 ALPHA = %x41-5A / %x61-7A; A-Z / a-z 172 DIGIT = %x30-39; 0-9 174 An NSS for the MEID is defined under the '3gpp2' NID. 176 An MEID is an identifier under the '3gpp2' NID that uniquely 177 identifies mobile equipment used in 3GPP2 defined networks. 179 The representation of the MEID is a specific number of hexadecimal 180 digits, as described in [S.R0048-A]. 182 The formal definition of a URN with 'meid' NSS contains one meidval 183 with the formal definition according to the following ABNF [RFC5234]: 185 meidval = Manufacturer-Code "-" Serial-Number 186 Manufacturer-Code = 8HEX 187 Serial-Number = 6HEX 188 HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 189 and can comprise any 190 ASCII characters compliant with URN syntax in [RFC8141]. 192 The 3GPP2 will take responsibility for the '3gpp2' namespace, 193 including the 'meid' NSS. 195 Relevant ancillary documentation: 197 See 3G Mobile Equipment Identifier [S.R0048-A] and GHA (Global 198 Hexadecimal Administrator) Assignment Guidelines and Procedures for 199 Mobile Equipment Identifier (MEID) and Short Form Expanded UIM 200 Identifier (SF_EUIMID) [SC.R4002-0]. 202 Identifier uniqueness considerations: 204 Identifiers in the '3gpp2' NID are defined and assigned by the 3GPP2 205 or an agency appointed by 3GPP2 after ensuring that the URNs to be 206 assigned are unique. 208 Procedures are in place to ensure that each MEID is uniquely assigned 209 by the mobile equipment manufacturer so that it is guaranteed to 210 uniquely identify that particular mobile equipment. 212 Identifier persistence considerations: 214 The 3GPP2 is committed to maintaining uniqueness and persistence of 215 all resources identified by assigned URNs. 217 As the NID sought is '3gpp2', and 3GPP2 is the long standing acronym 218 for the standards organization which includes the mobile phone 219 operators, the URN should also persist indefinitely (at least as long 220 as there is a need for its use). The assignment process guarantees 221 that names are not reassigned. The binding between the name and its 222 resource is permanent. 224 The Manufacturer Code and Serial Number portions of the MEID are 225 permanently stored in the mobile equipment so they remain persistent 226 as long as the mobile equipment exists. The process for Manufacturer 227 Code and Serial Number assignment is documented in [SC.R4002-0] and 228 the Manufacturer Code and Serial Number values once assigned are not 229 re-assigned to other mobile equipments. 231 Process of identifier assignment: 233 The 3GPP2 or its approved agency will manage the (including 234 '3gpp2') and identifier resources to maintain 235 uniqueness. The process for MEID assignment is documented in 236 [SC.R4002-0]. 238 Process for identifier resolution: 240 Since the '3gpp2' NSS is not currently globally resolvable, this is 241 not applicable. 243 Rules for Lexical Equivalence: 245 Two 3GPP2 MEID URNs are equivalent if they have the same 'meidval' 246 and the same parameter values in the same sequential order. All of 247 these comparisons are to be case-insensitive. 249 Any identifier in '3gpp2' NSS can be compared using the normal 250 mechanisms for percent-encoded UTF-8 strings (see [RFC3629]). 252 Conformance with URN Syntax: 254 The string representation of the '3gpp2' NID and of the MEID NSS is 255 fully compatible with the URN syntax (see [RFC8141]). 257 Validation Mechanism: 259 The MEID can be validated using the mechanism defined in [S.R0048-A]. 261 Scope: 263 3GPP2 URN is global in scope. 265 4. Specification 267 4.1. MEID Parameters 269 Any future change to the format of the 'meid' NSS requires the use of 270 the procedure for URN NSS changes (currently through the publication 271 of a future Informational RFCs approved by IETF consensus). 273 [draft-atarius-dispatch-meid-urn-as-instanceid] specifies how the 274 MEID URN can be used as an instance ID as specified in [RFC5626]. 275 Any change to the instance ID, will require an update to 276 [draft-atarius-dispatch-meid-urn-as-instanceid]. An example of 3GPP2 277 MEID URN is: 279 urn:3gpp2:meid:A04B0D56-02A7E3 281 4.2. MEID Format 283 4.2.1. Manufacturer Code 285 The manufacturer code is an 8 hexadecimal digit value. The 286 manufacturer code identifies the mobile equipment manufacturer. The 287 manufacturer code is chosen from a range of values allocated to the 288 mobile equipment manufacturer in order to uniquely identify the 289 mobile equipment. 291 4.2.2. Serial Number 293 The serial number is a 6 hexadecimal digit value. The serial number 294 identifies equipment within the manufacturer code. 296 4.2.3. Check Digit 298 This is a single hexadecimal digit (bits 1-4 of octet 8) and is used 299 as assurance of integrity in error-prone operations, e.g. when used 300 with certain types of readers during inventory management operations. 301 The check digit is not transmitted by the mobile equipment. 303 4.2.4. Hexadecimal Encoding 305 The MEID format is 15 hexadecimal digits encoded in 8 octets as 306 defined in [S.R0048-A]. The following figure is an abstract 307 representation of a hexadecimal encoded MEID stored in memory (the 308 actual storage format in memory is implementation specific). In this 309 figure, the most significant digit of the Manufacturer Code is 310 encoded in the bits 1-4 of octet 1. Bits 5-8 of octet 8 are zero- 311 padded, since the bits 1-4 are only needed to encode the Check Digit. 312 The most significant digit of the Serial Number is encoded in the 313 bits 1-4 of octet 5. When MEID is included in a cellular signaling 314 message, the Check Digit is omitted and the first 7 Octets in the 315 following figure are only transmitted, [X.S0008-0]. 317 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Hexadecimal 318 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Digits 319 | | | | 320 | | | | 321 | Manufacturer Code | Serial Number |CD| 322 | | | | 323 | | | | 324 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 325 1 2 3 4 5 6 7 8 Octets 327 5. Community considerations 329 3GPP2 defined mobile equipment will interoperate with Internet 330 devices for a variety of voice and data communication services. To 331 do this, they need to make use of Internet protocols that will 332 operate end to end between mobile equipments in 3GPP2 networks and 333 devices in the general Internet. Some of these protocols require the 334 use of URNs as identifiers. Within the 3GPP2 networks, mobile 335 equipments are identified by their MEID. Internet users will need to 336 be able to receive and include the 3GPP2 URN in various Internet 337 protocol elements to facilitate communication between pure Internet- 338 based devices and 3GPP2 mobile equipments. Thus the existence and 339 syntax of these namespaces needs to be available to the general 340 Internet community and the namespace needs to be reserved with IANA 341 in order to guarantee uniqueness and prevent potential namespace 342 conflicts both within the Internet and within 3GPP2 networks. 343 Conversely, Internet implementations will not generally possess MEID 344 identifiers. The identifiers generated by such implementations will 345 typically be URNs within namespaces other than '3gpp2', and may, 346 depending on context, even be non-URN URIs. Implementations are 347 advised to be ready to process URIs other than '3gpp2' namespaced 348 URNs, so as to aid in interoperability. 350 6. Namespace considerations 352 A URN was considered the most appropriate URI to represent the MEID 353 as this identifier may be used and transported similarly to the 354 Universally Unique Identifier (UUID) which is defined as a URN in 355 [RFC4122]. Since specifications for protocols that are used to 356 transport device identifiers often require the device identifier to 357 be globally unique and in the URN format, it is necessary that the 358 URN formats are defined to represent the MEID. 360 7. IANA considerations 362 In accordance with BCP 66 [RFC8141], IANA is asked to register the 363 Formal URN namespace '3gpp2' in the "Uniform Resource Name (URN) 364 Namespaces" registry, using the registration template presented in 365 Section 3 of this document. 367 8. Security and privacy considerations 369 An MEID is usually printed outside of the box, a mobile device ships 370 in. The MEID may also be printed under the battery on a mobile 371 device, however very few devices have removable batteries today. One 372 can retrieve the MEID via either settings or by dialing *#06#. 373 Anyone with brief physical access to the mobile device or its box can 374 therefore easily obtain the MEID. Therefore MEIDs MUST NOT be used 375 as security capabilities (identifiers whose mere possession grants 376 access). Unfortunately there are currently examples of some 377 applications which are using the MEID for authorization. Also some 378 service providers' customer service departments have been known to 379 use knowledge of the MEID as "proof" that the caller is the 380 legitimate owner of the mobile device. Both of these are 381 inappropriate uses of the MEID. 383 Since the MEID is permanently assigned to the mobile equipment and is 384 not modified when the ownership of the mobile equipment changes, 385 (even upon a complete software reload of the mobile equipment), the 386 MEID URN MUST NOT be used as a user identifier or user address by an 387 application. Using the MEID to identify a user or as a user address 388 could result in communications destined for a previous owner of a 389 device being received by the new device owner or could allow the new 390 device owner to access information or services owned by the previous 391 device owner. 393 Additionally, since the MEID identifies the mobile equipment, it 394 potentially could be used to identify and track users for the 395 purposes of surveillance and call data mining if sent in the clear. 397 Since the MEID is personally identifiable information, uses of the 398 MEID URN with IETF protocols require a specification and IETF expert 399 review [RFC5226] in order to ensure that the privacy concerns are 400 appropriately addressed. Protocols carrying the MEID URN SHOULD at a 401 minimum use strongly hop-by-hop encrypted channels and that it is 402 RECOMMENDED that end-to-end encryption is used. 404 9. Acknowledgements 406 This document draws heavily on the 3GPP2 work on Numbering, 407 Addressing and Identification in [S.R0048-A] and also on the style 408 and structure used in [RFC7254] and [RFC4122]. 410 The author thanks for the detailed comments, provided by Ramachandran 411 Subramanian, Alex Gogic, and Randall Gellens. 413 10. References 415 10.1. Normative References 417 [draft-atarius-dispatch-meid-urn-as-instanceid] 418 Atarius, R., "S.R0048-A: Using the Mobile Equipment 419 Identity (MEID) Uniform Resource Name (URN) as an Instance 420 ID", Internet Draft draft-atarius-dispatch-meid-urn-as- 421 instanceid, January 2018. 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, 425 DOI 10.17487/RFC2119, March 1997, 426 . 428 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 429 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 430 2003, . 432 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 433 Unique IDentifier (UUID) URN Namespace", RFC 4122, 434 DOI 10.17487/RFC4122, July 2005, 435 . 437 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 438 IANA Considerations Section in RFCs", RFC 5226, 439 DOI 10.17487/RFC5226, May 2008, 440 . 442 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 443 Specifications: ABNF", STD 68, RFC 5234, 444 DOI 10.17487/RFC5234, January 2008, 445 . 447 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 448 "Managing Client-Initiated Connections in the Session 449 Initiation Protocol (SIP)", RFC 5626, 450 DOI 10.17487/RFC5626, October 2009, 451 . 453 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 454 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 455 . 457 [S.R0048-A] 458 3GPP2, "S.R0048-A: 3G Mobile Equipment Identifier (MEID) - 459 Stage 1, Version 4.0", 3GPP2 TS S.R0048-A 4.0, June 2005, 460 . 463 [SC.R4002-0] 464 3GPP2, "SC.R4002-0: GHA (Global Hexadecimal Administrator) 465 Assignment Guidelines and Procedures for Mobile Equipment 466 Identifier (MEID) and Short Form Expanded UIM Identifier 467 (SF_EUIMID), Version 10.0", 3GPP2 TS SC.R4002-0 10.0, 468 December 2013, . 471 [X.S0008-0] 472 3GPP2, "X.S0008-0: MAP Support for the Mobile Equipment 473 Identity (MEID), Version 2.0", 3GPP2 TS X.S0008-0 2.0, 474 October 2005, . 477 10.2. Informative References 479 [RFC7254] Montemurro, M., Allen, A., McDonald, D., Gosden, P.,, "A 480 Uniform Resource Name Namespace for the Global System for 481 Mobile Communications Association (GSMA) and the 482 International Mobile station Equipment Identity (IMEI)", 483 Internet Draft RFC7254, May 2014. 485 Author's Address 487 Roozbeh Atarius 489 Email: r_atarius@yahoo.com