idnits 2.17.1 draft-atarius-dispatch-meid-urn-as-instanceid-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 3, 2018) is 2298 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4346 (ref. '6') (Obsoleted by RFC 5246) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dispatch Working Group R. Atarius, Ed. 3 Internet-Draft January 3, 2018 4 Intended status: Informational 5 Expires: July 7, 2018 7 Using the Mobile Equipment Identity (MEID) Uniform Resource Name (URN) 8 as an Instance ID 9 draft-atarius-dispatch-meid-urn-as-instanceid-06 11 Abstract 13 This specification specifies how the Uniform Resource Name (URN) 14 namespace reserved for the Third Generation Partnership Project 2 15 (3GPP2) identities and its Namespace Specific String (NSS) for the 16 Mobile Equipment Identity (MEID) can be used as an instance-id. Its 17 purpose is to fulfill the requirements for defining how a specific 18 URN needs to be constructed and used in the "+sip.instance" Contact 19 header field parameter for outbound behavior. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 7, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. 3GPP2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. User Agent Client Procedures . . . . . . . . . . . . . . . . 5 60 6. User Agent Server Procedures . . . . . . . . . . . . . . . . 5 61 7. 3GPP/3GPP2 SIP Registrar Procedures . . . . . . . . . . . . . 6 62 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 63 9. Security considerations . . . . . . . . . . . . . . . . . . . 6 64 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 11.1. Normative references . . . . . . . . . . . . . . . . . . 7 67 11.2. Informative references . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 This specification specifies how the Uniform Resource Name (URN) 73 namespace reserved for Third Generation Partnership Project 2 (3GPP2) 74 identities and its Namespace Specific String (NSS) for the Mobile 75 Equipment Identity (MEID) as specified in draft-atarius-dispatch- 76 meid-urn [8] can be used as an instance-id as specified in RFC 5626 77 [2] and also as used by RFC 5627 [3]. 79 RFC 5626 [2] specifies the "+sip.instance" Contact header field 80 parameter that contains a URN as specified in RFC 8141 [4]. The 81 instance-id uniquely identifies a specific User Agent (UA) instance. 82 This instance-id is used as specified in RFC 5626 [2] so that the 83 Session Initiation Protocol (SIP) registrar (as specified in RFC 3261 84 [1]) can recognize that the contacts from multiple registrations 85 correspond to the same UA. The instance-id is also used as specified 86 by RFC 5627 [3] to create Globally Routable User Agent URIs (GRUUs) 87 that can be used to uniquely address a UA when multiple UAs are 88 registered with the same Address of Record (AoR). 90 RFC 5626 [2] requires that a UA SHOULD create a Universally Unique 91 Identifier (UUID) URN as specified in RFC 4122 [7] as its instance-id 92 but allows for the possibility to use other URN schemes. 94 RFC 5626 [2] states: 96 "If a URN scheme other than UUID is used, the UA MUST only 97 use URNs for which an RFC (from the IETF stream) defines how 98 the specific URN needs to be constructed and used in the 99 "+sip.instance" Contact header field parameter for outbound 100 behavior." 102 This specification meets this requirement by specifying how the 3GPP2 103 MEID URN is used in the "+sip.instance" Contact header field 104 parameter for outbound behavior and draft-atarius-dispatch-meid-urn 105 [8] specifies how the 3GPP2 MEID URN is constructed. 107 The 3GPP2 MEID URN is a URN for the MEID a globally unique identifier 108 that identifies mobile devices used in the 3GPP2 networks. The MEID 109 allocation is managed by the 3GPP2 to ensure that the MEID values are 110 globally unique. Details of the formatting of the MEID as a URN are 111 specified in draft-atarius-dispatch-meid-urn [8] and the definition 112 of the MEID is contained in 3GPP2 S.R0048-A [11]. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 8174 [5]. 120 3. Background 122 Mobile communication has been rapidly improved from low bit rate 123 circuit switched system to the higher data rate packet switched 124 system. The packet switched system has added mobile capability of 125 Internet Protocol (IP) connectivity and thereby the IP Multimedia 126 Subsystem (IMS) have made SIP based calls and IP multimedia sessions 127 from mobile devices possible. 129 3GPP2 defines High Rate Packet Data (HRPD) with high data rates and 130 it dispenses with the 1x Circuit Switched (1xCS) infrastructure. 131 This means that with HRPD networks, voice calls will need to be 132 conducted using IP and IMS. However, the transition to all IP, SIP 133 based IMS networks worldwide will take a great many years from the 134 time of this writing and mobile devices will need to operate in both 135 IP/SIP/IMS mode and circuit switched mode. This means that calls and 136 sessions will need to be handed over between IP/SIP/IMS mode and 137 circuit switched mode mid-call or mid-session. To achieve this the 138 mobile device needs to simultaneously communicate via both the 139 IP/SIP/IMS domain and the circuit switched domain. 141 To meet this need 3GPP2 has specified how to maintain voice session 142 continuity between the IP/SIP/IMS domain and the circuit switched 143 domain in 3GPP2 S.X0042-B [12]. 145 In order for the mobile device to access SIP/IMS voice service via 146 the circuit switched domain 3GPP2 has specified that Mobile Switching 147 Center (MSC) server either via IMS Media Gateway Control Function 148 (MGCF) or directly, if enhanced by SIP interface, controls mobile 149 voice call setup over the circuit switched radio access while 150 establishing the corresponding voice session in the core network 151 using SIP/IMS. To enable this, the mobile device MUST be identified 152 in both 1xCS and IP/SIP/IMS domains. The only mobile device 153 identifier that is transportable using 1xCS signaling is the MEID 154 therefore the instance-id included by the MGCF or the MSC server, and 155 the instance-id directly included by the mobile device both need to 156 be based on the MEID. 158 Additionally in order to meet the above requirements, the same MEID 159 that is obtained from the circuit switched signaling by the MSC 160 server needs to be obtainable from SIP signaling so that it can be 161 determined that both the SIP signaling and circuit switched signaling 162 originate from the same mobile device. 164 4. 3GPP2 Use Cases 166 1. The mobile device includes its MEID in the SIP REGISTER request 167 so that the SIP registrar can perform a check of the Equipment 168 Identity Register (EIR) to verify if this mobile device is allowed or 169 barred from accessing the network for non-emergency services (e.g., 170 because it has been stolen). If the mobile device is not allowed to 171 access the network for non-emergency services the SIP registrar can 172 reject the registration. Thus a barred mobile device is prevented 173 from accessing the network for non-emergency services. 175 2. The mobile device includes its MEID in SIP INVITE requests used 176 to establish emergency sessions. This is so that the Public Safety 177 Answering Point (PSAP) can obtain the MEID of the mobile device for 178 identification purposes if required by regulations. 180 3. The inclusion by the mobile device of its MEID in SIP INVITE 181 requests used to establish emergency sessions is also used in the 182 cases of unauthenticated emergency sessions to enable the network to 183 identify the mobile device. This is especially important if the 184 unauthenticated emergency session is handed over from the packet 185 switched domain to the circuit switched domain. In this scenario the 186 MEID is the only identifier that is common to both domains. The 187 Emergency Access Transfer Function (EATF) which coordinates the call 188 transfer between the domains, can thus use the MEID to identify that 189 the circuit switched call is from the same mobile device that was in 190 the emergency session in the packet switched domain. 192 5. User Agent Client Procedures 194 A single mode 3GPP2 User Agent Client (UAC) which uses only 3GPP2 195 technology to transmit and receive voice or data has an MEID as 196 specified in 3GPP2 S.R0048-A [11]. The single mode 3GPP2 UAC that is 197 registering with a 3GPP2 IMS network includes in the "sip.instance" 198 media feature tag the 3GPP2 MEID URN according to the syntax 199 specified in draft-atarius-dispatch-meid-urn [8] when performing the 200 registration procedures specified in RFC 5626 [2] or RFC 5627 [3] or 201 any other procedure requiring the inclusion of the "sip.instance" 202 media feature tag. 204 A UAC MUST NOT use the 3GPP2 MEID URN as an instance-id except when 205 registering with a 3GPP2 IMS network. When a UAC is operating in IMS 206 mode it will obtain the domain of the carrier's IMS network to 207 register with, from the Universal Integrated Circuit Card (UICC), 208 pre-configuration, or the network at the time of establishing the 209 Packet Data Protocol (PDP) context. These three methods are carrier 210 specific and are only performed by the carrier IMS networks. The UAC 211 will also obtain the address of the IMS edge proxy to send the 212 REGISTER request containing the MEID using information elements in 213 the Attach response when it attempts to connect to the carriers 214 packet data network. When registering with a non-3GPP or non-3GPP2 215 IMS network a UAC SHOULD use a Universally Unique Identifier (UUID) 216 as an instance-id as specified in RFC 5626 [2]. 218 A UAC MUST NOT include the "sip.instance" media feature tag 219 containing the 3GPP2 MEID URN in the Contact header field of non- 220 REGISTER requests except when the request is related to an emergency 221 session. Regulatory requirements can require the MEID to be provided 222 to the PSAP. Any future exceptions to this prohibition require an 223 RFC that addresses how privacy is not violated by such a usage. 225 6. User Agent Server Procedures 227 A User Agent Server (UAS) MUST NOT include its "sip.instance" media 228 feature tag containing the 3GPP2 MEID URN in the Contact header field 229 of responses except when the response is related to an emergency 230 session. Regulatory requirements can require the MEID to be provided 231 to the PSAP. Any future exceptions to this prohibition require an 232 RFC that addresses how privacy is not violated by such a usage. 234 7. 3GPP/3GPP2 SIP Registrar Procedures 236 In 3GPP/3GPP2 IMS when the SIP Registrar receives in the Contact 237 header field a "sip.instance" media feature tag containing the 3GPP2 238 MEID URN according to the syntax specified in draft-atarius-dispatch- 239 meid-urn [8] the SIP registrar follows the procedures specified in 240 RFC 5626 [2]. The MEID URN MAY be validated as described in the 241 draft-atarius-dispatch-meid-urn [8]. If the UA indicates that it 242 supports the extension in RFC 5627 [3] and the SIP Registrar 243 allocates a GRUU according to the procedures specified in RFC 5627 244 [3] the instance-id MUST be obfuscated when creating the "gr" 245 parameter in order not to reveal the MEID to other UAs when the 246 public GRUU is included in non-REGISTER requests and responses. 3GPP 247 TS 24.229 [9] subclause 5.4.7A.2 specifies the mechanism for 248 obfuscating the MEID when creating the "gr" parameter. 250 8. IANA considerations 252 This document defines no items requiring action by IANA. 254 9. Security considerations 256 Since MEIDs like other formats of instance-ids can be correlated to a 257 user, they are personally identifiable information and MUST be 258 treated as such. In particular, the "sip.instance" media feature tag 259 containing the 3GPP2 MEID URN MUST NOT be included in requests or 260 responses intended to convey any level of anonymity, as this could 261 violate the users privacy. RFC 5626 [2] states "One case where a UA 262 could prefer to omit the "sip.instance" media feature tag is when it 263 is making an anonymous request or some other privacy concern requires 264 that the UA not reveal its identity". The same concerns apply when 265 using the 3GPP2 MEID URN as an instance-id. Publication of the 3GPP2 266 MEID URN to networks that the UA is not attached to or the UA does 267 not have a service relationship with is a security breach and the 268 "sip.instance" media feature tag MUST NOT be forwarded by the service 269 provider's network elements when forwarding requests or responses 270 towards the destination UA. Additionally, an instance-id containing 271 the 3GPP2 MEID URN identifies a mobile device and not a user. The 272 instance-id containing the 3GPP2 MEID URN MUST NOT be used alone as 273 an address for a user or as an identification credential for a user. 274 The GRUU mechanism specified in RFC 5627 [3] provides a means to 275 create URIs that address the user at a specific device or User Agent. 277 Entities that log the instance-id need to protect them as personally 278 identifiable information. Regulatory requirements can require 279 carriers to log SIP MEIDs. 281 In order to protect the "sip.instance" media feature tag containing 282 the 3GPP2 MEID URN from being tampered with, those REGISTER requests 283 containing the 3GPP2 MEID URN MUST be sent using a security mechanism 284 such as Transport Layer Security (TLS) as specified in RFC 4346 [6] 285 or any other security mechanism that provides equivalent levels of 286 protection such as hop-by-hop security based upon IP Security 287 (IPsec). 289 10. Acknowledgments 291 This document draws heavily on draft-atarius-dispatch-meid-urn [8] 292 and also on the style and structure used in RFC 7255 [10]. 294 The author thanks for the detailed comments, provided by Andrew 295 Allen. 297 11. References 299 11.1. Normative references 301 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 302 A., Peterson, J., Sparks, R., Handley, M., and E. 303 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 304 DOI 10.17487/RFC3261, June 2002, 305 . 307 [2] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 308 "Managing Client-Initiated Connections in the Session 309 Initiation Protocol (SIP)", RFC 5626, 310 DOI 10.17487/RFC5626, October 2009, 311 . 313 [3] Rosenberg, J., "Obtaining and Using Globally Routable User 314 Agent URIs (GRUUs) in the Session Initiation Protocol 315 (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, 316 . 318 [4] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 319 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 320 . 322 [5] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 323 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 324 May 2017, . 326 [6] Dierks, T. and E. Rescorla, "The Transport Layer Security 327 (TLS) Protocol Version 1.1", RFC 4346, 328 DOI 10.17487/RFC4346, April 2006, 329 . 331 [7] Leach, P., Mealling, M., and R. Salz, "A Universally 332 Unique IDentifier (UUID) URN Namespace", RFC 4122, 333 DOI 10.17487/RFC4122, July 2005, 334 . 336 [8] Atarius, R., "A Uniform Resource Name Namespace for the 337 Device Identity and the Mobile Equipment Identity (MEID)", 338 Internet Draft draft-atarius-dispatch-meid-urn, January 339 2018. 341 [9] 3GPP, "TS 24.229: IP multimedia call control protocol 342 based on Session Initiation Protocol (SIP) and Session 343 Description Protocol (SDP); Stage 3 (Release 10)", 344 3GPP 24.229, September 2013, . 347 11.2. Informative references 349 [10] Allen, A., Ed., "Using the International Mobile station 350 Equipment Identity (IMEI) Uniform Resource Name (URN) as 351 an Instance ID", RFC 7255, DOI 10.17487/RFC7255, May 2014, 352 . 354 [11] 3GPP2, "S.R0048-A: 3G Mobile Equipment Identifier (MEID) - 355 Stage 1, Version 4.0", 3GPP2 S.R0048-A 4.0, June 2005. 357 [12] 3GPP2, "S.X0042-B: Voice Call Continuity between IMS and 358 Circuit Switched Systems - Version 1.0", 3GPP2 S.X0042-B 359 1.0, December 2013. 361 Author's Address 363 Roozbeh Atarius (editor) 365 Email: r_atarius@yahoo.com