One document matched: draft-ietf-enum-privacy-security-01.txt
Differences from draft-ietf-enum-privacy-security-00.txt
IETF ENUM Working Group
Internet Draft Richard Shockey
Document: draft-ietf-enum-privacy-security-01.txt NeuStar,Inc
John Morris
Center for
Democracy and
Technology
Expires: January 2004 July 2003
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].
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026 except that the
right to produce derivative works is not granted.
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.
This Internet-Draft will expire on January 1, 2004.
Copyright Notice
Copyright (c) The Internet Society (2003). All Rights Reserved.
Abstract
Many individuals and groups have expressed concerns about the
privacy and security of personal information to be contained in
Shockey Et.Al Expires January 2004 [Page 1]
draft-ietf-enum-privacy-security-01.txt July 2003
implementations of ENUM. 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.
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
[RFC2119].
Table of Contents
1.0 INTRODUCTION.................................................3
2.0 THE RATIONALE FOR ENUM.......................................3
3.0 VIEWS OF ENUM................................................4
3.1 NUMBER TRANSLATION DATABASE...............................4
3.2 CALLED PARTY CONTROL OF ENUM ENABLED COMMUNICATIONS.......5
3.3 CALLING PARTY CONTROL OF COMMUNICATIONS...................5
4.0 PROCEDURES FOR ENUM REGISTRATION.............................6
5.0 SECURITY CONSIDERATIONS IN ENUM..............................7
5.1 SECURITY IN ENUM PROVISIONING.............................7
5.2 SECURITY OF THE DNS.......................................7
6.0 PRIVACY CONSIDERATIONS IN ENUM...............................8
6.1 PRIVACY CONCERNS INHERENT IN ENUM'S RELIANCE ON THE DNS...8
6.1.1 CALLED PARTY VERSUS CALLING PARTY CONTROL...............8
6.1.2 SIP AS A TOOL FOR ENABLING PRIVACY......................9
6.1.3 THE USE OF REAL AND OR ALIAS NAMES.....................10
6.2 PRIVACY CONCERNS RAISED BY IMPLEMENTATION DECISIONS......11
6.2.1 PRIVACY OF REGISTRATION INFORMATION....................11
6.2.2 OPT-IN NATURE OF ENUM..................................12
6.2.3 CONTROL OVER DATA IN ENUM RECORD.......................13
7.0 FAIR INFORMATION PRACTICES..................................13
8.0 REFERENCES..................................................14
Acknowledgments.................................................16
Author's Addresses...........................................16
Shockey,et.al. Expires - January 2004 [Page 2]
draft-ietf-enum-privacy-security-01.txt July 2003
1.0 INTRODUCTION
Many individuals groups have expressed concerns about the privacy
and data security implications of ENUM as it moves forward toward
global deployment. For example, see [EPIC], [CLARKE], [CDT]. In
that context there are several different views 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 a system
that works within the DNS. Specifically ENUM is a system that
translates 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 FQDN. Many entities (service
providers, enterprises and indeed some consumers) could control
their own DNS servers for ENUM registered domain names.
As noted in [ENUM] and other documents, the utility of the DNS is
essentially that it is open and globally accessible to any one on
the Internet.
There are two forms of data required for the global ENUM system
to work. First is the actual data to be entered into the DNS
system -- the NAPTR records to be associated with an appropriate
ENUM Fully Qualified Domain Name. Second is the data that will be
required to maintain appropriate authentication, valid
registration, administrative and technical contact for ENUM
records stored in DNS servers. Both forms of data raise privacy
and security issues.
The agreements between the IAB and the ITU over the management
and control of the e164.arpa namespace [RFC 3026, RFC 3245] 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.0 THE RATIONALE FOR ENUM
Before a discussion of privacy and security issues raised by the
global ENUM system, it is valuable to note why the IETF technical
community developed ENUM, what applications it was designed to
Shockey,et.al. Expires - January 2004 [Page 3]
draft-ietf-enum-privacy-security-01.txt July 2003
serve and the implications of those applications for privacy and
security issues.
Since telephone numbers are the global naming scheme for Public
Switched Telephony, ENUM is designed to map phone numbers with
the Internet DNS and its naming and addressing conventions (IP
numbers and Domain Names). As such ENUM exists primarily to
facilitate the interconnection of systems that rely on telephone
numbers with those that use URI's to route transactions.
Therefore in and of itself ENUM has no specific application
value. It is only the applications themselves that are mapped to
phone numbers that users direct interact with.
Many businesses and consumers are very comfortable with using
telephone numbers for communications. The ITU developed E.164
numbering plan is a well organized and internationally recognized
system that is essential to the proper functioning of the PSTN.
Though it is clear that ENUM can and will be used for service
routing of a variety applications, the principal focus of
attention on ENUM application development has been focused on
voice communications based on SIP [RFC 3261], the ITU developed
H.323, and the general concept of convergence of the IP and PSTN
networks.
ENUM is, consequently, part of the list of technologies developed
in the IETF and the ITU that attempt to extend the functionality
of IP based communications and reinvent the concept of telephony
specifically.
3.0 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 IP number
necessary for a client to find a server running HTTP. No other
intervention by the DNS is necessary.
This is also the function of the DNS in E-mail where the DNS is
used simply to locate an MX record for a SMTP server within a
domain. No policy or personal information is exposed in the DNS
beyond a host name.
Shockey,et.al. Expires - January 2004 [Page 4]
draft-ietf-enum-privacy-security-01.txt July 2003
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.
The essential difference between the DNS and PSTN Service Control
Points is that the DNS is a highly distributed database globally
accessible to any device or network connected to the Internet and
Service Control Points are a high specialized and restricted
databases available only to uniquely authenticated and authorized
PSTN network elements, such as Class 5 switches. Appropriate
domain name holders can modify DNS entries while only authorized
carriers can only modify data in PSTN Service Control points.
3.2 CALLED PARTY CONTROL OF ENUM ENABLED COMMUNICATIONS
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 called party. User
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 1]. 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
the Session Description Protocol.
The called parties proxy can also be used to enforce policy
(including privacy policy) about sessions, including how, when
and from whom to establish sessions. The presumption of this
model is that only the minimum information about location of the
endpoint proxy is necessary to expose in the global DNS, since
the proxies perform all other forms of session negotiation.
3.3 CALLING PARTY CONTROL OF COMMUNICATIONS
One other view of ENUM wishes to give the calling party the
complete control over how they wish to contact someone else. The
preference here is for the maximum amount of information exposed
in the global DNS to permit the calling party the choice of
contact methodology to the called party.
Shockey,et.al. Expires - January 2004 [Page 5]
draft-ietf-enum-privacy-security-01.txt July 2003
In this scenario all the various endpoints that a called party
has under their control could be listed in the DNS with various
hints as to their nature and function in the NAPTR enumservice
field, such as E2U+sip,E2U+sms:tel, etc. [BRANDNER 1, BRANDNER 2]
The calling party's device or user agent could then parse the
various NAPTR records an present the options for communication to
the calling party.
$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
IN NAPTR 100 10 "u" "E2U+web:http" "!^.*$! http:www.example.foo!"
IN NAPTR 100 10 "u" "E2U+mms:tel; " !^.*$!tel:+46987654321!"
IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:patrik@barfoo.bar!"
IN NAPTR 100 10 "u" "E2U+ifax:mailto" "!^.*$!mailto:patrik@mailco.foo!"
The calling party then selects the methodology for communication
from that list.
4.0 PROCEDURES FOR ENUM REGISTRATION
Various national ENUM groups have emerged with the task of
developing policies and procedures for administrating the ENUM
system within their various jurisdictions. [See
http://www.itu.int/osg/spu/enum/index.html#trials ] 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 authoritative 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.
A Registrant in the global ENUM system is presumed to the
Telephone Number Holder or consumer. An ENUM Registrar is an
administrative entity that assists Registrants in populating the
global ENUM tree in e164.arpa by providing authentication and
authorization functions, in order to preserve and protect both
the interests of consumers and the global integrity of the E.164
Shockey,et.al. Expires - January 2004 [Page 6]
draft-ietf-enum-privacy-security-01.txt July 2003
numbering plan. The ENUM Registry is a national administrative
entity that manages that portion of the E.164 namespace
appropriate within e164.arpa (such as 6.4.e164.arpa for Sweden or
4.4.e164.arpa for the United Kingdom, or possibly a sub-namespace
within a national namespace).
Various jurisdictions have different laws and regulations
regarding data acquisition and the protection of data acquired
from consumers (registrants). What those policies and procedures
should be will ultimately be a national sovereign decision of the
nation state managing their portion of the e164.arpa namespace.
5.0 SECURITY CONSIDERATIONS IN ENUM
Privacy is often viewed as an element of security, and thus the
privacy considerations discussed below in Sections 6 and 7 are
security considerations. This section security concerns in more
traditional terms.
5.1 SECURITY IN ENUM PROVISIONING
Since the global ENUM system relies on the DNS and the protocol
itself converts E.164 numbers into domain names there has been
considerable discussion on how data is to be exchanged between
the ENUM registrants, registrars and registries and how that data
is protected.
For some time the IETF PROVREG working group has been developing
a robust Extensible Provisioning Protocol [EPP] for the domain
name industry. This protocol has within it several highly secure
mechanisms for the exchange of data between the various
Registrants, Registrars and Registries in the ENUM system.
This work could easily be adapted to the needs of ENUM, however
there are a variety of highly secure protocols and technologies
such as Simple Object Access Protocol (SOAP) that could provide
similar capabilities.
5.2 SECURITY OF THE DNS
The security issues surrounding the DNS are well understood
[DNSSEC-INTRO]. 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.
Shockey,et.al. Expires - January 2004 [Page 7]
draft-ietf-enum-privacy-security-01.txt July 2003
The IETF has developed DNSSEC [DNSSEC-ROADMAP] to authenticate
that the responses from the DNS are indeed from the zone for
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]
It is the consensus of the IETF ENUM Work group that the use of
DNSSEC will become necessary as the protocol matures.
6.0 PRIVACY CONSIDERATIONS IN ENUM
ENUM raises a range of privacy concerns, both in its reliance on
the DNS, and in decisions that will be made by each national
authority that decides to implement ENUM. This section discusses
both groups of concerns. Many of these concerns are raised by
privacy principles called "fair information practices" These
broad principles are briefly summarized below in Section 7.0.
6.1 PRIVACY CONCERNS INHERENT IN ENUM'S RELIANCE ON THE DNS
Because ENUM utilizes the global DNS to store information about
how to contact individuals, and information stored in DNS records
are freely accessible by any user on the Internet, ENUM
inherently raises questions about user privacy. Although ENUM-
like capability could have been designed without using the DNS,
the robust and globally deployed nature of the DNS offered a
means to develop and deploy ENUM without having to create a
separate global information lookup system. Considerations raised
by this reliance on the DNS are addressed below.
6.1.1 CALLED PARTY VERSUS CALLING PARTY CONTROL
As a technical matter, there is no reason to conclude that either
the Called Party Control or Calling Party Control views of ENUM
are right or wrong. There are clearly circumstances where
consumers or businesses, for various reasons, might prefer each
option.
A variety of businesses and enterprises may wish to expose and
individually characterize the maximum number of contact points in
the global DNS order, to facilitate communications by calling
parties in the most convenient means available.
Consumers, however, will probably prefer that information about
them is masked or aliased in the DNS, in order to benefit from
Shockey,et.al. Expires - January 2004 [Page 8]
draft-ietf-enum-privacy-security-01.txt July 2003
advanced IP communications, while preserving personal preferences
and privacy.
What is important is ENUM and the global ENUM system is flexible
enough to permit either approach, and the choice of either
methodology should be based on the informed consent of the user.
No implementation of ENUM should preclude or inhibit the use of
either the Called Party Control or the Calling Party Control
models.
6.1.2 SIP AS A TOOL FOR ENABLING PRIVACY
As described above in Section 3.2, the Called Party Control model
offers ENUM users the ability to exert control over what
information is provided through the ENUM system. Critical to
this model of ENUM is technology such as the Session Initiation
Protocol, SIP, which can be used as a tool to greatly enhance the
privacy of information accessed through an ENUM transaction.
Traditional telephony relies on essentially "stupid" endpoints
such as traditional telephone instruments and "intelligence" in
the network embodied in Class 5 switches at the core of the PSTN.
These switches, typically controlled by service providers,
provide all of the advanced applications consumers have come to
expect.
Services such as Do Not Disturb, Call Forwarding, Call Screening
can only be enabled by these switches under the administrative
control of service providers. As a globally closed system, call
signaling and transport in the PSTN are tightly bound together,
the exact opposite of the architectural design of the Internet.
[RFC 1958]
SIP as an application technology at the edges of the Internet
reverses the PSTN control model. SIP endpoints and proxies are
assumed to be "intelligent" and configurable by network
administrators.
SIP through the use of advanced Call Processing Language
techniques can be quickly and easily programmed to provide Class
5 like features without the intervention of the call transport
mechanism.
The Called Party Control model of ENUM, therefore, relies on and
will promote the broad deployment of applications such as SIP
that give consumers direct control over their communications
options, and more generally allow the user to control who
accesses personal information about the user.
Shockey,et.al. Expires - January 2004 [Page 9]
draft-ietf-enum-privacy-security-01.txt July 2003
6.1.3 THE USE OF REAL AND OR ALIAS NAMES
Even with the Called Party Control models some information is
necessarily exposed in the global DNS, but important steps can be
taken to reduce the disclosure of personal information in the DNS
records themselves. In order to establish a session between two
endpoints it is necessary to describe that endpoint as a form or
URL. However, it not necessary nor is it a requirement to use
personally identifying information to establish a successful end-
to-end SIP connection. If this information is exposed is only
because an end user chooses to do so by configuration of their
proxy.
The classic form of NAPTR record for SIP looks much like this.
$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:patrik.faltstrom@example.foo!"
One alternative method of achieving the same result without
exposing a real name or other form of Personally Identifying
Information is to use various forms of aliases. The following are
example of a highly constrained, but equally valid, ENUM SIP
response. In the first case the identification of the SIP
endpoint is configured using an alias convention
"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@example.foo!"
OR
$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:anon5613@example!"
Where the user name "anon5616" is randomly selected.
Notice that the ENUM query only returns from the global DNS
information that a SIP proxy for the user "4689761234" or
"anon5616" exists within the domain example.foo. No personal
information is exposed in the global DNS other than the phone
number or anonymous alias used to create the FQDN query.
From the perspective of the SIP proxy, if properly configured,
there is no functional difference between
sip:patrik.faltstrom@example.foo and sip:4689761234@example.foo
or sip:anon5651@example.foo. All three could accurately describe
a unique SIP aware client or user agent.
Shockey,et.al. Expires - January 2004 [Page 10]
draft-ietf-enum-privacy-security-01.txt July 2003
These examples illustrate a particular view of what is necessary
to establish a connection between two parties. That one name can
be an alias to something else well understood in Internet
engineering terms. For instance it is very easy to give out a e-
mail address foobar@domain.us that can be automatically forwarded
to a different email address rich.shockey@example.biz.
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". [PETERSON 2] 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, on any device, by means of configuring
in that presence or SRS service only that data that they choose
to expose to persons wishing to contact them. The calling party
in this scenario would first executing a query to DNS to find the
presence server or SRS and based on locally controlled policy the
server would return the options available.
$ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa.
IN NAPTR 100 10 "u" "E2U+pres" "!^.*$!pres:jon.peterson@foobar.foo!"
This represents a more robust and expansive concept of presence
where a presence server or SRS would not automatically reveal or
display the physical or network presence of an individual or the
services under the called parties control but becomes a point of
control for how, why when and where presence and a form of
communication session might be established.
6.2 PRIVACY CONCERNS RAISED BY IMPLEMENTATION DECISIONS
The above privacy concerns arise because of ENUM's reliance on
the DNS system. This section instead discusses concerns that may
(or may not) arise in national implementations of ENUM. These
considerations are offered to reduce possible privacy-harming
impacts that could arise in ENUM implementations.
6.2.1 PRIVACY OF REGISTRATION INFORMATION
Unlike the ICANN administered domain name industry, the global
ENUM system has no requirement for a central WHOIS registry of
registrants. There is, however, a strong need to be able to
locate technical contact information concerning an ENUM record.
Shockey,et.al. Expires - January 2004 [Page 11]
draft-ietf-enum-privacy-security-01.txt July 2003
Unlike with the domain name system, ENUM URLs could not possibly
contain trademarked or other potentially disputed names. More
generally, ENUM records do not, in an of themselves, provide ANY
"ultimate" service to any Internet users. All that an ENUM
record does is to provide pointers to one or more references to
other services available over the Internet. If anyone (such as
an intellectual property holder, for example) needs to contact
the owner of one a service that is referenced in an ENUM record,
they can use the URL/URI of the referenced service to locate the
relevant party.
For these reasons, there is little reason to require that the
identity of the holder of an ENUM record be disclosed in a WHOIS-
like system.
In contrast, there is value in linking technical contacts with
particular ENUM records. Because the ENUM system depends on the
security and stability of DNS servers to function properly, it is
prudent and necessary that 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.
A discussion of the various problems with the current WHOIS
protocol is beyond the scope of this document. The IETF CRISP
working group [http://www.ietf.org/html.charters/crisp-
charter.html ] is developing requirements [CRISP-REQ] for a next
generation WHOIS like protocol that may offer a more appropriate
solution to the ENUM environment.
6.2.2 OPT-IN NATURE OF ENUM
With both the Called Party Control model of ENUM, and especially
with the Calling Party Control model, some degree of personal
contact information is exposed in the global DNS. It is
important that information regarding end telephone users NOT be
imported on a blanket or wholesale basis into the ENUM/DNS
system. Users should have a choice of whether to have any
information about them listed in the publicly-available DNS.
Such an approach will, for example, reasonably preserve the
ability of end users to maintain an "unlisted" telephone number,
even using VoIP technology. Assuming users are given a choice
about enrolling in the ENUM system, a user could forego the
benefits of ENUM in favor of directly providing (for example) a
SIP address of record to trusted family members and associates.
Shockey,et.al. Expires - January 2004 [Page 12]
draft-ietf-enum-privacy-security-01.txt July 2003
6.2.3 CONTROL OVER DATA IN ENUM RECORD
Because as noted some degree of personal contact information is
exposed in the global DNS, it is important that the ENUM
registrants be provided effective and efficient control over that
information. It is also important that ENUM registrants fully
understand the privacy implications of placing information in the
global DNS.
The flip side of effective user control over ENUM records is that
only authorized users should be able to control the content of
ENUM records. This issue is briefly discussed as a security
consideration above.
7.0 FAIR INFORMATION PRACTICES
As guiding principles, consumer privacy protection in many parts
of the world is based on "fair information practices," which were
authoritatively detailed in [OECD] by the Organization for
Economic Co-operation and Development. The principles should be
considered in any implementation of ENUM. Fair information
practices include the following principles:
* Notice and Consent - before the collection of data, the
data subject should be provided: notice of what information is
being collected and for what purpose and an opportunity to choose
whether to accept the data collection and use. In Europe, data
collection cannot proceed unless data subject has unambiguously
given his consent (with exceptions).
* Collection Limitation - data should be collected for
specified, explicit and legitimate purposes. The data collected
should be adequate, relevant and not excessive in relation to the
purposes for which they are collected.
* Use/Disclosure Limitation - data should be used only for
the purpose for which it was collected and should not be used or
disclosed in any way incompatible with those purposes.
* Retention Limitation - data should be kept in a form that
permits identification of the data subject no longer than is
necessary for the purposes for which the data were collected.
* Accuracy - the party collecting and storing data is
obligated to ensure its accuracy and, where necessary, keep it up
to date; every reasonable step must be taken to ensure that data
which are inaccurate or incomplete are corrected or deleted.
Shockey,et.al. Expires - January 2004 [Page 13]
draft-ietf-enum-privacy-security-01.txt July 2003
* Access - a data subject should have access to data about
himself, in order to verify its accuracy and to determine how it
is being used.
* Security - those holding data about others must take
steps to protect its confidentiality.
8.0 REFERENCES
1. [RFC2916bis] Faltstrom, P.& Mealling,M. "The E.164 to URI
DDDS Applications",draft-ietf-enum-rfc2916bis-06.txt, (work in
progress), May 2003
2. [RFC2119]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. [PETERSON1] Peterson, J. etal, "Using ENUM for SIP
Applications", draft-ietf-sipping-e164.02.txt, (work in
progress), October 2002
7. [BRANDNER 1] Brandner, R. et.al." Registration for
enumservices of group messages", draft-ietf-enum-msg-00.txt,
(work in progress) June 2003
8. [BRANDNER 2] Brandner, R. et.al." Registration for
enumservices web and ft", draft-ietf-enum-webft-00.txt, (work
in progress) June 2003
9. [DNSSEC-INTRO] Arends, R.,"DNS Security Introduction and
Requirements", draft-ietf-dnsext-dnssec-intro-05.txt, (work in
progress) February 2003
Shockey,et.al. Expires - January 2004 [Page 14]
draft-ietf-enum-privacy-security-01.txt July 2003
10. [RFC 3130] Lewis, E. "Notes from the State-Of-The-Technology:
DNSSEC" RFC 3130, June 2001
11. [RFC 1958] Carpenter, B. Editor "Architectural Principals of
the Internet", RFC 1958 June 1996
12. [RFC 3245] Klensin, J. Editor "The History and Context of
Telephone Number Mapping (ENUM) Operational Decisions:
Informational Documents Contributed to ITU-T Study Group 2
(SG2)", RFC 3245, March 2002
13. [PETERSON2] Peterson, J "Enumservice Registration for
Presence Services", draft-peterson-enum-pres-00.txt, (work-in-
progress) February 2003
14. [RFC 3130] Lewis, E. "Notes from the State-Of-The-Technology:
DNSSEC" RFC 3130, June 2001
15. [PROVREG] Hollenbeck,S. "Extensible Provisioning Protocol",
draft-ietf-provreg-epp-09.txt, (work in progress) September
2003
16. [CRISP-REQ] Newton, A. "Cross Registry Internet Service
Protocol (CRISP) Requirements", draft-ietf-crisp-requirements-
05.txt, (work in progress) May 2003
17. [DNSSEC-ROADMAP] Rose, S. "DNS Security Document Roadmap",
draft-ietf-dnsext-dnssec-roadmap-07.txt (work in progress) Feb
2003
18. [CLARKE] Clarke, R. "ENUM - A Case Study in Social
Irresponsibility," March 2003,
http://www.anu.edu.au/people/Roger.Clarke/DV/enumISOC02.html
19. [EPIC] Electronic Privacy Information Center, "EPIC Comments
on Privacy Issues in ENUM Forum 11-01-02 Unified Document,"
November 2002,
http://www.epic.org/privacy/enum/enumcomments11.02.html
20. [CDT] Center for Democracy & Technology, "ENUM: Mapping
Telephone Numbers onto the Internet - Potential Benefits with
Public Policy Risks," April 2003,
http://www.cdt.org/standards/enum/030428analysis.pdf
Shockey,et.al. Expires - January 2004 [Page 15]
draft-ietf-enum-privacy-security-01.txt July 2003
Acknowledgments
The original suggestion for this document came from Allison
Mankin and Scott Bradner.
Author's Addresses
Richard Shockey
NeuStar, Inc
46000 Center Oak Plaza
Sterling, VA 20166 USA
Phone: +1 571 434 5651
Email: richard.shockey@neustar.biz
John B. Morris, Jr.
Director, Internet Standards, Technology & Privacy Project
Center for Democracy and Technology
1634 I Street NW, Suite 1100
Washington, DC 20006 USA
Email: jmorris@cdt.org
http://www.cdt.org
Intellectual Property Statement
The IETF takes no position regarding the validity or scope
of any intellectual property or other rights that might be
claimed to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation can
be found in BCP-11. Copies of claims of rights made available for
publication and any assurances of licenses to be made available,
or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementors
or users of this specification can be obtained from the IETF
Secretariat.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director.
Shockey,et.al. Expires - January 2004 [Page 16]
draft-ietf-enum-privacy-security-01.txt July 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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
assignees.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by
the Internet Society.
Shockey,et.al. Expires - January 2004 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 01:08:22 |