mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-30 05:57:52 +00:00
Code Issues Releases Wiki Activity

updated drafts

Browse Source
This commit is contained in:
Andreas Gustafsson 2001-07-05 17:56:47 +00:00
parent 97c5be1daa
commit f18701aeaf
6 changed files with 400 additions and 330 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
doc/draft/draft-ietf-dnsext-ad-is-secure-01.txt → doc/draft/draft-ietf-dnsext-ad-is-secure-02.txt
View File

@ -1,12 +1,7 @@
DNSEXT Working Group Brian Wellington (Nominum)
INTERNET-DRAFT Olafur Gudmundsson (NAI Labs)
<draft-ietf-dnsext-ad-is-secure-01.txt> January 2001
DNSEXT Working Group Brian Wellington
INTERNET-DRAFT Olafur Gudmundsson
<draft-ietf-dnsext-ad-is-secure-02.txt> June 2001
Updates: RFC 2535
@ -37,7 +32,7 @@ Status of this Memo
Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org
This draft expires on July 19, 2001.
This draft expires on December 18, 2001.
Copyright Notice
@ -55,9 +50,9 @@ Abstract
Expires July 2001 [Page 1]
Expires December 2001 [Page 1]
INTERNET-DRAFT AD bit set on secure answers January 2001
INTERNET-DRAFT AD bit set on secure answers June 2001
1 - Introduction
@ -111,14 +106,14 @@ INTERNET-DRAFT AD bit set on secure answers January 2001
Expires July 2001 [Page 2]
Expires December 2001 [Page 2]
INTERNET-DRAFT AD bit set on secure answers January 2001
INTERNET-DRAFT AD bit set on secure answers June 2001
If the answer section contains any data, the server MUST NOT include
data in the authority section that would cause the AD bit to be
unset.
AD should be set if and only if all RRs in the answer section, and
any relevant negative response RRs in the authority section are
Authenticated.
The AD bit MUST NOT be set on a response unless all of the RRsets in
the answer and authority sections are Authenticated.
@ -161,15 +156,15 @@ References:
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification'', STD 13, RFC 1035, November 1987.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
2535, March 1999.
Expires July 2001 [Page 3]
Expires December 2001 [Page 3]
INTERNET-DRAFT AD bit set on secure answers January 2001
INTERNET-DRAFT AD bit set on secure answers June 2001
[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
@ -183,12 +178,11 @@ INTERNET-DRAFT AD bit set on secure answers January 2001
Authors Addresses
Brian Wellington Olafur Gudmundsson
Nominum Inc. NAI Labs
950 Charter Street 3060 Washington Road (Rt. 97)
Redwood City, CA, 94063 Glenwood, MD, 21738
Nominum Inc.
950 Charter Street 3826 Legation Street, NW
Redwood City, CA, 94063 Washington, DC, 20015
USA USA
+1 650 381 6022 +1 443 259 2389
<Brian.Wellington@nominum.com> <ogud@tislabs.com>
<Brian.Wellington@nominum.com> <ogud@ogud.com>
Full Copyright Statement
@ -223,4 +217,6 @@ Full Copyright Statement
Expires July 2001 [Page 4]
Expires December 2001 [Page 4]

179
doc/draft/draft-ietf-dnsext-axfr-clarify-01.txt → doc/draft/draft-ietf-dnsext-axfr-clarify-02.txt
View File

@ -1,6 +1,7 @@
INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-axfr-clarify-01.txt Nominum Inc.
November 2000
draft-ietf-dnsext-axfr-clarify-02.txt Nominum Inc.
June 2001
DNS Zone Transfer Protocol Clarifications
@ -49,9 +50,9 @@ Abstract
Expires May 2001 [Page 1]
Expires December 2001 [Page 1]
draft-ietf-dnsext-axfr-clarify-01.txt November 2000
draft-ietf-dnsext-axfr-clarify-02.txt June 2001
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@ -75,6 +76,11 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000
transfer, it MUST respond with a single DNS message containing an
appropriate RCODE other than NOERROR.
Slave servers should note that some master server implementations
will simply close the connection when denying the slave access to the
zone. Therefore, slaves MAY interpret an immediate graceful close of
the TCP connection as equivalent to a "Refused" response (RCODE 5).
If a zone transfer can be provided, the master server sends one or
more DNS messages containing the zone data as described below.
@ -98,18 +104,17 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000
DNS message size. In the case of a small zone, this can cause the
entire transfer to be transmitted in a single response message.
Expires December 2001 [Page 2]
draft-ietf-dnsext-axfr-clarify-02.txt June 2001
Slaves MUST accept messages containing any number of answer RRs. For
compatibility with old slaves, masters that support sending multiple
answers per message SHOULD be configurable to revert to the
historical mode of one answer per message, and the configuration
Expires May 2001 [Page 2]
draft-ietf-dnsext-axfr-clarify-01.txt November 2000
SHOULD be settable on a per-slave basis.
3.2. DNS message header contents
@ -121,19 +126,20 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000
ID Copy from request
QR 1
OPCODE QUERY
AA 1 (but MAY be 0 when RCODE is nonzero)
AA 1, but MAY be 0 when RCODE is not NOERROR
TC 0
RD Copy from request
RA Set according to availability of recursion S Z 0
RD Copy from request, or 0
RA Set according to availability of recursion, or 0
Z 0
AD 0
CD 0
RCODE 0 or error code
RCODE NOERROR on success, error code otherwise
The slave MUST check the RCODE and abort the transfer if it is
nonzero. It SHOULD check the ID of the first message received and
abort the transfer if it does not match the ID of the request. The
ID SHOULD be ignored in subsequent messages, and fields other than
RCODE and ID SHOULD be ignored in all messages, to ensure
The slave MUST check the RCODE in each message and abort the transfer
if it is not NOERROR. It SHOULD check the ID of the first message
received and abort the transfer if it does not match the ID of the
request. The ID SHOULD be ignored in subsequent messages, and fields
other than RCODE and ID SHOULD be ignored in all messages, to ensure
interoperability with certain older implementations which transmit
incorrect or arbitrary values in these fields.
@ -154,51 +160,50 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000
3.5. The authority section
Expires December 2001 [Page 3]
draft-ietf-dnsext-axfr-clarify-02.txt June 2001
The master server MUST transmit messages with an empty authority
section. Slaves MUST ignore any authority section contents they may
receive from masters that do not comply with this requirement.
Expires May 2001 [Page 3]
draft-ietf-dnsext-axfr-clarify-01.txt November 2000
3.6. The additional section
The additional section MAY contain additional RRs such as transaction
signatures. The slave MUST ignore any unexpected RRs in the
additional section.
4. Glue
4. Zone data
A master transmitting a zone transfer MUST include the full set of
zone data it loaded from the zone's master file, from an incoming
zone transfer, or other similar means of configuring zone data. This
includes any nonauthoritative data ("glue") associated with the zone
by being present in the zone's master file or the incoming transfer
along with the authoritative data. This glue data includes any
configured zone data obscured by zone cuts or otherwise outside the
zone in case; it is not limited to RRs pointed to by NS records.
The purpose of the zone transfer mechanism is to exactly replicate at
each slave the set of RRs associated with a particular zone at its
primary master. An RR is associated with a zone by being loaded from
the master file of that zone at the primary master server, or by some
other, equivalent method for configuring zone data.
The glue RRs are transmitted in the answer section along with the
authoritative data. This is unlike ordinary DNS responses where glue
is transmitted in the authority or additional section.
This replication shall be complete and unaltered, regardless of how
many and which intermediate masters/slaves are involved, and
regardless of what other zones those intermediate masters/slaves do
or do not serve, and regardless of what data may be cached in
resolvers associated with the intermediate masters/slaves.
Zone transfers MUST NOT contain RRs from the authoritative data of
zones other than the one being transferred or from the cache, even
when such RRs are pointed to by NS records in the zone being
transferred.
Therefore, in a zone transfer the master MUST send exactly those
records that are associated with the zone, whether or not their owner
names would be considered to be "in" the zone for purposes of
resolution, and whether or not they would be eligible for use as glue
in responses. The transfer MUST NOT include any RRs that are not
associated with the zone, such as RRs associated with zones other
than the one being transferred or present in the cache of the local
resolver, even if their owner names are in the zone being transferred
or are pointed to by NS records in the zone being transferred.
A slave receiving a zone transfer MUST accept glue data and recognize
it as such; glue MUST NOT be treated as authoritative data nor
entered into the cache. Note that classifying an RR as glue or non-
glue may not be possible until the entire zone has been received so
that the zone cuts defined by the zone's NS records can be
determined. Glue data that is not below the zone origin ("cross-zone
glue") MAY be discarded by the slave.
The slave MUST associate the RRs received in a zone transfer with the
specific zone being transferred, and maintain that association for
purposes of acting as a master in outgoing transfers.
5. Transmission order
@ -210,30 +215,33 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000
zone's apex are transmitted only once.
Therefore, the quoted sentence is hereby changed to read "The first
Expires December 2001 [Page 4]
draft-ietf-dnsext-axfr-clarify-02.txt June 2001
and last RR transmitted must be the SOA record of the zone".
The initial and final SOA record MUST be identical, with the possible
exception of case and compression. In particular, they MUST have the
Expires May 2001 [Page 4]
draft-ietf-dnsext-axfr-clarify-01.txt November 2000
same serial number.
The transmission order of all other RRs in the zone, including glue
records, is undefined.
The transmission order of all other RRs in the zone is undefined.
Each of them MUST be transmitted exactly once. As some older masters
do not comply with this requirement, slaves SHOULD silently ignore
duplicate RRs for interoperability.
6. Security Considerations
The zone transfer protocol as defined in [RFC1034] and clarified by
this memo does not have any built-in mechanisms for the slave to
securely verify the identity of the master server and the integrity
of the transferred zone data. The use of TSIG [RFC2845] for this
purpose is RECOMMENDED.
of the transferred zone data. The use of a cryptographic mechanism
for ensuring authenticity and integrity, such as TSIG [RFC2845],
IPSEC, or TLS, is RECOMMENDED.
The zone transfer protocol allows read-only public access to the
complete zone data. Since data in the DNS is public by definition,
@ -244,6 +252,13 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000
These clarifications are not believed to themselves introduce any new
security problems, nor to solve any existing ones.
Acknowledgements
Many people have contributed input and commentary to earlier versions
of this document, including but not limited to Bob Halley, Dan
Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Levon Esibov,
Mark Andrews, Michael Patton, Peter Koch, and Sam Trenholme.
References
[RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
@ -256,6 +271,14 @@ References
S. Bradner, BCP 14, March 1997.
[RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P.
Expires December 2001 [Page 5]
draft-ietf-dnsext-axfr-clarify-02.txt June 2001
Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
Author's Address
@ -266,21 +289,14 @@ Author's Address
Redwood City, CA 94063
USA
Phone: +1 650 779 6004
Phone: +1 650 381 6004
Email: gson@nominum.com
Expires May 2001 [Page 5]
draft-ietf-dnsext-axfr-clarify-01.txt November 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (2000, 2001). 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
@ -314,20 +330,5 @@ Full Copyright Statement
Expires May 2001 [Page 6]
Expires December 2001 [Page 6]

178
doc/draft/draft-ietf-dnsext-dnssec-roadmap-03.txt → doc/draft/draft-ietf-dnsext-dnssec-roadmap-04.txt
View File

@ -6,52 +6,52 @@
DNEXT Working Group S. Rose
Internet Draft NIST
Expires: November 2001 April 2001
Expires: January 2001 July 2001
Category: Informational
DNS Security Document Roadmap
------------------------------
<draft-ietf-dnsext-dnssec-roadmap-03.txt>
DNS Security Document Roadmap
------------------------------
<draft-ietf-dnsext-dnssec-roadmap-04.txt>
Status of this Document
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
Distribution of this document is unlimited. Comments
regarding this document should be sent to the author.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Distribution of this
document is unlimited. Comments regarding this document should be
sent to the author.
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."
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.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
DNS Security (DNSSEC)technology is composed of extensions
to the Domain Name System (DNS) protocol that provide
data integrity and authentication to security aware
resolvers and applications through the use of
cryptographic digital signatures. Several documents
exist to describe these extensions and the
implementation-specific details regarding specific
digital signing schemes. The interrelationship between
these different documents is discussed here. A brief
DNS Security (DNSSEC)technology is composed of extensions to the
Domain Name System (DNS) protocol that provide data integrity and
authentication to security aware resolvers and applications through
the use of cryptographic digital signatures. Several documents exist
to describe these extensions and the implementation-specific details
regarding specific digital signing schemes. The interrelationship
between these different documents is discussed here. A brief
overview of what to find in which document and author guidelines for
what to include in new DNS Security documents, or revisions to
existing documents, is described.
@ -64,11 +64,6 @@ Rose [Page 1]
INTERNET-DRAFT DNS Security Document Roadmap April 2001
overview of what to find in which document and author
guidelines for what to include in new DNS Security
documents, or revisions to existing documents, is
described.
@ -108,6 +103,11 @@ Table of Contents
@ -206,13 +206,14 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
| RRs | | | | Uses |
| [RFC2538, | | [RFC2535, | | [SSH-DNS] |
| RFC2931, | | RFC3007, | +-------------+
| NO] | | RFC3008, |
| NO, DSIG] | | RFC3008, |
+------------+ | RFC3090, |
| SIZE ] |
| OKBIT, |
| ADBIT, |
| OPTIN, |
| PARSIG ] |
| PARSIG, |
| PARKEY ] |
+-----------+
|
|
@ -224,16 +225,15 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
| Algorithm | | Transactions | * Notes *
| Impl. | | | | |
| [RFC2536, | | [RFC2845, | * [CAIRN, *
| RFC2537 | | RFC2930] | | ROLLOVER ] |
| RFC2539 | | | * *
| RFC2537 | | RFC2930] | | ROLLOVER, |
| RFC2539 | | | * RESROLLOVER ] *
| GSS-TSIG, | | | +-*-*-*-*-*-*-*-*-+
| RSA-SHA] | +---------------+
| RFC3110] | +---------------+
+------------+
Figure 1 DNSSEC Document Roadmap
Rose [Page 4]
@ -259,8 +259,8 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
of the specification to be modified SHOULD be synopsized in the new
document for the benefit of the reader. The "DNSSEC protocol" set
includes the documents [RFC2535], [RFC3007], [RFC3008], [RFC3090],
[SIZE], [OKBIT], [ADBIT], [OPTIN], [PARSIG] and their derivative
documents.
[SIZE], [OKBIT], [ADBIT], [OPTIN], [PARSIG], [PARKEY] and their
derivative documents.
The "New Security RRs" set refers to the group of documents that seek
to add additional Resource Records to the set of base DNS Record
@ -272,7 +272,7 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
that describe how a specific digital signature algorithm is imple-
mented to fit the DNSSEC Resource Record format. Each one of these
documents deals with one specific digital signature algorithm. Exam-
ples of this set include [RFC2536], [RFC2537], [RFC2539], [RSA-SHA]
ples of this set include [RFC2536], [RFC2537], [RFC2539], [RFC3110]
and [GSS-TSIG].
The "Transactions" document set refers to the group of documents that
@ -316,9 +316,10 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
tions, but can also point to places in the protocol specifications
that need improvement. Documents in this set may be offspring of
both the DNSEXT and/or DNSOP Working Groups. Currently, there are
two Internet Drafts that fall under this category: the report on the
CAIRN DNSSEC testbed [CAIRN] and a draft on security key rollover
[ROLLOVER]. These documents were submitted through the DNSOP Working
three Internet Drafts that fall under this category: the report on
the CAIRN DNSSEC testbed [CAIRN] and a draft on security key rollover
[ROLLOVER] and the draft on resolver configured key rollover [RES-
ROLLOVER]. These documents were submitted through the DNSOP Working
Group, however the main concern of these documents is the implementa-
tion and limitations of the DNS security extensions, hence their
interest to the DNS security community. The CAIRN draft deals with
@ -350,7 +351,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
SHOULD be interpreted as a minimum set of information required/needed
in a document, any additional information regarding the specific
extension should also be included in the document. These criteria
are not officially part of the IETF guidelines regarding RFC/Internet
@ -363,6 +363,7 @@ Rose [Page 6]
INTERNET-DRAFT DNS Security Document Roadmap April 2001
are not officially part of the IETF guidelines regarding RFC/Internet
Drafts, but should be considered as guidance to promote uniformity to
Working Group documents.
@ -410,7 +411,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
In addition, authors are encouraged to include any necessary descrip-
tion of the algorithm itself, as well as any know/suspected
weaknesses as an appendix to the document. This is for reference
only, as the goals of the DNSEXT working group is to propose
@ -423,7 +423,8 @@ Rose [Page 7]
INTERNET-DRAFT DNS Security Document Roadmap April 2001
extensions to the DNS protocol, not cryptographic research.
only, as the goals of the DNSEXT working group is to propose exten-
sions to the DNS protocol, not cryptographic research.
4.3 Refinement of Security Procedures
@ -470,7 +471,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
6. Acknowledgements
In addition to the RFCs mentioned in this document, there are also
@ -483,6 +483,7 @@ Rose [Page 8]
INTERNET-DRAFT DNS Security Document Roadmap April 2001
In addition to the RFCs mentioned in this document, there are also
numerous Internet drafts that fall in one or more of the categories
of DNS Security documents mentioned above. Depending on where (and
if) these documents are on the IETF standards track, the reader may
@ -505,8 +506,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
with Minimum Disclosure". <draft-ietf-dnsext-not-existing-rr-NN.txt>
* OKBIT: D. Conrad. "Indicting Resolver Support of DNSSEC".
<draft-ietf-dnsext-dnssec-okbit-NN.txt>
* RSA-SHA: D. Eastlake. "RSA/SHA-1 SIGs and RSA KEYs in the
Domain Name System (DNS)" <draft-ietf-dnsext-rsa-NN.txt>
* ROLLOVER: M. Andrews, D. Eastlake. "Domain Name System (DNS)
Security Key Rollover" <draft-ietf-dnsopt-rollover-NN.txt>.
* ADBIT: B. Wellington. "Redefinition of DNS AD bit" <draft-
@ -515,8 +514,15 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
kosters-dnsext-dnssec-opt-in-NN.txt>
* SSH-DNS: W. Griffin. "Storing SSH Host Keys in DNS" <draft-
griffin-ssh-host-keys-in-dns-NN.txt>
* PARSIG: R. Geiben, T. Lindgreen. "Parent's SIG Over Child's
KEY" <draft-ietf-dnsext-parent-sig-NN.txt>
* PARKEY: R. Geiben, T. Lindgreen. "Parent stores the child's
zone KEYs" <draft-ietf-dnsext-parent-stores-zone-keys-NN.txt>
* PARSIG: R. Geiben, T. Lindgreen. "Parent's SIG over Child's KEY"
<draft-ietf-dnsext-parent-sig-NN.txt>
* DSIG: O. Gudmundsson. "Delegation Signer Record in Parent".
<draft-ietf-dnsext-delegation-signer-NN.txt>
* RESROLLOVER: O. Kolkman, M. Gieben, R. Arends. "Rollover of
statically configured resolver keys". <draft-ietf-dnsop-resolver-
rollover-NN.txt>
7. References
@ -524,13 +530,7 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
[RFC2535] D. Eastlake, "Domain Name System Security Extensions", RFC
2535, March 1999.
[RFC2537] D. Eastlake, "RSA/MD5 KEYs and SIGs in the Domain Name Sys-
tem (DNS)", RFC 2537, March 1999.
[RFC2536] D. Eastlake, "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[RFC2137] D. Eastlake, "Secure Domain Name System Dynamic Update",
[RFC2537] D. Eastlake, "RSA/MD5 KEYs and SIGs in the Domain Name
@ -543,6 +543,12 @@ Rose [Page 9]
INTERNET-DRAFT DNS Security Document Roadmap April 2001
System (DNS)", RFC 2537, March 1999.
[RFC2536] D. Eastlake, "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[RFC2137] D. Eastlake, "Secure Domain Name System Dynamic Update",
RFC 2137, April 1997.
[RFC2539] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
@ -554,9 +560,12 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
[RFC2930] D. Eastlake, "Secret Key Establishment for DNS" RFC 2930,
September 2000.
[RFC2931] D. Eastlake "DNS Request and Transaction Signatures
[RFC2931] D. Eastlake, "DNS Request and Transaction Signatures
(SIG(0))" RFC 2931, September 2000.
[RFC3110] D. Eastlake, "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Name System (DNS)", May 2001.
[RFC3090] E. Lewis "DNS Security Extensions Clarification on Zone
Status" RFC 3090, March 2001.
@ -585,15 +594,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
8. Authors' Addresses
Scott Rose
National Institute for Standards and Technology
Gaithersburg, MD
Email: scott.rose@nist.gov
Rose [Page 10]
@ -603,9 +603,18 @@ Rose [Page 10]
INTERNET-DRAFT DNS Security Document Roadmap April 2001
8. Author's Addresses
Scott Rose
National Institute for Standards and Technology
Gaithersburg, MD
Email: scott.rose@nist.gov
Expiration and File Name:
This draft, titled <draft-ietf-dnsext-dnssec-roadmap-03.txt> expires November
This draft, titled <draft-ietf-dnsext-dnssec-roadmap-04.txt> expires January 2001.
@ -642,15 +651,6 @@ Full Copyright Statement
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 develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
@ -663,6 +663,15 @@ Rose [Page 11]
INTERNET-DRAFT DNS Security Document Roadmap April 2001
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 develop-
ing 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
@ -695,15 +704,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001

