IETF ENUM WG Internet Draft Richard Shockey Document: NeuStar,Inc draft-shockey-enum-privacy-security-00.txt Expires: March 2003 October 2002 Privacy and Security Considerations in ENUM Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Many individuals and groups have expressed concerns about the privacy and security of personal information to be established in implementations of RFC 2916. This document discusses some of the technical as well as security and privacy considerations national implementations of ENUM should consider. This is a work in progress. Input from security and privacy experts is welcome. Expires - April 2003 [Page 1] draft-shockey-enum-privacy-security-00.txt October 2002 Discussion of this document is welcomed on the IETF ENUM mailing list. General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents 1) Introduction...............................................2 2) THE RATIONALE FOR ENUM.....................................3 3) THREE VIEWS OF ENUM........................................4 3.1 NUMBER TRANSLATION DATABASE...............................4 3.2 CALLED PARTY CONTROL OF ENUM ENABLED COMMUNICAITONS.......5 3.2.1 THE USE OF REAL AND OR ALIAS NAMES IN A SIP ADDRESS-OF- RECORD........................................................6 3.3 CALLING PARTY CONTROL OF COMMUNICATIONS...................7 3.4 OBSERVATIONS ON CALLED PARTY VS CALLING PARTY CONTROL.....8 4) WHAT INFORMATION IS NECESSARY FOR ENUM REGISTRATION?.......8 5) PRIVACY AND DATA PROTECTION CONSIDERATIONS IN THE NORTH AMERICAN CONTEXT.................................................9 6) PRIVACY and DATA PROTECTIONS CONSIDERATIONS IN THE EUROPEAN COMMUNITY CONTEXT...............................................10 7) SECURITY CONSIDERATIONS IN ENUM...........................10 7.1 SECURITY OF THE DNS......................................10 7.2 SECURITY OF ENUM PROVISIONING INFRASTRUCTURE.............10 8) References................................................10 9) Acknowledgments...........................................11 10) Author's Addresses........................................11 1) Introduction Readers of this Internet Draft are expected to have a working knowledge of the technology and principals embodied in [RFC2916bis]. Many individuals groups have expressed concerns about the privacy and data security implications of ENUM as it moves forward toward global deployment. In that context there are several different views Shockey Expires û April 2003 [Page 2] draft-shockey-enum-privacy-security-00.txt October 2002 of what ENUM is, what it does, and how a global ENUM system may affect personal privacy and the security of data contained in the global ENUM system. It is important to note that ENUM is first and foremost the DNS. Specifically ENUM is a system that translates E.164 phone numbers [ITU-T] into Fully Qualified Domain Names that can be queried to return a specific set of data (URIÆs)in the form of NAPTR records [RFC 3403]. The global and distributed nature of the DNS means delegation and control can occur at any point within the ENUM defined FQDN. Many entities, service providers, enterprises and indeed some consumers could, control their own DNS servers for ENUM registered domain names. There are two forms of data required for the ENUM system to work. First is the actual data to be entered into the global ENUM DNS system, the NAPTR records, that can be accessed by any IP end point any where in the world, without restriction and second, the data that will be required to maintain appropriate authentication, valid registration, administrative and technical contact for DNS servers. Issues involving domain name registration are well known to the privacy and security communities and have continually surfaced in context with the Domain Name Registration industry and ICANN approved registry-registrar business practices. The agreements between the IAB and the ITU over the management and control of the e164.arpa namespace [RFC 3026] for those portions of the E.164 global numbering plan clearly articulates that the administration, management and control of the zones and administrative portions of the E.164 plan are nation-state issues governed by appropriate national laws and regulations, many of which have yet to be determined. 2) THE RATIONALE FOR ENUM Before a discussion of privacy and security issues can be applied to various parts of the global ENUM system it is essential to note why the IETF technical community developed ENUM, what applications it was designed to serve and the implications of those applications for privacy and security issues. Shockey Expires û April 2003 [Page 3] draft-shockey-enum-privacy-security-00.txt October 2002 Since Telephone Numbers are the global naming and addressing scheme for Public Switched Telephony, ENUM was designed to map phone numbers with the Internet DNS and its naming and addressing conventions (IP numbers and Domain Names). Principally ENUM enables the use of phone numbers as identifiers of services defined as URIÆs on the Internet as well as facilitate the interconnection of systems that rely on telephone numbers with those that use URIÆs to route transactions. It is well known that businesses and consumers are very comfortable with using telephone numbers for PSTN communications. The E.164 numbering plan is a well organized and internationally recognized system of naming and addressing that is essential to the proper functioning of the PSTN. Phone Numbers have the additional advantage of being easily understood, are a useful input mechanism on billions of terminal devices (telephones) that do not have QWERTY like keyboards and, significantly, are linguistically neutral, unlike domain names. Though it is clear that ENUM can and will be used for service routing of applications other than voice, the principal focus of attention on ENUM application development has, naturally, been voice communications based on SIP [RFC 3261] and ITU developed H.323, and the general concept of convergence in IP and PSTN networks. 3) THREE VIEWS OF ENUM Even within the technical community there are different views of what ENUM is and what it is designed to accomplish. 3.1 NUMBER TRANSLATION DATABASE One view sees ENUM in the DNS as essentially a benign number translation database that exposes on the minimal subset of data necessary to establish a connection between two endpoints. This is the model we essentially have in the DNS now. DNS translates the URI concept such as http://www.foobar.org to an IP number necessary for a client to find a server running HTTP. No other intervention by the DNS is necessary. Shockey Expires û April 2003 [Page 4] draft-shockey-enum-privacy-security-00.txt October 2002 This is also the function of the DNS in E-mail where the DNS is used to locate an MX record for a SMTP server within a domain. No policy or personal information is exposed in the DNS beyond a server name. This concept is roughly analogous to the concept of a Service Control Point within the architecture of the PSTN that provide routing data to a circuit switch based on the numeric input of a phone number. 3.2 CALLED PARTY CONTROL OF ENUM ENABLED COMMUNICAITONS An emerging view of ENUM is that it enables an advanced form of called party control of communications since it is presumed that the communications servers at the edge of network are under the administrative or operational control of the called party. Called party control of those servers permits policy in some form to be directly applied to inbound communications irrespective of the wishes of the calling party. This view is particularly relevant in the case of SIP based communication [PETERSON et.al.]. The classic SIP model is based on the use of proxies between end point client/user agents that can then negotiate information about each other in order to establish a session. The calling party has no need to discover the capabilities of the called parties end point since those are established during the signaling portion of a SIP session using Session Description Protocol. The called parties proxy can also be used to enforce policy about sessions including how, when and from whom to establish sessions. The presumption of this model is that only the minimum information about an endpoint is necessary to expose in the global DNS, since the proxies perform all other forms of session negotiation and policy enforcement. Consequently it is not necessary to expose in the DNS whether a particular SIP endpoint supports voice, instant messaging, video or fax or whether that endpoint operates on a wire line or wireless connection. Shockey Expires û April 2003 [Page 5] draft-shockey-enum-privacy-security-00.txt October 2002 3.3.1 THE USE OF REAL AND OR ALIAS NAMES IN A SIP ADDRESS-OF-RECORD. Because SIP can negotiate the session creation between end points, it is not necessary expose in the global DNS specific personal identification elements, such as a personal name, to establish a successful end-to-end SIP connection. Information, such as a personal name, is exposed only because an end user chooses to do so by configuration of their entries into the DNS. For example, a classic example of a ENUM response with a SIP URI using a personal name might be as follows: $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:patrik.faltstrom@foobar.se!" One alternative method of achieving the same result with out exposing a real name is to configure the called parties ENUM DNS entries to use other forms of names as aliases. In the following example, the identification of the SIP endpoint is configured using the generic format "sip:e164number@userdomain.foo" $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:4689761234@foobar.se!" OR $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:anon5613@foobar.se!" Where the user name "anon5616" is randomly selected. Notice that the ENUM query only returns information that a SIP proxy for the user "4689761234" or "anon5616" exists within the domain foobar.se. No personal information is exposed in the global DNS other than the domain to which a SIP proxy exists and a form of user name. From the perspective of the called parties SIP proxy, if properly configured, there is no functional difference between sip:patrik.faltstrom@foobar.se or sip:4689761234@foobar.se or sip:anon5651@foobar.se. Shockey Expires û April 2003 [Page 6] draft-shockey-enum-privacy-security-00.txt October 2002 All three could accurately describe a unique SIP client or user agent and transactions could be routed equally among all three names. These examples illustrate an alternate view of what is necessary to establish a connection between two parties using ENUM and SIP. This concept of can easily be applied to many applications which can be ENUM enabled. An individual may choose give out a form of personal SIP URI using their personal on their business card, but there is no practical reason this must be entered into the global DNS. Current discussion in the IETF ENUM WG have explored the concept of indirect resolution to all forms of communications, not just SIP, through the use of presence servers or a concept called a Service resolution service. Once again the called party who is registering their phone number in the global ENUM system would then have control of how he or she could be contacted by any method. The concept of a Service Resolution Service has not been defined in the IETF, however it is within the realm of technical possibility. TBD Examples 3.3 CALLING PARTY CONTROL OF COMMUNICATIONS One other view of ENUM wishes to give the calling party the maximum control and options over how they wish to contact someone else. The preference here is for the maximum amount of information exposed in the DNS to permit the calling party the choice of contact methodology to the called party. Not only are all potential communications endpoints exposed in the global DNS but verbose hints to the nature and capabilities of those endpoints are described in the NAPTR enumservice field.[BRADNER] The ENUM DNS query returns all the available URIÆs listed, however the in these examples the called party has chosen to display other attributes about those services such as voice:home, sip:im , voice:mobile,mailto, etc. Shockey Expires û April 2003 [Page 7] draft-shockey-enum-privacy-security-00.txt October 2002 A client application or service parses the NAPTR records and displays the various options and the calling party then selects the most appropriate option based on their preference and not that of the called party. $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip:voice:home" "!^.*$!sip:patrik.faltstrom@foobar.se!" IN NAPTR 100 10 "u" "E2U+sip:voice:mobile" " !^.*$!sip:faltstrom@carrier.se!" IN NAPTR 100 10 "u" "E2U+mailto" "!^.*$!mailto:faltstrom@dorame.se!" IN NAPTR 100 10 "u" "E2U+sip:im" "!^.*$!sip:patrik@hugesoftwareco.se!" IN NAPTR 100 10 "u" "E2U+sip:fax" "!^.*$!sip:patrik@fasolaredo.se!" 3.4 OBSERVATIONS ON CALLED PARTY VS CALLING PARTY CONTROL It would be unreasonable and inappropriate to conclude that either view of ENUM enabled communications is right or wrong. There are clearly circumstances where consumers or businesses, for various reasons, might prefer each option. A variety of businesses and enterprises my wish to expose and individually describe the maximum number of contact points in the global DNS order to facilitate communications by calling parties by the most convenient means available. Consumers may prefer information about them to be masked or aliases in the DNS, in order to benefit from advanced IP communications, such as SIP, while preserving personal preferences and privacy. What is important is ENUM and the global ENUM system is flexible enough to permit either concept. The choice is directly a function of called parties registering their E.164 resources in the global ENUM system and configuring their NAPTR resources appropriately to their wishes. 4) WHAT OTHER INFORMATION IS NECESSARY FOR ENUM REGISTRATION? Shockey Expires û April 2003 [Page 8] draft-shockey-enum-privacy-security-00.txt October 2002 Various national ENUM groups have emerged with the task of developing policies and procedures for administrating the ENUM system within their various jurisdictions. Many of these forums have described a multi-tier model for ENUM registration and provisioning that will require some forms of personal data to be collected and stored as well as technical contact data on who is the responsible party for the management of the authoritive name servers that hold and manage ENUM records. Many concepts and principals have been borrowed from domain name registration where there are three distinct parties to the transaction, Registrant, Registrar and Registry. Various jurisdictions have different laws and regulations regarding data acquisition and the protection of data acquired from consumers (registrants). (See 5 and 6) Unlike the ICANN administered domain name industry, the global ENUM system has no requirement for a central WHOIS registry of registrants. Information on whom or what entity is in administrative control of a phone number is widely available as a part of normal telephone service subscription. What is different about the ENUM system is that it depends on the security and stability of DNS servers to function properly. It is necessary and prudent that this technical contact data for these servers be widely available to network administrators so that they can be contacted in the event there is a technical problem with aspects of the DNS under their management and control. Consequently it is suggested that national ENUM implementations SHOULD implement a form of WHOIS for the technical contact data appropriate to the registration of a E.164 number. 5) PRIVACY AND DATA PROTECTION CONSIDERATIONS IN THE NORTH AMERICAN CONTEXT TBD Shockey Expires û April 2003 [Page 9] draft-shockey-enum-privacy-security-00.txt October 2002 6) PRIVACY and DATA PROTECTIONS CONSIDERATIONS IN THE EUROPEAN COMMUNITY CONTEXT TBD 7) SECURITY CONSIDERATIONS IN ENUM 7.1 SECURITY OF THE DNS The security issues surrounding the DNS are well understood. This has enormous implications for emerging national ENUM administrations. In particular a DNS request can be subject to man-in-the-middle attacks where the response from the DNS may be altered in transit. This has serious implications for the accuracy and authentication of responses from the DNS to ENUM formatted queries by applications. The IETF has developed DNSSEC [ARENDS] to authenticate that the responses from the DNS are indeed from the zone from which they have been requested, however DNSSEC is still in early testing and deployment and has not been deployed in a large scale environment such as generic or country code Top Level Domain.[RFC 3130] Consequently it is premature for emerging national ENUM administrations to consider mandating DNSSEC for those Country Code zones and administrative number ranges under their control until such time as there is sufficient operational experience with DNSSEC. 7.2 SECURITY OF ENUM PROVISIONING INFRASTRUCTURE. TBD 8) References 1. [RFC2916bis] Faltstrom, P.& Mealling,M. ôThe E.164 to URI DDDS Applicationsö,draft-ietf-enum-rfc2916bis-01.txt, (work in progress), May 2002 Shockey Expires û April 2003 [Page 10] draft-shockey-enum-privacy-security-00.txt October 2002 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3. [ITU-T], "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. 4. [RFC3026] Blaine, R. öLiaison to IETF/ISOC on ENUMö RFC 3026,January 2001 5. [RFC 3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The URI Resolution Application", RFC 3403 October 2002. 6. [PETERSON] Peterson, J. etal, ôUsing ENUM for SIP Applicationsö, draft-ietf-sipping-e164.02.txt, (work in progress), October 2002 7. [BRANDER] Brandner, R. et.al."Categorical enumservices", draft-brandner-enum-categorical-enumservices-00.txt, (work in progress, June 2002 8. [DNSEXT] Arends, R.,ôDNS Security Introduction and Requirementsö, draft-ietf-dnsext-dnssec-intro-03.txt, (work in progress) October 2002 9. [RFC 3130] Lewis, E. ôNotes from the State-Of-The-Technology: DNSSECö RFC 3130, June 2001 9) Acknowledgments The original suggestion for this document came from Allison Mankin and Scott Bradner. 10) Author's Addresses Richard Shockey NeuStar, Inc 46000 Center Oak Plaza Sterling, VA 20166 Phone: +1 571 434 5651 Email: richard.shockey@neustar.biz Shockey Expires û April 2003 [Page 11] draft-shockey-enum-privacy-security-00.txt October 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Shockey Expires û April 2003 [Page 12]