RFC 7255

🎀 Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID

Okay bestie, this is RFC 7255 🦋 It was published by the Internet Engineering Task Force (IETF) in May 2014 (ISSN 2070-1721), and it's written by A. Allen, Ed. from Blackberry. It's Informational, so it's published for information and isn't a standards-track spec. It doesn't list anything it obsoletes or updates, so it's a standalone doc. 💅

---

Abstract ✨

So this spec explains how the URN reserved for the Global System for Mobile Communications Association (GSMA) identities, and its sub-namespace for the International Mobile station Equipment Identity (IMEI), can be used as an instance-id. The goal is to meet the requirements for how a specific URN needs to be built and used in the +sip.instance Contact header field parameter for outbound behavior. Main character energy 🌸

Status of This Memo 📜

This document isn't an Internet Standards Track specification. It's published for informational purposes. 🧚

It's a product of the IETF, it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. Not everything the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 for the details. 🤓

If you want the current status, any errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc7255. 💖

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), as in effect on the date of publication. Please actually read those, because they spell out your rights and restrictions for this document. 🫶 Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License. 🔥

Table of Contents 🗂️

1. Introduction ....................................................2
2. Terminology .....................................................3
3. Background ......................................................3
4. 3GPP Use Cases ..................................................5
5. User Agent Client Procedures ....................................5
6. User Agent Server Procedures ....................................6
7. 3GPP SIP Registrar Procedures ...................................6
8. Security Considerations .........................................7
9. Acknowledgements ................................................7
10. References .....................................................8
   10.1. Normative References ......................................8
   10.2. Informative References ....................................8

---

1. Introduction ✨

Okay, so this spec defines how the URN reserved for the GSMA identities, and its IMEI sub-namespace, can be used as an instance-id. That URN is specified in RFC 7254 [1], and the instance-id it becomes is used as specified in RFC 5626 [2] and also as used by RFC 5627 [3]. 🦋

RFC 5626 [2] specifies the +sip.instance Contact header field parameter, which holds a URN as specified in RFC 2141 [4]. The instance-id uniquely identifies one specific User Agent (UA) instance. RFC 5626 [2] uses it so that the Session Initiation Protocol (SIP) registrar (as specified in RFC 3261 [9]) can recognize that contacts from multiple registrations belong to the same UA. RFC 5627 [3] also uses it to create Globally Routable User Agent URIs (GRUUs), which can be used to uniquely address a UA when several UAs are registered with the same Address of Record (AoR). It's giving organized 🍓

RFC 5626 [2] says a UA SHOULD create a Universally Unique Identifier (UUID) URN as specified in RFC 4122 [6] as its instance-id, but it also allows other URN schemes. The exact quote is: "If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior". This spec meets that requirement by saying how the GSMA IMEI URN gets used in the +sip.instance Contact header field parameter for outbound behavior, and RFC 7254 [1] says how the GSMA IMEI URN gets constructed. Iconic cross-referencing 💅

The GSMA IMEI is a URN for the IMEI, which is a globally unique identifier for mobile devices used in GSM, Universal Mobile Telecommunications System (UMTS), and 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) networks. The GSMA manages IMEI allocation so the values stay globally unique. The formatting of the IMEI as a URN is in RFC 7254 [1], the definition of the IMEI is in 3GPP TS 23.003 [10], and you can find more about the GSMA's role in allocating the IMEI, plus the allocation guidelines, in GSMA PRD TS.06 [11]. 🌸

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 RFC 2119 [7]. Those capital words are the official BCP 14 key words, so they carry their exact RFC 2119 meaning. 🧚

3. Background 🌈

GSM, UMTS, and LTE capable mobile devices make up 90% of the mobile devices in use worldwide. Every manufactured GSM, UMTS, or LTE mobile device gets an allocated IMEI that uniquely identifies that specific device. Among other things, in some regulatory jurisdictions the IMEI is used to spot a stolen mobile device that's being used, to help identify the subscription using it, and to prevent the device from being used at all. GSM started out as a circuit switched system, but enhancements like the General Packet Radio Service (GPRS) and UMTS added IP data capabilities. Along with the IP Multimedia Subsystem (IMS) definition, those made SIP-based calls and IP multimedia sessions possible from mobile devices. 📱✨