112
doc/draft/draft-ietf-dnsext-rfc2782bis-00.txt → doc/draft/draft-ietf-dnsext-rfc2782bis-01.txt
View File

@ -5,10 +5,10 @@
Network Working Group A. Gulbrandsen
Category: INTERNET-DRAFT Trolltech AS
Obsoletes: 2052 P. Vixie
draft-ietf-dnsext-rfc2782bis-00.txt Internet Software Consortium
November 16, 2000 L. Esibov
Expires: May 16, 2001 Microsoft Corp.
Obsoletes: 2782 P. Vixie
draft-ietf-dnsext-rfc2782bis-01.txt Internet Software Consortium
June 6, 2001 L. Esibov
Expires: December 6, 2001 Microsoft Corp.
@ -35,7 +35,7 @@ Status of this Memo
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
@ -63,9 +63,9 @@ Overview and rationale
Expires May 2001 [Page 1]
Expires December 2001 [Page 1]
INTERNET-DRAFT DNS SRV RR Novemeber 2000
INTERNET-DRAFT DNS SRV RR June 2001
Definitions
@ -119,9 +119,9 @@ The format of the SRV RR
Expires May 2001 [Page 2]
Expires December 2001 [Page 2]
INTERNET-DRAFT DNS SRV RR Novemeber 2000
INTERNET-DRAFT DNS SRV RR June 2001
Some widely used services, notably POP, don't have a single
@ -175,9 +175,9 @@ INTERNET-DRAFT DNS SRV RR Novemeber 2000
Expires May 2001 [Page 3]
Expires December 2001 [Page 3]
INTERNET-DRAFT DNS SRV RR Novemeber 2000
INTERNET-DRAFT DNS SRV RR June 2001
specified by the SRV RRs, will be contacted. The following
@ -231,9 +231,9 @@ Domain administrator advice
Expires May 2001 [Page 4]
Expires December 2001 [Page 4]
INTERNET-DRAFT DNS SRV RR Novemeber 2000
INTERNET-DRAFT DNS SRV RR June 2001
suboptimal) fallback hosts for Telnet, NNTP and other protocols
@ -287,9 +287,9 @@ The "Weight" field
Expires May 2001 [Page 5]
Expires December 2001 [Page 5]
INTERNET-DRAFT DNS SRV RR Novemeber 2000
INTERNET-DRAFT DNS SRV RR June 2001
The only way the authors can see of getting a "better" load figure is
@ -337,15 +337,17 @@ Usage rules
the reply:
If there is precisely one SRV RR, and its Target is "."
(the root domain), abort.
(the root domain), abort and do not attempt lookup for
QNAME=domain, QCLASS=IN, QTYPE=A.
Expires May 2001 [Page 6]
INTERNET-DRAFT DNS SRV RR Novemeber 2000
Expires December 2001 [Page 6]
INTERNET-DRAFT DNS SRV RR June 2001
Else, for all such RR's, build a list of (Priority, Weight,
@ -399,9 +401,9 @@ Notes:
Expires May 2001 [Page 7]
Expires December 2001 [Page 7]
INTERNET-DRAFT DNS SRV RR Novemeber 2000
INTERNET-DRAFT DNS SRV RR June 2001
- Future protocols could be designed to use SRV RR lookups as the
@ -455,9 +457,9 @@ Fictional example
Expires May 2001 [Page 8]
Expires December 2001 [Page 8]
INTERNET-DRAFT DNS SRV RR Novemeber 2000
INTERNET-DRAFT DNS SRV RR June 2001
In this example, a client of the "foobar" service in the
@ -483,22 +485,40 @@ IANA Considerations
The IANA has assigned RR type value 33 to the SRV RR. No other IANA
services are required by this document.
Changes from RFC 2052
Changes from RFC 2782
This document obsoletes RFC 2782
Only editorial clarifications were made to this document. Namely
- it was clarified that "Weight" subsection refers to real "random
number" rather than integer number;
- it was clarified that the "Name" used in the owner name of the SRV
record used in "The format of the SRV RR" section is a "Domain"
name;
- the "QNAME=_service._protocol.target" was replaced by
"QNAME=_service._protocol.domain" in "Usage rules" section to
eliminate a possibility of confusion with the Target field of the
SRV record.
- client's behavior when response to a query contains a single SRV
RR and its Target is "." is clarified in "Usage rules" section.
This document obsoletes RFC 2052. The major change from that
previous, experimental, version of this specification is that now the
protocol and service labels are prepended with an underscore, to
lower the probability of an accidental clash with a similar name used
for unrelated purposes. Aside from that, changes are only intended
to increase the clarity and completeness of the document. This
document especially clarifies the use of the Weight field of the SRV
records.
Security Considerations
The authors believe this RR to not cause any new security problems.
Some problems become more visible, though.
Expires December 2001 [Page 9]
INTERNET-DRAFT DNS SRV RR June 2001
- The ability to specify ports on a fine-grained basis obviously
changes how a router can filter packets. It becomes impossible
to block internal clients from accessing specific external
@ -510,18 +530,14 @@ Security Considerations
as servers. This could lead to denial of service.
Expires May 2001 [Page 9]
INTERNET-DRAFT DNS SRV RR Novemeber 2000
- With SRV, DNS spoofers can supply false port numbers, as well as
host names and addresses. Because this vulnerability exists
already, with names and addresses, this is not a new
vulnerability, merely a slightly extended one, with little
practical effect.
References
STD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
@ -557,19 +573,9 @@ References
Expires December 2001 [Page 10]
Expires May 2001 [Page 10]
INTERNET-DRAFT DNS SRV RR Novemeber 2000
INTERNET-DRAFT DNS SRV RR June 2001
Acknowledgements
@ -623,14 +629,14 @@ Authors' Addresses
Expires May 2001 [Page 11]
Expires December 2001 [Page 11]
INTERNET-DRAFT DNS SRV RR Novemeber 2000
INTERNET-DRAFT DNS SRV RR June 2001
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (2001). 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
@ -679,4 +685,4 @@ Acknowledgement
Expires May 16, 2001 [Page 12]
Expires December 6, 2001 [Page 12]

