<title abbrev="Using MEID "MEID URN as an Instance ID">
Using the Mobile Equipment Identity (MEID) Uniform Resource Name (URN) URN as an Instance ID
</title>
<--[rfced] Throughout the document, we note the use of "instance-id",
which is not uniform with the use in the title of "Instance ID".
The companion (draft-atarius-dispatch-meid-urn-18) uses "instance
ID" in running text. Past RFC titles (e.g., RFC 7255) appear to
use "Instance ID" and the same throughout the text.
We have updated to use "Instance ID" throughout the text instead of
"instance-id" to match past use in RFCs. Please let us know any
objections.
<-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->
<keyword>
example
</keyword>
<abstract>
<t>
This specification 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. Its 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.
This specification 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 draft-atarius-dispatch-meid-urn RFC YYYY <xref target="refs.draft-atarius-dispatch-meid-urn" "RFCYYYY" format="default" pageno="false"/> can be used as an instance-id Instance ID as specified in RFC 5626 <xref target="RFC5626" format="default" pageno="false"/> and also as used by RFC 5627 <xref target="RFC5627" format="default" pageno="false"/>.
</t>
<t>
RFC 5626 <xref target="RFC5626" format="default" pageno="false"/> specifies the "+sip.instance" Contact header field parameter that contains a URN as specified in RFC 8141 <xref target="RFC8141" format="default" pageno="false"/>. The instance-id Instance ID uniquely identifies a specific User Agent (UA) instance. This instance-id Instance ID is used as specified in RFC 5626 <xref target="RFC5626" format="default" pageno="false"/> so that the Session Initiation Protocol (SIP) registrar (as specified in RFC 3261 <xref target="RFC3261" format="default" pageno="false"/>) can recognize that the contacts from multiple registrations correspond to the same UA. The instance-id Instance ID is also used as specified by RFC 5627 <xref target="RFC5627" format="default" pageno="false"/> 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).
</t>
<t>
RFC 5626 <xref target="RFC5626" format="default" pageno="false"/> requires that a UA SHOULD create a Universally Unique Identifier (UUID) URN as specified in RFC 4122 <xref target="RFC4122" format="default" pageno="false"/> as its instance-id Instance ID but allows allow for the possibility to use other URN schemes.
RFC 5626 <xref target="RFC5626" format="default" pageno="false"/> states: RFC 5626 <xref target="RFC5626" format="default" pageno="false"/> states: <--begin DNE text - quote from RFC 5626; accuracy confirmed.-->
<list>
<t>
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.
"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."
</artwork>
</figure>
<t>
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 draft-atarius-dispatch-meid-urn RFC YYYY <xref target="refs.draft-atarius-dispatch-meid-urn" "RFCYYYY" format="default" pageno="false"/> specifies how the 3GPP2 MEID URN is constructed.
</t>
<t>
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 draft-atarius-dispatch-meid-urn RFC YYYY <xref target="refs.draft-atarius-dispatch-meid-urn" "RFCYYYY" format="default" pageno="false"/> and the definition of the MEID is contained in 3GPP2 S.R0048-A <xref target="refs.S.R0048-A" format="default" pageno="false"/>.
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 RFC 8174 BCP 14 <xref target="RFC2119" format="default" pageno="false"/> <xref target="RFC8174" format="default" pageno="false"/>. "false"/> when, and only when, they appear in all capitals, as shown here.
Mobile communication has been rapidly improved from low bit rate circuit switched system low-bit-rate circuit-switched systems to the higher data rate packet switched higher-data-rate packet-switched system. The packet switched packet-switched system has added the mobile capability of Internet Protocol (IP) connectivity and thereby connectivity; thereby, the IP Multimedia Subsystem (IMS) have made SIP based SIP-based calls and IP multimedia sessions from mobile devices possible.
</t>
<t>
3GPP2 defines High Rate Packet Data (HRPD) with high data rates 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, the transition to all IP, SIP based SIP-based IMS networks worldwide will take a great many years from the time of this writing and mobile devices will need to operate in both IP/SIP/IMS mode and circuit-switched mode.
<--[rfced] This sentence is difficult to parse. Please clarify the
use of "the transition to all IP". If the proposed text does not
capture your intent, please let us know how to update.
Original:
However, the transition to all IP, SIP
based IMS networks worldwide will take a great many years from the
time of this writing and mobile devices will need to operate in both
IP/SIP/IMS mode and circuitswitchedmode.
Perhaps:
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 circuit-switched mode mid-call or mid-session. To achieve this this, the mobile device needs to simultaneously communicate via both the IP/SIP/IMS domain and the circuit switched circuit-switched domain.
</t>
<t>
To meet this need need, 3GPP2 has specified how to maintain voice session voice-session continuity between the IP/SIP/IMS domain and the circuit switched domain in 3GPP2 S.X0042-B <xref target="refs.S.X0042-B" format="default" pageno="false"/>.
</t>
<--[rfced] This sentence is long and a bit convoluted. Please rephrase (and consider breaking into smaller sentences).
Original:
In order for the mobile device to access SIP/IMS voice service via
the circuit switched domain 3GPP2 has specified that Mobile Switching
Center (MSC) server either via IMS Media Gateway Control Function
(MGCF) or directly, if enhanced by SIP interface, controls mobile
voice call setup over the circuit switched radio access while
establishing the corresponding voice session in the core network
using SIP/IMS.
-->
<t>
In order for the mobile device to access SIP/IMS voice service via the circuit switched domain circuit-switched domain, 3GPP2 has specified that the Mobile Switching Center (MSC) server either via IMS Media Gateway Control Function (MGCF) or directly, if enhanced by SIP interface, controls 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 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 MEID; therefore, the instance-id Instance ID included by the MGCF or the MSC server, server and the instance-id Instance ID directly included by the mobile device both need to be based on the MEID.
</t>
<t>
Additionally in order to meet the above requirements, the same MEID that is obtained from the circuit switched 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 circuit-switched signaling originate from the same mobile device.
</t>
</section>
<--start here -->
<section title="3GPP2 Use Cases" numbered="true" toc="default">
<t>
<list style="numbers">
<t>
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 services, the SIP registrar can reject the registration. Thus Thus, a barred mobile device is prevented from accessing the network for non-emergency services.
</t>
<t>
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.
</t>
<t>
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 packet-switched domain to the circuit switched circuit-switched domain. In this scenario scenario, the MEID is the only identifier that is common to both domains. The Emergency Access Transfer Function (EATF) (EATF), which coordinates the call transfer between the domains, can thus use the MEID to identify that the circuit switched circuit-switched call is from the same mobile device that was in the emergency session in the packet switched packet-switched domain.
A single mode 3GPP2 User Agent Client (UAC) (UAC), which uses only 3GPP2 technology to transmit and receive voice or data data, has an MEID as specified in 3GPP2 S.R0048-A <xref target="refs.S.R0048-A" format="default" pageno="false"/>. 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 draft-atarius-dispatch-meid-urn RFC YYYY <xref target="refs.draft-atarius-dispatch-meid-urn" "RFCYYYY" format="default" pageno="false"/> when performing the registration procedures specified in RFC 5626 <xref target="RFC5626" format="default" pageno="false"/> or RFC 5627 <xref target="RFC5627" format="default" pageno="false"/> or (or any other procedure requiring the inclusion of the "sip.instance" media feature tag. tag).
</t>
<t>
A UAC MUST NOT use the 3GPP2 MEID URN as an instance-id Instance ID except when registering with a 3GPP2 IMS network. When a UAC is operating in IMS mode mode, it will obtain the domain of the carrier's IMS network to register with, from the Universal Integrated Circuit Card (UICC), pre-configuration, 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 carriers carrier's packet data network. When registering with a non-3GPP or non-3GPP2 IMS network network, a UAC SHOULD use a Universally Unique Identifier (UUID) UUID as an instance-id Instance ID as specified in RFC 5626 <xref target="RFC5626" format="default" pageno="false"/>.
</t>
<t>
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. <--[rfced] This sentence seems redundant. Note that a similar sentence occurs in the section that follows as well.
Original:
Regulatory requirements can
require the MEID to be provided to the
PSAP.
Perhaps:
Regulations can require that the MEID be provided to the PSAP.
-->
Regulatory requirements 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 a usage.
</t>
</section>
<section anchor="UAS" title="User Agent Server Procedures" numbered="true" toc="default">
<t>
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. Regulatory requirements 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 a usage.
In 3GPP/3GPP2 IMS 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 draft-atarius-dispatch-meid-urn RFC YYYY <xref target="refs.draft-atarius-dispatch-meid-urn" "RFCYYYY" format="default" pageno="false"/> "false"/>, the SIP registrar follows the procedures specified in RFC 5626 <xref target="RFC5626" format="default" pageno="false"/>. The MEID URN MAY be validated as described in the draft-atarius-dispatch-meid-urn RFC YYYY <xref target="refs.draft-atarius-dispatch-meid-urn" "RFCYYYY" format="default" pageno="false"/>. If the UA indicates that it supports the extension in RFC 5627 <xref target="RFC5627" format="default" pageno="false"/> and the SIP Registrar allocates a GRUU according to the procedures specified in RFC 5627 <xref target="RFC5627" format="default" pageno="false"/> "false"/>, the instance-id 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 <xref target="refs.TS-24.229" format="default" pageno="false"/> subclause 5.4.7A.2 specifies the mechanism for obfuscating the MEID when creating the "gr" parameter.
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 <xref target="RFC5626" format="default" pageno="false"/> states:
<--Begin DNE text; quote from RFC 5626; quote verified -->
<list>
<t>
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.
</t>
</list>
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 users privacy. RFC 5626 <xref target="RFC5626" format="default" pageno="false"/> 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". <--End DNE text -->
The same concerns apply when using the 3GPP2 MEID URN as an instance-id. 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 and 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 <xref target="RFC3680" format="default" pageno="false"/>. Additionally, an instance-id Instance ID containing the 3GPP2 MEID URN identifies a mobile device and not a user. The instance-id 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 <xref target="RFC5627" format="default" pageno="false"/> provides a means to create URIs that address the user at a specific device or User Agent. UA.
</t>
<t>
Entities that log the instance-id Instance ID need to protect them as personally identifiable information. Regulatory requirements can require carriers to log SIP MEIDs.
</t>
<t>
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 4346 8446 <xref target="RFC4346" "RFC8446" format="default" pageno="false"/> or any other security mechanism that provides equivalent levels of protection such as hop-by-hop security based upon IP Security (IPsec).
This document draws heavily on draft-atarius-dispatch-meid-urn <xref target="refs.draft-atarius-dispatch-meid-urn" format="default" pageno="false"/> and also on the style and structure used in RFC 7255 <xref target="RFC7255" format="default" pageno="false"/>.
</t>
<t>
The author thanks for the detailed comments, provided by Andrew Allen.
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]
This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications. [STANDARDS-TRACK]
The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars, and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep-alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its registrar. [STANDARDS-TRACK]
Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog. [STANDARDS-TRACK]
A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406.
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<-- <?rfc include="reference.RFC.4346"?>; obsoleted by RFC 8446 -->
<--[rfced] As RFC 4346 has been obsoleted by RFC 8446, we have updated the citation and corresponding reference entry to point to the latter document. Please let us know any objections. -->
This document specifies Version 1.1 version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, or and message forgery. [STANDARDS-TRACK]
</t>
<t>
This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.
This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.
</t>
<t>
This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]
This document defines a Uniform Resource Name (URN) namespace for the Third Generation Partnership Project 2 (3GPP2) and a Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID). The structure of an MEID is 15 hexadecimal digits long and is defined in the Third Generation Partnership Project 2 (3GPP2) (see [S.R0048-A]) to uniquely identify each individual mobile equipment (e.g., a handset or mobile phone). The 3GPP2 has a requirement to be able to use an MEID as a URN. This document fulfills that requirement.
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.
<--[rfced] We were unable to find a 2013 version of the S.X0042-B. We found S.X0042-A. Please point us to the version where we can check the reference. -->
This document draws heavily on RFC YYYY <xref target="RFCYYYY" format="default" pageno="false"/> and also on the style and structure used in RFC 7255 <xref target="RFC7255" format="default" pageno="false"/>.
</t>
<t>
The author thanks Andrew Allen for the detailed comments.