The latest enhancement, LTE, brings even higher data rates and gets rid of the circuit switched infrastructure completely. So with LTE networks, voice calls will need to run over IP and IMS. The switch to all-IP SIP-based IMS networks worldwide is going to take a great many years, though, and mobile devices, being mobile, need to work in both IP/SIP/IMS mode and circuit switched mode. That means calls and sessions need to be handed over between the two modes mid-call or mid-session. 🔥

It also gets messier: many existing GSM and UMTS radio access networks can't support IP/SIP/IMS-based voice services in a commercially acceptable way. So some sessions could have some media types delivered via IP/IMS at the same time that voice media is delivered over the circuit switched domain to the same mobile device. To make that work, the mobile device needs to be attached through both the IP/SIP/IMS domain and the circuit switched domain at once. 💜

To meet this need, the 3GPP has specified how to keep session continuity between the IP/SIP/IMS domain and the circuit switched domain in 3GPP TS 24.237 [12]. It has also specified in 3GPP TS 24.292 [13] how to reach IMS hosted services through both domains. 🦋

To let a mobile device reach SIP/IMS services over the circuit switched domain, the 3GPP specified a Mobile Switching Center (MSC) server enhanced for IMS Centralized Services (ICS) and a MSC server enhanced for Single Radio Voice Call Continuity (SR-VCC). These control mobile voice call setup over the circuit switched radio access, and they set up the matching voice session in the core network using SIP/IMS. To make that happen, the MSC server enhanced for ICS or the MSC server enhanced for SR-VCC does SIP registration on behalf of the mobile device, which is also directly registered with the IP/SIP/IMS domain at the same time. 🌟

The only mobile device identifier that can be carried over GSM/UMTS/LTE signaling is the IMEI. That's why the instance-id included by the MSC server enhanced for ICS or the MSC server enhanced for SR-VCC when acting for the mobile device, and the instance-id the mobile device includes directly, both need to be based on the IMEI. 💖

On top of that, the same IMEI that the MSC server gets from circuit switched signaling needs to be obtainable from SIP signaling too. That's how you can tell that the SIP signaling and the circuit switched signaling both come from the same mobile device. 🤓

For these reasons, 3GPP TS 24.237 [12] and 3GPP TS 24.292 [13] already specify using the GSMA IMEI URN namespace from RFC 7254 [1] as the instance-id. GSM/UMTS/LTE mobile devices, the MSC server enhanced for SR-VCC, and the MSC server enhanced for ICS all use it for SIP/IMS registrations and emergency-related SIP requests. 👑

4. 3GPP Use Cases 🚨

1. The mobile device includes its IMEI in the SIP REGISTER request so the SIP registrar can check the Equipment Identity Register (EIR) to see whether this mobile device is allowed to access the network for non-emergency services or is barred from doing so (for example, because the device was stolen). If the device isn't allowed on the network for non-emergency services, the SIP registrar can reject the registration, which stops a barred mobile device from getting onto the network for non-emergency services. 🙈
2. The mobile device includes its IMEI in SIP INVITE requests used to set up emergency sessions. That way the Public Safety Answering Point (PSAP) can get the IMEI of the mobile device for identification purposes, if regulations require it. 🆘
3. The IMEI that the mobile device includes in SIP INVITE requests for emergency sessions is also used for unauthenticated emergency sessions, so the network can identify the mobile device. This matters a lot if an unauthenticated emergency session gets handed over from the packet switched domain to the circuit switched domain. In that case the IMEI is the only identifier common to both domains, so the Emergency Access Transfer Function (EATF) in the network, which coordinates the transfer between domains in those cases, can use the IMEI to confirm that the circuit switched call is from the same mobile device that was in the emergency session in the packet switched domain. 🦋

