idnits 2.17.1 draft-goix-appsawg-enum-acct-uri-07.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 date (June 18, 2014) is 3599 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC2617' is defined on line 307, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 appsawg L. Goix 3 Internet-Draft Telecom Italia 4 Intended status: Experimental K. Li 5 Expires: December 20, 2014 Huawei Technologies 6 June 18, 2014 8 ENUM Service Registration for acct URI 9 draft-goix-appsawg-enum-acct-uri-07 11 Abstract 13 This document registers a Telephone Number Mapping (ENUM) service for 14 'acct:' URIs (Uniform Resource Identifiers). 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 20, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3.1. Reverse phone lookup . . . . . . . . . . . . . . . . . . 2 54 3.2. Routing of mobile social communications . . . . . . . . . 3 55 4. IANA Registration . . . . . . . . . . . . . . . . . . . . . . 3 56 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 6. DNS Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 10.2. Informative References . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 ENUM (E.164 Number Mapping, [RFC6116]) is a system that uses DNS 69 (Domain Name Service, [RFC1034]) to translate telephone numbers, such 70 as '+44 1632 960123', into URIs (Uniform Resource Identifiers, 71 [RFC3986]), such as 'acct:user@example.com'. ENUM exists primarily 72 to facilitate the interconnection of systems that rely on telephone 73 numbers with those that use URIs to identify resources. 75 [I-D.ietf-appsawg-acct-uri] defines the 'acct' URI scheme as a way to 76 identify a user's account at a service provider. 78 This document registers an Enumservice for advertising acct URI 79 information associated with an E.164 number. 81 2. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 3. Use cases 89 3.1. Reverse phone lookup 91 In this example, an address book application could issue ENUM queries 92 looking for 'acct' URIs corresponding to phone numbers. This could 93 be used to display the account identifier as well as an icon based on 94 the host (domain) portion of that URI. 96 Similarly, an endpoint could trigger this resolution process during 97 inbound and/or outbound calls to discover an account associated with 98 the remote party. 100 In general the provision of an ENUM record to map a phone number into 101 an account may be useful for businesses or professional workers to 102 identify themselves publicly (in a similar way as vCard enum 103 records). 105 3.2. Routing of mobile social communications 107 The Open Mobile Alliance (OMA) develops mobile service enabler 108 specifications, which support the creation of interoperable end-to- 109 end mobile services independent of the underlying wireless platforms, 110 such as GSM (Global System for Mobile communications), UMTS 111 (Universal Mobile Telecommunications System) and LTE (Long Term 112 Evolution) mobile networks. The OMA Social Network Web (SNeW) 113 Enabler Release [OMA-SNeW] has introduced a number of Social 114 Networking functionalities for mobile subscribers identified by their 115 MSISDN (Mobile Subscriber Integrated Services Digital Network number, 116 a number uniquely identifying a subscription in a mobile network), 117 amongst which is the ability to follow each other's social activities 118 across service providers. 120 Such functionality requires the global resolution of the MSISDN to 121 the corresponding account and provider, in an analogous way as MMS 122 routing, to identify the target endpoint for the related messages. 123 Although alternatives solutions exist (e.g. based on mobile network 124 operations and/or proprietary lookup techniques), ENUM provides a 125 globally accessible mechanism for enabling resolution from network 126 entities on behalf of an endpoint, or from an endpoint itself. 128 For example, a user of a service provider could request to follow the 129 social activities of user '+44 1632 960123'. The home SNEW Server of 130 the former user could perform an ENUM query to identify the 'acct' 131 URI corresponding to that phone number. Based on the resulting URI, 132 the server could then identify the SNEW Server of the target user and 133 route the original user's request to the appropriate endpoint. 135 A similar mechanism can apply to other types of social networking- 136 related messages or other communications targeted to a mobile 137 subscriber. 139 4. IANA Registration 141 As defined in [RFC6117], the following is a template covering 142 information needed for the registration of the Enumservice specified 143 in this document: 145 146 Application-Based, Ancillary 147 acct 148 acct 149 150 151 This Enumservice indicates that the resource 152 can be identified by the associated 'acct' URI 153 . 154 155 156 157 For DNS considerations in avoiding loops when 158 searching for "acct" NAPTRs, 159 see , 160 Section 6. 161 For security considerations, 162 see , 163 Section 7. 164 165 COMMON 166 167 168 169 170 171 172 174 175 176 Laurent-Walter Goix 177 Telecom Italia 178 mailto:laurentwalter.goix@telecomitalia.it 179 2014-06-18 180 181 183 [Note for RFC-Editor: Please replace any instance of rfcTHIS with the 184 RFC number of this document before publication] 186 5. Examples 188 The following is an example of the use of the Enumservice registered 189 by this document in a NAPTR resource record for phone number +44 1632 190 960123. 192 $ORIGIN 3.2.1.0.6.9.2.3.6.1.4.4.e164.arpa. 194 IN NAPTR 10 100 "u" "E2U+acct" "!^.*$!acct:441632960123@foo.com!" . 196 IN NAPTR 10 101 "u" "E2U+acct" "!^.*$!acct:john.doe@example.com!" . 198 Note that in the first record, the revealed information is limited to 199 the domain of the service provider serving that user as the userpart 200 of the acct URI simply replicates the phone number. 202 6. DNS Considerations 204 There may not be any "E2U+acct" NAPTRs returned in response to the 205 original ENUM query on the requested telephone number, but other 206 terminal ENUM NAPTRs that include tel: URLs [RFC3966] (e.g., 207 "voice:tel" or "pstn:tel" or "SMS:tel" or "MMS:tel" - see [RFC6118]) 208 may be present. 210 The application that made that ENUM query may choose to re-submit 211 ENUM queries for any E.164 numbers included in those returned 212 terminal NAPTRs. Doing so may cause a query loop (e.g., the ENUM 213 records returned from subsequent queries may refer to the telephone 214 number already considered). If applications choose to perform 215 subsequent ENUM queries using telephone numbers retrieved from 216 earlier queries, these applications MUST be aware of the potential 217 for query loops, and MUST be prepared to abort the set of queries if 218 such a loop is detected. 220 This is a similar issue to the referential loop issue caused by 221 processing non-terminal NAPTR queries, as mentioned in section 5.2.1 222 of [RFC6116], and a similar technique to mitigate this issue can be 223 used; an application searching for records with "acct" Enumservice 224 may consider that submitting a chain of more that 5 ENUM queries 225 without finding such a record indicates that a referential loop has 226 been entered, and the chain of queries SHOULD be abandoned. 228 7. Security Considerations 230 DNS, as used by ENUM, is a global, distributed database. Should 231 implementers of this specification use e164.arpa or any other 232 publicly available domain as the tree for maintaining PSTN 233 Enumservice data, this information would be visible to anyone 234 anonymously. 236 Carriers, service providers, and other users may choose not to 237 publish such information in the public e164.arpa tree. They may 238 instead simply publish this in an internal ENUM infrastructure that 239 is only able to be queried by trusted elements of their network, thus 240 limiting threats. 242 For security considerations that apply to all Enumservices, please 243 refer to [RFC6116], section 7. 245 It is important to note that the ENUM record itself does not need to 246 contain any personal information but only contains a pointer to an 247 account identifier. This identifier may be queried to discover 248 pointers to personal information (e.g. social network information) 249 endpoints and an authorisation mechanism may be in place in that 250 context with any level of granularity although it is out of scope of 251 this document. 253 Technically, ENUM records themselves could contain pointers to the 254 same endpoints. However the visibility of ENUM records cannot be 255 controlled based on the requesting entity. In that context the 256 simple mapping of the phone number to the account identifier, 257 notwithstanding the disclosure of the association itself, still 258 enables the reuse of more advanced access policies. 260 Revealing an 'acct' URI by itself is unlikely to introduce many 261 privacy concerns, although, depending on the structure of the URI, it 262 might reveal the full name or employer of the target. The use of 263 anonymous URIs mitigates this risk. 265 Unlike a traditional telephone number, the endpoint identified by an 266 'acct' URI may require that requesting entities provide cryptographic 267 credentials for authentication and authorization before messages are 268 exchanged. ENUM can actually provide far greater protection from 269 unwanted requesting entities than does the existing PSTN, despite the 270 public availability of ENUM records. 272 More serious security concerns are associated with potential attacks 273 against an underlying system (for example, social network system) 274 using the 'acct' URI. For this reason, underlying system should have 275 a number of security requirements that call for authentication, 276 integrity and confidentiality properties, and similar measures to 277 prevent such attacks. And this is out of scope of this document. 279 8. IANA Considerations 281 This document requests the IANA registration of the Enumservice with 282 Type "acct" according to the definitions in this document, [RFC6116] 283 and [RFC6117]. 285 Details of the registration are given in Section 4. 287 9. Acknowledgements 289 The authors would like to thank Gonzalo Salgueiro, Paul Jones, 290 Lawrence Conroy, Enrico Marocco, Bert Greevenbosch and Bernie 291 Hoeneisen for their valuable feedback to improve this document. 293 10. References 295 10.1. Normative References 297 [I-D.ietf-appsawg-acct-uri] 298 Saint-Andre, P., "The 'acct' URI Scheme", draft-ietf- 299 appsawg-acct-uri-07 (work in progress), January 2014. 301 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 302 STD 13, RFC 1034, November 1987. 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 308 Leach, P., Luotonen, A., and L. Stewart, "HTTP 309 Authentication: Basic and Digest Access Authentication", 310 RFC 2617, June 1999. 312 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 313 3966, December 2004. 315 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 316 Resource Identifier (URI): Generic Syntax", STD 66, RFC 317 3986, January 2005. 319 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 320 Uniform Resource Identifiers (URI) Dynamic Delegation 321 Discovery System (DDDS) Application (ENUM)", RFC 6116, 322 March 2011. 324 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 325 Registration of Enumservices: Guide, Template, and IANA 326 Considerations", RFC 6117, March 2011. 328 [RFC6118] Hoeneisen, B. and A. Mayrhofer, "Update of Legacy IANA 329 Registrations of Enumservices", RFC 6118, March 2011. 331 10.2. Informative References 333 [OMA-SNeW] 334 Open Mobile Alliance, "Social Network Web Enabler", OMA- 335 ER-SNeW-V1_0 336 http://technical.openmobilealliance.org/Technical/ 337 release_program/snew_v1_0.aspx, Aug 2013. 339 Authors' Addresses 341 Laurent-Walter Goix 342 Telecom Italia 343 Via Golgi, 42 344 Milano 20133 345 Italy 347 Email: laurentwalter.goix@telecomitalia.it 349 Kepeng Li 350 Huawei Technologies 351 Huawei Base, Bantian, Longgang District 352 Shenzhen 518129 353 P. R. China 355 Phone: +86-755-28971807 356 Email: likepeng@huawei.com