22
doc/draft/draft-ietf-idn-aceid-01.txt → doc/draft/draft-ietf-idn-aceid-02.txt
View File

@ -1,7 +1,8 @@
Internet Draft Naomasa Maruyama
draft-ietf-idn-aceid-01.txt Yoshiro Yoneya
Dec 11, 2000 JPNIC
Expires June 11, 2001
draft-ietf-idn-aceid-02.txt Yoshiro Yoneya
Jun 19, 2000 JPNIC
Expires Dec 19, 2001
Proposal for a determining process of ACE identifier
@ -87,14 +88,15 @@ domain name and those which have an ACE suffix identifier candidate at
the tail of at least one label of the name. These domain names are
collectively called "relevant domain names".
This suspension should be continued until March 1, 2001 00:00:00 UTC.
This suspension should be continued until September 1, 2001
00:00:00 UTC.
2.2 Survey of relevant domain name registration
All registries recognized by ICANN SHOULD conduct a survey about
relevant domain names registered in their zone, and report, no later
than February 10, 2001 00:00:00 UTC, all of the ACE identifier
than August 11, 2001 00:00:00 UTC, all of the ACE identifier
candidates which are used by relevant domain names.
@ -103,7 +105,7 @@ candidates which are used by relevant domain names.
The IDN WG or other organ of IETF or ICANN MUST summarize the
reports and list ACE identifier candidates that are not reported to be
used in registered domain names by February 17, 2001 00:00:00 UTC, and
used in registered domain names by August 18, 2001 00:00:00 UTC, and
select ten to twenty ACE prefix identifier candidates and ten to
twenty ACE suffix identifier candidates for ACE identifiers. Among
these twenty to forty ACE identifiers, one prefix identifier and one
@ -111,7 +113,7 @@ suffix identifier will be used for experiments. Others will be used,
one by one as ACE standard evolves.
The list of ACE identifiers will be sent to IANA, and will be
maintained by IANA from February 24, 2001 00:00:00 UTC. Domain names
maintained by IANA from August 25, 2001 00:00:00 UTC. Domain names
relevant to these identifiers SHOULD NOT be registered in any DNS
zone, except for registration of multilingual domain names compliant
to one of future IDN standards. This new restriction about the domain
@ -125,13 +127,13 @@ immediately after it receives the list.
described in section 2.3 SHOULD NOT be registered in any zone of ICANN
recognized registries except for registration of multilingual domain
names compliant to one of future IDN standards. All ICANN recognized
registries SHOULD implement this restriction no later than March 1,
registries SHOULD implement this restriction no later than September 1,
2001 00:00:00 UTC.
Registration for domain names relevant to ACE identifier
candidates, tentatively suspended by 2.1, but not relevant to ACE
identifiers selected by section 2.3 MAY be reopened from March 1, 2001
00:00:00 UTC.
identifiers selected by section 2.3 MAY be reopened from September 1,
2001 00:00:00 UTC.
3. Use of an ACE identifier in writing an ACE proposal