5. User Agent Client Procedures ✨

okay bestie, this is where the UAC (User Agent Client) gets its homework 📝💅. A UAC that has an IMEI from 3GPP TS 23.003 [10] and is registering with a 3GPP IMS network MUST put the GSMA IMEI URN in the "sip.instance" media feature tag, using the syntax from RFC 7254 [1], whenever it does the registration stuff from RFC 5626 [2] or RFC 5627 [3], or any other procedure that needs "sip.instance" 🎀. The UAC SHOULD NOT include the optional svn parameter in that URN, because the software version can change after firmware upgrades and that would make a brand new instance-id 🙈. Future non-zero values of the vers parameter, or any new parameters meant to be part of an instance-id, will require an update to this RFC 🌸. The UAC MUST send character-by-character identical URNs in every registration according to RFC 5626 [2] 💖. So any optional or variable parts (like vers) MUST have the same values, in the same order, in every registration as in the first one 🫶.

A UAC MUST NOT use the GSMA IMEI URN as an instance-id, except when registering with a 3GPP IMS network 🦋. When it's in IMS mode, the UAC gets the domain of the network to register with from the UICC (aka the SIM card) 💳. That's the carrier's IMS network domain. It also gets the address of the IMS edge proxy, for sending the REGISTER request with the IMEI, from information elements in the Attach response when it connects to the carrier's packet data network 📡. When registering with a non-3GPP IMS network, a UAC SHOULD use a UUID as the instance-id, as specified in RFC 5626 [2] 🧚.

A UAC MUST NOT include the "sip.instance" media feature tag with the GSMA IMEI URN in the Contact header field of non-REGISTER requests, except when the request is related to an emergency session 🚨. Regulatory requirements can require the IMEI to be given to the PSAP 🙏. Any future exceptions to this rule will require publishing an RFC that explains how privacy isn't violated by that usage 🔐.

6. User Agent Server Procedures 🌈

A User Agent Server (UAS) MUST NOT include its "sip.instance" media feature tag with the GSMA IMEI URN in the Contact header field of responses, except when the response is related to an emergency session 💜. Regulatory requirements can require the IMEI to be given to the PSAP 🙏. Any future exceptions to this rule will require publishing an RFC that explains how privacy isn't violated by that usage 🔐.

7. 3GPP SIP Registrar Procedures 👑

In 3GPP IMS, when the SIP registrar gets a "sip.instance" media feature tag with the GSMA IMEI URN in the Contact header field, following the syntax from RFC 7254 [1], it follows the procedures from RFC 5626 [2] ✨. The IMEI URN MAY be validated as described in RFC 7254 [1] 🔍. If the UA says it supports the extension in RFC 5627 [3], and the SIP registrar allocates a public GRUU using the procedures from RFC 5627 [3], then the instance-id MUST be obfuscated when creating the gr parameter 🫣. That way the IMEI isn't revealed to other UAs when the public GRUU shows up in non-REGISTER requests and responses 🎭. 3GPP TS 24.229 [8], subclause 5.4.7A.2, describes how to obfuscate the IMEI when creating the gr parameter 🧩.

8. Security Considerations 🙈

Okay, this section is SERIOUS, bestie. Read it all 😭🚨

Because IMEIs, like other kinds of instance-ids, can be linked back to a user, they are personally identifiable information, and so they MUST be treated the same way as any other personally identifiable information 🔐. In particular, the "sip.instance" media feature tag with the GSMA IMEI URN MUST NOT be included in requests or responses meant to give any level of anonymity, because that could violate the user's privacy 💀. RFC 5626 [2] says that "One case where a UA could prefer to omit the "sip.instance" media feature tag is when it is making an anonymous request or some other privacy concern requires that the UA not reveal its identity". The same concerns apply when the GSMA IMEI URN is used as an instance-id 💅. Publishing the GSMA IMEI URN to networks the UA isn't attached to, or doesn't have a service relationship with, is a security breach 🚫. The "sip.instance" media feature tag MUST NOT be forwarded by the service provider's network elements when they forward requests or responses toward the destination UA 🛑. Also, an instance-id with the GSMA IMEI URN identifies a mobile device, not a user 📱. That instance-id MUST NOT be used alone as an address for a user, or as an identification credential for a user 🙅‍♀️. The GRUU mechanism in RFC 5627 [3] gives a way to create URIs that address the user at a specific device or User Agent 🎯.

