summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8465.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8465.txt')
-rw-r--r--doc/rfc/rfc8465.txt451
1 files changed, 451 insertions, 0 deletions
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,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [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, <https://www.rfc-editor.org/info/rfc3261>.
+
+ [3] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
+ Package for Registrations", RFC 3680, DOI 10.17487/RFC3680,
+ March 2004, <https://www.rfc-editor.org/info/rfc3680>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc5626>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc5627>.
+
+ [6] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)",
+ RFC 8141, DOI 10.17487/RFC8141, April 2017,
+ <https://www.rfc-editor.org/info/rfc8141>.
+
+ [7] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
+ Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
+ <https://www.rfc-editor.org/info/rfc8174>.
+
+ [8] Rescorla, E., "The Transport Layer Security (TLS) Protocol
+ Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+ <https://www.rfc-editor.org/info/rfc8446>.
+
+
+
+
+
+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,
+ <https://www.rfc-editor.org/info/rfc4122>.
+
+ [10] Atarius, R., "A URN Namespace for Device Identity and Mobile
+ Equipment Identity (MEID)", RFC 8464, DOI 10.17487/RFC8464,
+ September 2018, <https://www.rfc-editor.org/info/rfc8464>.
+
+ [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,
+ <ftp://ftp.3gpp.org/Specs/archive/24_series/24.229/>.
+
+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,
+ <https://www.rfc-editor.org/info/rfc7255>.
+
+ [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, <https://www.3gpp2.org/Public_html/Specs/
+ X.S0042-A_v1.0_080904.pdf>.
+
+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]
+