193
doc/draft/draft-ietf-idn-idna-01.txt → doc/draft/draft-ietf-idn-idna-02.txt
View File

@ -1,9 +1,9 @@
Internet Draft Patrik Faltstrom
draft-ietf-idn-idna-01.txt Cisco
Paul Hoffman
Internet Draft Patrik Faltstrom
draft-ietf-idn-idna-02.txt Cisco
June 16, 2001 Paul Hoffman
Expires in six months IMC & VPNC
Internationalizing Host Names In Applications (IDNA)
Internationalizing Host Names In Applications (IDNA)
Status of this Memo
@ -19,13 +19,11 @@ 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 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.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
@ -58,8 +56,8 @@ the body of the message.
1.1 Design philosophy
To date, the proposals for IDN protocols have required that DNS servers
be updated to handle internationalized host names. Because of this, the
Many proposals for IDN protocols have required that DNS servers be
updated to handle internationalized host names. Because of this, the
person who wanted to use an internationalized host name had to be sure
that their request went to a DNS server that was updated for IDN.
Further, that server could only send queries to other servers that had
@ -69,13 +67,24 @@ these proposals require that resolvers must be updated to use the new
protocols, and in most cases the applications would need to be updated
as well.
Updating all (or even a significant percentage) of the DNS servers in
the world will be difficult, to say the least. Because of this, we have
designed a protocol that requires no updating of any name servers. IDNA
still requires the updating of applications, but once a user has updated
these, she or he could immediately start using internationalized host
names. The cost of implementing IDN would thus be much lower, and the
speed of implementation will be much higher.
These proposals would require that the application protocols that use
host names as protocol elements to change. This is due to the
assumptions and requirements made in those protocols about the
characters that have always been used for host names, and the encoding
of those characters. Other proposals for IDN protocols do not require
changes to DNS servers but still require changes to most application
protocols to handle the new names.
Updating all (or even a significant percentage) of the existing servers
in the world will be difficult, to say the least. Updating applications,
application gateways, and clients to handle changes to the application
protocols is also daunting. Because of this, we have designed a protocol
that requires no updating of any name servers. IDNA still requires the
updating of applications, but only for input and display of names, not
for changes to the protocols. Once a user has updated these, she or he
could immediately start using internationalized host names. The cost of
implementing IDN may thus be much lower, and the speed of implementation
could be much higher.
1.2 Terminology
@ -98,26 +107,29 @@ The interfaces in IDNA can be represented pictorially as:
+------+
| User |
+------+
^
| Input and display: local interface methods
| (pen, keyboard, glowing phosphorus, ...)
+--------------- v -------------------------------+
| +-------------+ |
| | Application | | End system
| +-------------+
| ^
| | API call and return: nameprepped ACE
| v
| +----------+
| | Resolver |
| +----------+ |
+----------------^--------------------------------+
| DNS query and response: nameprepped ACE
v
+-------------+
| DNS servers |
+-------------+
^
|Input and display: local interface methods
|(pen, keyboard, glowing phosphorus, ...)
+-----------------|------------------------------+
| v |
| +--------------------------+ |
| | Application | |
| +--------------------------+ |
| ^ ^ |
| Call to resolver:| |Application-specific |
| nameprepped ACE| |protocol: |
| v |predefined by the | End system
| +----------+ |protocol or defaults |
| | Resolver | |to nameprepped ACE |
| +----------+ | |
| ^ | |
+---------------|----------|---------------------+
DNS protocol:| |
nameprepped ACE| |
v v
+-------------+ +---------------------+
| DNS servers | | Application servers |
+-------------+ +---------------------+
This document uses the generic term "ACE" for an ASCII-compatible
encoding. After the IDN Working Group has chosen a specific ACE, this
@ -125,7 +137,7 @@ document will be updated to refer to just that single ACE. Until that
time, an implementor creating experimental software must choose an ACE
to use, such as RACE or LACE or DUDE.
2.1.1 Users and applications
2.1.1 Entry and display in applications
Applications can accept host names using any character set or sets
desired by the application developer, and can display host names in any
@ -145,6 +157,23 @@ glyphs, the rendering engine for an application SHOULD have an option
for the user to select the preferred display; if it does, rendering the
ACE SHOULD NOT be the default.
Host names are often stored and transported in many places. For example,
they are part of documents such as mail messages and web pages. They are
transported in the many parts of many protocols, such as both the
control commands and the RFC 2822 body parts of SMTP, and the headers
and the body content in HTTP.
In protocols and document formats that define how to handle
specification or negotiation of charsets, IDN host name parts can be
given in any charset allowed by the protocol or document format. If a
protocol or document format only allows one charset, IDN host name parts
must be given in that charset.
All protocols that have host names as protocol elements already have the
capacity for handling host names in the ASCII charset. Thus, IDN host
name parts can be specified in those protocols in the ACE charset, which
is a superset of the ASCII charset that uses the same set of octets.
2.1.2 Applications and resolvers
Applications communicate with resolver libraries through a programming
@ -193,6 +222,42 @@ possible in order to prevent users from seeing the ACE. However, this is
not considered a big problem because so few applications show this type
of resolution to users.
If an application decodes an ACE name but cannot show all of the
characters in the decoded name, such as if the name contains characters
that the output system cannot display, the application SHOULD show the
name in ACE format instead of displaying the name with the replacement
character (U+FFFD). This is to make it easier for the user to transfer
the name correctly to other programs using copy-and-paste techniques.
Programs that by default show the ACE form when they cannot show all the
characters in a name part SHOULD also have a mechanism to show the name
with as many characters as possible and replacement characters in the
positions where characters cannot be displayed.
2.1.5 Automatic detection of ACE
An application which receives a host name SHOULD verify whether or not
the host name is in ACE. This is possible by verifying the prefix in
each of the labels, and seeing whether or not the label is in ACE. This
MUST be done regardless of whether or not the communication channel used
(such as keyboard input, cut and paste, application protocol,
application payload, and so on) has negotiated ACE.
The reason for this requirement is that many applications are not
ACE-aware. Applications that are not ACE-aware will send host names in
ACE but mark the charset as being US-ASCII or some other charset which
has the characters that are valid in [STD13] as a subset.
2.1.6 Bidirectional text
In IDNA, bidirectional text is entered and displayed exactly as it is
specified in ISO/IEC 10646. Both ISO/IEC 10646 and the Unicode standard
have extensive discussion of how to deal with bidirectional text. Any
input mechanism and display mechanism that handles characters from
bidirectional scripts should already conform to those specifications.
Note that the formatting characters that manually change the direction
of display are prohibited by nameprep, thus making the task for input
and display mechanisms easier.
3. Name Server Considerations
@ -209,6 +274,8 @@ passed to an application, it will result in an error being passed to the
application with no error being reported to the name server. Further, no
application will ever ask for a name that is not legal in [NAMEPREP]
because requests always go through [NAMEPREP] before getting to the DNS.
Note that [NAMEPREP] describes how to handle versioning of unallocated
codepoints.
The host name data in zone files (as specified by section 5 of RFC 1035)
MUST be both nameprepped and ACE encoded.
@ -217,7 +284,7 @@ MUST be both nameprepped and ACE encoded.
4. Root Server Considerations
Because there are no changes to the DNS protocols, adopting this
protocol has no effect on the root servers.
protocol has no effect on the DNS root servers.
5. Security Considerations
@ -226,6 +293,17 @@ Much of the security of the Internet relies on the DNS. Thus, any change
to the characteristics of the DNS can change the security of much of the
Internet.
This memo describes an algorithm which encodes characters that are not
valid according to STD3 and STD13 into octet values that are valid. No
security issues such as string length increases or new allowed values
are introduced by the encoding process or the use of these encoded
values, apart from those introduced by the ACE encoding itself.
When detecting an ACE-encoded host name, and decoding the ACE, care must
be taken that the resulting value(s) are valid characters which can be
handled by the application. This is described in more detail in section
2.1.4.
Host names are used by users to connect to Internet servers. The
security of the Internet would be compromised if a user entering a
single internationalized name could be connected to different servers
@ -243,9 +321,6 @@ Internationalized Host Names", draft-ietf-idn-nameprep.
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119.
[RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO
10646", January 1998, RFC 2279.
[STD3] Bob Braden, "Requirements for Internet Hosts -- Communication
Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application
and Support" (RFC 1123), STD 3, October 1989.
@ -255,26 +330,23 @@ and Support" (RFC 1123), STD 3, October 1989.
STD 13, November 1987.
B. Changes from the -00 draft
B. Changes from the -01 draft
Throughout: Changed "RACE" to "ACE" and removed RACE-specific wording.
1.1: Revised whole section to deal with more proposals.
1: Added pointer to the mailing list.
2.1: Clarified the ASCII art
1.3: Removed the [IDNCOMP] comparison section.
2.1.1: Changed the section title. Added the last three paragraphs.
2.1: Added the last paragraph discussing ACEs.
2.1.4: Added the second paragraph.
2.1.2: Changed the discussion of IPv6 APIs to say they are not
standards. Added reference to [STD3].
2.1.6: Added this section.
2.1.3: Added reference to [STD3]. Removed the sentence about making
things smaller.
2.1.5: Added this section.
3: Added reference to [STD3].
3: Added note in the last sentence of second paragraph.
6: Added [STD3], and updated the reference info for [STD13].
Removed [IDNCOMP].
5: Added second and third paragraphs.
C. Authors' Addresses
@ -290,11 +362,4 @@ Paul Hoffman
Internet Mail Consortium and VPN Consortium
127 Segre Place
Santa Cruz, CA 95060 USA
phoffman@imc.org
--
Patrik F„ltstr÷m <paf@cisco.com> Cisco Systems
Consulting Engineer Office of the CSO
Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-8509
PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC
phoffman@imc.org