diff options
Diffstat (limited to 'doc/rfc/rfc7255.txt')
| -rw-r--r-- | doc/rfc/rfc7255.txt | 507 |
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc7255.txt b/doc/rfc/rfc7255.txt new file mode 100644 index 0000000..9411fb9 --- /dev/null +++ b/doc/rfc/rfc7255.txt @@ -0,0 +1,507 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Allen, Ed. +Request for Comments: 7255 Blackberry +Category: Informational May 2014 +ISSN: 2070-1721 + + + Using the International Mobile station Equipment Identity (IMEI) + Uniform Resource Name (URN) as an Instance ID + +Abstract + + This specification defines how the Uniform Resource Name (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. Its + purpose is to fulfill the requirements for defining how a specific + URN needs to be constructed and used in the '+sip.instance' Contact + header field parameter for outbound behavior. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7255. + + + + + + + + + + + + + + + + + +Allen Informational [Page 1] + +RFC 7255 Using IMEI URN as an Instance ID May 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 + 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. 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 + + This specification defines how the Uniform Resource Name (URN) + reserved for the Global System for Mobile Communications Association + (GSMA) identities and its sub-namespace for the International Mobile + station Equipment Identity (IMEI) as specified in RFC 7254 [1] can be + used as an instance-id 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 that contains a URN as specified in RFC 2141 [4]. The + instance-id uniquely identifies a specific User Agent (UA) instance. + This instance-id is used as specified in RFC 5626 [2] so that the + Session Initiation Protocol (SIP) registrar (as specified in RFC 3261 + [9]) can recognize that the contacts from multiple registrations + correspond to the same UA. The instance-id is also used as specified + + + + + +Allen Informational [Page 2] + +RFC 7255 Using IMEI URN as an Instance ID May 2014 + + + by RFC 5627 [3] to create Globally Routable User Agent URIs (GRUUs) + that can be used to uniquely address a UA when multiple UAs are + registered with the same Address of Record (AoR). + + RFC 5626 [2] requires that a UA SHOULD create a Universally Unique + Identifier (UUID) URN as specified in RFC 4122 [6] as its instance-id + but allows for the possibility to use other URN schemes. Per + RFC 5626, "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 + specification meets this requirement by specifying how the GSMA IMEI + URN is used in the '+sip.instance' Contact header field parameter for + outbound behavior, and RFC 7254 [1] specifies how the GSMA IMEI URN + is constructed. + + The GSMA IMEI is a URN for the IMEI -- a globally unique identifier + that identifies mobile devices used in the GSM, Universal Mobile + Telecommunications System (UMTS), and 3rd Generation Partnership + Project (3GPP) Long Term Evolution (LTE) networks. The IMEI + allocation is managed by the GSMA to ensure that the IMEI values are + globally unique. Details of the formatting of the IMEI as a URN are + specified in RFC 7254 [1], and the definition of the IMEI is + contained in 3GPP TS 23.003 [10]. Further details about the GSMA's + role in allocating the IMEI, and the IMEI allocation guidelines, can + be found 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]. + +3. Background + + GSM, UMTS, and LTE capable mobile devices represent 90% of the mobile + devices in use worldwide. Every manufactured GSM, UMTS, or LTE + mobile device has an allocated IMEI that uniquely identifies this + specific mobile device. Among other things, in some regulatory + jurisdictions the IMEI is used to identify that a stolen mobile + device is being used, to help to identify the subscription that is + using it, and to prevent use of the mobile device. While GSM was + originally a circuit switched system, enhancements such as the + General Packet Radio Service (GPRS) and UMTS have added IP data + capabilities that, along with the definition of the IP Multimedia + Subsystem (IMS), have made SIP-based calls and IP multimedia sessions + from mobile devices possible. + + + + +Allen Informational [Page 3] + +RFC 7255 Using IMEI URN as an Instance ID May 2014 + + + The latest enhancement, known as LTE, introduces even higher data + rates and dispenses with the circuit switched infrastructure + completely. This means that with LTE networks, voice calls will need + to be conducted using IP and IMS. However, the transition to all IP + SIP-based IMS networks worldwide will take a great many years, and + mobile devices, being mobile, will need to operate in both IP/SIP/IMS + mode and circuit switched mode. This means that calls and sessions + will need to be handed over between IP/SIP/IMS mode and circuit + switched mode mid-call or mid-session. Also, since many existing GSM + and UMTS radio access networks are unable to support IP/SIP/IMS-based + voice services in a commercially acceptable manner, some sessions + could have some media types delivered via IP/IMS simultaneously with + voice media delivered via the circuit switched domain to the same + mobile device. To achieve this, the mobile device needs to be + simultaneously attached via both the IP/SIP/IMS domain and the + circuit switched domain. + + To meet this need, the 3GPP has specified how to maintain session + continuity between the IP/SIP/IMS domain and the circuit switched + domain in 3GPP TS 24.237 [12], and in 3GPP TS 24.292 [13] has + specified how to access IMS hosted services via both the IP/SIP/IMS + domain and the circuit switched domain. + + In order for the mobile device to access SIP/IMS services via the + circuit switched domain, the 3GPP has 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) + that control mobile voice call setup over the circuit switched radio + access while establishing the corresponding voice session in the core + network using SIP/IMS. To enable this, the MSC server enhanced for + ICS or the MSC server enhanced for SR-VCC performs SIP registration + on behalf of the mobile device, which is also simultaneously directly + registered with the IP/SIP/IMS domain. The only mobile device + identifier that is transportable using GSM/UMTS/LTE signaling is the + IMEI; therefore, the instance-id included by the MSC server enhanced + for ICS or the MSC server enhanced for SR-VCC when acting on behalf + of the mobile device, and the instance-id directly included by the + mobile device, both need to be based on the IMEI. + + Additionally, in order to meet the above requirements, the same IMEI + that is obtained from the circuit switched signaling by the MSC + server needs to be obtainable from SIP signaling so that it can be + determined that both the SIP signaling and circuit switched signaling + originate from the same mobile device. + + For these reasons, 3GPP TS 24.237 [12] and 3GPP TS 24.292 [13] + already specify the use of the URN namespace for the GSMA IMEI URN as + specified in RFC 7254 [1] as the instance-id used by GSM/UMTS/LTE + + + +Allen Informational [Page 4] + +RFC 7255 Using IMEI URN as an Instance ID May 2014 + + + mobile devices, the MSC server enhanced for SR-VCC, and the MSC + server enhanced for ICS, 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 that the SIP registrar can perform a check of the Equipment + Identity Register (EIR) to verify whether this mobile device is + allowed to access the network for non-emergency services or is + barred from doing so (e.g., because the device has been stolen). + If the mobile device is not allowed to access the network for + non-emergency services, the SIP registrar can reject the + registration and thus prevent a barred mobile device from + accessing the network for non-emergency services. + + 2. The mobile device includes its IMEI in SIP INVITE requests used + to establish emergency sessions. This is so that the Public + Safety Answering Point (PSAP) can obtain the IMEI of the mobile + device for identification purposes if required by regulations. + + 3. The IMEI that is included in SIP INVITE requests by the mobile + device and used to establish emergency sessions is also used in + cases of unauthenticated emergency sessions to enable the network + to identify the mobile device. This is especially important if + the unauthenticated emergency session is handed over from the + packet switched domain to the circuit switched domain. In this + scenario, the IMEI is the only identifier that is common to both + domains, so the Emergency Access Transfer Function (EATF) in the + network, which in such cases coordinates the transfer between + domains, can use the IMEI to determine 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 + + A User Agent Client (UAC) that has an IMEI as specified in 3GPP TS + 23.003 [10] and that is registering with a 3GPP IMS network MUST + include in the "sip.instance" media feature tag the GSMA IMEI URN + according to the syntax specified in RFC 7254 [1] when performing the + registration procedures specified in RFC 5626 [2] or RFC 5627 [3], or + any other procedure requiring the inclusion of the "sip.instance" + media feature tag. The UAC SHOULD NOT include the optional 'svn' + parameter in the GSMA IMEI URN in the "sip.instance" media feature + tag, since the software version can change as a result of upgrades to + the device firmware that would create a new instance-id. Any future + non-zero values of the 'vers' parameter, or the future definition of + additional parameters for the GSMA IMEI URN that are intended to be + + + +Allen Informational [Page 5] + +RFC 7255 Using IMEI URN as an Instance ID May 2014 + + + used as part of an instance-id, will require that an update be made + to this RFC. The UAC MUST provide character-by-character identical + URNs in each registration according to RFC 5626 [2]. Hence, any + optional or variable components of the URN (e.g., the 'vers' + parameter) MUST be presented with the same values and in the same + order in every registration as in the first registration. + + A UAC MUST NOT use the GSMA IMEI URN as an instance-id, except when + registering with a 3GPP IMS network. When a UAC is operating in IMS + mode, it will obtain from the Universal Integrated Circuit Card + (UICC) (commonly known as the SIM card) the domain of the network + with which to register. This is a carrier's IMS network domain. The + UAC will also obtain the address of the IMS edge proxy to send the + REGISTER request containing the IMEI using information elements in + the Attach response when it attempts to connect to the carrier's + packet data network. When registering with a non-3GPP IMS network, a + UAC SHOULD use a UUID as an instance-id as specified in RFC 5626 [2]. + + A UAC MUST NOT include the "sip.instance" media feature tag + containing 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 that the IMEI be + provided to the PSAP. Any future exceptions to this prohibition will + require the publication of an RFC that addresses how privacy is not + violated by such usage. + +6. User Agent Server Procedures + + A User Agent Server (UAS) MUST NOT include its "sip.instance" media + feature tag containing 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 that the IMEI be + provided to the PSAP. Any future exceptions to this prohibition will + require the publication of an RFC that addresses how privacy is not + violated by such usage. + +7. 3GPP SIP Registrar Procedures + + In 3GPP IMS, when the SIP registrar receives in the Contact header + field a "sip.instance" media feature tag containing the GSMA IMEI URN + according to the syntax specified in RFC 7254 [1] the SIP registrar + follows the procedures specified in RFC 5626 [2]. The IMEI URN MAY + be validated as described in RFC 7254 [1]. If the UA indicates that + it supports the extension in RFC 5627 [3] and the SIP registrar + allocates a public GRUU according to the procedures specified in + RFC 5627 [3], the instance-id MUST be obfuscated when creating the + 'gr' parameter in order not to reveal the IMEI to other UAs when the + + + + +Allen Informational [Page 6] + +RFC 7255 Using IMEI URN as an Instance ID May 2014 + + + public GRUU is included in non-REGISTER requests and responses. 3GPP + TS 24.229 [8] subclause 5.4.7A.2 specifies the mechanism for + obfuscating the IMEI when creating the 'gr' parameter. + +8. Security Considerations + + Because IMEIs, like other formats of instance-ids, can be correlated + to a user, they are personally identifiable information and therefore + MUST be treated in the same way as any other personally identifiable + information. In particular, the "sip.instance" media feature tag + containing the GSMA IMEI URN MUST NOT be included in requests or + responses intended to convey any level of anonymity, as this could + violate the user's privacy. RFC 5626 [2] states 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 using the GSMA IMEI URN as an instance-id. Publication of + the GSMA IMEI URN to networks to which the UA is not attached, or + with which the UA does not have a service relationship, is a security + breach, and the "sip.instance" media feature tag MUST NOT be + forwarded by the service provider's network elements when forwarding + requests or responses towards the destination UA. Additionally, an + instance-id containing the GSMA IMEI URN identifies a mobile device + and not a user. The instance-id containing the GSMA IMEI URN MUST + NOT be used alone as an address for a user or as an identification + credential for a user. The GRUU mechanism specified in RFC 5627 [3] + provides a means to create URIs that address the user at a specific + device or User Agent. + + Entities that log the instance-id need to protect them as personally + identifiable information. Regulatory requirements can require that + carriers log SIP IMEIs. + + In order to protect the "sip.instance" media feature tag containing + the GSMA IMEI URN from being tampered with, those 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 provides equivalent levels of protection such + as hop-by-hop security based upon 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 + providing their comments. + + + + + +Allen Informational [Page 7] + +RFC 7255 Using IMEI URN as an Instance ID May 2014 + + +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>. + + + + +Allen Informational [Page 8] + +RFC 7255 Using IMEI URN as an Instance ID May 2014 + + + [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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Allen Informational [Page 9] + |