Entities that log the instance-id need to protect it as personally identifiable information 🗂️. Regulatory requirements can require carriers to log SIP IMEIs 📜.

To protect the "sip.instance" media feature tag with the GSMA IMEI URN from being tampered with, REGISTER requests containing the GSMA IMEI URN MUST be sent using a security mechanism such as Transport Layer Security (TLS) (RFC 5246 [5]), or another security mechanism that gives equivalent protection, such as hop-by-hop security based on IPsec 🔒✨.

9. Acknowledgements 💖

The author would like to thank Paul Kyzivat, Dale Worley, Cullen Jennings, Adam Roach, Keith Drage, Mary Barnes, Peter Leis, James Yu, S. Moonesamy, Roni Even, and Tim Bray for reviewing this document and sharing their comments 🥰.

10. References 📚

10.1. Normative References

[1]  Montemurro, M., Ed., Allen, A., McDonald, D., and P.  Gosden, "A
     Uniform Resource Name Namespace for the Global System for Mobile
     Communications Association (GSMA) and the International Mobile
     station Equipment Identity (IMEI)", RFC 7254, May 2014.

[2]  Jennings, C., Mahy, R., and F. Audet, "Managing Client-
     Initiated Connections in the Session Initiation Protocol (SIP)",
     RFC 5626, October 2009.

[3]  Rosenberg, J., "Obtaining and Using Globally Routable User Agent
     URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC
     5627, October 2009.

[4]  Moats, R., "URN Syntax", RFC 2141, May 1997.

[5]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
     Protocol Version 1.2", RFC 5246, August 2008.

[6]  Leach, P., Mealling, M., and R. Salz, "A Universally Unique
     IDentifier (UUID) URN Namespace", RFC 4122, July 2005.

[7]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

[8]  3GPP, "IP multimedia call control protocol based on Session
     Initiation Protocol (SIP) and Session Description Protocol
     (SDP); Stage 3", 3GPP TS 24.229 (Release 8), March 2014,
     <ftp://ftp.3gpp.org/Specs/archive/24_series/ 24.229/>.

[9]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
     Peterson, J., Sparks, R., Handley, M., and E.  Schooler, "SIP:
     Session Initiation Protocol", RFC 3261, June 2002.

10.2. Informative References

[10] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003
     (Release 8), March 2014, <ftp://ftp.3gpp.org/Specs/
     archive/23_series/23.003/>.

[11] GSM Association, "IMEI Allocation and Approval Guidelines", PRD
     TS.06 (DG06) Version 6.0, July 2011,
     <http://www.gsma.com/newsroom/wp-content/uploads/2012/06/
     ts0660tacallocationprocessapproved.pdf>.

[12] 3GPP, "Mobile radio interface Layer 3 specification; Core
     network protocols; Stage 3", 3GPP TS 24.237 (Release 8),
     September 2013, <ftp://ftp.3gpp.org/Specs/archive/
     24_series/24.237/>.

[13] 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem
     Centralized Services (ICS); Stage 3", 3GPP TS 24.292 (Release
     8), December 2013, <ftp://ftp.3gpp.org/Specs/
     archive/24_series/24.292/>.

Author's Address 🎀

Andrew Allen (editor)
Blackberry
1200 Sawgrass Corporate Parkway
Sunrise, Florida  33323
USA

EMail: aallen@blackberry.com