idnits 2.17.1 draft-goix-appsawg-enum-sn-service-02.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 (July 11, 2012) is 4306 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-appsawg-webfinger-00 Summary: 0 errors (**), 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: Standards Track K. Li 5 Expires: January 12, 2013 Huawei Technologies 6 July 11, 2012 8 ENUM Service Registration for Social Networking (SN) Services 9 draft-goix-appsawg-enum-sn-service-02 11 Abstract 13 This document registers a Telephone Number Mapping (ENUM) service for 14 Social Networking (SN). Specifically, this document focuses on 15 provisioning 'acct:' URIs (Uniform Resource Identifiers) in ENUM. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 12, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Justification . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. IANA Registration . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. DNS Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 8. Change log (to be deleted before publication) . . . . . . . . 6 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . . 7 71 9.2. Informative References . . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 ENUM (E.164 Number Mapping, [RFC6116]) is a system that uses DNS 78 (Domain Name Service, [RFC1034]) to translate telephone numbers, such 79 as '+44 01632 960123', into URIs (Uniform Resource Identifiers, 80 [RFC3986], such as 'acct:user@example.com'. ENUM exists primarily to 81 facilitate the interconnection of systems that rely on telephone 82 numbers with those that use URIs to identify resources. 84 Social Networking (SN) services allow users to post and retrieve 85 activities (e.g. status updates or media uploads) and related 86 replies. [I-D.saintandre-acct-uri] is proposing a generic URI to 87 identify an SN service account for a particular resource: the 'acct:' 88 URI scheme. 90 This document registers an enumservice for advertising account 91 information associated with an E.164 number. 93 1.1. Justification 95 The requirement to map an SN account with an E.164 number is from the 96 Open Mobile Alliance (OMA) Social Network Web Enabler Release 97 [OMA-SNeW-ER]. 99 In Mobile networks, users are traditionally identified through a 100 Mobile Subscriber ISDN (MSISDN) number. In order to provide SN 101 functionality to mobile subscribers identified by their MSISDN, a 102 mapping is needed to identify a corresponding SN account and 103 provider. 105 1.2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 2. IANA Registration 113 As defined in [RFC6117], the following is a template covering 114 information needed for the registration of the enumservice specified 115 in this document: 117 118 Application-Based, Common 119 sn 120 acct 121 122 123 This Enumservice indicates that the resource 124 can be addressed by the associated URI using 125 SN protocols, including 126 127 to discover additional information. 128 129 130 131 See . 132 133 COMMON 134 135 This document. 136 137 138 139 140 142 143 144 Laurent-Walter Goix 145 Telecom Italia 146 mailto:laurentwalter.goix@telecomitalia.it 147 2012-07-10 148 149 151 3. Examples 153 The following is an example of the use of the enumservice registered 154 by this document in a NAPTR resource record for phone number +44 155 01632 960123. 157 $ORIGIN 3.2.1.0.6.9.2.3.6.1.0.4.4.e164.arpa. 159 IN NAPTR 10 100 "u" "E2U+sn" "!^.*$!acct:john.doe@example.com!" . 161 4. DNS Considerations 163 If no "E2U+sn" NAPTR record exist for the requested number, the 164 resolution process over issuing ENUM queries may be recursively 165 performed over E.164 numbers identified by other NAPTR records for 166 the requested number pointing to "tel" URIs [RFC3966]. Whilst this 167 process is useful to support, amongst others, number portability as 168 per [RFC4769], Section 4, this may also create potential loops in 169 this resolution process. As such ENUM clients performing such ENUM 170 queries over "tel" URIs to identify "acct" URIs SHOULD understand the 171 "enumdi" indicator defined in [RFC4759]. In particular, if the 172 result of the query does not include "E2U+sn" NAPTR records, and 173 includes a NAPTR resource record containing a "tel" URI that has the 174 same E.164 number, or a "tel" URI with the "enumdi" parameter set, 175 that client SHOULD NOT perform subsequent ENUM queries over such 176 numbers and SHOULD consider that the original requested number cannot 177 be mapped. 179 Furthermore the client MAY stop performing subsequent ENUM queries 180 after the fifth recursive query as suggested in [RFC6116] section 181 5.2.1. 183 5. Security Considerations 185 DNS, as used by ENUM, is a global, distributed database. Should 186 implementers of this specification use e164.arpa or any other 187 publicly available domain as the tree for maintaining PSTN 188 Enumservice data, this information would be visible to anyone 189 anonymously. 191 As noted earlier, carriers, service providers, and other users may 192 choose not to publish such information in the public e164.arpa tree. 193 They may instead simply publish this in an internal ENUM 194 infrastructure that is only able to be queried by trusted elements of 195 their network, thus limiting threats. 197 Per se, this enumservice does not introduce specific security 198 considerations beyond [RFC6116], section 7. However, it has to be 199 acknowledged that the proposed Enumservice could lead to the 200 discovery or disclosure of Personally Identifiable Information (PII) 201 if used in combination with the WebFinger protocol. Please see 202 [I-D.ietf-appsawg-webfinger], section 10 for additional information 203 regarding WebFinger security to avoid unwanted disclosure of 204 information. 206 Similar security concerns are associated with potential attacks 207 against an underlying Social Networking system. Unlike a traditional 208 telephone number, and as per the indirect nature of SN communication 209 (typically through an intermediary network element), the resource 210 identified by an 'acct:' URI may not be subject to direct 211 communication with other peers. However (e.g. in case of private 212 message exchange) it may require that peers provide cryptographic 213 credentials for authentication and authorization before messages are 214 exchanged. For this reason, SN protocols should have a number of 215 security requirements that call for authentication, integrity and 216 confidentiality properties, and similar measures to prevent such 217 attacks. 219 6. IANA Considerations 221 This document requests the IANA registration of the Enumservice with 222 Type "sn" according to the definitions in this document, [RFC6116] 223 and [RFC6117]. 225 Details of the registration are given in Section 2. 227 7. Acknowledgements 229 The authors would like to thank Gonzalo Salgueiro, Paul Jones, 230 Lawrence Conroy, and Enrico Marocco for their valuable feedback to 231 improve this document. 233 8. Change log (to be deleted before publication) 235 -02 Draft 237 * Updated references to acct: URI I-D and OMA specifications 239 * Added changelog section 241 -01 Draft 243 * Made changes to example phone numbers 245 * Updated security and DNS considerations 247 * Fixed IANA registration template 249 * Added acknowledgment section 251 9. References 252 9.1. Normative References 254 [I-D.ietf-appsawg-webfinger] 255 Jones, P., Salgueiro, G., and J. Smarr, "WebFinger", 256 draft-ietf-appsawg-webfinger-00 (work in progress), 257 July 2012. 259 [I-D.saintandre-acct-uri] 260 Saint-Andre, P., "The 'acct' URI Scheme", 261 draft-saintandre-acct-uri-01 (work in progress), 262 July 2012. 264 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 265 STD 13, RFC 1034, November 1987. 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, March 1997. 270 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 271 RFC 3966, December 2004. 273 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 274 Resource Identifier (URI): Generic Syntax", STD 66, 275 RFC 3986, January 2005. 277 [RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip 278 Indicator Parameter for the "tel" URI", RFC 4759, 279 December 2006. 281 [RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an 282 Enumservice Containing Public Switched Telephone Network 283 (PSTN) Signaling Information", RFC 4769, November 2006. 285 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 286 Uniform Resource Identifiers (URI) Dynamic Delegation 287 Discovery System (DDDS) Application (ENUM)", RFC 6116, 288 March 2011. 290 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 291 Registration of Enumservices: Guide, Template, and IANA 292 Considerations", RFC 6117, March 2011. 294 9.2. Informative References 296 [OMA-SNeW-ER] 297 Open Mobile Alliance, "Social Network Web Enabler", OMA- 298 ER-SNeW-V1_0 20120702-D, July 2012. 300 Authors' Addresses 302 Laurent-Walter Goix 303 Telecom Italia 304 P.za Einaudi, 8 305 Milano 20124 306 Italy 308 Email: laurentwalter.goix@telecomitalia.it 310 Kepeng Li 311 Huawei Technologies 312 Huawei Base, Bantian, Longgang District 313 Shenzhen, Guangdong 518129 314 P. R. China 316 Phone: +86-755-28974289 317 Email: likepeng@huawei.com