From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8465.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc8465.txt (limited to 'doc/rfc/rfc8465.txt') diff --git a/doc/rfc/rfc8465.txt b/doc/rfc/rfc8465.txt new file mode 100644 index 0000000..aaad3d6 --- /dev/null +++ b/doc/rfc/rfc8465.txt @@ -0,0 +1,451 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Atarius, Ed. +Request for Comments: 8465 September 2018 +Category: Informational +ISSN: 2070-1721 + + + Using the Mobile Equipment Identity (MEID) URN as an Instance ID + +Abstract + + This document specifies how the Uniform Resource Name (URN) namespace + reserved for the Third Generation Partnership Project 2 (3GPP2) + identities and its Namespace Specific String (NSS) for the Mobile + Equipment Identity (MEID) can be used as an Instance ID. The purpose + of this Instance ID 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 candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8465. + +Copyright Notice + + Copyright (c) 2018 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 + (https://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. + + + +Atarius Informational [Page 1] + +RFC 8465 MEID URN as an Instance ID September 2018 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. 3GPP2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. User Agent Client Procedures . . . . . . . . . . . . . . . . 5 + 6. User Agent Server Procedures . . . . . . . . . . . . . . . . 5 + 7. 3GPP/3GPP2 SIP Registrar Procedures . . . . . . . . . . . . . 5 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 + 10.2. Informative References . . . . . . . . . . . . . . . . . 8 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 + +1. Introduction + + This document specifies how the Uniform Resource Name (URN) namespace + reserved for Third Generation Partnership Project 2 (3GPP2) + identities and its Namespace Specific String (NSS) for the Mobile + Equipment Identity (MEID) as specified in RFC 8464 [10] can be used + as an Instance ID as specified in RFC 5626 [4] and also as used by + RFC 5627 [5]. + + RFC 5626 [4] specifies the "+sip.instance" Contact header field + parameter that contains a URN as specified in RFC 8141 [6]. The + Instance ID uniquely identifies a specific User Agent (UA) instance. + This Instance ID is used as specified in RFC 5626 [4] so that the + Session Initiation Protocol (SIP) registrar (as specified in RFC 3261 + [2]) can recognize that the contacts from multiple registrations + correspond to the same UA. The Instance ID is also used as specified + by RFC 5627 [5] 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 [4] requires that a UA SHOULD create a Universally Unique + Identifier (UUID) URN as specified in RFC 4122 [9] as its Instance ID + but allow for the possibility to use other URN schemes. + + RFC 5626 [4] states: + + 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. + + + + +Atarius Informational [Page 2] + +RFC 8465 MEID URN as an Instance ID September 2018 + + + This specification meets this requirement by specifying how the 3GPP2 + MEID URN is used in the "+sip.instance" Contact header field + parameter for outbound behavior and RFC 8464 [10] specifies how the + 3GPP2 MEID URN is constructed. + + The 3GPP2 MEID URN is a URN for the MEID a globally unique identifier + that identifies mobile devices used in the 3GPP2 networks. The MEID + allocation is managed by the 3GPP2 to ensure that the MEID values are + globally unique. Details of the formatting of the MEID as a URN are + specified in RFC 8464 [10] and the definition of the MEID is + contained in 3GPP2 S.R0048-A [13]. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [1] [7] when, and only when, they appear in all capitals, as + shown here. + +3. Background + + Mobile communication has been rapidly improved from low-bit-rate + circuit-switched systems to the higher-data-rate packet-switched + system. The packet-switched system has added the mobile capability + of Internet Protocol (IP) connectivity; thereby, the IP Multimedia + Subsystem (IMS) have made SIP-based calls and IP multimedia sessions + from mobile devices possible. + + 3GPP2 defines High Rate Packet Data (HRPD) with high data rates, and + it dispenses with the 1x Circuit Switched (1xCS) infrastructure. + This means that with HRPD networks, voice calls will need to be + conducted using IP and IMS. However, SIP-based IMS networks will + take a great many years from the time of writing to transition to the + use of all IP; mobile devices 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. To achieve this, the mobile + device needs to simultaneously communicate via both the IP/SIP/IMS + domain and the circuit-switched domain. + + To meet this need, 3GPP2 has specified how to maintain voice-session + continuity between the IP/SIP/IMS domain and the circuit-switched + domain in 3GPP2 S.X0042-A [14]. + + In order for the mobile device to access SIP/IMS voice service via + the circuit-switched domain, 3GPP2 has specified that a Mobile + Switching Center (MSC) server will control mobile voice call setup + + + +Atarius Informational [Page 3] + +RFC 8465 MEID URN as an Instance ID September 2018 + + + over the circuit-switched radio access while establishing the + corresponding voice session in the core network using SIP/IMS. The + specified MSC server operates either via an IMS Media Gateway Control + Function (MGCF) or directly if it is enhanced by SIP interface. To + enable this, the mobile device MUST be identified in both the 1xCS + and IP/SIP/IMS domains. The only mobile device identifier that is + transportable using 1xCS signaling is the MEID; therefore, the + Instance ID included by the MGCF or the MSC server and the Instance + ID directly included by the mobile device both need to be based on + the MEID. + + Additionally in order to meet the above requirements, the same MEID + 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. + +4. 3GPP2 Use Cases + + 1. The mobile device includes its MEID in the SIP REGISTER request + so that the SIP registrar can perform a check of the Equipment + Identity Register (EIR) to verify if this mobile device is + allowed or barred from accessing the network for non-emergency + services (e.g., because it 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. Thus, a + barred mobile device is prevented from accessing the network for + non-emergency services. + + 2. The mobile device includes its MEID in SIP INVITE requests used + to establish emergency sessions. This is so that the Public + Safety Answering Point (PSAP) can obtain the MEID of the mobile + device for identification purposes if required by regulations. + + 3. The inclusion by the mobile device of its MEID in SIP INVITE + requests used to establish emergency sessions is also used in the + 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 MEID is the only identifier that is common to both + domains. The Emergency Access Transfer Function (EATF), which + coordinates the call transfer between the domains, can thus use + the MEID to identify that the circuit-switched call is from the + same mobile device that was in the emergency session in the + packet-switched domain. + + + + + +Atarius Informational [Page 4] + +RFC 8465 MEID URN as an Instance ID September 2018 + + +5. User Agent Client Procedures + + A single mode 3GPP2 User Agent Client (UAC), which uses only 3GPP2 + technology to transmit and receive voice or data, has an MEID as + specified in 3GPP2 S.R0048-A [13]. The single mode 3GPP2 UAC that is + registering with a 3GPP2 IMS network includes in the "sip.instance" + media feature tag the 3GPP2 MEID URN according to the syntax + specified in RFC 8464 [10] when performing the registration + procedures specified in RFC 5626 [4] or RFC 5627 [5] (or any other + procedure requiring the inclusion of the "sip.instance" media feature + tag). + + A UAC MUST NOT use the 3GPP2 MEID URN as an Instance ID except when + registering with a 3GPP2 IMS network. When a UAC is operating in IMS + mode, it will obtain the domain of the carrier's IMS network to + register with, from the Universal Integrated Circuit Card (UICC), + preconfiguration, or the network at the time of establishing the + Packet Data Protocol (PDP) context. These three methods are carrier + specific and are only performed by the carrier IMS networks. The UAC + will also obtain the address of the IMS edge proxy to send the + REGISTER request containing the MEID 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 or non-3GPP2 + IMS network, a UAC SHOULD use a UUID as an Instance ID as specified + in RFC 5626 [4]. + + A UAC MUST NOT include the "sip.instance" media feature tag + containing the 3GPP2 MEID URN in the Contact header field of non- + REGISTER requests except when the request is related to an emergency + session. Regulations can require that the MEID be provided to the + PSAP. Any future exceptions to this prohibition require 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 3GPP2 MEID URN in the Contact header field + of responses except when the response is related to an emergency + session. Regulations can require the MEID to be provided to the + PSAP. Any future exceptions to this prohibition require an RFC that + addresses how privacy is not violated by such usage. + +7. 3GPP/3GPP2 SIP Registrar Procedures + + In 3GPP/3GPP2 IMS, when the SIP Registrar receives in the Contact + header field a "sip.instance" media feature tag containing the 3GPP2 + MEID URN according to the syntax specified in RFC 8464 [10], the SIP + registrar follows the procedures specified in RFC 5626 [4]. The MEID + + + +Atarius Informational [Page 5] + +RFC 8465 MEID URN as an Instance ID September 2018 + + + URN MAY be validated as described in the RFC 8464 [10]. If the UA + indicates that it supports the extension in RFC 5627 [5] and the SIP + Registrar allocates a GRUU according to the procedures specified in + RFC 5627 [5], the Instance ID MUST be obfuscated when creating the + "gr" parameter in order not to reveal the MEID to other UAs when the + public GRUU is included in non-REGISTER requests and responses. 3GPP + TS 24.229 [11] subclause 5.4.7A.2 specifies the mechanism for + obfuscating the MEID when creating the "gr" parameter. + +8. IANA Considerations + + This document has no IANA actions. + +9. Security Considerations + + Since MEIDs, like other formats of Instance IDs, can be correlated to + a user, they are personally identifiable information and MUST be + treated as such. In particular, the "sip.instance" media feature tag + containing the 3GPP2 MEID 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 [4] states: + + 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 3GPP2 MEID URN as an Instance + ID. Publication of the 3GPP2 MEID URN to networks that the UA is not + attached to or the UA does not 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 forwarding + requests or responses towards the destination UA. The 3GPP2 MEID URN + MUST NOT accidentally leak in other contexts, such as and in + particular when application servers subscribe to user registration + state using the event package defined in RFC 3680 [3]. Additionally, + an Instance ID containing the 3GPP2 MEID URN identifies a mobile + device and not a user. The Instance ID containing the 3GPP2 MEID 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 [5] provides a means to create URIs that address the user + at a specific device or UA. + + Entities that log the Instance ID need to protect them as personally + identifiable information. Regulations can require carriers to log + SIP MEIDs. + + + + + +Atarius Informational [Page 6] + +RFC 8465 MEID URN as an Instance ID September 2018 + + + In order to protect the "sip.instance" media feature tag containing + the 3GPP2 MEID URN from being tampered with, those REGISTER requests + containing the 3GPP2 MEID URN MUST be sent using a security mechanism + such as Transport Layer Security (TLS) as specified in RFC 8446 [8] + or any other security mechanism that provides equivalent levels of + protection such as hop-by-hop security based upon IP Security + (IPsec). + +10. References + +10.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, + . + + [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, + June 2002, . + + [3] Rosenberg, J., "A Session Initiation Protocol (SIP) Event + Package for Registrations", RFC 3680, DOI 10.17487/RFC3680, + March 2004, . + + [4] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing + Client-Initiated Connections in the Session Initiation Protocol + (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, + . + + [5] Rosenberg, J., "Obtaining and Using Globally Routable User Agent + URIs (GRUUs) in the Session Initiation Protocol (SIP)", + RFC 5627, DOI 10.17487/RFC5627, October 2009, + . + + [6] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", + RFC 8141, DOI 10.17487/RFC8141, April 2017, + . + + [7] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key + Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, + . + + [8] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + + + + + +Atarius Informational [Page 7] + +RFC 8465 MEID URN as an Instance ID September 2018 + + + [9] Leach, P., Mealling, M., and R. Salz, "A Universally Unique + IDentifier (UUID) URN Namespace", RFC 4122, + DOI 10.17487/RFC4122, July 2005, + . + + [10] Atarius, R., "A URN Namespace for Device Identity and Mobile + Equipment Identity (MEID)", RFC 8464, DOI 10.17487/RFC8464, + September 2018, . + + [11] 3GPP, "IP multimedia call control protocol based on Session + Initiation Protocol (SIP) and Session Description Protocol + (SDP); Stage 3", 3GPP 24.229, Version 10.13.0, Release 10, + September 2013, + . + +10.2. Informative References + + [12] Allen, A., Ed., "Using the International Mobile station + Equipment Identity (IMEI) Uniform Resource Name (URN) as an + Instance ID", RFC 7255, DOI 10.17487/RFC7255, May 2014, + . + + [13] 3GPP2, "3G Mobile Equipment Identifier (MEID) - Stage 1, Version + 4.0", Stage 1, Version 4.0, 3GPP2 S.R0048-A, June 2005. + + [14] 3GPP2, "Voice Call Continuity between IMS and Circuit Switched + Systems - Version 1.0", Version 1.0, 3GPP2 S.X0042-A 1.0, August + 2008, . + +Acknowledgments + + This document draws heavily on RFC 8464 [10] and also on the style + and structure used in RFC 7255 [12]. + + The author thanks Andrew Allen for the detailed comments. + +Author's Address + + Roozbeh Atarius (editor) + + Email: ratarius@motorola.com + + + + + + + + + +Atarius Informational [Page 8] + -- cgit v1.2.3