idnits 2.17.00 (12 Aug 2021) /tmp/idnits15975/draft-shockey-enum-privacy-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 13 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 21 instances of too long lines in the document, the longest one being 131 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7157 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) -- Missing reference section? '1' on line 14 looks like a reference -- Missing reference section? '2' on line 62 looks like a reference -- Missing reference section? 'RFC2916bis' on line 430 looks like a reference -- Missing reference section? 'ITU-T' on line 439 looks like a reference -- Missing reference section? 'RFC 3403' on line 445 looks like a reference -- Missing reference section? 'RFC 3026' on line 122 looks like a reference -- Missing reference section? 'RFC 3261' on line 161 looks like a reference -- Missing reference section? 'BRADNER' on line 305 looks like a reference -- Missing reference section? 'ARENDS' on line 412 looks like a reference -- Missing reference section? 'RFC 3130' on line 461 looks like a reference -- Missing reference section? 'RFC3026' on line 442 looks like a reference -- Missing reference section? 'PETERSON' on line 449 looks like a reference -- Missing reference section? 'BRANDER' on line 453 looks like a reference -- Missing reference section? 'DNSEXT' on line 457 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF ENUM WG 3 Internet Draft Richard Shockey 4 Document: NeuStar,Inc 5 draft-shockey-enum-privacy-security-00.txt 6 Expires: March 2003 October 2002 8 Privacy and Security Considerations in ENUM 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work 24 in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2002). All Rights Reserved. 35 Abstract 37 Many individuals and groups have expressed concerns about the 38 privacy and security of personal information to be established in 39 implementations of RFC 2916. This document discusses some of the 40 technical as well as security and privacy considerations national 41 implementations of ENUM should consider. 43 This is a work in progress. Input from security and privacy 44 experts is welcome. 46 draft-shockey-enum-privacy-security-00.txt October 2002 48 Discussion of this document is welcomed on the IETF ENUM mailing 49 list. 51 General Discussion:enum@ietf.org 52 To Subscribe: enum-request@ietf.org 53 In Body: subscribe 54 Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 59 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 60 "OPTIONAL" in this document are to be interpreted as described in 61 RFC-2119 [2]. 63 Table of Contents 65 1) Introduction...............................................2 66 2) THE RATIONALE FOR ENUM.....................................3 67 3) THREE VIEWS OF ENUM........................................4 68 3.1 NUMBER TRANSLATION DATABASE...............................4 69 3.2 CALLED PARTY CONTROL OF ENUM ENABLED COMMUNICAITONS.......5 70 3.2.1 THE USE OF REAL AND OR ALIAS NAMES IN A SIP ADDRESS-OF- 71 RECORD........................................................6 72 3.3 CALLING PARTY CONTROL OF COMMUNICATIONS...................7 73 3.4 OBSERVATIONS ON CALLED PARTY VS CALLING PARTY CONTROL.....8 74 4) WHAT INFORMATION IS NECESSARY FOR ENUM REGISTRATION?.......8 75 5) PRIVACY AND DATA PROTECTION CONSIDERATIONS IN THE NORTH 76 AMERICAN CONTEXT.................................................9 77 6) PRIVACY and DATA PROTECTIONS CONSIDERATIONS IN THE EUROPEAN 78 COMMUNITY CONTEXT...............................................10 79 7) SECURITY CONSIDERATIONS IN ENUM...........................10 80 7.1 SECURITY OF THE DNS......................................10 81 7.2 SECURITY OF ENUM PROVISIONING INFRASTRUCTURE.............10 82 8) References................................................10 83 9) Acknowledgments...........................................11 84 10) Author's Addresses........................................11 86 1) Introduction 88 Readers of this Internet Draft are expected to have a working knowledge of the technology and 89 principals embodied in [RFC2916bis]. 91 Many individuals groups have expressed concerns about the privacy 92 and data security implications of ENUM as it moves forward toward 93 global deployment. In that context there are several different views 94 draft-shockey-enum-privacy-security-00.txt October 2002 96 of what ENUM is, what it does, and how a global ENUM system may 97 affect personal privacy and the security of data contained in the 98 global ENUM system. 100 It is important to note that ENUM is first and foremost the DNS. 101 Specifically ENUM is a system that translates E.164 phone numbers 102 [ITU-T] into Fully Qualified Domain Names that can be queried to 103 return a specific set of data (URIÆs)in the form of NAPTR records 104 [RFC 3403]. The global and distributed nature of the DNS means 105 delegation and control can occur at any point within the ENUM 106 defined FQDN. Many entities, service providers, enterprises and 107 indeed some consumers could, control their own DNS servers for ENUM 108 registered domain names. 110 There are two forms of data required for the ENUM system to work. 111 First is the actual data to be entered into the global ENUM DNS 112 system, the NAPTR records, that can be accessed by any IP end point 113 any where in the world, without restriction and second, the data 114 that will be required to maintain appropriate authentication, valid 115 registration, administrative and technical contact for DNS servers. 116 Issues involving domain name registration are well known to the 117 privacy and security communities and have continually surfaced in 118 context with the Domain Name Registration industry and ICANN 119 approved registry-registrar business practices. 121 The agreements between the IAB and the ITU over the management and 122 control of the e164.arpa namespace [RFC 3026] for those portions of 123 the E.164 global numbering plan clearly articulates that the 124 administration, management and control of the zones and 125 administrative portions of the E.164 plan are nation-state issues 126 governed by appropriate national laws and regulations, many of which 127 have yet to be determined. 129 2) THE RATIONALE FOR ENUM 131 Before a discussion of privacy and security issues can be applied to 132 various parts of the global ENUM system it is essential to note why 133 the IETF technical community developed ENUM, what applications it 134 was designed to serve and the implications of those applications for 135 privacy and security issues. 137 draft-shockey-enum-privacy-security-00.txt October 2002 139 Since Telephone Numbers are the global naming and addressing scheme 140 for Public Switched Telephony, ENUM was designed to map phone 141 numbers with the Internet DNS and its naming and addressing 142 conventions (IP numbers and Domain Names). Principally ENUM enables 143 the use of phone numbers as identifiers of services defined as URIÆs 144 on the Internet as well as facilitate the interconnection of systems 145 that rely on telephone numbers with those that use URIÆs to route 146 transactions. 148 It is well known that businesses and consumers are very comfortable 149 with using telephone numbers for PSTN communications. The E.164 150 numbering plan is a well organized and internationally recognized 151 system of naming and addressing that is essential to the proper 152 functioning of the PSTN. Phone Numbers have the additional advantage 153 of being easily understood, are a useful input mechanism on billions 154 of terminal devices (telephones) that do not have QWERTY like 155 keyboards and, significantly, are linguistically neutral, unlike 156 domain names. 158 Though it is clear that ENUM can and will be used for service 159 routing of applications other than voice, the principal focus of 160 attention on ENUM application development has, naturally, been voice 161 communications based on SIP [RFC 3261] and ITU developed H.323, and 162 the general concept of convergence in IP and PSTN networks. 164 3) THREE VIEWS OF ENUM 166 Even within the technical community there are different views of 167 what ENUM is and what it is designed to accomplish. 169 3.1 NUMBER TRANSLATION DATABASE 171 One view sees ENUM in the DNS as essentially a benign number 172 translation database that exposes on the minimal subset of data 173 necessary to establish a connection between two endpoints. This is 174 the model we essentially have in the DNS now. DNS translates the 175 URI concept such as http://www.foobar.org to an IP number necessary 176 for a client to find a server running HTTP. No other intervention by 177 the DNS is necessary. 179 draft-shockey-enum-privacy-security-00.txt October 2002 181 This is also the function of the DNS in E-mail where the DNS is used 182 to locate an MX record for a SMTP server within a domain. No policy 183 or personal information is exposed in the DNS beyond a server name. 185 This concept is roughly analogous to the concept of a Service 186 Control Point within the architecture of the PSTN that provide 187 routing data to a circuit switch based on the numeric input of a 188 phone number. 190 3.2 CALLED PARTY CONTROL OF ENUM ENABLED COMMUNICAITONS 192 An emerging view of ENUM is that it enables an advanced form of 193 called party control of communications since it is presumed that the 194 communications servers at the edge of network are under the 195 administrative or operational control of the called party. Called 196 party control of those servers permits policy in some form to be 197 directly applied to inbound communications irrespective of the 198 wishes of the calling party. 200 This view is particularly relevant in the case of SIP based 201 communication [PETERSON et.al.]. The classic SIP model is based on 202 the use of proxies between end point client/user agents that can 203 then negotiate information about each other in order to establish a 204 session. The calling party has no need to discover the capabilities 205 of the called parties end point since those are established during 206 the signaling portion of a SIP session using Session Description 207 Protocol. 209 The called parties proxy can also be used to enforce policy about 210 sessions including how, when and from whom to establish sessions. 211 The presumption of this model is that only the minimum information 212 about an endpoint is necessary to expose in the global DNS, since 213 the proxies perform all other forms of session negotiation and 214 policy enforcement. 216 Consequently it is not necessary to expose in the DNS whether a 217 particular SIP endpoint supports voice, instant messaging, video or 218 fax or whether that endpoint operates on a wire line or wireless 219 connection. 221 draft-shockey-enum-privacy-security-00.txt October 2002 223 3.3.1 THE USE OF REAL AND OR ALIAS NAMES IN A SIP ADDRESS-OF-RECORD. 225 Because SIP can negotiate the session creation between end points, 226 it is not necessary expose in the global DNS specific personal 227 identification elements, such as a personal name, to establish a 228 successful end-to-end SIP connection. 230 Information, such as a personal name, is exposed only because an end 231 user chooses to do so by configuration of their entries into the 232 DNS. 234 For example, a classic example of a ENUM response with a SIP URI 235 using a personal name might be as follows: 237 $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. 238 IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:patrik.faltstrom@foobar.se!" 240 One alternative method of achieving the same result with out 241 exposing a real name is to configure the called parties ENUM DNS 242 entries to use other forms of names as aliases. In the following 243 example, the identification of the SIP endpoint is configured using 244 the generic format "sip:e164number@userdomain.foo" 246 $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. 247 IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:4689761234@foobar.se!" 249 OR 251 $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. 252 IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:anon5613@foobar.se!" 254 Where the user name "anon5616" is randomly selected. 256 Notice that the ENUM query only returns information that a SIP proxy 257 for the user "4689761234" or "anon5616" exists within the domain 258 foobar.se. No personal information is exposed in the global DNS 259 other than the domain to which a SIP proxy exists and a form of user 260 name. 262 From the perspective of the called parties SIP proxy, if properly 263 configured, there is no functional difference between 264 sip:patrik.faltstrom@foobar.se or 265 sip:4689761234@foobar.se or 266 sip:anon5651@foobar.se. 268 draft-shockey-enum-privacy-security-00.txt October 2002 270 All three could accurately describe a unique SIP client or user 271 agent and transactions could be routed equally among all three 272 names. 274 These examples illustrate an alternate view of what is necessary to 275 establish a connection between two parties using ENUM and SIP. This 276 concept of can easily be applied to many applications which can be 277 ENUM enabled. 279 An individual may choose give out a form of personal SIP URI using 280 their personal on their business card, but there is no practical 281 reason this must be entered into the global DNS. 283 Current discussion in the IETF ENUM WG have explored the concept of 284 indirect resolution to all forms of communications, not just SIP, 285 through the use of presence servers or a concept called a Service 286 resolution service. Once again the called party who is registering 287 their phone number in the global ENUM system would then have control 288 of how he or she could be contacted by any method. 290 The concept of a Service Resolution Service has not been defined in 291 the IETF, however it is within the realm of technical possibility. 293 TBD Examples 295 3.3 CALLING PARTY CONTROL OF COMMUNICATIONS 297 One other view of ENUM wishes to give the calling party the maximum 298 control and options over how they wish to contact someone else. The 299 preference here is for the maximum amount of information exposed in 300 the DNS to permit the calling party the choice of contact 301 methodology to the called party. 303 Not only are all potential communications endpoints exposed in the 304 global DNS but verbose hints to the nature and capabilities of those 305 endpoints are described in the NAPTR enumservice field.[BRADNER] 307 The ENUM DNS query returns all the available URIÆs listed, however 308 the in these examples the called party has chosen to display other 309 attributes about those services such as voice:home, sip:im , 310 voice:mobile,mailto, etc. 312 draft-shockey-enum-privacy-security-00.txt October 2002 314 A client application or service parses the NAPTR records and 315 displays the various options and the calling party then selects the 316 most appropriate option based on their preference and not that of 317 the called party. 319 $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. 320 IN NAPTR 100 10 "u" "E2U+sip:voice:home" "!^.*$!sip:patrik.faltstrom@foobar.se!" 322 IN NAPTR 100 10 "u" "E2U+sip:voice:mobile" " !^.*$!sip:faltstrom@carrier.se!" 324 IN NAPTR 100 10 "u" "E2U+mailto" "!^.*$!mailto:faltstrom@dorame.se!" 326 IN NAPTR 100 10 "u" "E2U+sip:im" "!^.*$!sip:patrik@hugesoftwareco.se!" 328 IN NAPTR 100 10 "u" "E2U+sip:fax" "!^.*$!sip:patrik@fasolaredo.se!" 330 3.4 OBSERVATIONS ON CALLED PARTY VS CALLING PARTY CONTROL 332 It would be unreasonable and inappropriate to conclude that either 333 view of ENUM enabled communications is right or wrong. There are 334 clearly circumstances where consumers or businesses, for various 335 reasons, might prefer each option. 337 A variety of businesses and enterprises my wish to expose and 338 individually describe the maximum number of contact points in the 339 global DNS order to facilitate communications by calling parties by 340 the most convenient means available. 342 Consumers may prefer information about them to be masked or aliases 343 in the DNS, in order to benefit from advanced IP communications, 344 such as SIP, while preserving personal preferences and privacy. 346 What is important is ENUM and the global ENUM system is flexible 347 enough to permit either concept. The choice is directly a function 348 of called parties registering their E.164 resources in the global 349 ENUM system and configuring their NAPTR resources appropriately to 350 their wishes. 352 4) WHAT OTHER INFORMATION IS NECESSARY FOR ENUM REGISTRATION? 353 draft-shockey-enum-privacy-security-00.txt October 2002 355 Various national ENUM groups have emerged with the task of 356 developing policies and procedures for administrating the ENUM 357 system within their various jurisdictions. Many of these forums 358 have described a multi-tier model for ENUM registration and 359 provisioning that will require some forms of personal data to be 360 collected and stored as well as technical contact data on who is the 361 responsible party for the management of the authoritive name servers 362 that hold and manage ENUM records. 364 Many concepts and principals have been borrowed from domain name 365 registration where there are three distinct parties to the 366 transaction, Registrant, Registrar and Registry. 368 Various jurisdictions have different laws and regulations regarding 369 data acquisition and the protection of data acquired from consumers 370 (registrants). (See 5 and 6) 372 Unlike the ICANN administered domain name industry, the global ENUM 373 system has no requirement for a central WHOIS registry of 374 registrants. Information on whom or what entity is in administrative 375 control of a phone number is widely available as a part of normal 376 telephone service subscription. 378 What is different about the ENUM system is that it depends on the 379 security and stability of DNS servers to function properly. It is 380 necessary and prudent that this technical contact data for these 381 servers be widely available to network administrators so that they 382 can be contacted in the event there is a technical problem with 383 aspects of the DNS under their management and control. Consequently 384 it is suggested that national ENUM implementations SHOULD implement 385 a form of WHOIS for the technical contact data appropriate to the 386 registration of a E.164 number. 388 5) PRIVACY AND DATA PROTECTION CONSIDERATIONS IN THE NORTH AMERICAN 389 CONTEXT 391 TBD 393 draft-shockey-enum-privacy-security-00.txt October 2002 395 6) PRIVACY and DATA PROTECTIONS CONSIDERATIONS IN THE EUROPEAN 396 COMMUNITY CONTEXT 398 TBD 400 7) SECURITY CONSIDERATIONS IN ENUM 402 7.1 SECURITY OF THE DNS 404 The security issues surrounding the DNS are well understood. This 405 has enormous implications for emerging national ENUM 406 administrations. In particular a DNS request can be subject to 407 man-in-the-middle attacks where the response from the DNS may be 408 altered in transit. This has serious implications for the 409 accuracy and authentication of responses from the DNS to ENUM 410 formatted queries by applications. 412 The IETF has developed DNSSEC [ARENDS] to authenticate that the 413 responses from the DNS are indeed from the zone from which they 414 have been requested, however DNSSEC is still in early testing and 415 deployment and has not been deployed in a large scale environment 416 such as generic or country code Top Level Domain.[RFC 3130] 418 Consequently it is premature for emerging national ENUM 419 administrations to consider mandating DNSSEC for those Country 420 Code zones and administrative number ranges under their control 421 until such time as there is sufficient operational experience 422 with DNSSEC. 424 7.2 SECURITY OF ENUM PROVISIONING INFRASTRUCTURE. 426 TBD 428 8) References 430 1. [RFC2916bis] Faltstrom, P.& Mealling,M. ôThe E.164 to URI 431 DDDS Applicationsö,draft-ietf-enum-rfc2916bis-01.txt, (work in 432 progress), May 2002 434 draft-shockey-enum-privacy-security-00.txt October 2002 436 2. Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, March 1997 439 3. [ITU-T], "The International Public Telecommunication Number 440 Plan", Recommendation E.164, May 1997. 442 4. [RFC3026] Blaine, R. öLiaison to IETF/ISOC on ENUMö RFC 443 3026,January 2001 445 5. [RFC 3403] Mealling, M., "Dynamic Delegation Discovery System 446 (DDDS) Part Four: The URI Resolution Application", RFC 3403 447 October 2002. 449 6. [PETERSON] Peterson, J. etal, ôUsing ENUM for SIP 450 Applicationsö, draft-ietf-sipping-e164.02.txt, (work in 451 progress), October 2002 453 7. [BRANDER] Brandner, R. et.al."Categorical enumservices", 454 draft-brandner-enum-categorical-enumservices-00.txt, (work in 455 progress, June 2002 457 8. [DNSEXT] Arends, R.,ôDNS Security Introduction and 458 Requirementsö, draft-ietf-dnsext-dnssec-intro-03.txt, (work in 459 progress) October 2002 461 9. [RFC 3130] Lewis, E. ôNotes from the State-Of-The-Technology: 462 DNSSECö RFC 3130, June 2001 464 9) Acknowledgments 466 The original suggestion for this document came from Allison 467 Mankin and Scott Bradner. 469 10) Author's Addresses 471 Richard Shockey 472 NeuStar, Inc 473 46000 Center Oak Plaza 474 Sterling, VA 20166 475 Phone: +1 571 434 5651 476 Email: richard.shockey@neustar.biz 478 draft-shockey-enum-privacy-security-00.txt October 2002 480 Full Copyright Statement 482 Copyright (C) The Internet Society (2002). All Rights Reserved. 484 This document and translations of it may be copied and furnished to 485 others, and derivative works that comment on or otherwise explain it 486 or assist in its implementation may be prepared, copied, published 487 and distributed, in whole or in part, without restriction of any 488 kind, provided that the above copyright notice and this paragraph 489 are included on all such copies and derivative works. However, this 490 document itself may not be modified in any way, such as by removing 491 the copyright notice or references to the Internet Society or other 492 Internet organizations, except as needed for the purpose of 493 developing Internet standards in which case the procedures for 494 copyrights defined in the Internet Standards process must be 495 followed, or as required to translate it into languages other than 496 English. 498 The limited permissions granted above are perpetual and will not be 499 revoked by the Internet Society or its successors or assigns. 501 This document and the information contained herein is provided on an 502 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 503 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 504 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 505 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 506 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 508 Acknowledgement 510 Funding for the RFC Editor function is currently provided by the 511 Internet Society.