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