idnits 2.17.1 draft-montemurro-gsma-imei-urn-20.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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 2014) is 3705 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3406 (ref. '1') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2141 (ref. '8') (Obsoleted by RFC 8141) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Montemurro, Ed. 3 Internet-Draft A. Allen 4 Intended status: Informational Blackberry 5 Expires: August 30, 2014 D. McDonald 6 Eircom 7 P. Gosden 8 GSM Association 9 February 26, 2014 11 A Uniform Resource Name Namespace for the Global System for Mobile 12 communications Association (GSMA) and the International Mobile station 13 Equipment Identity (IMEI) 14 draft-montemurro-gsma-imei-urn-20 16 Abstract 18 This specification specifies a Uniform Resource Name namespace for 19 the GSMA (Global System for Mobile communications Association) and a 20 Namespace Specific String (NSS) for the IMEI (International Mobile 21 station Equipment Identity), and an associated parameter for the 22 IMEISV (International Mobile station Equipment Identity and Software 23 Version number). The IMEI and IMEISV were introduced as part of the 24 specification for Global System for Mobile communications (GSM) and 25 are also now incorporated by the 3rd Generation Partnership Project 26 (3GPP) as part of the 3GPP specification for GSM, the Universal 27 Mobile Telecommunications System (UMTS) and 3GPP LTE (Long Term 28 Evolution). The IMEI and IMEISV are used to uniquely identify Mobile 29 Equipment within these systems and are managed by the GSMA. URNs 30 from this namespace almost always contain Personally Identifying 31 Information and need to be treated accordingly. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 30, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 3. Namespace Registration Template . . . . . . . . . . . . . . . 5 85 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9 86 4.1. IMEI Parameters . . . . . . . . . . . . . . . . . . . . . 9 87 4.2. IMEI Format . . . . . . . . . . . . . . . . . . . . . . . 10 88 4.2.1. Type Allocation Code (TAC) . . . . . . . . . . . . . . 10 89 4.2.2. Serial Number (SNR) . . . . . . . . . . . . . . . . . 10 90 4.2.3. Spare . . . . . . . . . . . . . . . . . . . . . . . . 10 91 4.2.4. Binary Encoding . . . . . . . . . . . . . . . . . . . 10 92 4.3. IMEISV Format . . . . . . . . . . . . . . . . . . . . . . 11 93 4.3.1. Type Allocation Code (TAC) . . . . . . . . . . . . . . 11 94 4.3.2. Serial Number (SNR) . . . . . . . . . . . . . . . . . 11 95 4.3.3. Software Version Number (SVN) . . . . . . . . . . . . 11 96 4.3.4. Binary Encoding . . . . . . . . . . . . . . . . . . . 11 98 5. Community considerations . . . . . . . . . . . . . . . . . . . 12 100 6. Namespace considerations . . . . . . . . . . . . . . . . . . . 12 102 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 104 8. Security and privacy considerations . . . . . . . . . . . . . 13 106 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 108 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 109 10.1. Normative references . . . . . . . . . . . . . . . . . . . 14 110 10.2. Informative references . . . . . . . . . . . . . . . . . . 15 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 114 1. Introduction 116 This specification specifies a Uniform Resource Name (URN) namespace 117 for the GSMA (GSM Association) and a NSS for the IMEI (International 118 Mobile station Equipment Identity), and associated parameter for the 119 Software Version number from the IMEISV (International Mobile station 120 Equipment Identity and Software Version number) as per the namespace 121 registration requirement found in RFC 3406 [1]. The NID (Namespace 122 Identifier) 'gsma' is for identities used in GSM, UMTS and LTE 123 networks. The IMEI and the IMEISV are managed by the GSMA, so this 124 NID is managed by the GSMA. Whilst this specification currently 125 specifies only the IMEI NSS under the 'gsma' NID, additional NSS 126 under the 'gsma' NID may be specified in the future by the GSMA using 127 the procedure for URN NSS changes and additions (currently through 128 the publication of future Informational RFCs approved by IETF 129 conensus). 131 The IMEI is 15 decimal digits long and includes a Type Allocation 132 Code (TAC) of 8 decimal digits and a Serial Number (SNR) of 6 decimal 133 digits plus a Spare decimal digit. The TAC identifies the type of 134 the Mobile Equipment and is chosen from a range of values allocated 135 to the Mobile Equipment manufacturer in order to uniquely identify 136 the model of the Mobile Equipment. The SNR is an individual serial 137 number that uniquely identifies each Mobile Equipment within the TAC. 138 The Spare digit is used as a check digit to validate the IMEI and is 139 always set to the value 0 when transmitted by the Mobile Equipment. 141 The IMEISV is 16 decimal digits long and includes the TAC and SNR 142 same as for the IMEI but also a 2 decimal digit Software Version 143 Number (SVN) which is allocated by the Mobile Equipment manufacturer 144 to identify the software version of the Mobile Equipment. 146 The information here is meant to be a concise guide for those wishing 147 to use the IMEI and IMEISV as URNs. Nothing in this document should 148 be construed to override 3GPP Technical Specification (TS) 23.003 [2] 149 that specifies the IMEI and IMEISV. 151 The GSM Association (GSMA) is a global trade association representing 152 nearly 800 mobile phone operators across 220 territories and 153 countries of the world. The primary goals of the GSMA are to ensure 154 mobile phones and wireless services work globally and are easily 155 accessible. Further details about the GSMA role in allocating the 156 IMEI and the IMEISV and the IMEI and IMEISV allocation guidelines can 157 be found in GSMA Permanent Reference Document (PRD) TS 06 [3]. 159 2. Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC 2119 [4]. 165 3. Namespace Registration Template 167 Namespace ID: 'gsma' requested 169 Registration Information: 171 Registration version number: 1 173 Registration date: 2014-01-12 175 Declared registrant of the namespace: 176 Registering organization: 177 Name: GSM Association 178 Address: 1st Floor, Mid City Place, 179 71 High Holborn, London, England 181 Designated contact person: 182 Name: Paul Gosden 183 Coordinates: pgosden@gsma.com 185 Declaration of syntactic structure: 186 The identifier is expressed in American Standard Code for 187 Information Interchange (ASCII) characters and has a hierarchical 188 structure expressed using the augmented Backus-Naur Form (ABNF) 189 defined in RFC 5234 [5] as follows: 191 gsma-urn = "urn:" gsma-NID ":" gsma-NSS 192 gsma-NID = "gsma" 193 gsma-NSS = imei-specifier / future-gsma-specifier 194 imei-specifier = "imei:" ( imeival / ext-imei ) 195 [ ";" sw-version-param ] 196 [ ";" imei-version-param ] 197 ext-imei = gsma-defined-nonempty ;GSMA defined and 198 ;IETF consensus 199 ;required 200 sw-version-param = "svn=" software-version 201 imei-version-param = "vers=" imei-version-val 202 software-version = 2DIGIT 203 imei-version-val = DIGIT 204 future-gsma-specifier = future-specifier 205 *( ";" future-param ) 206 future-specifier = gsma-defined-nonempty ;GSMA defined and 207 ;IETF consensus 208 ;required 209 future-param = par-name [ EQUAL par-value ] 210 par-name = gsma-defined-nonempty 211 par-value = gsma-defined-nonempty 212 EQUAL = "=" 213 gsma-defined-nonempty = 1*gsma-urn-char 214 gsma-urn-char = ALPHA / DIGIT 215 / "-" / "." / "_" / "%" / ":" 217 A NSS for the IMEI is defined under the 'gsma' NID. 219 An IMEI is an identifier under the 'gsma' NID that uniquely 220 identifies the mobile devices used in the GSM, UMTS and LTE 221 networks. 223 The representation of the IMEI is defined in 3GPP TS 23.003 [2]. 224 To accurately represent an IMEI received in a cellular signaling 225 message (see 3GPP TS 24.008 [6]) as a URN, it is necessary to 226 convert the received binary (Binary Coded Decimal (BCD) encoded 227 bit sequence to a decimal digit string representation. Each field 228 has its representation for humans as a decimal digit string with 229 the most significant digit first. 231 The following augmented Backus-Naur Form (ABNF) includes the set 232 of core rules in RFC 5234 [5], and are not repeated here. 234 A URN with the 'imei' NSS contains one imeival, and its formal 235 definition is provided by the following ABNF (RFC 5234) [5]: 237 imeival = tac "-" snr "-" spare 238 tac = 8DIGIT 239 snr = 6DIGIT 240 spare = DIGIT 242 The , and can 243 comprise any ASCII characters compliant with the above ABNF. 245 The GSMA will take responsibility for the NSS 'imei'. 247 Additional NSS may be added for future identifiers needed by the 248 GSMA using the procedure for URN NSS changes and additions 249 (currently through the publication of future Informational RFCs 250 approved by IETF consensus). 252 Relevant ancillary documentation: 253 See IMEI Allocation and Approval Guidelines [3] and 3GPP TS 23.003 254 [2]. 256 Identifier uniqueness considerations: 257 Identifiers under the 'gsma' NID are defined and assigned by the 258 GSMA after ensuring that the URNs to be assigned are unique. 259 Uniqueness is achieved by checking against the IANA registry of 260 previously assigned names. 262 Procedures are in place to ensure that each IMEI is uniquely 263 assigned by the Mobile Equipment manufacturer so that it is 264 guaranteed to uniquely identify that particular Mobile Equipment. 265 Procedures are in place to ensure that each IMEISV is uniquely 266 assigned by the Mobile Equipment manufacturer so that it is 267 guaranteed to uniquely identify that particular Mobile Equipment 268 and the specific software version installed. 270 Identifier persistence considerations: 271 The GSMA is committed to maintaining uniqueness and persistence of 272 all resources identified by assigned URNs. 274 As the NID sought is 'gsma' and GSMA is the long standing acronym 275 for the trade association that represents the mobile phone 276 operators the URN should also persist indefinitely (at least as 277 long as there is a need for its use). The assignment process 278 guarantees that names are not reassigned. The binding between the 279 name and its resource is permanent. 281 The TAC and SNR portions of the IMEI and IMEISVs are permanently 282 stored in the Mobile Equipment so they remain persistent as long 283 as the Mobile Equipment exists. The process for TAC and SNR 284 assignment is documented in GSMA PRD TS 06[3] and the TAC and SNR 285 values once assigned are not re-assigned to other Mobile 286 Equipment. The SVN portion of the IMEISV may be modified by 287 software when new versions are installed but should be persistent 288 for the duration of the installation of that specific version of 289 software. 291 Process of identifier assignment: 292 GSMA will manage the (including 'imei'), and identifier resources to maintain uniqueness. 295 The process for IMEI and IMEISV assignment is documented in GSMA 296 PRD TS 06[3] 298 Process for identifier resolution: 299 Since the 'gsma' NSS is not currently globally resolvable, this is 300 not applicable. 302 Rules for Lexical Equivalence: 303 Two GSMA IMEI URNs are equivalent if they have the same 'imeival' 304 value, and the same parameter values in the same sequential order, 305 with the exception that the "vers=0" parameter is to be ignored 306 for the purposes of comparison. All of these comparisons are to 307 be case-insensitive. 309 Any identifier in 'gsma' NSS can be compared using the normal 310 mechanisms for percent-encoded UTF-8 strings (see RFC 3629 [7]). 312 Conformance with URN Syntax: 313 The string representation of the 'gsma' NID and of the IMEI NSS is 314 fully compatible with the URN syntax(see RFC 2141 [8]). 316 Validation Mechanism: 317 The IMEI can be validated using the mechanism defined in Annex B 318 of 3GPP TS 23.003 [2]. There is no mechanism defined to validate 319 the SVN field of the IMEISV. 321 Scope: GSMA URN is global in scope. 323 4. Specification 325 4.1. IMEI Parameters 327 The optional 'vers' parameter and the 'ext-imei' field in the ABNF 328 are included for extensibility of the IMEI NSS, for example if the 329 IMEI format is extended in the future (such as with additional digits 330 or using hex digits). In this case the 'vers' parameter would 331 contain a non zero value and the 'ext-imei' would be further defined 332 to represent the syntax of the extended IMEI format. A value of the 333 'vers' parameter equal to 0 or the absence of the 'vers' parameter 334 means the URN format is compliant with the format specified here. 335 Any change to the format specified here requires the use of the 336 procedure for URN NSS changes and additions (currently the 337 publication of a future Informational RFCs approved by IETF 338 consensus). The reason why use of the 'vers' parameter was chosen 339 for extensibility instead of defining a new NSS (e.g. 'imei2') is 340 that it is likely that many applications will only need to perform 341 string compares of the 'imeival'. So even if the format or length of 342 the 'imeival' changes in the future, such applications should 343 continue to work without having to be updated to understand a new 344 NSS. 346 draft-allen-dispatch-imei-urn-as-instanceid-13 [10] specifies how the 347 GSMA IMEI URN can be used as an instance ID as specified in RFC 5626 348 [11]. Any future value of the 'vers' parameter other than equal to 0 349 or the definition of additional parameters that are intended to be 350 used as part of an instance ID will require an update to 351 draft-allen-dispatch-imei-urn-as-instanceid-13 [10]. 353 For example: 354 urn:gsma:imei:90420156-025763-0;vers=0 356 The IMEISV is an identifier that uniquely identifies mobile devices 357 and their associated software versions used in the GSM, UMTS and LTE 358 networks. The representation of the IMEISV is defined in 3GPP TS 359 23.003 [2]. 361 To represent the IMEISV the URN parameter 'svn' is appended to the 362 GSMA IMEI URN and set equal to the decimal string representation of 363 the two software version number (svn) digits in the IMEISV and the 364 spare digit in the IMEI imeival is set to zero. 366 For example: 368 urn:gsma:imei:90420156-025763-0;svn=42 370 4.2. IMEI Format 372 4.2.1. Type Allocation Code (TAC) 374 The TAC is an 8 decimal digit value. The TAC identifies the type of 375 the Mobile Equipment and is chosen from a range of values allocated 376 to the Mobile Equipment manufacturer in order to uniquely identify 377 the model of the Mobile Equipment. 379 4.2.2. Serial Number (SNR) 381 The SNR is a 6 decimal digit value. The SNR is an individual serial 382 number that uniquely identifies each Mobile Equipment within the TAC. 384 4.2.3. Spare 386 The Spare is a single decimal digit. When the IMEI is stored on the 387 Mobile Equipment and network equipment it contains a value that is 388 used as a Check Digit and is intended to avoid manual reporting 389 errors, (e.g. when customers register stolen mobiles at the 390 operator's customer care desk) and also to help guard against the 391 possibility of incorrect entries being provisioned in the network 392 equipment. The Spare is always set to zero when transmitted by the 393 Mobile Equipment, (including when in the IMEI URN format). Annex B 394 of 3GPP TS 23.003 [2] specifies a mechanism for computing the actual 395 check digit in order to validate the TAC and SNR. 397 4.2.4. Binary Encoding 399 When included in a cellular signaling message the IMEI format is 15 400 decimal digits encoded in 8 octets using BCD as defined in 3GPP TS 401 24.008 [6]. Figure 1 is an abstract representation of a BCD encoded 402 IMEI stored in memory (the actual storage format in memory is 403 implementation specific). In Figure 1 the most significant digit of 404 the TAC is coded in the least significant bits of octet 1. The most 405 significant digit of the SNR is coded in the least significant bits 406 of octet 5. The Spare digit is coded in the least significant bits 407 of octet 8. When included in an identity element in a cellular 408 signaling message the most significant digit of the TAC is included 409 in digit 1 of the identity element in Figure 10.5.4 of 3GPP TS 24.008 410 [6]. 412 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits 413 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 414 | | | S| 415 | T | S | p| 416 | A | N | a| 417 | C | R | r| 418 | | | e| 419 +--+-----+-----+-----+--+--+-----+-----+--+--+ 420 1 2 3 4 5 6 7 8 Octets 421 Figure 1. IMEI Format 423 4.3. IMEISV Format 425 4.3.1. Type Allocation Code (TAC) 427 The TAC is the same as the TAC in the IMEI in Section 4.2.1. 429 4.3.2. Serial Number (SNR) 431 The SNR is the same as the SNR in the IMEI in Section 4.2.2. 433 4.3.3. Software Version Number (SVN) 435 The Software Version Number is allocated by the mobile device 436 manufacturer to identify the software version of the mobile device. 438 4.3.4. Binary Encoding 440 When included in a cellular signaling message the IMEISV format is 16 441 decimal digits encoded in 8 octets using BCD as defined in 3GPP TS 442 24.008 [6]. Figure 2 is an abstract representation of a BCD encoded 443 IMEISV stored in memory (the actual storage format in memory is 444 implementation specific). In Figure 2 the most significant digit of 445 the TAC is coded in the most significant bits of octet 1. The most 446 significant digit of the SNR is coded in the most significant bits of 447 octet 5. The most significant digit of the SVN is coded in the most 448 significant bits of octet 8. When included in an identity element in 449 a cellular signaling message the most significant digit of the TAC is 450 included in digit 1 of the identity element in Figure 10.5.4 of 3GPP 451 TS 24.008 [6]. 453 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits 454 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 455 | | | | 456 | T | S | S | 457 | A | N | V | 458 | C | R | N | 459 | | | | 460 +-----+-----+-----+-----+-----+-----+-----+-----+ 461 1 2 3 4 5 6 7 8 Octets 462 Figure 2. IMEISV Format 464 5. Community considerations 466 GSM, UMTS and LTE mobile devices will be interoperating with Internet 467 devices for a variety of voice and data services. To do this, they 468 need to make use of Internet protocols that will operate end to end 469 between devices in GSM/UMTS/LTE networks and those in the general 470 internet. Some of these protocols require the use of URN's as 471 identifiers. Within the GSM/UMTS/LTE networks, mobile devices are 472 identified by their IMEI or IMEISV. Internet users will need to be 473 able to receive and include the GSMA URN in various Internet protocol 474 elements to facilitate communication between pure internet based 475 devices and GSM/UMTS/LTE mobile devices. Thus the existence and 476 syntax of these namespaces needs to be available to the general 477 internet community and the namespace needs to be reserved with IANA 478 in order to guarantee uniqueness and prevent potential namespace 479 conflicts both within the internet and within GSM/UMTS/LTE networks. 480 Conversely, Internet implementations will not generally possess IMEI 481 identifiers. The identifiers generated by such implementations will 482 typically be URNs within namespaces other than 'gsma', and may, 483 depending on context, even be non-URN URIs. Implementations are 484 advised to be ready to process URIs other than 'gsma' namespaced 485 URNs, so as to aid in interoperability. 487 6. Namespace considerations 489 A URN was considered the most appropriate URI to represent the IMEI 490 and IMEISV as these identifiers may be used and transported similarly 491 to the Universally Unique Identifier (UUID) which is defined as a URN 492 in RFC 4122 [12]. Since specifications for protocols that are used 493 to transport device identifiers often require the device identifier 494 to be globally unique and in the URN format it is necessary that the 495 URN formats are defined to represent the IMEI and IMEISV. 497 7. IANA considerations 499 In accordance with BCP 66 (RFC 3406) [1], IANA is asked to register 500 the Formal URN Namespace 'gsma' in the Registry of URN Namespaces, 501 using the registration template presented in Section 3 of this 502 document. 504 8. Security and privacy considerations 506 IMEIs (but with the Spare value set to the value of the Check Digit) 507 are displayable on most mobile devices and in many cases are printed 508 on the case within the battery compartment. Anyone with brief 509 physical access to the mobile device can therefore easily obtain the 510 IMEI. Therefore IMEIs MUST NOT be used as security capabilities 511 (identifiers whose mere possession grants access). Unfortuantely 512 there are currently examples of some applications which are using the 513 IMEI for authorisation. Also some service provider's customer 514 service departments have been known to use knowledge of the IMEI as 515 "proof" that the caller is the legitimate owner of the mobile device. 516 Both of these are inappropriate uses of the IMEI. 518 Whilst the specific software version of the mobile device only 519 identifies the lower layer software that has undergone and passed 520 certification testing and not the operating system or application 521 software, the software version could identify software that is 522 vulnerable to attacks or is known to contain security holes. 523 Therfore the IMEISV MUST only be delivered to trusted entities within 524 carrier networks and not provided to the internet at large, as it 525 could help a malicious device identify that the mobile device is 526 running software that is known to be vulnerable to certain attacks. 527 This is a similar concern to the use of the User-Agent header in SIP 528 (Session Initiation Protocol) as specified in RFC 3261 [13]. 529 Therefore the IMEISV (that is, the IMEI URN with a 'svn' parameter) 530 MUST NOT be delivered to devices that are not trusted. IMEIs are 531 almost always as personally identifiable information and so these 532 URNs MUST be treated as personally identifiable information in all 533 cases. In order to prevent violating a user's privacy the IMEI URN 534 MUST NOT be included in messages intended to convey any level of 535 anonymity. 537 Since the IMEI is permanently assigned to the mobile device and is 538 not modified when the ownership of the mobile device changes, (even 539 upon a complete software reload of the device), the IMEI URN MUST NOT 540 be used as a user identifier or user address by an application. 541 Using the IMEI to identify a user or as a user address could result 542 in communications destined for a previous owner of a device being 543 received by the new device owner or allow the new device owner to 544 access information or services owned by the previous device owner. 546 Additionally, since the IMEI identifies the mobile device, it 547 potentially could be used to identify and track users for the 548 purposes of survellience and call data mining if sent in the clear. 550 Since the IMEI is personally identifiable information uses of the 551 IMEI URN with IETF protocols require a specification and IETF expert 552 review in order to ensure that the privacy concerns are appropriately 553 addressed. Protocols carrying the IMEI URN SHOULD at a minimum use 554 strongly hop-by-hop encrypted channels and that it is RECOMMENDED 555 that end-to-end encryption is used 557 Additional security considerations are specified in 3GPP TS 22.016 558 [9]. Specifically the IMEI is to be incorporated in a module which 559 is contained within the terminal. The IMEI SHALL NOT be changed 560 after the terminal's production process. It SHALL resist tampering, 561 i.e. manipulation and change, by any means (e.g. physical, electrical 562 and software). 564 9. Acknowledgements 566 This document draws heavily on the 3GPP work on Numbering, Addressing 567 and Identification in 3GPP TS 23.003 [2] and also on the style and 568 structure used in RFC 4122 [12]. The authors would like to thank 569 Cullen Jennings, Lisa Dusseault, Dale Worley, Ivo Sedlacek, Atle 570 Monrad, James Yu, Mary Barnes, Tim Bray, S. Moonesamy, Alexey 571 Melnikov, Martin Duerst, John Klensin, Paul Kyzivat, Christer 572 Holmberg, Barry Leiba, and Stephen Farrell for their help and 573 comments. 575 10. References 577 10.1. Normative references 579 [1] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 580 "Uniform Resource Names (URN) Namespace Definition Mechanisms", 581 BCP 66, RFC 3406, October 2002. 583 [2] 3GPP, "TS 23.003: Numbering, addressing and identification 584 (Release 8)", 3GPP 23.003, September 2012, 585 . 587 [3] GSMA Association, "IMEI Allocation and Approval Guidelines", 588 PRD TS 06 (DG06) version 6.0, July 2011, . 592 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 593 Levels", BCP 14, RFC 2119, March 1997. 595 [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax 596 Specifications: ABNF", STD 68, RFC 5234, January 2008. 598 [6] 3GPP, "TS 24.008: Mobile radio interface Layer 3 specification; 599 Core network protocols; Stage 3 (Release 8)", 3GPP 24.008, 600 June 2013, 601 . 603 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 604 STD 63, RFC 3629, November 2003. 606 [8] Moats, R., "URN Syntax", RFC 2141, May 1997. 608 [9] 3GPP, "TS 22.016: International Mobile station Equipment 609 Identities (IMEI) (Release 8)", 3GPP 22.016, December 2009, 610 . 612 10.2. Informative references 614 [10] Allen, A., "Using the International Mobile station Equipment 615 Identity(IMEI) URN as an Instance ID, work in progress", 616 Internet Draft draft-allen-dispatch-imei-urn-as-instanceid-13, 617 February 2014. 619 [11] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 620 Initiated Connections in the Session Initiation Protocol 621 (SIP)", RFC 5626, October 2009. 623 [12] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 624 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 626 [13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 627 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 628 Session Initiation Protocol", RFC 3261, June 2002. 630 Authors' Addresses 632 Michael Montemurro (editor) 633 Blackberry 634 4701 Tahoe Dr 635 Mississauga, Ontario L4W 0B4 636 Canada 638 Email: mmontemurro@blackberry.com 640 Andrew Allen 641 Blackberry 642 1200 Sawgrass Corporate Parkway 643 Sunrise, Florida 33323 644 USA 646 Email: aallen@blackberry.com 648 David McDonald 649 Eircom 651 Email: David.McDonald@meteor.ie 653 Paul Gosden 654 GSM Association 655 1st Floor, Mid City Place, 71 High Holborn, 656 London 657 England 659 Email: pgosden@gsma.com