mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-31 06:25:31 +00:00
Code Issues Releases Wiki Activity

added new drafts and removed obsolete ones

Browse Source
This commit is contained in:
Andreas Gustafsson
2000-03-03 20:50:20 +00:00
parent 37d86b4a61
commit 5a2eb474fb
14 changed files with 5267 additions and 2819 deletions
Download Patch File Download Diff File Expand all files Collapse all files

126
doc/draft/draft-ietf-dnsind-apl-rr-03.txt → doc/draft/draft-ietf-dnsext-apl-rr-00.txt
View File

@@ -1,9 +1,11 @@
INTERNET-DRAFT Peter Koch
Expires: April 2000 Universitaet Bielefeld
Updates: RFC 1035 October 1999
Expires: September 2000 Universitaet Bielefeld
Updates: RFC 1035 March 2000
A DNS RR Type for Lists of Address Prefixes (APL RR)
draft-ietf-dnsind-apl-rr-03.txt
draft-ietf-dnsext-apl-rr-00.txt
Status of this Memo
@@ -45,14 +47,18 @@ Abstract
Domain names herein are for explanatory purposes only and should not
be expected to lead to useful information in real life [RFC2606].
Koch Expires April 2000 [Page 1]
INTERNET-DRAFT DNS APL RR October 1999
Koch Expires September 2000 [Page 1]
INTERNET-DRAFT DNS APL RR March 2000
2. Background
The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
assign addresses and other internet infrastructure elements to
associate addresses and other internet infrastructure elements with
hierarchically built domain names. Various types of resource records
have been defined, especially those for IPv4 and IPv6 [RFC1886]
addresses. In [RFC1101] a method is described to publish information
@@ -82,6 +88,7 @@ INTERNET-DRAFT DNS APL RR October 1999
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
ADDRESSFAMILY 16 bit unsigned value as assigned by IANA
(see IANA Considerations)
PREFIX 8 bit unsigned binary coded prefix length.
@@ -94,11 +101,15 @@ INTERNET-DRAFT DNS APL RR October 1999
family dependent part (7 bit unsigned).
AFDPART address family dependent part. See below.
This document defines the AFDPARTs for address families 1 (IPv4) and
Koch Expires April 2000 [Page 2]
INTERNET-DRAFT DNS APL RR October 1999
Koch Expires September 2000 [Page 2]
INTERNET-DRAFT DNS APL RR March 2000
2 (IPv6). Future revisions may deal with additional address
families.
@@ -149,9 +160,12 @@ INTERNET-DRAFT DNS APL RR October 1999
5.2. Textual Representation of IPv6 Addresses
Koch Expires April 2000 [Page 3]
INTERNET-DRAFT DNS APL RR October 1999
Koch Expires September 2000 [Page 3]
INTERNET-DRAFT DNS APL RR March 2000
The representation of an IPv6 address in the <address> part of an
<apstring> follows [RFC2373], section 2.2. Legal values for <prefix>
@@ -194,17 +208,22 @@ INTERNET-DRAFT DNS APL RR October 1999
o how to deal with APL RR list elements which belong to other
address families, including those not yet defined
o the exact semantics of list elements negated by the "!" character
Possible applications include the publication of address ranges
similar to [RFC1101], description of zones built following [RFC2317]
and in-band access control to limit general access or zone transfer
(AXFR) availability for zone data held in DNS servers.
Koch Expires September 2000 [Page 4]
INTERNET-DRAFT DNS APL RR March 2000
The specification of particular application scenarios is out of the
Koch Expires April 2000 [Page 4]
INTERNET-DRAFT DNS APL RR October 1999
scope of this document.
8. Examples
@@ -242,20 +261,29 @@ INTERNET-DRAFT DNS APL RR October 1999
10. IANA Considerations
This section is to be interpreted as following [RFC2434].
This document does not define any new namespaces. It uses the 16 bit
identifiers for address families maintained by IANA in
ftp://ftp.iana.org/in-notes/iana/assignments/address-family-numbers.
IANA is asked to assign a numeric RR type value for APL.
11. Acknowledgements
Koch Expires September 2000 [Page 5]
INTERNET-DRAFT DNS APL RR March 2000
The author would like to thank Mark Andrews for his review and
constructive comments.
12. References
Koch Expires April 2000 [Page 5]
INTERNET-DRAFT DNS APL RR October 1999
[RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
RFC 1034, STD 13, November 1987
@@ -281,6 +309,10 @@ INTERNET-DRAFT DNS APL RR October 1999
[RFC2373] Hinden,R., Deering,S., "IP Version 6 Addressing
Architecture", RFC 2373, July 1998
[RFC2434] Narten,T., Alvestrand,H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, BCP 26, October
1998
[RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC
2535, March 1999
@@ -291,15 +323,67 @@ INTERNET-DRAFT DNS APL RR October 1999
"Secret Key Transaction Signatures for DNS (TSIG)",
<draft-ietf-dnsind-tsig-XX.txt>, work in progress
13. Author's Address
Peter Koch
Koch Expires September 2000 [Page 6]
INTERNET-DRAFT DNS APL RR March 2000
Universitaet Bielefeld
Technische Fakultaet
Postfach 10 01 31
D-33501 Bielefeld
D-33594 Bielefeld
Germany
+49 521 106 2902
<pk@TechFak.Uni-Bielefeld.DE>
Koch Expires April 2000 [Page 6]
Koch Expires September 2000 [Page 7]

282
doc/draft/draft-ietf-dnsext-edns0dot5-00.txt Normal file
View File

@@ -0,0 +1,282 @@
Network Working Group R. Austein
draft-ietf-dnsext-edns0dot5-00.txt InterNetShare.com, Inc.
H. Alvestrand
EDB MaXware AS
February 2000
A Proposed Enhancement to the EDNS0 Version Mechanism
Status of this document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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>
Distribution of this document is unlimited. Please send comments to
the Namedroppers mailing list <namedroppers@ops.ietf.org>.
Motivation and Scope
EDNS0 [EDNS0] specifies a general framework for extending the packet
format used by the Domain Name System protocols. The framework
includes a simple version numbering scheme to allow the parties in a
DNS protocol exchange to determine which extension features the other
party understands. While having the advantage of simplicity, the
version numbering scheme as specified has drawbacks:
- It provides no way to deprecate a protocol feature;
- It provides no way to deploy experimental protocol features.
Austein & Alvestrand Expires 28 August 2000 [Page 1]
draft-ietf-dnsext-edns0dot5-00.txt February 2000
This note proposes to replace the monolithic version numbering
mechanism with a mechanism for listing an explicit set of protocol
features that a particular implementation supports. We retain
version numbering as a way of abbreviating the feature sets that we
expect to see in common use.
Model
Our revised extension model for EDNS0 is designed with three goals in
mind:
- We want the protocol to be as simple as possible for the common
case of a client or server that implements "mainstream standard
DNS";
- We want to provide a safe way to experiment with new protocol
features, both inside and outside the deployed DNS;
- We want to provide a safe way to deprecate protocol features.
Our revised extension model has two parts, both of which are carried
in the OPT pseudo-RR: the VERSION, which stored in the second octet
of the TTL field of the OPT RR, and a variable-length list of
FEATURES, stored in the variable part of the OPT RR.
All FEATUREs are extensions of the DNS. We reserve FEATURE numbers 1
to 100 for describing features of the original RFC 1034/1035 DNS
specification that we might eventually chose to deprecate.
Any query/response pair can be described as using a set of DNS
FEATUREs. Such features might for instance be:
- Domain binary labels according to [BINARY-LABELS];
- Extended RCODEs (the general principle, not specific values);
- Multi-packet UDP response;
- Increased maximum UDP payload size;
- Character set identification in DNS labels;
- SIG record parsing and checking;
FEATURE numbers are handed out by IANA on a first-come-first-served
basis. Any revised specification of a format or function should have
its own FEATURE number; in the IETF process, any significantly
changed Internet-Draft should have a new FEATURE number assigned for
Austein & Alvestrand Expires 28 August 2000 [Page 2]
draft-ietf-dnsext-edns0dot5-00.txt February 2000
experimentation.
An assigned VERSION number names a set of FEATUREs. VERSION numbers
are assigned by the IETF through a standards action.
Normally, any VERSION number encompasses every FEATURE of all lower
VERSION numbers, but the possibility of removing FEATUREs exists for
two reasons:
- To remove the need for supporting FEATUREs that turned out to be a
Really Bad Idea;
- To allow replacing a badly specified FEATURE with a better
specified FEATURE performing the same function that has a new
FEATURE number.
Mechanism
We propose to transport explicit feature sets as lists of integers
carried in the variable RDATA portion of the EDNS0 OPT pseudo-RR.
The OPTION-CODE for FEATURES is [TBD].
The OPTION-DATA for FEATURES is an ordered list of "feature numbers";
a feature number is represented as a big-endian 16-bit unsigned
integer, and the list is sorted into numerically increasing order.
Each feature number names a particular protocol feature that is
supported by the implementation that generated this OPT pseudo-RR.
Usage
When composing a query message, the client includes an OPT record
indicating the set of FEATUREs that:
- Allows the client to express this query;
- Allows the server to express all responses that the client is
prepared to accept for this query.
This set is expressed as a VERSION and any additional FEATURES
required.
The server will include an OPT pseudo-RR that indicates:
- The highest VERSION numbers supported by the responder (for
information only -- the client takes no action based on this);
Austein & Alvestrand Expires 28 August 2000 [Page 3]
draft-ietf-dnsext-edns0dot5-00.txt February 2000
- The set of FEATUREs not encompassed by the VERSION that are
necessary to express the response.
No FEATURE may be included or used that is not within the set of
FEATUREs that the query originator indicated.
As a special case, if a client explicitly queries for the OPT RR of
the root zone, the server returns an OPT record including all
FEATUREs that the server supports. This functionality is provided
strictly for diagnostic purposes.
Life Cycle
We expect the life cycle of new features to proceed as follows:
- VERSION X is defined and deployed.
- A new FEATURE is defined and experimentally implemented. All
clients and servers part of the experiment use FEATURE to indicate
support.
- Community consensus is reached that this FEATURE is genuinely
useful.
- VERSION X+1 is defined, encompassing all FEATUREs from VERSION X,
plus the new FEATURE (and perhaps others).
- The next generation of DNS software supports VERSION X+1, and never
use FEATURE.
Risks
While we have tried to provide the ability to deprecate old bad
protocol features, such an ability should be used only rarely, if at
all, since by any realistic estimate it takes years (decades?) to
upgrade all the DNS implementations already in the field.
A flexible extension mechanism of this type increases the risk that
some implementors might chose to deploy features designed to hinder
interoperability (so-called "labeled noninteroperability").
Security Considerations
We do not believe that this protocol enhancement adds any new
security risks, but we do believe that it would be helpful in getting
complicated DNS extensions such as [DNSSEC] deployed more quickly.
Austein & Alvestrand Expires 28 August 2000 [Page 4]
draft-ietf-dnsext-edns0dot5-00.txt February 2000
IANA Considerations
IANA will need to allocate an EDNS0 option code for FEATURES.
IANA will need to create a new registry of feature numbers.
References
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and
facilities", RFC 1034, November 1987.
[DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation
and specification", RFC 1035, November 1987.
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999.
[BINARY-LABELS] Crawford, M., "Binary Labels in the Domain Name
System", RFC 2673 August 1999.
Author's addresses:
Rob Austein
InterNetShare.com, Inc.
505 West Olive Ave., Suite 321
Sunnyvale, CA 94086
USA
sra@hactrn.net
Harald Tveit Alvestrand
EDB MaXware AS
Pirsenteret
N-7486 Trondheim
NORWAY
+47 73 54 57 97
Harald@Alvestrand.no
Austein & Alvestrand Expires 28 August 2000 [Page 5]

696
doc/draft/draft-ietf-dnsext-iana-dns-00.txt Normal file
View File

@@ -0,0 +1,696 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
Eric Brunner
Bill Manning
Expires: June 2000 February 2000
Domain Name System (DNS) IANA Considerations
------ ---- ------ ----- ---- --------------
Status of This Document
Distribution of this draft <draft-ietf-dnsext-iana-dns-00.txt>, which
is intended to become a Best Current Practice, is unlimited. Comments
should be sent to the DNS Working Group mailing list
<namedroppers@internic.net> or to the authors.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``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.
Abstract
Internet Assigned Number Authority (IANA) parameter assignment
considerations are given for the allocation of Domain Name System
(DNS) classes, RR types, operation codes, error codes, etc.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 1]
INTERNET-DRAFT DNS IANA Considerations February 2000
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. DNS Query/Response Headers..............................3
2.1 One Spare Bit?.........................................4
2.2 Opcode Assignment......................................4
2.3 RCODE Assignment.......................................5
3. DNS Resource Records....................................5
3.1 RR TYPE IANA Considerations............................7
3.1.1 Special Note on the OPT RR...........................8
3.2 RR CLASS IANA Considerations...........................8
3.3 RR NAME Considerations.................................9
4. Designated Expert......................................10
5. Security Considerations................................10
References................................................10
Authors Addresses.........................................12
Expiration and File Name..................................12
D. Eastlake 3rd, E. Brunner, B. Manning [Page 2]
INTERNET-DRAFT DNS IANA Considerations February 2000
1. Introduction
The Domain Name System (DNS) provides replicated distributed secure
hierarchical databases which hierarchically store "resource records"
(RRs) under domain names.
This data is structured into CLASSes and zones which can be
independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535]
familiarity with which is assumed.
This document covers, either directly or by reference, general IANA
parameter assignment considerations applying across DNS query and
response headers and all RRs. There may be additional IANA
considerations that apply to only a particular RR type or
query/response opcode. See the specific RFC defining that RR type or
query/response opcode for such considerations if they have been
defined.
IANA currently maintains a web page of DNS parameters at
<http://www.isi.edu/in-notes/iana/assignments/dns-parameters>.
"IETF Standards Action", "IETF Consensus", "Specification Required",
and "Private Use" are as defined in [RFC 2434].
2. DNS Query/Response Headers
The header for DNS queries and responses contains field/bits in the
following diagram taken from [RFC 2136, 2535]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The ID field identifies the query and is echoed in the response so
they can be matched.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 3]
INTERNET-DRAFT DNS IANA Considerations February 2000
The QR bit indicates whether the header is for a query or a response.
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. However,
many DNS implementations copy the query header as the initial value
of the response header without clearing bits. Thus any attempt to
use a "query" bit with a different meaning in a response or to define
a query meaning for a "response" bit is dangerous given existing
implementation. Such meanings may only be assigned by an IETF
Standards Action.
The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
authority count (NSCOUNT), and additional information count (ARCOUNT)
express the number of records in each section for all opcodes except
Update. These fields have the same structure and data type for
Update but are instead the counts for the zone (ZOCOUNT),
prerequisite (PRCOUNT), update (UPCOUNT), and additional information
(ARCOUNT) sections.
2.1 One Spare Bit?
There have been ancient DNS implementations for which the Z bit being
on in a query meant that only a response from the primary server for
a zone is acceptable. It is believed that current DNS
implementations ignore this bit.
Assigning a meaning to the Z bit requires an IETF Standards Action.
2.2 Opcode Assignment
New OpCode assignments require an IETF Standards Action.
Currently DNS OpCodes are assigned as follows:
OpCode Name Reference
0 Query [RFC 1035]
1 IQuery (Inverse Query) [RFC 1035]
2 Status [RFC 1035]
3 available for assignment
4 Notify [RFC 1996]
5 Update [RFC 2136]
6-15 available for assignment
D. Eastlake 3rd, E. Brunner, B. Manning [Page 4]
INTERNET-DRAFT DNS IANA Considerations February 2000
2.3 RCODE Assignment
It would appear from the DNS header above that only four bits of
RCODE, or response/error code are available. However, RCODEs can
appear not only at the top level of a DNS response but also inside
TSIG RRs [RFC XXX3] and OPT RRs [RFC 2671]. The OPT RR provides an
eight bit extension resulting in a 12 bit RCODE field and the TSIG RR
has a 16 bit RCODE field.
RCODE Name Description Reference
Decimal
Hexadecimal
0 NoError No Error [RFC 1035]
1 FormErr Format Error [RFC 1035]
2 ServFail Server Failure [RFC 1035]
3 NXDomain Non-Existent Domain [RFC 1035]
4 NotImp Not Implemented [RFC 1035]
5 Refused Query Refused [RFC 1035]
6 YXDomain Name Exists when it should not [RFC 2136]
7 YXRRSet RR Set Exists when it should not [RFC 2136]
8 NXRRSet RR Set that should exist does not [RFC 2136]
9 NotAuth Server Not Authoritative for zone [RFC 2136]
10 NotZone Name not contained in zone [RFC 2136]
11-15 available for assignment
16 BADVERS Bad OPT Version [RFC 2671]
16 BADSIG TSIG Signature Failure [RFC XXX3]
17 BADKEY Key not recognized [RFC XXX3]
18 BADTIME Signature out of time window [RFC XXX3]
19-3840 available for assignment
0x0013-0x0F00
3841-4095 Private Use
0x0F01-0x0FFF
4096-65535 available for assignment
0x1000-0xFFFF
Since it is important that RCODEs be understood for interoperability,
assignment of new RCODE listed above as "available for assignment"
requires an IETF Consensus.
3. DNS Resource Records
All RRs have the same top level format shown in the figure below
taken from [RFC 1035]:
D. Eastlake 3rd, E. Brunner, B. Manning [Page 5]
INTERNET-DRAFT DNS IANA Considerations February 2000
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAME is an owner name, i.e., the name of the node to which this
resource record pertains. NAMEs are specific to a CLASS as described
in section 3.2. NAMEs consist of an ordered sequence of one or more
labels each of which has a label type [RFC 1035, 2671].
TYPE is a two octet unsigned integer containing one of the RR TYPE
codes. See section 3.1.
CLASS is a two octet unsigned integer containing one of the RR CLASS
codes. See section 3.2.
TTL is a four octet (32 bit) bit unsigned integer that specifies the
number of seconds that the resource record may be cached before the
source of the information should again be consulted. Zero is
interpreted to mean that the RR can only be used for the transaction
in progress.
RDLENGTH is an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
RDATA is a variable length string of octets that constitutes the
resource. The format of this information varies according to the
TYPE and in some cases the CLASS of the resource record.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 6]
INTERNET-DRAFT DNS IANA Considerations February 2000
3.1 RR TYPE IANA Considerations
There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
and MetaTYPEs.
Data TYPEs are the primary means of storing data. QTYPES can only be
used in queries. Meta-TYPEs designate transient data associated with
an particular DNS message and in some cases can also be used in
queries. Thus far, data TYPEs have been assigned from 1 upwards plus
the block from 100 through 103 while Q and Meta Types have been
assigned from 255 downwards (except for the OPT Meta-RR which is
assigned TYPE 41). There have been DNS implementations which made
caching decisions based on the top bit of the bottom byte of the RR
TYPE.
There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
[RFC XXX3], and TKEY [work in progress].
There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
AXFR, and IXFR.
Considerations for the allocation of new RR TYPEs are as follows:
Decimal
Hexadecimal
0
0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
2535] and in other circumstances and must never be allocated
for ordinary use.
1 - 127
0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
TYPEs by IETF Consensus.
128 - 255
0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
Meta TYPEs by IETF Consensus.
256 - 32767
0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
Consensus.
32768 - 65279
0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
65280 - 65535
0xFF00 - 0xFFFF - Private Use.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 7]
INTERNET-DRAFT DNS IANA Considerations February 2000
3.1.1 Special Note on the OPT RR
The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its
primary purpose is to extend the effective field size of various DNS
fields including RCODE, label type, OpCode, flag bits, and RDATA
size. In particular, for resolvers and servers that recognize it, it
extends the RCODE field from 4 to 12 bits.
3.2 RR CLASS IANA Considerations
DNS CLASSes have been little used but constitute another dimension of
the DNS distributed database. In particular, there is no necessary
relationship between the name space or root servers for one CLASS and
those for another CLASS. The same name can have completely different
meanings in different CLASSes although the label types are the same
and the null label is usable only as root in every CLASS. However,
as global networking and DNS have evolved, the IN, or Internet, CLASS
has dominated DNS use.
There are two subcategories of DNS CLASSes: normal data containing
classes and QCLASSes that are only meaningful in queries or updates.
The current CLASS assignments and considerations for future
assignments are as follows:
Decimal
Hexadecimal
0
0x0000 - assignment requires an IETF Standards Action.
1
0x0001 - Internet (IN).
2
0x0002 - available for assignment by IETF Consensus as a data CLASS.
3
0x0003 - Chaos (CH) [Moon 81].
4
0x0004 - Hesiod (HS) [Dyer 87].
5 - 127
0x0005 - 0x007F - available for assignment by IETF Consensus as data
CLASSes only.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 8]
INTERNET-DRAFT DNS IANA Considerations February 2000
128 - 253
0x0080 - 0x00FD - available for assignment by IETF Consensus as
QCLASSes only.
254
0x00FE - QCLASS None [RFC 2136].
255
0x00FF - QCLASS Any [RFC 1035].
256 - 32767
0x0100 - 0x7FFF - assigned by IETF Consensus.
32768 - 65280
0x8000 - 0xFEFF - assigned based on Specification Required as defined
in [RFC 2434].
65280 - 65534
0xFF00 - 0xFFFE - Private Use.
65535
0xFFFF - can only be assigned by an IETF Standards Action.
3.3 RR NAME Considerations
DNS NAMEs are sequences of labels [RFC 1035]. The last label in each
NAME is "ROOT" which is the zero length label. By definition, the
null or ROOT label can not be used for any other NAME purpose.
At the present time, there are two categories of label types, data
labels and compression labels. Compression labels are pointers to
data labels elsewhere within an RR or DNS message and are intended to
shorten the wire encoding of NAMEs. The two existing data label
types are frequently referred to as ASCII and Binary. ASCII labels
can, in fact, include any octet value including zero octets but most
current uses involve only [US-ASCII] For retrieval ASCII labels are
defined to treat upper and lower case letters the same. Binary
labels are bit sequences [RFC 2673].
IANA considerations for label types are given in [RFC 2671].
NAMEs are local to a CLASS. The Hesiod [Dyer 87] and Chaos [Moon 81]
CLASSes are essentially for local use. The IN or Internet CLASS is
thus the only DNS CLASS in global use on the Internet at this time.
A somewhat dated description of name allocation in the IN Class is
given in [RFC 1591]. Some information on reserved top level domain
names is in Best Current Practice 32 [RFC 2606].
D. Eastlake 3rd, E. Brunner, B. Manning [Page 9]
INTERNET-DRAFT DNS IANA Considerations February 2000
4. Designated Expert
To provide additional support to IANA in the DNS area, the IESG MAY
appoint a designed expert.
5. Security Considerations
This document addresses IANA considerations in the allocation of
general DNS parameters, not security. See [RFC 2535] for secure DNS
considerations.
References
[Dyer 87] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
Plan - Name Service, April 1987,
[Moon 81] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
Institute of Technology Artificial Intelligence Laboratory, June
1981.
[RFC 1034] - P. Mockapetris, "Domain Names - Concepts and
Facilities", STD 13, November 1987.
[RFC 1035] - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987.
[RFC 1591] - J. Postel, "Domain Name System Structure and
Delegation", March 1994.
[RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", August 1996.
[RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
[RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS
Specification", July 1997.
[RFC 2434] - "Guidelines for Writing an IANA Considerations Section
in RFCs", T. Narten, H. Alvestrand, October 1998.
[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
June 1999.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 10]
INTERNET-DRAFT DNS IANA Considerations February 2000
[RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
1999.
[RFC 2672] - M. Crawford, " Non-Terminal DNS Name Redirection",
August 1999.
[RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
August 1999.
[RFC XXX3] - P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
"Secret Key Transaction Signatures for DNS (TSIG)", xxx 2000 (draft-
ietf-dnsind-tsig-*.txt).
[US-ASCII] - ANSI, "USA Standard Code for Information
Interchange", X3.4, American National Standards Institute: New York,
1968.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 11]
INTERNET-DRAFT DNS IANA Considerations February 2000
Authors Addresses
Donald E. Eastlake 3rd
Motorola
65 Shindegan Hill Road
Carmel, NY 10512 USA
Telephone: +1-914-276-2668 (h)
+1-508-261-5434 (w)
email: dee3@torque.pothole.com
Eric Brunner
1415 Forest Avenue
Portland, ME 04103 USA
Telephone: +1 207-797-0525
email: brunner@world.std.com
Bill Manning
USC/ISI
4676 Admiralty Way, #1001
Marina del Rey, CA 90292 USA
Telephone: +1 310 822 1511
email: bmanning@isi.edu
Expiration and File Name
This draft expires August 2000.
Its file name is draft-ietf-dnsext-iana-dns-00.txt.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 12]

522
doc/draft/draft-ietf-dnsext-sig-zero-00.txt Normal file
View File

@@ -0,0 +1,522 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
UPDATES RFC 2535 Motorola
Expires: September 2000 March 2000
DNS Request and Transaction Signatures ( SIG(0)s )
--- ------- --- ----------- ---------- - ------- -
draft-ietf-dnsext-sig-zero-00.txt
Status of This Document
This draft, file name draft-ietf-dnsext-sig-zero-00.txt, is intended
to become a Proposed Standard RFC updating Proposed Standard [RFC
2535]. Distribution of this document is unlimited. Comments should
be sent to the DNS Working Group mailing list
<namedroppers@internic.net> or to the author. [This is the successor
to draft-ietf-dnsind-sig-zero-01.txt.]
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
Abstract
Extensions to the Domain Name System (DNS) are described in [RFC
2535] that can provide data origin and transaction integrity and
authentication to security aware resolvers and applications through
the use of cryptographic digital signatures.
Implementation experience has indicated the need for minor but non-
interoperable changes in Request and Transaction signature resource
records ( SIG(0)s ). These changes are documented herein.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT DNS SIG(0) March 2000
Acknowledgments
The significant contributions and suggestions of the following
persons (in alphabetic order) to this draft are gratefully
acknowledged:
Olafur Gudmundsson
Brian Wellington
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Acknowledgments............................................2
Table of Contents..........................................2
1. Introduction............................................3
2. SIG(0) Design Rationale.................................3
2.1 Transaction Authentication.............................3
2.2 Request Authentication.................................4
2.3 Keying.................................................4
2.4 Differences Between TSIG and SIG(0)....................4
3. The SIG(0) Resource Record..............................5
3.1 Calculating Request and Transaction SIGs...............6
3.2 Processing Responses and SIG(0) RRs....................7
3.3 SIG(0) Lifetime and Expiration.........................7
4. Security Considerations.................................7
5. IANA Considerations.....................................8
References.................................................8
Author's Address...........................................9
Expiration and File Name...................................9
Appendix: SIG(0) Changes from RFC 2535.....................9
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT DNS SIG(0) March 2000
1. Introduction
This document makes minor but non-interoperable changes to part of
[RFC 2535], familiarity with which is assumed, and includes
additional explanatory text. These changes concern SIG Resource
Records (RRs) that are used to digitally sign DNS requests and
transactions / responses. Such a resource record, because it has a
type covered field of zero, is frequently called a SIG(0). The
changes are based on implementation and attempted implementation
experience with TSIG [draft-ietf-{dnsind|dnsext}-tsig-*.txt] and the
[RFC 2535] specification for SIG(0).
Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2
and 4.3. No changes are made herein related to the KEY or NXT RRs or
to the processing involved with data origin and denial authentication
for DNS data.
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. SIG(0) Design Rationale
The authenticated data origin and data existence denial services of
secure DNS protect only regular data resource records (RRs) or
authenticatably deny their nonexistence. These services provide no
protection for glue records, DNS requests, no protection for message
headers on requests or responses, and no protection of the overall
integrity of a response.
If header bits are falsely set or the like by a bad server, there is
little that can be done. However, it is possible to add transaction
and query authentication to be sure that queries and responses and
not tampered with in transit.
2.1 Transaction Authentication
Transaction authentication means that a requester can be sure it is
at least getting the messages from the server it queried and that the
response is from the request it sent (i.e., that these messages have
not been diddled in transit). This is accomplished by optionally
adding either a TSIG RR [draft-ietf-{dnsind|dnsext}-tsig-*.txt] or,
as described herein, a SIG(0) resource record at the end of the
response which digitally signs the concatenation of the server's
response and the corresponding resolver query.
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT DNS SIG(0) March 2000
2.2 Request Authentication
Requests can also be authenticated by including a TSIG or, as
described herein, a special SIG(0) RR at the end of the request.
Authenticating requests serves no function in DNS servers the predate
the specification of dynamic update. Requests with a non-empty
additional information section produce error returns or may even be
ignored by a few such older DNS servers. However, this syntax for
signing requests is defined for authenticating dynamic update
requests [RFC 2136], TKEY requests [draft-ietf-dnsext-tkey-*.txt], or
future requests requiring authentication.
2.3 Keying
The private keys used in transaction security belong to the host
composing the DNS response message, not to the zone involved.
Request authentication may also involve the private key of the host
or other entity composing the request or of a zone to be affected by
the request or other private keys depending on the request authority
it is sought to establish. The corresponding public key(s) are
normally stored in and retrieved from the DNS for verification as KEY
RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY).
Because requests and replies are highly variable, message
authentication SIGs can not be pre-calculated. Thus it will be
necessary to keep the private key on-line, for example in software or
in a directly connected piece of hardware.
2.4 Differences Between TSIG and SIG(0)
There are significant differences between TSIG and SIG(0).
Because TSIG involves secret keys installed at both the requester and
server the presence of such a key implies that the other party
understands TSIG and likely has the same key installed. Furthermore,
TSIG uses keyed hash authentication codes which are relatively
inexpensive to compute. Thus it is common to authenticate requests
with TSIG and responses are authenticated with TSIG if the
corresponding request is authenticated.
SIG(0) on the other hand, uses public key authentication, where the
public keys are stored in DNS as KEY RRs. Thus, existence of such a
KEY RR does not necessarily imply implementation of SIG(0). In
addition, SIG(0) involves relatively expensive public key
cryptographic operations that should be minimized and the
verification of a SIG(0) involves obtaining and verifying the
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT DNS SIG(0) March 2000
corresponding KEY which can be an expensive and lengthy operation.
Indeed, a policy of using SIG(0) on all requests and verifying it
before responding would, for some configurations, lead to a deadly
embrace with the attempt to obtain and verify the KEY needed to
authenticate the request SIG(0) resulting in additional requests
accompanied by a SIG(0) leading to further requests accompanied by a
SIG(0), etc. Furthermore, omitting SIG(0)s when not required on
requests halves the number of public key operations required by the
transaction.
For these reasons, SIG(0)s SHOULD only be used on requests when
necessary to authenticate that the requester has some required
privilege or identity. SIG(0)s on replies are defined in such a way
as to not require a SIG(0) on the corresponding request and still
provide transaction protection. Some responses, such as those
involving TKEY [draft-ietf-dnsext-tkey-*.txt], MUST be authenticated
with TSIG or SIG(0). For other replies, whether they are
authenticated by the server or required to be authenticated by the
requester SHOULD be a local configuration option.
3. The SIG(0) Resource Record
The structure of and type number of SIG resource records (RRs) is
given in [RFC 2535] Section 4.1. However all of Section 4.1.8.1 and
the parts of Sections 4.2 and 4.3 related to SIG(0) should be
considered replaced by the material below. Any conflict between [RFC
2535] and this document concerning SIG(0) RRs should be resolved in
favor of this document.
For all transaction SIG(0)s, the signer field MUST be the name of the
originating server host and there MUST be a KEY RR at that name with
the public key corresponding to the private key used to calculate the
signature. (The inverse IP address mapping name for an IP address of
the server MAY be used if the relevant KEY is stored there.)
For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are
meaningless. The TTL fields SHOULD be zero and the CLASS filed
SHOULD be ANY. To conserve space, the owner name SHOULD be root (a
single zero octet). When SIG(0) authentication on a response is
desired, that SIG RR must be considered the highest priority of any
additional information for inclusion in the response. If the SIG(0)
RR cannot be added without causing the message to be truncated, the
server MUST alter the response so that a SIG(0) can be included.
This response consists of only the question and a SIG(0) record, and
has the TC bit set and RCODE 0 (NOERROR). The client should at this
point retry the request using TCP.
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT DNS SIG(0) March 2000
3.1 Calculating Request and Transaction SIGs
A DNS request may be optionally signed by including one or more
SIG(0)s at the end of the query additional information section. Such
SIGs are identified by having a "type covered" field of zero. They
sign the preceding DNS request message including DNS header but not
including the UDP/IP header or any request SIG(0)s at the end and
before the request RR counts have been adjusted for the inclusions of
any request SIG(0)s.
Note: requests and response can either have a single TSIG or one or
more SIG(0)s but not both a TSIG and a SIG(0).
They are calculated by using a "data" (see [RFC 2535], Section 4.1.8)
of (1) the SIG's RDATA section omitting the signature subfield
itself, (2) the entire DNS query messages, including DNS header, but
not the UDP/IP header or any SIG(0) and before the reply RR counts
have been adjusted for the inclusion of any SIG(0). That is
data = RDATA | request - SIG(0)s
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
calculated less the signature itself.
Similarly, a SIG(0) can be used to secure a response and the request
that produced it. Such transaction signatures are calculated by
using a "data" of (1) the SIG's RDATA section omitting the signature
itself, (2) the entire DNS query message that produced this response,
including the query's DNS header and any SIG(0)s but not its UDP/IP
header, and (3) the entire DNS response message, including DNS header
but not the UDP/IP header or any SIG(0) and before the response RR
counts have been adjusted for the inclusion of any SIG(0).
That is
data = RDATA | full query | response - SIG(0)s
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
calculated less the signature itself.
Verification of a response SIG(0) (which is signed by the server host
key, not the zone key) by the requesting resolver shows that the
query and response were not tampered with in transit, that the
response corresponds to the intended query, and that the response
comes from the queried server.
In the case of a DNS message via TCP, a SIG(0) on the first data
packet is calculated with "data" as above and for each subsequent
packet, it is calculated as follows:
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT DNS SIG(0) March 2000
data = RDATA | DNS payload - SIG(0)s | previous packet
where "|" is concatenations, RDATA is as above, and previous packet
is the previous DNS payload including DNS header and any SIG(0)s but
not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an
alternative, TSIG may be used after, if necessary, setting up a key
with TKEY [draft-ietf-dnsext-tkey-*.txt].
Except where needed to authenticate an update, TKEY, or similar
privileged request, servers are not required to check request SIGs.
3.2 Processing Responses and SIG(0) RRs
If a SIG RR is at the end of the additional information section of a
response and has a type covered of zero, it is a transaction
signature covering the response and the query that produced the
response. For TKEY responses, it MUST be checked and the message
rejected if the checks fail unless otherwise specified for the TKEY
mode in use. For all other responses, it MAY be checked and the
message rejected if the checks fail.
If a response SIG(0) checks succeed, such a transaction
authentication SIG does NOT directly authenticate the validity any
data-RRs in the message. However, it authenticates that they were
sent by the queried server and have not been diddled. (Only a proper
SIG(0) RR signed by the zone or a key tracing its authority to the
zone or to static resolver configuration can directly authenticate
data-RRs, depending on resolver policy.) If a resolver or server does
not implement transaction and/or request SIGs, it MUST ignore them
without error where they are optional and treat them as failing where
they are required.
3.3 SIG(0) Lifetime and Expiration
The inception and expiration times in SIG(0)s are for the purpose of
resisting replay attacks. They should be set to form a time bracket
such that messages outside that bracket can be ignored. In IP
networks, this time bracket should not normally extend further than 5
minutes into the past and 5 minutes into the future.
4. Security Considerations
No additional considerations beyond those in [RFC 2535].
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT DNS SIG(0) March 2000
The inclusion of the SIG(0) inception and expiration time under the
signature improves resistance to replay attacks.
5. IANA Considerations
No new fields are created or field values assigned by the document.
References
[RFC 1982] - Robert Elz, Randy Bush, "Serial Number Arithmetic",
09/03/1996.
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
[draft-ietf-{dnsind|dnsext}-tsig-*.txt] - P. Vixie, O. Gudmundsson,
D. Eastlake, B. Wellington, "Secret Key Transaction Signatures for
DNS (TSIG)".
[draft-ietf-dnsext-tkey-*.txt] - D. Eastlake, "Secret Key
Establishment for DNS (RR)"
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT DNS SIG(0) March 2000
Author's Address
Donald E. Eastlake 3rd
Motorola
65 Shindegan Hill Road
Carmel, NY 10512 USA
Telephone: +1-914-276-2668(h)
+1-508-261-5434(w)
fax: +1-508-261-4447(w)
email: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires September 2000.
Its file name is draft-ietf-dnsext-sig-zero-00.txt.
Appendix: SIG(0) Changes from RFC 2535
Add explanatory text concerning the differences between TSIG and
SIG(0).
Change the data over which SIG(0) is calculated to include the SIG(0)
RDATA other than the signature itself so as to secure the signature
inception and expiration times and resist replay attacks. Specify
SIG(0) for TCP.
Add discussion of appropriate inception and expiration times for
SIG(0).
Add working to indicate that either a TSIG or one or more SIG(0)s may
be present but not both.
Reword some areas for clarity.
D. Eastlake 3rd [Page 9]

390
doc/draft/draft-ietf-dnsext-signing-auth-00.txt Normal file
View File

@@ -0,0 +1,390 @@
DNSIND Working Group Brian Wellington (NAILabs)
INTERNET-DRAFT January 2000
<draft-ietf-dnsext-signing-auth-00.txt>
Updates: RFC 2535
Domain Name System Security (DNSSEC) Signing Authority
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
Comments should be sent to the authors or the DNSIND WG mailing list
namedroppers@internic.net.
This draft expires on July 31, 2000.
Copyright Notice
Copyright (C) The Internet Society (2000). All rights reserved.
Abstract
This document proposes a revised model of Domain Name System Security
(DNSSEC) Signing Authority. The revised model is designed to clarify
earlier documents and add additional restrictions to simplify the
Expires July 2000 [Page 1]
INTERNET-DRAFT DNSSEC Signing Authority January 2000
secure resolution process. Specifically, this affects the
authorization of keys to sign sets of records.
1 - Introduction
This document defines additional restrictions on DNSSEC signatures (SIG)
records relating to their authority to sign associated data. The intent
is to establish a standard policy followed by a secure resolver; this
policy can be augmented by local rules. This builds upon [RFC2535] and
updates section 2.3.6.
The most significant change is that in a secure zone, zone data is
required to be signed by the zone key.
Familiarity with the DNS system [RFC1034, RFC1035] and the DNS security
extensions [RFC2535] is assumed.
2 - The SIG Record
A SIG record is normally associated with an RRset, and ``covers'' (that
is, demonstrates the authenticity and integrity of) the RRset. This is
referred to as a ``data SIG''. Note that there can be multiple SIG
records covering an RRset, and the same validation process should be
repeated for each of them. Some data SIGs are considered ``material'',
that is, relevant to a DNSSEC capable resolver, and some are
``immaterial'' or ``extra-DNSSEC'', as they are not relevant to DNSSEC
validation. Immaterial SIGs may have application defined roles. SIG
records may exist which are not bound to any RRset; these are also
considered immaterial. The validation process determines which SIGs are
material; once a SIG is shown to be immaterial, no other validation is
necessary.
SIGs may also be used for transaction security. In this case, a SIG
record with a type covered field of 0 is attached to a message, and is
used to protect message integrity. This is referred to as a SIG(0).
The following sections define requirements for all of the fields of a
SIG record. These requirements MUST be met in order for a DNSSEC
capable resolver to process this signature. If any of these
requirements are not met, the SIG cannot be further processed.
Additionally, once a KEY has been identified as having generated this
SIG, there are requirements that it MUST meet.
Expires July 2000 [Page 2]
INTERNET-DRAFT DNSSEC Signing Authority January 2000
2.1 - Type Covered
For a data SIG, the type covered MUST be the same as the type of data in
the associated RRset. For a SIG(0), the type covered MUST be 0.
2.2 - Algorithm Number
The algorithm specified in a SIG MUST be recognized by the client, and
it MUST be an algorithm that has a defined SIG rdata format.
2.3 - Labels
The labels count MUST be less than or equal to the number of labels in
the SIG owner name, as specified in [RFC2535, section 4.1.3].
2.4 - Original TTL
The original TTL MUST be greater than or equal to the TTL of the SIG
record itself, since the TTL cannot be increased by intermediate
servers. This field can be ignored for SIG(0) records.
2.5 - Signature Expiration and Inception
The current time at the time of validation MUST lie within the validity
period bounded by the inception and expiration times.
2.6 - Key Tag
There are no restrictions on the Key Tag field, although it is possible
that future algorithms will impose contraints.
2.7 - Signer's Name
The signer's name field of a data SIG MUST contain the name of the zone
to which the data and signature belong. The combination of signer's
name, key tag, and algorithm MUST identify a zone key if the SIG is to
be considered material. As this document defines a standard policy,
this can be overriden by local configuration.
There are no restrictions on the signer field of a SIG(0) record. The
combination of signer's name, key tag, and algorithm MUST identify a key
if this SIG(0) is to be processed.
Expires July 2000 [Page 3]
INTERNET-DRAFT DNSSEC Signing Authority January 2000
2.8 - Signature
There are no restrictions on the signature field. The signature will be
verified at some point, but does not need to be examined prior to pre-
verification unless a future algorithm imposes constraints.
3 - The Signing KEY Record
Once a signature has been examined and its fields validated (but before
the signature has been verified), the resolver attempts to locate a KEY
that matches the signer name, key tag, and algorithm fields in the SIG.
If one is not found, the SIG cannot be verified and is considered
immaterial. If KEYs are found, several fields of the KEY record MUST
have specific values if the SIG is to be considered material and
authorized. If there are multiple KEYs, the following checks are
performed on all of them, as there is no way to determine which one
generated the signature until the verification is performed.
3.1 - Type Flags
The signing KEY record MUST have a flags value of 00 or 01
(authentication allowed, confidentiality optional) [RFC2535, 3.1.2]. If
a key is not permitted to authenticate data, a DNSSEC resolver MUST NOT
trust any signature that it generates.
3.2 - Name Flags
The interpretation of this field is considerably different for data SIGs
and SIG(0) records.
3.2.1 - Data SIG
If the SIG record covers an RRset, the name type of the associated KEY
MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535, section
2.3.6. The DNSSEC validation process performed by a resolver MUST
ignore all keys that are not zone keys unless local policy dictates
otherwise.
The primary reason that host and/or user keys were allowed to generate
material DNSSEC signatures was to allow dynamic update without online
zone keys. The desire to avoid online signing keys cannot be achieved,
though, because they are necessary to sign NXT and SOA sets [SSU].
These online zone keys can sign any incoming data, thus removing the
need for host/user key signatures stored in the DNS.
Expires July 2000 [Page 4]
INTERNET-DRAFT DNSSEC Signing Authority January 2000
This simplifies the validation process. If data must be signed by a
zone key, determining whether a key is authorized to sign an RRset
requires finding the enclosing zone of the RRset, and following a chain
of trusted zone keys to a known trusted key (which may be the DNS root
key). If host and user keys were permitted to generate material
signatures, following a chain of trust to a trusted DNSSEC key could
involve any number of non-zone keys and a non-trivial amount of work to
determine if all such keys have the proper authority.
Finally, there is no additional flexibility granted by allowing
host/user key generated material signatures. As long as users and hosts
have the ability to authenticate update requests to the primary zone
server, signatures by zone keys are sufficient to protect the integrity
of the data to the world at large.
3.2.2 - SIG(0)
If the SIG record is a SIG(0) protecting a message, the name type of the
associated KEY SHOULD be 00 (user) or 10 (host/entity). Transactions
are initiated by a host or user, not a zone, so zone keys SHOULD not
generate SIG(0) records.
A client is either explicitly executed by a user or on behalf of a host,
therefore the name type of a SIG(0) generated by a client SHOULD be
either user or host. A nameserver is associated with a host, and its
use of SIG(0) is not associated with a particular zone, so the name type
of a SIG(0) generated by a nameserver SHOULD be host.
3.3 - Signatory Flags
This document does not assign any values to the signatory field, nor
require any values to be present.
3.4 - Protocol
The signing KEY record MUST have a protocol value of 3 (DNSSEC) or 255
(ALL). If a key is not specified for use with DNSSEC, a DNSSEC resolver
MUST NOT trust any signature that it generates.
3.5 - Algorithm Number
The algorithm field MUST be identical to that of the generated SIG
record, and MUST meet all requirements for an algorithm value in a SIG
record.
Expires July 2000 [Page 5]
INTERNET-DRAFT DNSSEC Signing Authority January 2000
4 - Security considerations
This document defines a standard baseline for a DNSSEC capable resolver.
This is necessary for a thorough security analysis of DNSSEC, if one is
to be done.
Specifically, this document places additional restrictions on SIG
records that a resolver must validate before the signature can be
considered worthy of DNSSEC trust. This simplifies the protocol, making
it more robust and able to withstand scrutiny by the security community.
5 - Acknowledgements
The author would like to thank the following people for review and
informative comments (in alphabetical order):
Olafur Gudmundsson
Ed Lewis
6 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, ISI, November 1987.
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
& Cisco & DEC, April 1997.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC
2065, IBM, March 1999.
[SSU] B. Wellington, ``Simple Secure Domain Name System (DNS)
Dynamic Update,'' draft-ietf-dnsext-simple-secure-
update-00.txt, NAILabs, January 2000.
Expires July 2000 [Page 6]
INTERNET-DRAFT DNSSEC Signing Authority January 2000
7 - Author's Address
Brian Wellington
NAILabs
Network Associates
3060 Washington Road (Rt. 97)
Glenwood, MD 21738
+1 443 259 2369
<bwelling@tislabs.com>
8 - Full Copyright Statement
Copyright (C) The Internet Society (2000). 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 implmentation 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."
Expires July 2000 [Page 7]

501
doc/draft/draft-ietf-dnsext-simple-secure-update-00.txt Normal file
View File

@@ -0,0 +1,501 @@
DNSIND Working Group Brian Wellington (NAILabs)
INTERNET-DRAFT January 2000
<draft-ietf-dnsext-simple-secure-update-00.txt>
Updates: RFC 2535, RFC 2136,
Replaces: RFC 2137, [update2]
Simple Secure Domain Name System (DNS) Dynamic Update
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
Comments should be sent to the authors or the DNSIND WG mailing list
namedroppers@internic.net.
This draft expires on July 31, 2000.
Copyright Notice
Copyright (C) The Internet Society (2000). All rights reserved.
Abstract
This document proposes a method for performing secure Domain Name
System (DNS) dynamic updates. The method described here is intended
Expires July 2000 [Page 1]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
to be flexible and useful while requiring as few changes to the
protocol as possible. The authentication of the dynamic update
message is separate from later DNSSEC validation of the data. Secure
communication based on authenticated requests and transactions is
used to provide authorization.
1 - Introduction
This document defines a means to secure dynamic updates of the Domain
Name System (DNS), allowing only authorized sources to make changes to a
zone's contents. The existing unsecured dynamic update operations form
the basis for this work.
Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update
[RFC2136] is helpful and is assumed by this document. In addition,
knowledge of DNS security extensions [RFC2535], SIG(0) transaction
security [RFC2535], and TSIG transaction security [TSIG] is recommended.
This document updates portions of RFC 2535, in particular section 3.1.2.
This document obsoletes RFC 2137, an alternate proposal for secure
dynamic update, due to implementation experience.
1.1 - Overview of DNS Dynamic Update
DNS dynamic update defines a new DNS opcode and a new interpretation of
the DNS message if that opcode is used. An update can specify
insertions or deletions of data, along with prerequisites necessary for
the updates to occur. All tests and changes for a DNS update request
are restricted to a single zone, and are performed at the primary server
for the zone. The primary server for a dynamic zone must increment the
zone SOA serial number when an update occurs or before the next
retrieval of the SOA.
1.2 - Overview of DNS Transaction Security
Exchanges of DNS messages which include TSIG [TSIG] or SIG(0) [RFC2535]
records allow two DNS entities to authenticate DNS requests and
responses sent between them. A TSIG MAC (message authentication code)
is derived from a shared secret, and a SIG(0) is generated from a
private key whose public counterpart is stored in DNS. In both cases, a
record containing the message signature/MAC is included as the final
resource record in a DNS message. Keyed hashes, used in TSIG, are
inexpensive to calculate and verify. Public key encryption, as used in
SIG(0), is more scalable as the public keys are stored in DNS.
Expires July 2000 [Page 2]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
1.3 - Comparison of data authentication and message authentication
DNSSEC SIG records can be used to protect the integrity of individual
RRs or RRsets in an update message. However, this cannot sufficiently
protect the dynamic update request.
SIG records do not cover the message header, which includes record
counts. Therefore, it is possibly to maliciously insert or remove
RRsets without causing a verification failure.
A SIG record can be used to protect the contents of the zone section (an
SOA record). Including such a SIG record in the zone section violates
the dynamic update protocol.
If SIG records were used to protect the prerequisite section, it would
be impossible to determine whether the SIGs themselves were a
prerequisite or simply used for validation.
In the update section, signing requests to add an RRset is
straightforward, and this signature could be permanently used to protect
the data, as specified in [RFC2535]. However, if an RRset is deleted,
there is no data for a SIG to cover.
Requiring SIGs in the zone, prerequisite, and update sections might be a
feasible solution. Multiple signatures would be generated and verified
for each update, though, which requires considerable processing time.
Message based authentication, using TSIG or SIG(0), avoids all of these
problems. Only one signature/MAC is generated for the entire message,
and it protects the integrity of the message header and all sections, as
well as having the advantage that only one verification is performed.
1.4 - Data and message signatures
As specified in [signing-auth], the DNSSEC validation process performed
by a resolver MUST NOT process any non-zone keys unless local policy
dictates otherwise. When performing secure dynamic update, all zone
data modified in a signed zone MUST be signed by a relevant zone key.
This completely disassociates authentication of an update request from
authentication of the data itself.
The primary usefulness of host and user keys, with respect to DNSSEC, is
to authenticate messages, including dynamic updates. Thus, host and
user keys MAY be used to generate SIG(0) records to authenticate updates
and MAY be used in the TKEY [TKEY] process to generate TSIG shared
secrets. In both cases, no SIG records generated by non-zone keys will
be used in a DNSSEC validation process unless local policy dictates.
Expires July 2000 [Page 3]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
Authentication of data, once it is present in DNS, only involves DNSSEC
zone keys and signatures generated by them.
1.5 - Signatory strength
[RFC2535, section 3.1.2] defines the signatory field of a key as the
final 4 bits of the flags field, but does not define its value. This
proposal leaves this field undefined. Updating [RFC2535], this field
SHOULD be set to 0 in KEY records, and MUST be ignored.
2 - Authentication
TSIG or SIG(0) records MUST be included in all secure dynamic update
messages. This allows the server to verifiably determine the originator
of a message. If the message contains authentication in the form of a
SIG(0), the identity of the sender (that is, the principal) is the owner
of the KEY RR that generated the SIG(0). If the message contains a TSIG
generated by a statically configured shared secret, the principal is the
same as or derived from the shared secret name. If the message contains
a TSIG generated by a dynamically configured shared secret, the
principal is the same as the one that authenticated the TKEY process; if
the TKEY process was unauthenticated, no information is known about the
principal, and the associated TSIG shared secret MUST NOT be used for
secure dynamic update.
SIG(0) signatures SHOULD NOT be generated by zone keys, since
transactions are initiated by a host or user, not a zone.
DNSSEC SIG records (other than SIG(0)) MAY be included in an update
message, but MUST NOT be used to authenticate the update request.
If an update fails because it is signed with an unauthorized key, the
server MUST indicate failure by returning a message with RCODE REFUSED.
Other TSIG, SIG(0), or dynamic update errors are returned as specified
in the appropriate protocol description.
Expires July 2000 [Page 4]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
3 - Policy
All policy is configured by the zone administrator and enforced by the
zone's primary name server. Policy dictates the authorized actions that
an authenticated principal can take. Policy checks are based on the
principal and the desired action, where the principal is derived from
the message signing key and applied to dynamic update messages signed
with that key.
The server's policy defines criteria which determine if the key used to
sign the update is permitted to perform the requested updates. By
default, a principal MUST NOT be permitted to make any changes to zone
data; any permissions MUST be enabled though configuration.
The policy is fully implemented in the primary zone server's
configuration for several reasons. This removes limitations imposed by
encoding policy into a fixed number of bits (such as the KEY RR's
signatory field). Policy is only relevant in the server applying it, so
there is no reason to expose it. Finally, a change in policy or a new
type of policy should not affect the DNS protocol or data format, and
should not cause interoperability failures.
3.1 - Standard policies
Implementations SHOULD allow access control policies to use the
principal as an authorization token, and MAY also allow policies to
grant permission to a signed message regardless of principal.
A common practice would be to restrict the permissions of a principal by
domain name. That is, a principal could be permitted to add, delete, or
modify entries corresponding to one or more domain names.
Implementations SHOULD allow per-name access control, and SHOULD provide
a concise representation of the principal's own name, its subdomains,
and all names in the zone.
Additionally, a server SHOULD restrict updates by RR type, so that a
principal could add, delete, or modify specific record types at certain
names. Implementations SHOULD allow per-type access control, and SHOULD
provide concise representations of all types and all ``user'' types,
where a user type is defined as one that does not affect the operation
of DNS itself.
3.1.1 - User types
User types include all data types except SOA, NS, SIG, and NXT. SOA and
NS SHOULD NOT be modified by normal users, since these types create or
Expires July 2000 [Page 5]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
modify delegation points. The addition of SIG records can lead to
attacks resulting in additional workload for resolvers, and the deletion
of SIG records could lead to extra work for the server if the zone SIG
was deleted. Note that these records are not forbidden, but not
recommended for normal users.
NXT records MUST NOT be created, modified, or deleted by dynamic update,
as their update may cause instability in the protocol. This is an
update to RFC 2136.
Issues concerning updates of KEY records are discussed in the Security
Considerations section.
3.2 - Additional policies
Users are free to implement any policies. Policies may be as specific
or general as desired, and as complex as desired. They may depend on
the principal or any other characteristics of the signed message.
4 - Interaction with DNSSEC
An authorized update request MAY include SIG records with each RRset.
Since SIG records (except SIG(0) records) MUST NOT be used for
authentication of the update message, they are not required. If the
updated zone is secured, the data affected by an update operation MUST
be secured by one or more SIG records. For each RRset, if the update
includes a valid signature by a zone key, this signature SHOULD be
reused. Otherwise, the server MUST generate SIG records with one or
more zone keys (of which the private components MUST be online). If
multiple zone keys are online and an RRset requires a signature, a SIG
MUST be generated by at least one of the zone keys.
If a principal is authorized to add SIG records and there are SIG
records in the request, the following rules are applied. If the SIG was
generated by a zone key for the relevant zone, verification is attempted
(the public key must be available if the determination that it is a zone
key was made). If successful, the SIG is retained; otherwise, the SIG
is dropped. Otherwise, the SIG is retained without verification, since
it is considered immaterial to the DNSSEC validation process. The
server MAY examine SIG records and drop SIGs with a temporal validity
period in the past. At the completion of the update process, each
updated RRset must be signed in accordance with the zone's signing
policy; the SIGs must either be included in the update or generated by
the server.
The server MUST also, if necessary, generate a new SOA record and new
NXT records, and sign these with the appropriate zone keys. NXT records
Expires July 2000 [Page 6]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
are explicitly forbidden. SOA updates are allowed, since the
maintenance of SOA parameters is outside of the scope of the DNS
protocol.
5 - Security considerations
This document requires that a zone key and possibly other cryptographic
secret material be held in an on-line, network-connected host, most
likely a name server. This material is at the mercy of host security to
remain a secret. Exposing this secret puts DNS data at risk of
masquerade attacks. The data at risk is that in both zones served by
the machine and delegated from this machine.
Allowing updates of KEY records may lead to undesirable results, since a
principal may be allowed to insert a public key without holding the
private key, and possibly masquerade as the key owner.
6 - Acknowledgements
The author would like to thank the following people for review and
informative comments (in alphabetical order):
Donald Eastlake
Olafur Gudmundsson
Andreas Gustafsson
Bob Halley
Stuart Kwan
Ed Lewis
7 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, ISI, November 1987.
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
& Cisco & DEC, April 1997.
[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC
2137, CyberCash, April 1997.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC
2065, IBM, March 1999.
Expires July 2000 [Page 7]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
[TSIG] P. Vixie (Ed.), O. Gudmundsson, D. Eastlake, B. Wellington
``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
ietf-dnsind-tsig-13.txt, ISC & NAILabs & IBM & NAILabs,
December 1999.
[TKEY] D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),''
draft-ietf-dnsind-tkey-03.txt, IBM, December 1999.
[signing-auth]
B. Wellington ``Domain Name System Security (DNSSEC) Signing
Authority,'' draft-ietf-dnsext-signing-auth-00.txt, NAILabs,
January 2000.
8 - Author's Address
Brian Wellington
NAILabs
Network Associates
3060 Washington Road (Rt. 97)
Glenwood, MD 21738
+1 443 259 2369
<bwelling@tislabs.com>
9 - Full Copyright Statement
Copyright (C) The Internet Society (2000). 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 implmentation 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
Expires July 2000 [Page 8]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
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."
Expires July 2000 [Page 9]

987
doc/draft/draft-ietf-dnsext-tkey-01.txt Normal file
View File

@@ -0,0 +1,987 @@
DNSEXT Working Group Donald E. Eastlake, 3rd
INTERNET-DRAFT Motorola
Expires: September 2000 March 2000
Secret Key Establishment for DNS (TKEY RR)
------ --- ------------- --- --- ----- ---
draft-ietf-dnsext-tkey-01.txt
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnsext-tkey-01.txt, is intended to
be become a Proposed Standard RFC. Distribution of this document is
unlimited. Comments should be sent to the DNS working group mailing
list <namedroppers@ops.ietf.org> or to the author.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
Donald E. Eastlake 3rd [Page 1]
INTERNET-DRAFT The DNS TKEY RR March 2000
Abstract
[draft-ietf-{dnsind|dnsext}-tsig-*.txt] provides a means of
authenticating Domain Name System (DNS) queries and responses using
shared secret keys via the TSIG resource record (RR). However, it
provides no mechanism for setting up such keys other than manual
exchange. This document describes a TKEY RR that can be used in a
number of different modes to establish shared secret keys between a
DNS resolver and server.
Acknowledgments
The comments and ideas of the following persons (listed in alphabetic
order) have been incorporated herein and are gratefully acknowledged:
Olafur Gudmundsson (TIS)
Stuart Kwan (Microsoft)
Ed Lewis (TIS)
Brian Wellington (TIS)
Donald E. Eastlake 3rd [Page 2]
INTERNET-DRAFT The DNS TKEY RR March 2000
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Acknowledgments............................................2
Table of Contents..........................................3
1. Introduction............................................4
1.1 Overview of Contents...................................4
2. The TKEY Resource Record................................5
2.1 The Name Field.........................................5
2.2 The TTL Field..........................................6
2.3 The Algorithm Field....................................6
2.4 The Inception and Expiration Fields....................6
2.5 The Mode Field.........................................7
2.6 The Error Field........................................7
2.7 The Key Size and Data Fields...........................8
2.8 The Other Size and Data Fields.........................8
3. General TKEY Considerations.............................8
4. Exchange via Resolver Query.............................9
4.1 Query for Diffie-Hellman Exchanged Keying..............9
4.2 Query for TKEY Deletion...............................10
4.3 Query for GSS-API Establishment.......................11
4.4 Query for Server Assigned Keying......................11
4.5 Query for Resolver Assigned Keying....................12
5. Spontaneous Server Inclusion...........................13
5.1 Spontaneous Server Key Deletion.......................13
5.2 Spontaneous GSS-API Exchange..........................14
6. Methods of Encryption..................................14
7. IANA Considerations....................................14
8. Security Considerations................................15
References................................................16
Author's Address..........................................17
Expiration and File Name..................................17
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT The DNS TKEY RR March 2000
1. Introduction
The Domain Name System (DNS) is a hierarchical, distributed, highly
available database used for bi-directional mapping between domain
names and addresses, for email routing, and for other information
[RFC 1034, 1035]. It has been extended to provide for public key
security and dynamic update [RFC 2535, RFC 2136]. Familiarity with
these RFCs is assumed.
[draft-ietf-{dnsind|dnsext}-tsig-*.txt] provides a means of
efficiently authenticating DNS messages using shared secret keys via
the TSIG resource record (RR) but provides no mechanism for setting
up such keys other than manual exchange. This document specifies a
TKEY RR that can be used in a number of different modes to establish
and delete such shared secret keys between a DNS resolver and server.
Note that TKEY established keying material and TSIGs that use it are
associated with DNS servers or resolvers. They are not associated
with zones. They may be used to authenticate queries and responses
but they do not provide zone based DNS data origin or denial
authentication [RFC 2535].
Certain modes of TKEY perform encryption which may affect their
export or import status for some countries. The affected modes
specified in this document are the server assigned mode and the
resolver assigned mode.
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].
In all cases herein, the term "resolver" includes that part of a
server which may make full and incremental [RFC 1995] zone transfer
queries, forwards recursive queries, etc.
1.1 Overview of Contents
Section 2 below specifies the TKEY RR and provides a description of
and considerations for its constituent fields.
Section 3 describes general principles of operations with TKEY.
Section 4 discusses key agreement and deletion via DNS requests with
the Query opcode for RR type TKEY. This method is applicable to all
currently defined TKEY modes, although in some cases it is not what
would intuitively be called a "query".
Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT The DNS TKEY RR March 2000
servers.
Section 6 describes encryption methods for transmitting secret key
information. In this document these are used only for the server
assigned mode and the resolver assigned mode.
Section 7 covers IANA considerations in assignment of TKEY modes.
Finally, Section 8 provides the required security considerations
section.
2. The TKEY Resource Record
The TKEY resource record (RR) has the structure given below. Its RR
type code is 249.
Field Type Comment
----- ---- -------
NAME domain see description below
TTYPE u_int16_t TKEY = 249
CLASS u_int16_t ignored, SHOULD be 255 (ANY)
TTL u_int32_t ignored, SHOULD be zero
RDLEN u_int16_t size of RDATA
RDATA:
Algorithm: domain
Inception: u_int32_t
Expiration: u_int32_t
Mode: u_int16_t
Error: u_int16_t
Key Size: u_int16_t
Key Data: octet-stream
Other Size: u_int16_t
Other Data: octet-stream undefined by this specification
2.1 The Name Field
The Name field relates to naming keys. Its meaning differs somewhat
with mode and context as explained in subsequent sections.
At any DNS server or resolver only one octet string of keying
material may be in place for any particular key name. An attempt to
establish another set of keying material at a server for an existing
name returns a BADNAME error.
For a TKEY with a non-root name appearing in a query, the TKEY RR
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT The DNS TKEY RR March 2000
name SHOULD be a domain locally unique at the resolver, less than 128
octets long in wire encoding, and meaningful to the resolver to
assist in distinguishing keys and/or key agreement sessions. For
TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD
be a globally unique server assigned domain.
A reasonable key naming strategy is as follows:
If the key is generated as the result of a query with root as
its owner name, then the server SHOULD create a globally unique
domain name, to be the key name, by suffixing a pseudo-random
[RFC 1750] label with a domain name of the server. For example
89n3mDgX072pp.server.example.com. If generation of a new
pseudo-random name in each case is an excessive computation load
or entropy drain, a serial number prefix can be added to a fixed
pseudo-random name generated an DNS server start time, such as
1001.89n3mDgX072pp.server.example.com.
If the key is generated as the result of a query with a non-root
name, say 789.resolver.example.net, then use the concatenation
of that with a name of the server. For example
789.resolver.example.net.server.example.com.
2.2 The TTL Field
The TTL field is meaningless. It SHOULD always be zero to be sure
that older DNS implementations do not cache TKEY RRs.
2.3 The Algorithm Field
The algorithm name is in the form of a domain name with the same
meaning as in [draft-ietf-{dnsind|dnsext}-tsig-*.txt]. The algorithm
determines how the secret keying material agreed to using the TKEY RR
is actually used to derive the algorithm specific key.
2.4 The Inception and Expiration Fields
The inception time and expiration times are in number of seconds
since the beginning of 1 January 1970 GMT ignoring leap seconds
treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages
between a DNS resolver and a DNS server where these fields are
meaningful, they are either the requested validity interval for the
keying material asked for or specify the validity interval of keying
material provided.
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT The DNS TKEY RR March 2000
To avoid different interpretations of the inception and expiration
times in TKEY RRs, resolvers and servers exchanging them must have
the same idea of what time it is. One way of doing this is with the
NTP protocol [RFC 2030] but that or any other time synchronization
used for this purpose MUST be done securely.
2.5 The Mode Field
The mode field specifies the general scheme for key agreement or the
purpose of the TKEY DNS message. Servers and resolvers supporting
this specification MUST implement the Diffie-Hellman key agreement
mode and the key deletion mode for queries. All other modes are
OPTIONAL. A server supporting TKEY that receives a TKEY request with
a mode it does not support returns the BADMODE error. The following
values of the Mode octet are defined, available, or reserved:
Value Description
----- -----------
0 - reserved, see section 7
1 server assignment
2 Diffie-Hellman exchange
3 GSS-API negotiation
4 resolver assignment
5 key deletion
6-65534 - available, see section 7
65535 - reserved, see section 7
2.6 The Error Field
The error code field is an extended RCODE. The following values are
defined:
Value Description
----- -----------
0 - no error
1-15 a non-extended RCODE
16 BADSIG (tsig)
17 BADKEY (tsig)
18 BADTIME (tsig)
19 BADMODE
20 BADNAME
21 BADALG
When the TKEY Error Field is non-zero in a response to a TKEY query,
the DNS header RCODE field indicates no error. However, it is
possible if a TKEY is spontaneously included in a response the TKEY
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT The DNS TKEY RR March 2000
RR and DNS header error field could have unrelated non-zero error
codes.
2.7 The Key Size and Data Fields
The key data size field is an unsigned 16 bit integer in network
order which specifies the size of the key exchange data field in
octets. The meaning of the key data depends on the mode.
2.8 The Other Size and Data Fields
The Other Size and Other Data fields are not used in this
specification but may be used in future extensions. The RDLEN field
MUST equal the length of the RDATA section through the end of Other
Data or the RR is to be considered malformed and rejected.
3. General TKEY Considerations
TKEY is a meta-RR that is not stored or cached in the DNS and does
not appear in zone files. It supports a variety of modes for the
establishment and deletion of shared secret keys information between
DNS resolvers and servers. The establishment of such a shared key
requires that state be maintained at both ends and the allocation of
the resources to maintain such state may require mutual agreement. In
the absence of willingness to provide such state, servers MUST return
errors such as NOTIMP or REFUSED for an attempt to use TKEY and
resolvers are free to ignore any TKEY RRs they receive.
The shared secret keying material developed by using TKEY is a plain
octet sequence. The means by which this shared secret keying
material, exchanged via TKEY, is actually used in any particular TSIG
algorithm is algorithm dependent and is defined in connection with
that algorithm. For example, see [RFC 2104] for how TKEY agreed
shared secret keying material is used in the HMAC-MD5 algorithm or
other HMAC algorithms.
There MUST NOT be more than one TKEY RR in a DNS query or response.
Except for GSS-API mode, TKEY responses MUST always have DNS
transaction authentication to protect the integrity of any keying
data, error codes, etc. This authentication MUST use a previously
established secret (TSIG) or public (SIG(0)) key and MUST NOT use any
key that the response to be verified is itself providing.
Donald E. Eastlake 3rd [Page 8]
INTERNET-DRAFT The DNS TKEY RR March 2000
TKEY queries MUST be authenticated for all modes except GSS-API and,
under some circumstances, server assignment mode. In particular, if
the query for a server assigned key is for a key to assert some
privilege, such as update authority, then the query must be
authenticated to avoid spoofing. However, if the key is just to be
used for transaction security, then spoofing will lead at worst to
denial of service. Query authentication SHOULD use an established
secret (TSIG) key authenticator if available. Otherwise, it must use
a public (SIG(0)) key signature. It MUST NOT use any key that the
query is itself providing.
To avoid replay attacks, it is necessary that a TKEY response or
query not be valid if replayed on the order of 2**32 second (about
136 years), or a multiple thereof, later. To accomplish this, the
keying material used in any TSIG or SIG(0) RR that authenticates a
TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds
(about 68 years). Thus, on attempted replay, the authenticating TSIG
or SIG(0) RR will not be verifiable due to key expiration and the
replay will fail.
4. Exchange via Resolver Query
One method for a resolver and a server to agree about shared secret
keying material for use in TSIG is through DNS requests from the
resolver which are syntactically DNS queries for type TKEY. Such
queries MUST be accompanied by a TKEY RR in the additional
information section to indicate the mode in use and accompanied by
other information where required.
Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
ignore the recursive header bit in TKEY queries they receive.
4.1 Query for Diffie-Hellman Exchanged Keying
Diffie-Hellman (DH) key exchange is means whereby two parties can
derive some shared secret information without requiring any secrecy
of the messages they exchange [Schneier]. Provisions have been made
for the storage of DH public keys in the DNS [RFC 2539].
A resolver sends a query for type TKEY accompanied by a TKEY RR in
the additional information section specifying the Diffie-Hellman mode
and accompanied by a KEY RR also in the additional information
section specifying a resolver Diffie-Hellman key. The TKEY RR
algorithm field is set to the authentication algorithm the resolver
plans to use. The "key data" provided in the TKEY is used as a random
[RFC 1750] nonce to avoid always deriving the same keying material
Donald E. Eastlake 3rd [Page 9]
INTERNET-DRAFT The DNS TKEY RR March 2000
for the same pair of DH KEYs.
The server response contains a TKEY in its answer section with the
Diffie-Hellman mode. The "key data" provided in this TKEY is used as
an additional nonce to avoid always deriving the same keying material
for the same pair of DH KEYs. If the TKEY error field is non-zero,
the query failed for the reason given. FORMERR is given if the query
included no DH KEY and BADKEY is given if the query included an
incompatible DH KEY.
If the TKEY error field is zero, the resolver supplied Diffie-Hellman
KEY RR SHOULD be echoed in the additional information section and a
server Diffie-Hellman KEY RR will also be present in the answer
section of the response. Both parties can then calculate the same
shared secret quantity from the pair of Diffie-Hellman (DH) keys used
[Schneier] (provided these DH keys use the same generator and
modulus) and the data in the TKEY RRs. The TKEY RR data is mixed
with the DH result as follows:
keying material =
XOR ( DH value, MD5 ( query data | DH value ) |
MD5 ( server data | DH value ) )
Where XOR is an exclusive-OR operation and "|" is byte-stream
concatenation. The shorter of the two operands to XOR is byte-wise
left justified and padded with zero-valued bytes to match the length
of the other operand. "DH value" is the Diffie-Hellman value derived
from the KEY RRs. Query data and server data are the values sent in
the TKEY RR data fields. These "query data" and "server data" nonces
are suffixed by the DH value, digested by MD5, the results
concatenated, and then XORed with the DH value.
The inception and expiry times in the query TKEY RR are those
requested for the keying material. The inception and expiry times in
the response TKEY RR are the maximum period the server will consider
the keying material valid. Servers may pre-expire keys so this is
not a guarantee.
4.2 Query for TKEY Deletion
Keys established via TKEY can be treated as soft state. Since DNS
transactions are originated by the resolver, the resolver can simply
toss keys, although it may have to go through another key exchange if
it later needs one. Similarly, the server can discard keys although
that will result in an error on receiving a query with a TSIG using
the discarded key.
To avoid attempted reliance in requests on keys no longer in effect,
Donald E. Eastlake 3rd [Page 10]
INTERNET-DRAFT The DNS TKEY RR March 2000
servers MUST implement key deletion whereby the server "discards" a
key on receipt from a resolver of an authenticated delete request for
a TKEY RR with the key's name. If the server has no record of a key
with that name, it returns BADNAME.
Key deletion TKEY queries MUST be authenticated. This authentication
MAY be a TSIG RR using the key to be deleted.
For querier assigned and Diffie-Hellman keys, the server MUST truly
"discard" all active state associated with the key. For server
assigned keys, the server MAY simply mark the key as no longer
retained by the client and may re-send it in response to a future
query for server assigned keying material.
4.3 Query for GSS-API Establishment
This mode is described in a separate document under preparation which
should be seen for the full description. Basically the resolver and
server can exchange queries and responses for type TKEY with a TKEY
RR specifying the GSS-API mode in the additional information section
and a GSS-API token in the key data portion of the TKEY RR. See also
section 5.2.
Any issues of possible encryption of parts the GSS-API token data
being transmitted are handled by the GSS-API level. In addition, the
GSS-API level provides its own authentication so that this mode of
TKEY query and response MAY be, but do not need to be, authenticated
with TSIG RR or SIG(0) RR.
The inception and expiry times in a GSS-API mode TKEY RR are ignored.
4.4 Query for Server Assigned Keying
Optionally, the server can assign keying for the resolver. It is
sent to the resolver encrypted under a resolver public key. See
section 6 for description of encryption methods.
A resolver sends a query for type TKEY accompanied by a TKEY RR
specifying the "server assignment" mode and a resolver KEY RR to be
used in encrypting the response, both in the additional information
section. The TKEY algorithm field is set to the authentication
algorithm the resolver plans to use. It is RECOMMENDED that any "key
data" provided in the query TKEY RR by the resolver be strongly mixed
by the server with server generated randomness [RFC 1750] to derive
the keying material to be used. The KEY RR that appears in the query
need not be accompanied by a SIG(KEY) RR. If the query is
Donald E. Eastlake 3rd [Page 11]
INTERNET-DRAFT The DNS TKEY RR March 2000
authenticated by the resolver with a TSIG RR [draft-ietf-
{dnsind|dnsext}-tsig-*.txt] or SIG(0) RR and that authentication is
verified, then any SIG(KEY) provided in the query SHOULD be ignored.
The KEY RR in such a query SHOULD have a name that corresponds to the
resolver but it is only essential that it be a public key for which
the resolver has the corresponding private key so it can decrypt the
response data.
The server response contains a TKEY RR in its answer section with the
server assigned mode and echoes the KEY RR provided in the query in
its additional information section.
If the reponse TKEY error field is zero, the key data portion of the
response TKEY RR will be the server assigned keying data encrypted
under the public key in the resolver provided KEY RR. In this case,
the owner name of the answer TKEY RR will be the server assigned name
of the key.
If the error field of the response TKEY is non-zero, the query failed
for the reason given. FORMERR is given if the query specified no
encryption key.
The inception and expiry times in the query TKEY RR are those
requested for the keying material. The inception and expiry times in
the response TKEY are the maximum period the server will consider the
keying material valid. Servers may pre-expire keys so this is not a
guarantee.
The resolver KEY RR MUST be authenticated, through the authentication
of this query with a TSIG or SIG(0) or the signing of the resolver
KEY with a SIG(KEY). Otherwise, an attacker can forge a resolver KEY
for which they know the private key, and thereby the attacker could
obtain a valid shared secret key from the server.
4.5 Query for Resolver Assigned Keying
Optionally, a server can accept resolver assigned keys. The keying
material must be encrypted under a server key for protection in
transmission as described in Section 6.
The resolver sends a TKEY query with a TKEY RR that specifies the
encrypted keying material and a KEY RR specifying the server public
key used to encrypt the data, both in the additional information
section. The name of the key and the keying data are completely
controlled by the sending resolver so a globally unique key name
SHOULD be used. The KEY RR used MUST be one for which the server has
the corresponding private key, or it will not be able to decrypt the
keying material and will return a FORMERR, and no untrusted party
Donald E. Eastlake 3rd [Page 12]
INTERNET-DRAFT The DNS TKEY RR March 2000
(preferably no other party than the server) has the private key, or
the untrusted private key holder can capture the messages to the
server, learn the shared secret, and spoof valid TSIGs.
The query TKEY RR inception and expiry give the time period the
querier intends to consider the keying material valid. The server
can return a lesser time interval to advise that it will not maintain
state for that long and can pre-expire keys in any case.
This mode of query MUST be authenticated with a TSIG or SIG(0).
Otherwise, an attacker can forge a resolver assigned TKEY query, and
thereby the attacker could specify a shared secret key that would be
accepted, used, and honored by the server.
5. Spontaneous Server Inclusion
A DNS server may include a TKEY RR spontaneously as additional
information in responses. This SHOULD only be done if the server
knows the querier understands TKEY and has this option implemented.
This technique can be used for GSS-API exchange, and to delete a key.
A disadvantage of this technique is that there is no way for the
server to get any error or success indication back and, in the case
of UDP, no way to even know if the DNS response reached the resolver.
5.1 Spontaneous Server Key Deletion
A server can optionally tell a client that it has deleted a symmetric
key by spontaneously including a TKEY RR in the additional
information section of a response with the key's name and specifying
the key deletion mode. Such a response SHOULD be authenticated. If
authenticated, it "deletes" the key with the given name. The
inception and expiry times of the delete TKEY RR are ignored. Failure
by a client to receive or properly process such additional
information in a response would mean that the client might use a key
that the server had discarded and would then get an error indication.
For server assigned and Diffie-Hellman keys, the client must truly
"discard" all active state associated with the key. For querier
assigned keys, the querier MAY simply mark the key as no longer
retained by the server and may re-send it in a future query
specifying querier assigned keying material.
Donald E. Eastlake 3rd [Page 13]
INTERNET-DRAFT The DNS TKEY RR March 2000
5.2 Spontaneous GSS-API Exchange
A server can spontaneously include in the additional information
section of a response, a GSS-API mode TKEY RR. The information in
the key data section of such a TKEY is a GSS-API token which SHOULD
be fed by the resolver to its local GSS-API implementation. If such
a response is authenticated, the authentication MAY be verify before
processing the data. To the extent that GSS-API provides its own
security, such a response need not be authenticated. To the extent
that GSS-API handles duplicated messages, such a spontaneous TKEY
could be sent repeatedly, until, for example, a response via a GSS-
API mode TKEY query is received. See also section 4.3.
6. Methods of Encryption
For the server assigned and resolver assigned key agreement modes,
the keying material is sent within the key data field of a TKEY RR
encrypted under the public key in an accompanying KEY RR [RFC 2535].
This KEY RR MUST be for a public key algorithm where the public and
private keys can be used for encryption and the corresponding
decryption which recovers the originally encrypted data. The KEY RR
SHOULD correspond to a name for the decrypting resolver/server such
that the decrypting process has access to the corresponding private
key to decrypt the data. The secret keying material being sent will
generally be fairly short, usually less than 256 bits, because that
is adequate for very strong protection with modern keyed hash or
symmetric algorithms.
If the KEY RR specifies the RSA algorithm, then the keying material
is encrypted as per the description of RSA encryption in PKCS#1 [RFC
2437]. (Note, the secret keying material being sent is directly RSA
encrypted in PKCS#1 format, It is not "enveloped" under some other
symmetric algorithm.) In the unlikely event that the keying material
will not fit within one RSA modulus of the chosen public key,
additional RSA encryption blocks are included. The length of each
block is clear from the public RSA key specified and the PKCS#1
padding makes it clear what part of the encrypted data is actually
keying material and what part is formatting or the required at least
eight bytes of random [RFC 1750] padding.
7. IANA Considerations
This section is to be interpreted as provided in [RFC 2434].
Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF
can only be assigned by an IETF standards action. Special
Donald E. Eastlake 3rd [Page 14]
INTERNET-DRAFT The DNS TKEY RR March 2000
consideration should be given before the allocation of meaning for
Mode field values 0x0000 and 0xFFFF.
Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
are allocated by IESG approval or IETF consensus.
Mode field values 0x1000 through 0xEFFF are allocated based on
Specification Required as defined in [RFC 2434].
Mode values should not be changed when the status of their use
changes. For example, a mode value assigned for an Experimental
Standard should not be changed later just because that standard's
status is changed to Proposed.
The following assignments are documented herein:
RR Type 249 for TKEY.
TKEY Modes 1 through 5 as listed in section 2.5.
Extended RCODE Error values of 19, 20, and 21 as listed in
section 2.6.
8. Security Considerations
The entirety of this specification is concerned with the secure
establishment of a shared secret between DNS clients and servers in
support of TSIG.
Protection against denial of service via the use of TKEY is not
provided.
Donald E. Eastlake 3rd [Page 15]
INTERNET-DRAFT The DNS TKEY RR March 2000
References
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons
RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities",
STD 13, November 1987.
RFC 1035 - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987.
RFC 1750 - D. Eastlake, S. Crocker & J. Schiller, "Randomness
Recommendations for Security", December 1994.
RFC 1982 - Robert Elz, Randy Bush, "Serial Number Arithmetic",
09/03/1996.
RFC 1995 - Masataka Ohta, "Incremental Zone Transfer in DNS", August
1996.
RFC 2030 - D. Mills, "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", October 1996.
RFC 2104 - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", February 1997.
RFC 2119 - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
RFC 2136 - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs, October 1998.
RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", October 1998.
RFC 2535 - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
Name System (DNS)", March 1999.
draft-ietf-{dnsind|dnsext}-tsig-*.txt - P. Vixie, O. Gudmundsson, D.
Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)".
Donald E. Eastlake 3rd [Page 16]
INTERNET-DRAFT The DNS TKEY RR March 2000
Author's Address
Donald E. Eastlake 3rd
Motorola
65 Shindegan Hill Road, RR #1
Carmel, NY 10512 USA
Telephone: +1 914-276-2668 (h)
+1 508-261-5434 (w)
FAX: +1 914-276-2947 (h)
email: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires August 2000.
Its file name is draft-ietf-dnsext-tkey-01.txt.
Donald E. Eastlake 3rd [Page 17]

792
doc/draft/draft-ietf-dnsext-tsig-00.txt Normal file
View File

@@ -0,0 +1,792 @@
DNSIND Working Group Paul Vixie (Ed.) (ISC)
INTERNET-DRAFT Olafur Gudmundsson (NAILabs)
Donald Eastlake 3rd (Motorola)
Brian Wellington (NAILabs)
<draft-ietf-dnsext-tsig-00.txt> March 2000
Amends: RFC 1035
Secret Key Transaction Authentication for DNS (TSIG)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
Abstract
This protocol allows for transaction level authentication using
shared secrets and one way hashing. It can be used to authenticate
dynamic updates as coming from an approved client, or to authenticate
responses as coming from an approved recursive name server.
No provision has been made here for distributing the shared secrets;
it is expected that a network administrator will statically configure
name servers and clients using some out of band mechanism such as
sneaker-net until a secure automated mechanism for key distribution
is available.
Expires September 2000 [Page 1]
INTERNET-DRAFT DNS TSIG March 2000
1 - Introduction
1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated
hierarchical distributed database system that provides information
fundamental to Internet operations, such as name <=> address translation
and mail handling information. DNS has recently been extended [RFC2535]
to provide for data origin authentication, and public key distribution,
all based on public key cryptography and public key based digital
signatures. To be practical, this form of security generally requires
extensive local caching of keys and tracing of authentication through
multiple keys and signatures to a pre-trusted locally configured key.
1.2. One difficulty with the [RFC2535] scheme is that common DNS
implementations include simple ``stub'' resolvers which do not have
caches. Such resolvers typically rely on a caching DNS server on
another host. It is impractical for these stub resolvers to perform
general [RFC2535] authentication and they would naturally depend on
their caching DNS server to perform such services for them. To do so
securely requires secure communication of queries and responses.
[RFC2535] provides public key transaction signatures to support this,
but such signatures are very expensive computationally to generate. In
general, these require the same complex public key logic that is
impractical for stubs. This document specifies use of a message
authentication code (MAC), specifically HMAC-MD5 (a keyed hash
function), to provide an efficient means of point-to-point
authentication and integrity checking for transactions.
1.3. A second area where use of straight [RFC2535] public key based
mechanisms may be impractical is authenticating dynamic update [RFC2136]
requests. [RFC2535] provides for request signatures but with [RFC2535]
they, like transaction signatures, require computationally expensive
public key cryptography and complex authentication logic. Secure Domain
Name System Dynamic Update ([RFC2137]) describes how different keys are
used in dynamically updated zones. This document's secret key based
MACs can be used to authenticate DNS update requests as well as
transaction responses, providing a lightweight alternative to the
protocol described by [RFC2137].
1.4. A further use of this mechanism is to protect zone transfers. In
this case the data covered would be the whole zone transfer including
any glue records sent. The protocol described by [RFC2535] does not
protect glue records and unsigned records unless SIG(0) (transaction
signature) is used.
Expires September 2000 [Page 2]
INTERNET-DRAFT DNS TSIG March 2000
1.5. The authentication mechanism proposed in this document uses shared
secret keys to establish a trust relationship between two entities.
Such keys must be protected in a fashion similar to private keys, lest a
third party masquerade as one of the intended parties (forge MACs).
There is an urgent need to provide simple and efficient authentication
between clients and local servers and this proposal addresses that need.
This proposal is unsuitable for general server to server authentication
for servers which speak with many other servers, since key management
would become unwieldy with the number of shared keys going up
quadratically. But it is suitable for many resolvers on hosts that only
talk to a few recursive servers.
1.6. A server acting as an indirect caching resolver -- a ``forwarder''
in common usage -- might use transaction-based authentication when
communicating with its small number of preconfigured ``upstream''
servers. Other uses of DNS secret key authentication and possible
systems for automatic secret key distribution may be proposed in
separate future documents.
1.7. New Assigned Numbers
RRTYPE = TSIG (250)
ERROR = 0..15 (a DNS RCODE)
ERROR = 16 (BADSIG)
ERROR = 17 (BADKEY)
ERROR = 18 (BADTIME)
1.8. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in [RFC 2119].
2 - TSIG RR Format
2.1 TSIG RR Type
To provide secret key authentication, we use a new RR type whose
mnemonic is TSIG and whose type code is 250. TSIG is a meta-RR and MUST
not be cached. TSIG RRs are used for authentication between DNS
entities that have established a shared secret key. TSIG RRs are
dynamically computed to cover a particular DNS transaction and are not
DNS RRs in the usual sense.
Expires September 2000 [Page 3]
INTERNET-DRAFT DNS TSIG March 2000
2.2 TSIG Calculation
As the TSIG RRs are related to one DNS request/response, there is no
value in storing or retransmitting them, thus the TSIG RR is discarded
once it has been used to authenticate a DNS message. The only message
digest algorithm specified in this document is ``HMAC-MD5'' (see
[RFC1321], [RFC2104]). The ``HMAC-MD5'' algorithm is mandatory to
implement for interoperability. Other algorithms can be specified at a
later date. Names and definitions of new algorithms MUST be registered
with IANA. All multi-octet integers in TSIG Record are sent in network
byte order (see [RFC1035 2.3.2]).
2.3. Record Format
NAME The name of the key used in domain name syntax. The name
should reflect the names of the hosts and uniquely identify
the key among a set of keys these two hosts may share at any
given time. If hosts A.site.example and B.example.net share a
key, possibilities for the key name include
<id>.A.site.example, <id>.B.example.net, and
<id>.A.site.example.B.example.net. It should be possible for
more than one key to be in simultaneous use among a set of
interacting hosts. The name only needs to be meaningful to
the communicating hosts but a meaningful mnemonic name as
above is strongly recommended.
The name may be used as a local index to the key involved and
it is recommended that it be globally unique. Where a key is
just shared between two hosts, its name actually only need
only be meaningful to them but it is recommended that the key
name be mnemonic and incorporate the resolver and server host
names in that order.
TYPE TSIG (250: Transaction SIGnature)
CLASS ANY
TTL 0
RdLen (variable)
Expires September 2000 [Page 4]
INTERNET-DRAFT DNS TSIG March 2000
RDATA
Field Name Data Type Notes
--------------------------------------------------------------
Algorithm Name domain-name Name of the algorithm
in domain name syntax.
Time Signed u_int48_t seconds since 1-Jan-70 UTC.
Fudge u_int16_t seconds of error permitted
in Time Signed.
MAC Size u_int16_t number of octets in MAC.
MAC octet stream defined by Algorithm Name.
Original ID u_int16_t original message ID
Error u_int16_t expanded RCODE covering
TSIG processing.
Other Len u_int16_t length, in octets, of
Other Data.
Other Data octet stream empty unless Error == BADTIME
2.4. Example
NAME HOST.EXAMPLE.
TYPE TSIG
CLASS ANY
TTL 0
RdLen as appropriate
RDATA
Field Name Contents
-------------------------------------
Algorithm Name SAMPLE-ALG.EXAMPLE.
Time Signed 853804800
Fudge 300
MAC Size as appropriate
MAC as appropriate
Original ID as appropriate
Error 0 (NOERROR)
Other Len 0
Expires September 2000 [Page 5]
INTERNET-DRAFT DNS TSIG March 2000
Other Data empty
3 - Protocol Operation
3.1. Effects of adding TSIG to outgoing message
Once the outgoing message has been constructed, the keyed message digest
operation can be performed. The resulting message digest will then be
stored in a TSIG which is appended to the additional data section (the
ARCOUNT is incremented to reflect this). If the TSIG record cannot be
added without causing the message to be truncated, the server MUST alter
the response so that a TSIG can be included. This response consists of
only the question and a TSIG record, and has the TC bit set and RCODE 0
(NOERROR). The client SHOULD at this point retry the request using TCP
(per [RFC1035 4.2.2]).
3.2. TSIG processing on incoming messages
If an incoming message contains a TSIG record, it MUST be the last
record in the additional section. Multiple TSIG records are not
allowed. If a TSIG record is present in any other position, the packet
is dropped and a response with RCODE 1 (FORMERR) MUST be returned. Upon
receipt of a message with a correctly placed TSIG RR, the TSIG RR is
copied to a safe location, removed from the DNS Message, and decremented
out of the DNS message header's ARCOUNT. At this point the keyed
message digest operation is performed. If the algorithm name or key
name is unknown to the recipient, or if the message digests do not
match, the whole DNS message MUST be discarded. If the message is a
query, a response with RCODE 9 (NOTAUTH) MUST be sent back to the
originator with TSIG ERROR 17 (BADKEY) or TSIG ERROR 16 (BADSIG). If no
key is available to sign this message it MUST be sent unsigned (MAC size
== 0 and empty MAC). A message to the system operations log SHOULD be
generated, to warn the operations staff of a possible security incident
in progress. Care should be taken to ensure that logging of this type
of event does not open the system to a denial of service attack.
Expires September 2000 [Page 6]
INTERNET-DRAFT DNS TSIG March 2000
3.3. Time values used in TSIG calculations
The data digested includes the two timer values in the TSIG header in
order to defend against replay attacks. If this were not done, an
attacker could replay old messages but update the ``Time Signed'' and
``Fudge'' fields to make the message look new. This data is named
``TSIG Timers'', and for the purpose of digest calculation they are
invoked in their ``on the wire'' format, in the following order: first
Time Signed, then Fudge. For example:
Field Name Value Wire Format Meaning
---------------------------------------------------------------------------
Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997
Fudge 300 01 2C 5 minutes
3.4. TSIG Variables and Coverage
When generating or verifying the contents of a TSIG record, the
following data are digested, in network byte order or wire format, as
appropriate:
3.4.1. DNS Message
A whole and complete DNS message in wire format, before the TSIG RR has
been added to the additional data section and before the DNS Message
Header's ARCOUNT field has been incremented to contain the TSIG RR. If
the message ID differs from the original message ID, the original
message ID is substituted for the message ID. This could happen when
forwarding a dynamic update request, for example.
3.4.2. TSIG Variables
Source Field Name Notes
------------------------------------------------------------------------
TSIG RR NAME Key name, in canonical wire format
TSIG RR CLASS (Always ANY in the current specification)
TSIG RR TTL (Always 0 in the current specification)
TSIG RDATA Algorithm Name in canonical wire format
TSIG RDATA Time Signed in network byte order
TSIG RDATA Fudge in network byte order
TSIG RDATA Error in network byte order
TSIG RDATA Other Len in network byte order
TSIG RDATA Other Data exactly as transmitted
Expires September 2000 [Page 7]
INTERNET-DRAFT DNS TSIG March 2000
The RR RDLEN and RDATA MAC Length are not included in the hash since
they are not guaranteed to be knowable before the MAC is generated.
The Original ID field is not included in this section, as it has already
been substituted for the message ID in the DNS header and hashed.
``Canonical wire format'' [RFC2535] refers to uncompressed labels
shifted to lower case. The use of label types other than 00 is not
defined for this specification.
3.4.3. Request MAC
When generating the MAC to be included in a response, the request MAC
must be included in the digest. The request's MAC is digested in wire
format, including the following fields:
Field Type Description
---------------------------------------------------
MAC Length u_int16_t in network byte order
MAC Data octet stream exactly as transmitted
3.5. Padding
Digested components are fed into the hashing function as a continuous
octet stream with no interfield padding.
4 - Protocol Details
4.1. TSIG generation on requests
Client performs the message digest operation and appends a TSIG record
to the additional data section and transmits the request to the server.
The client MUST store the message digest from the request while awaiting
an answer. The digest components for a request are:
DNS Message (request)
TSIG Variables (request)
Note that some older name servers will not accept requests with a
nonempty additional data section. Clients SHOULD only attempt signed
transactions with servers who are known to support TSIG and share some
secret key with the client -- so, this is not a problem in practice.
Expires September 2000 [Page 8]
INTERNET-DRAFT DNS TSIG March 2000
4.2. TSIG on Answers
When a server has generated a response to a signed request, it signs the
response using the same algorithm and key. The server MUST not generate
a signed response to an unsigned request. The digest components are:
Request MAC
DNS Message (response)
TSIG Variables (response)
4.3. TSIG on TSIG Error returns
When a server detects an error relating to the key or MAC, the server
SHOULD send back an unsigned error message (MAC size == 0 and empty
MAC). If an error is detected relating to the TSIG validity period, the
server SHOULD send back a signed error message. The digest components
are:
Request MAC (if the request MAC validated)
DNS Message (response)
TSIG Variables (response)
The reason that the request is not included in this digest in some cases
is to make it possible for the client to verify the error. If the error
is not a TSIG error the response MUST be generated as specified in
[4.2].
4.4. TSIG on TCP connection
A DNS TCP session can include multiple DNS envelopes. This is, for
example, commonly used by zone transfer. Using TSIG on such a
connection can protect the connection from hijacking and provide data
integrity. The TSIG MUST be included on the first and last DNS
envelopes. It can be optionally placed on any intermediary envelopes.
It is expensive to include it on every envelopes, but it MUST be placed
on at least every 100'th envelope. The first envelope is processed as a
standard answer, and subsequent messages have the following digest
components:
Prior Digest (running)
DNS Messages (any unsigned messages since the last TSIG)
TSIG Timers (current message)
This allows the client to rapidly detect when the session has been
Expires September 2000 [Page 9]
INTERNET-DRAFT DNS TSIG March 2000
altered; at which point it can close the connection and retry. If a
client TSIG verification fails, the client MUST close the connection.
If the client does not receive TSIG records frequently enough (as
specified above) it SHOULD assume the connection has been hijacked and
it SHOULD close the connection. The client SHOULD treat this the same
way as they would any other interrupted transfer (although the exact
behavior is not specified).
4.5. Server TSIG checks
Upon receipt of a message, server will check if there is a TSIG RR. If
one exists, the server is REQUIRED to return a TSIG RR in the response.
The server MUST perform the following checks in the following order,
check KEY, check TIME values, check MAC.
4.5.1. KEY check and error handling
If a non-forwarding server does not recognize the key used by the
client, the server MUST generate an error response with RCODE 9
(NOTAUTH) and TSIG ERROR 17 (BADKEY). This response MUST be unsigned as
specified in [4.3]. The server SHOULD log the error.
4.5.2. TIME check and error handling
If the server time is outside the time interval specified by the request
(which is: Time Signed, plus/minus Fudge), the server MUST generate an
error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18 (BADTIME). The
server MAY also cache the most recent time signed value in a message
generated by a key, and MAY return BADTIME if a message received later
has an earlier time signed value. A response indicating a BADTIME error
MUST be signed by the same key as the request. It MUST include the
client's current time in the time signed field, the server's current
time (a u_int48_t) in the other data field, and 6 in the other data
length field. This is done so that the client can verify a message with
a BADTIME error without the verification failing due to another BADTIME
error. The data signed is specified in [4.3]. The server SHOULD log
the error.
Expires September 2000 [Page 10]
INTERNET-DRAFT DNS TSIG March 2000
4.5.3. MAC check and error handling
If a TSIG fails to verify, the server MUST generate an error response as
specified in [4.3] with RCODE 9 (NOTAUTH) and TSIG ERROR 16 (BADSIG).
This response MUST be unsigned as specified in [4.3]. The server SHOULD
log the error.
4.6. Client processing of answer
When a client receives a response from a server and expects to see a
TSIG, it first checks if the TSIG RR is present in the response.
Otherwise, the response is treated as having a format error and
discarded. The client then extracts the TSIG, adjusts the ARCOUNT, and
calculates the keyed digest in the same way as the server. If the TSIG
does not validate, that response MUST be discarded, unless the RCODE is
9 (NOTAUTH), in which case the client SHOULD attempt to verify the
response as if it were a TSIG Error response, as specified in [4.3]. A
message containing an unsigned TSIG record or a TSIG record which fails
verification SHOULD not be considered an acceptable response; the client
SHOULD log an error and continue to wait for a signed response until the
request times out.
4.6.1. Key error handling
If an RCODE on a response is 9 (NOTAUTH), and the response TSIG
validates, and the TSIG key is different from the key used on the
request, then this is a KEY error. The client MAY retry the request
using the key specified by the server. This should never occur, as a
server MUST NOT sign a response with a different key than signed the
request.
4.6.2. Time error handling
If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18 (BADTIME),
or the current time does not fall in the range specified in the TSIG
record, then this is a TIME error. This is an indication that the
client and server clocks are not synchronized. In this case the client
SHOULD log the event. DNS resolvers MUST NOT adjust any clocks in the
client based on BADTIME errors, but the server's time in the other data
field SHOULD be logged.
Expires September 2000 [Page 11]
INTERNET-DRAFT DNS TSIG March 2000
4.6.3. MAC error handling
If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), this
is a MAC error, and client MAY retry the request with a new request ID
but it would be better to try a different shared key if one is
available. Client SHOULD keep track of how many MAC errors are
associated with each key. Clients SHOULD log this event.
4.7. Special considerations for forwarding servers
A server acting as a forwarding server of a DNS message SHOULD check for
the existence of a TSIG record. If the name on the TSIG is not of a
secret that the server shares with the originator the server MUST
forward the message unchanged including the TSIG. If the name of the
TSIG is of a key this server shares with the originator, it MUST process
the TSIG. If the TSIG passes all checks, the forwarding server MUST, if
possible, include a TSIG of his own, to the destination or the next
forwarder. If no transaction security is available to the destination
and the response has the AD flag (see [RFC2535]), the forwarder MUST
unset the AD flag before adding the TSIG to the answer.
5 - Shared Secrets
5.1. Secret keys are very sensitive information and all available steps
should be taken to protect them on every host on which they are stored.
Generally such hosts need to be physically protected. If they are
multi-user machines, great care should be taken that unprivileged users
have no access to keying material. Resolvers often run unprivileged,
which means all users of a host would be able to see whatever
configuration data is used by the resolver.
5.2. A name server usually runs privileged, which means its
configuration data need not be visible to all users of the host. For
this reason, a host that implements transaction-based authentication
should probably be configured with a ``stub resolver'' and a local
caching and forwarding name server. This presents a special problem for
[RFC2136] which otherwise depends on clients to communicate only with a
zone's authoritative name servers.
5.3. Use of strong random shared secrets is essential to the security of
TSIG. See [RFC1750] for a discussion of this issue. The secret should
be at least as long as the keyed message digest, i.e. 16 bytes for HMAC-
MD5 or 20 bytes for HMAC-SHA1.
Expires September 2000 [Page 12]
INTERNET-DRAFT DNS TSIG March 2000
6 - Security Considerations
6.1. The approach specified here is computationally much less expensive
than the signatures specified in [RFC2535]. As long as the shared
secret key is not compromised, strong authentication is provided for the
last hop from a local name server to the user resolver.
6.2. Secret keys should be changed periodically. If the client host has
been compromised, the server should suspend the use of all secrets known
to that client. If possible, secrets should be stored in encrypted
form. Secrets should never be transmitted in the clear over any
network. This document does not address the issue on how to distribute
secrets. Secrets should never be shared by more than two entities.
6.3. This mechanism does not authenticate source data, only its
transmission between two parties who share some secret. The original
source data can come from a compromised zone master or can be corrupted
during transit from an authentic zone master to some ``caching
forwarder.'' However, if the server is faithfully performing the full
[RFC2535] security checks, then only security checked data will be
available to the client.
7 - IANA Considerations
IANA is expected to create and maintain a registry of algorithm names to
be used as "Algorithm Names" as defined in Section 2.3. The initial
value should be "HMAC-MD5.SIG-ALG.REG.INT". Algorithm names are text
strings encoded using the syntax of a domain name. There is no
structure required other than names for different algorithms must be
unique when compared as DNS names, i.e., comparison is case insensitive.
Note that the initial value mentioned above is not a domain name, and
therefore need not be a registed name within the DNS. New algorithms
are assigned using the IETF Consensus policy defined in RFC 2434.
IANA is expected to create and maintain a registry of "TSIG Error
values" to be used for "Error" values as defined in section 2.3.
Initial values should be those defined in section 1.7. New TSIG error
codes for the TSIG error field are assigned using the IETF Consensus
policy defined in RFC 2434.
Expires September 2000 [Page 13]
INTERNET-DRAFT DNS TSIG March 2000
7 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1034, ISI, November 1987.
[RFC1321] R. Rivest, ``The MD5 Message-Digest Algorithm,'' RFC 1321,
MIT LCS & RSA Data Security, Inc., April 1992.
[RFC1750] D. Eastlake, S. Crocker, J. Schiller, ``Randomness
Recommendations for Security,'' RFC 1750, DEC, CyberCash &
MIT, December 1995.
[RFC2104] H. Krawczyk, M. Bellare, R. Canetti, ``HMAC-MD5: Keyed-MD5
for Message Authentication,'' RFC 2104 , IBM, UCSD & IBM,
February 1997.
[RFC2119] S. Bradner, ``Key words for use in RFCs to Indicate
Requirement Levels,'' RFC 2119, Harvard, March 1997
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
& Cisco & DEC, April 1997.
[RFC2137] D. Eastlake 3rd ``Secure Domain Name System Dynamic Update,''
CyberCash, April 1997.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC
2535, IBM, March 1999.
Expires September 2000 [Page 14]
INTERNET-DRAFT DNS TSIG March 2000
9 - Authors' Addresses
Paul Vixie Olafur Gudmundsson
Internet Software Consortium NAILabs
950 Charter Street 3060 Washington Road, Route 97
Redwood City, CA 94063 Glenwood, MD 21738
+1 650 779 7001 +1 443 259 2389
<vixie@isc.org> <ogud@tislabs.com>
Donald E. Eastlake 3rd Brian Wellington
Motorola NAILabs
65 Shindegan Hill Road, RR #1 3060 Washington Road, Route 97
Carmel, NY 10512 USA Glenwood, MD 21738
+1 508 261 5434 +1 443 259 2369
<dee3@torque.pothole.com> <bwelling@tislabs.com>
Expires September 2000 [Page 15]

580
doc/draft/draft-ietf-dnsext-zone-status-00.txt Normal file
View File

@@ -0,0 +1,580 @@
DNSEXT WG Edward Lewis
INTERNET DRAFT NAI Labs
Category:I-D Feburary 1, 2000
DNS Security Extension Clarification on Zone Status
<draft-ietf-dnsext-zone-status-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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.
Comments should be sent to the authors or the DNSIND WG mailing list
namedroppers@internic.net.
This draft expires on August 1, 2000.
Copyright Notice
Copyright (C) The Internet Society (1999, 2000). All rights reserved.
Abstract
The definition of a secured zone is presented, updating RFC 2535. The
new definition has consequences which alter the interpretation of the
NXT record, obsolete NULL keys, and the designation of "experimentally
secure."
1 Introduction
Whether a DNS zone is "secured" or not is a question asked in at least
four contexts. A zone administrator asks the question when
configuring a zone to use DNSSEC. A dynamic update server asks the
question when an update request arrives, which may require DNSSEC
processing. A delegating zone asks the question of a child zone when
the parent enters data indicating the status the child. A resolver
asks the question upon receipt of data belonging to the zone.
A zone administrator needs to be able to determine what steps are
needed to make the zone as secure as it can be. Realizing that due to
Expires August 1, 2000 [Page 1]
DNS Security Extension Clarification on Zone Status February 1, 2000
the distributed nature of DNS and its administration, any single zone
is at the mercy of other zones when it comes to the appearance of
security. This document will define what makes a zone qualify as
secure (absent interaction with other zones).
A name server performing dynamic updates needs to know whether a zone
being updated is to have signatures added to the updated data, NXT
records applied, and other required processing. In this case, it is
conceivable that the name server is configured with the knowledge, but
being able to determine the status of a zone by examining the data is
a desirable alternative to configuration parameters.
A delegating zone is required to indicate whether a child zone is
secured. The reason for this requirement lies in the way in which a
resolver makes its own determination about a zone (next paragraph). To
shorten a long story, a parent needs to know whether a child should be
considered secured. This is a two part question, what does a parent
consider a secure child to be, and how does a parent know if the child
conforms?
A resolver needs to know if a zone is secured when the resolver is
processing data from the zone. Ultimately, a resolver needs to know
whether or not to expect a usable signature covering the data. How
this determination is done is out of the scope of this document,
except that, in some cases, the resolver will need to contact the
parent of the zone to see if the parent states that the child is
secured.
This document updates several sections of RFC 2535. The definition of
a secured zone is an update to section 3.4 of the RFC. The document
updates section 2.3.4, by specifying a replacement for the NULL zone
keys. The document also updates section 3.4 to eliminate the
definition of experimental keys and illustrate a way to still achieve
the functionality they were designed to provide.
2 Status of a Zone
In this section, rules governing a zone's DNSSEC status are presented.
There are three levels of security defined; full, private, and
unsecured. A zone is fully secure when it complies with the strictest
set of DNSSEC processing rules. A zone is privately secured when it
is configured in such a way that only resolvers that are appropriately
configured see the zone as secured. All other zones are unsecured.
Note: there currently is no other document completely defining DNSSEC
processing rules. For the purposes of this document, the strictest
rules are assumed to state that the verification chain of zone keys
parallels the delegation tree up to the root zone. This is not
intended to disallow alternate verification paths, just to establish a
baseline definition.
To avoid repetition in the rules below, the following term is defined.
2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01
Expires August 1, 2000 [Page 2]
DNS Security Extension Clarification on Zone Status February 1, 2000
for name type (indicating a zone key) and either value 00 or value 01
for key type (indicating a key permitted to authenticate data). (See
RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value
of DNSSEC (3) or All (255).
2.1 Fully Secured
A fully secured zone, in a nutshell, is a zone that uses only
mandatory to implement algorithms (RFC 2535, section 3.2) and relies
on a key certification chain that parallels the delegation tree. Fully
secured zones are defined by the following rules.
2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at least
one zone signing KEY RR (2.a) of a mandatory to implement algorithm in
the set.
2.1.b. The zone's apex KEY RR set MUST be signed by a private key
belonging to the parent zone. The private key's public companion MUST
be a zone signing KEY RR (2.a) of a mandatory to implement algorithm
and owned by the parent's apex.
If a zone cannot get a conforming signature from the parent zone, the
child zone cannot be considered fully secured.
2.1.c. NXT records MUST be deployed throughout the zone. (Updates RFC
2535, section 2.3.2.) Note: there is some operational discomfort with
the current NXT record. This requirement is open to modification when
two things happen. First, an alternate mechanism to the NXT is
defined and second, a means by which a zone can indicate that it is
using an alternate method.
2.1.d. Each RR set that qualifies for zone membership MUST be signed
by a key that is in the apex's KEY RR set and is a zone signing KEY RR
(2.a) of a mandatory to implement algorithm. (Updates 2535, section
2.3.1.)
2.2 Privately Secured
A privately secured zone is a zone that complies with rules like those
for fully secured, with the following exceptions. The signing keys
may be of an algorithm that is not mandatory to implement and/or the
verification of the zone keys in use may rely on a verification chain
that is not parallel to the delegation tree.
2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at least
one zone signing KEY RR (2.a) in the set.
2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
one of the following two sentences MUST hold true. The private key's
public companion MUST be preconfigured in all the resolvers of
interest. The private key's public component MUST be a zone signing
KEY RR (2.a) authorized to provide validation of the zone's apex KEY
RR set, as recognized by resolvers of interest.
Expires August 1, 2000 [Page 3]
DNS Security Extension Clarification on Zone Status February 1, 2000
The previous sentence is trying to convey the notion of using a
trusted third party to provide validation of keys. If the domain name
owning the validating key is not the parent zone, the domain name must
represent someone the resolver trusts to provide validation.
2.2.c. NXT records MUST be deployed throughout the zone. (Updates RFC
2535, section 2.3.2.) Note: see the discussion following 2.1.c.
2.2.d. Each RR set that qualifies for zone membership MUST be signed
by a key that is in the apex's KEY RR set and is a zone signing KEY RR
(2.a). (Updates 2535, section 2.3.1.)
2.3 Unsecured
All other zones qualify as unsecured. This includes zones that are
designed to be experimentally secure, as defined in a later section on
that topic.
2.4 Wrap up
The designation of fully secured, privately secured, and unsecured are
merely labels to apply to zones, based on their contents. Resolvers,
when determining whether a signature is expected or not, will only see
a zone as secured or unsecured.
Resolvers that follow the most restrictive DNSSEC verification rules
will only see fully secured zones as secured, and all others as
unsecured, including zones which are privately secured. Resolvers
which are not as restrictive, such as those that implement algorithms
in addition to the mandatory to implement algorithms, will see some
privately secured zones as secured.
The intent of the labels "fully" and "privately" is to identify the
specific attributes of a zone. The words are chosen to assist in the
writing of a document recommending the actions a zone administrator
take in making use of the DNS security extensions. The words are
explicitly not intended to convey a state of compliance with DNS
security standards.
3 Parental Notification
For a resolver to come to a definitive answer concerning a zone's
security status, there is a requirement that the parent of a zone
signify whether the child zone is signed or not. The justification of
this requirement requires a discussion of the resolver's activity,
which is described in RFC 2535.
In RFC 2535, a parent is required to hold a NULL key for an unsigned
child (a bone of contention here is how this works in light of
multiple algorithms). The parent has the option to hold the keys of
the child if the child is signed. The parent may also hold nothing
cryptographic if the child is signed. This, of course, assumes the
parent is a signed zone.
Expires August 1, 2000 [Page 4]
DNS Security Extension Clarification on Zone Status February 1, 2000
There is a strong case for discouraging a parent from holding keys of
a signed child. These include concrete concerns about performance and
more abstract concerns about the liability of the parent.
DNS [RFC 1034 and 1035] requires a parent to hold NS records for a
child zone, this signifies the delegation. RFC 2535 requires a
secured parent to also have signed NXT records for the child, and
possibly a signed KEY RR set (required for NULL key situations).
By redefining the security status of a zone to be per zone and not per
algorithm, there is an opportunity to completely remove the need for a
KEY RR set in the parent. Because the question of whether the zone is
secure or not is a yes-or-no question, the notification needs just one
bit to be expressed.
Keep in mind that the following sections speak to the contents of a
zone, not a name server. In the case of a name server speaking
authoritatively for both the parent and child, or if a server caches
the information for the other half of the delegation, then a server
will have more types of data at a delegation point than a parent is
supposed to hold. (E.g., if a parent zone's name server caches the
SOA for the child, the SOA is not in the parent zone, but is in the
server's cache.)
3.1 Child Is Secured Bit
This section is written assuming the current definition of NXT holds.
There is some controversy surrounding the NXT record which may result
in a complete replacement of it for proof of non-existence. The
current NXT definition provides an extension bit in the types present
bit map, whose use is remains incompletely defined. The following
text largely ignores these uncertainties, and should be rewritten to
accommodate these uncertainties in revisions.
In the parent's half of the delegation point, there will be an NXT
record. According to the rules for a delegation point, only the NS,
NXT, and SIG bits will be turned on in the types present field,
assuming we drop the KEY set altogether.
The KEY bit in the parent's NXT types present bit map is hereby
redefined to have the following meaning.
If the bit corresponding to the KEY RR set in a parent NXT is set, the
parent has signed a KEY RR set for the child that includes a zone
signing KEY RR (2.a). Furthermore, the validity period on the SIG
(KEY) RR covers the current time and the public component of the key
used to generate the SIG (KEY) RR is validly available from the
parent.
E.g., Assume the zone "test." signs a key for "zone1.test.," with the
signature valid from May 1st to June 1st and a public key from "test."
available from April 1st until July 1st. The NXT record for
"zone1.test." will have the KEY RR bit set from May 1st to June 1st.
Expires August 1, 2000 [Page 5]
DNS Security Extension Clarification on Zone Status February 1, 2000
This constraint may be enforced in the SIG (NXT) RR validity period,
timely editing of the master file, or whatever other mechanism "test."
chooses to implement.
Conversely, if the bit is 0, then the child is not secured. Note that
for a fully secured zone (section 2.1), the bit is on (1). For all
unsecured zones (section 2.3) the bit is off (0). For privately
secured zones (section 2.2), the setting of the bit is determined by
whether the parent signs the child's keys or not. Hence, for
privately secured zones, the parent may have no responsibility. A
child wishing to have the parent set the bit must contact the parent.
3.2 Rules Governing the Bit
In this section, the words of the previous are turned into definitive
MUST and SHOULDs. Note that this section does not refer to the bit in
the NXT. This is in anticipation of a change in the way NXT indicates
types present (e.g., if bit 0 of the field is defined) or a successor
to the NXT is defined.
3.2.a. At a delegation point, a parent zone MUST have a mechanism in
place to indicate which RR sets are present. The mechanism MUST
indicate that the NS, SIG, and the type(s) corresponding to the
mechanism itself are present (of course, with these types actually
being present). With the exception of the KEY RR type, all other
types MUST be indicated as not present, and, in accordance with
delegation rules, actually be absent from the zone. If, in the
future, other data is permitted to be present at a delegation point,
this requirement MUST be amended.
Assuming the NXT record, the above requirement reads as follows. At a
delegation point, a parent zone must have a secured NXT record. This
NXT record must indicate that the NS, SIG, and NXT types are present.
With the exception of KEY, all other types must be indicated as not
present. The lower casing of the word "must" is intentional,
conveying that this is an explanation of the rule above.
3.2.b. The KEY set MUST be indicated as present during the time when
the parent has issued a signature for the child's KEY set. Conversely,
during periods of time in which the parent knows it has not generated
a signature for the KEY RR set, the KEY set MUST be indicated to be
absent.
If the parent has issued signatures with discontinuous validity spans,
then the presence of the KEY set will flip from present to not present
and back as time progresses.
If the parent is aware that the child's keys are becoming valid or
will be becoming invalid at a certain point in time, it is recommended
that this be reflected in the NXT's signature validity period.
3.2.c. When signing a child's KEY RR set, a parent SHOULD carefully
consider the algorithm of the key used to generate the signature. The
parent SHOULD make clear to child zones what steps are to be taken to
Expires August 1, 2000 [Page 6]
DNS Security Extension Clarification on Zone Status February 1, 2000
get the parent to indicate that the child is signed. This document
will go no further in specifying operational considerations.
(Let's say the parent signs the child's key set with an algorithm the
child can't process. The child could elect not to advertise this
signature as it cannot verify that the signature covers the real key
set. If this happens, is the parent justified in claiming that the
child is secured?)
3.2.d. The parent MUST allow the child, through some trusted, probably
non-DNS mechanism, to request that the indication of the KEY set in
the NXT be turned off. This allows a child to revert to an unsigned
state.
3.2.e. The parent SHOULD NOT allow the child to request that the KEY
set be indicated in the absence of a key signing request.
3.3 Operational Considerations
Retrieving the NXT for a delegated name from the parent zone (the
upper NXT) is not a trivial operation. The complication arises due to
having an NXT in the delegatee (the lower NXT) that matches the owner
name of the upper NXT. (The case in which both the parent and child
zones are secured is the only case mentioned here. If both are not
secured, then there will be at most one NXT, which is easily
retrieved.)
There are two complications to describe. One involves the multiple
NXT sets matching the same owner. The other is the pragmatic issue of
knowing where to get the answer.
With multiple NXT sets at the same owner, caches may become a problem.
If a (for example) recursive server has cached the lower NXT, any
query for the upper NXT may be confused for a lower NXT query. This
is akin to the issue of the ANY query, where a server with some cached
data will answer with just that and not seek the rest of the data.
A resolver may know the child's server's addresses and the parent zone
may not be sharing servers with the child. In this case the resolver
will need to be able to locate the parent zones (possibly having to go
to the root servers and descend) in order to obtain the upper NXT
record.
A potential solution to this is to define an NXT meta-query which will
force a recursive server to find all available NXT RR sets for a given
name. Details of this have not been examined.
3.4 Interaction with Dynamic Update
Dynamic update [RFC 2136, draft-ietf-dnsext-simple-secure-update-
xy.txt] defines a means by which a zone can change without undergoing
a full reload. This combination of dynamic update and the proposed
use of the NXT record to signify a child's status raises some
concerns.
Expires August 1, 2000 [Page 7]
DNS Security Extension Clarification on Zone Status February 1, 2000
First a few elements need to be labeled. There is an off-line signer,
which is the process that signs zone data files away from the name
server. There is an on-line signer, part of a name server, that the
dynamic update mechanism uses to sign the updated data. Finally,
there is an on-line key validator, perhaps a misnomer, which accepts
requests for parent signatures over each child zone's keys.
The proposal depicted in this draft relies upon the on-line key
validator informing the on-line and off-line signers of the status of
a child, recall that the status of a child has a temporal element.
E.g., a signature may be generated for just the month of July, so the
child is secured for the month of July, but not August.
The first issues pertain to the way in which a validation is encoded
in an NXT record by the off-line signer. There is a need for the
status information to flow from the on-line validator to the off-line
signer and then be used as input to the signing process. The way that
this information makes the transition is an issue. The second issue
is through what mechanism is this information ingested into the NXT
generating process. Recall that all other information can be derived
by the zone data, the status of the child isn't stored anywhere else
in the parent zone.
The next issue is the means in which a validation action is reported
to the active zone. On the surface, dynamically updating the NXT
would seem to make sense, but updating the NXT in this manner can lead
to a race condition in the server, this is unstable. The issue here
is deriving a mechanism by which a name server knows to signify that
the child status has changed. Note that this applies to newly
validated keys as well as the granting of a child's request to cancel
a validation.
The final issue is the operation of the off-line signer. When an NXT
is being regenerated, the old NXT is needed to see what the previous
setting of the child's status had been. The old NXT signature is also
needed to know that, had the child been known to be secured, for what
interval was is it thought to be secured so that the new NXT signature
is appropriately set. Of course, if the reason for updating the NXT
is a change as described in the previous paragraph, the old NXT is of
lesser value.
The issue raised in the last paragraph leads to a questioning of the
sanity of using signature validity periods to signify the temporal
status of data in a server. What does a server return if the NXT
needed is not currently covered by a valid signature?
4 NULL keys
Through the use of the types present to indicate the existence of a
signature validating the KEY set of a child, the need for NULL keys
effectively disappears. NULL keys are left as a defined entity, but
are rendered meaningless in DNSSEC.
Expires August 1, 2000 [Page 8]
DNS Security Extension Clarification on Zone Status February 1, 2000
5 Experimental Status
Without NULL keys, an experimentally secured zone cannot be defined as
it is in RFC 2535. The purpose of an experimentally secured zone was
to facilitate the migration from an unsecured zone to a secured zone.
The objective of facilitating the migration can be achieved without a
special designation of an experimentally secure status. Experimentally
secured is a special case of privately secured. A zone administrator
can achieve this by publishing a zone with signatures and configuring
a set of test resolvers with the corresponding public keys. Even if
the public key is published in a KEY RR, as long as there is no parent
signature, the resolvers will need some preconfiguration to know to
process the signatures. This allows a zone to be secured with in the
sphere of the experiment, yet still be registered as unsecured in the
general Internet.
6 IANA/ICANN Considerations
This document does not request any action from an assigned number
authority nor recommends any actions.
7 Security Considerations
Without a means to enforce compliance with specified protocols or
recommended actions, declaring a DNS zone to be "completely" secured
is impossible. Even if, assuming an omnipotent view of DNS, one can
declare a zone to be properly configured for security, and all of the
zones up to the root too, a misbehaving resolver could be duped into
believing bad data. If a zone and resolver comply, a non-compliant or
subverted parent could interrupt operations. The best that can be
hoped for is that all parties are prepared to be judged secure and
that security incidents can be traced to the cause in short order.
8 Acknowledgements
The need to refine the definition of a secured zone has become
apparent through the efforts of the participants at two DNSSEC
workshops, sponsored by the NIC-SE (.se registrar) and CAIRN (a
DARPA-funded research network). Further discussions leading to the
document include Olafur Gudmundsson, Russ Mundy, Robert Watson, and
Brian Wellington.
9 References
[RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities,"
RFC 1034, November 1987.
[RFC1035] P. Mockapetris, "Domain Names - Implementation and
Specification," RFC 1034, November 1987.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997
Expires August 1, 2000 [Page 9]
DNS Security Extension Clarification on Zone Status February 1, 2000
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic
Updates in the Domain Name System," RFC 2136, April 1997.
[RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC
2535, March 1999.
[draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple
Secure Domain Name System (DNS) Dynamic Update", version 00, February
2000.
10 Author Information
Edward Lewis NAI Labs 3060 Washington Road Glenwood, MD 21738 +1 443
259 2352 <lewis@tislabs.com>
11 Full Copyright Statement
Copyright (C) The Internet Society (1999, 2000). 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."
Expires August 1, 2000 [Page 10]

927
doc/draft/draft-ietf-dnsind-iana-dns-02.txt
View File

@@ -1,927 +0,0 @@
INTERNET-DRAFT Donald E. Eastlake 3rd (IBM)
Eric Brunner (Nokia)
Bill Manning (ISI)
Expires: April 2000 October 1999
draft-ietf-dnsind-iana-dns-02.txt
Domain Name System (DNS) IANA Considerations
------ ---- ------ ----- ---- --------------
Status of This Document
Distribution of this draft <draft-ietf-dnsind-iana-dns-02.txt> is
unlimited. Comments should be sent to the DNS Working Group mailing
list <namedroppers@internic.net> or to the authors.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``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.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 1]
INTERNET-DRAFT DNS IANA Considerations October 1999
Abstract
Internet Assigned Number Authority (IANA) considerations are given
for the allocation of Domain Name System (DNS) classes, RR types,
operation codes, error codes, etc.
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Table of Contents..........................................2
1. Introduction............................................3
2. DNS Query/Response Headers..............................4
2.1 One Spare Bit?.........................................4
2.2 Opcode Assignment......................................5
2.3 RCODE Assignment.......................................5
3. DNS Resource Records....................................7
3.1 RR TYPE IANA Considerations............................8
3.1.1 Special Note on the OPT RR...........................8
3.1.2 Special Note on the SINK RR..........................9
3.2 RR CLASS IANA Considerations...........................9
3.3 RR NAME IANA Considerations...........................10
3.3.1 Reserved TLDs in the Internet CLASS.................10
3.3.2 'Country Code' TLDs in the Internet CLASS...........11
3.3.3 Other TLDs in the Internet CLASS....................12
4. Security Considerations................................13
References................................................13
Appendix: Single Letter or Digit Labels...................15
Authors Addresses.........................................16
Expiration and File Name..................................16
D. Eastlake 3rd, E. Brunner, B. Manning [Page 2]
INTERNET-DRAFT DNS IANA Considerations October 1999
1. Introduction
The Domain Name System (DNS) provides replicated distributed secure
hierarchical databases which hierarchially store "resource records"
(RRs) by CLASS under domain names.
This data is structured into CLASSes and zones which can be
independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535]
familiarity with which is assumed.
This document covers, either directly or by reference, general IANA
considerations applying across DNS query and response headers and all
RRs. There may be additional IANA considerations that apply to only
a particular RR type or query/response opcode. See the specific RFC
defining that RR type or query/response opcode for such
considerations if they have been defined.
IANA presently maintains a web page of DNS parameters at
<http://www.isi.edu/in-notes/iana/assignments/dns-parameters>.
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.
The terms of art used herein with respect to IANA Considerations are
as defined in [RFC 2434].
D. Eastlake 3rd, E. Brunner, B. Manning [Page 3]
INTERNET-DRAFT DNS IANA Considerations October 1999
2. DNS Query/Response Headers
The header for DNS queries and responses contains field/bits in the
following diagram taken from [RFC 2136, 2535]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The ID field identifies the query and is echoed in the response so
they can be matched.
The QR bit indicates whether the header is for a query or a response.
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. However,
many DNS implementations copy the query header as the initial value
of the response header without clearing bits. Thus any attempt to
use a "query" bit with a different meaning in a response or to define
a query meaning for a "response" bit is dangerous given existing
implementation. Such meanings may only be assigned by an IETF
standards action.
The QDCOUNT, ANCOUNT, NSCOUNT, and ARCOUNT fields give the number of
queries in the Query section, answer RRs in the Answer section, RRs
in the Authority section, and informational RRs in the Additional
Information section, respectively, for all opcodes except Update.
These fields have the same structure and data type for update but are
instead the counts for the Zone (ZOCOUNT), Prerequisite (PRCOUNT),
Update (UPCOUNT), and Additional Information (ARCOUNT) sections.
2.1 One Spare Bit?
It would appear that the "Z" bit is spare and [RFC 1035] says that it
must be zero in all queries and responses. However, there have been
DNS implementations for which that bit being on in a query meant that
D. Eastlake 3rd, E. Brunner, B. Manning [Page 4]
INTERNET-DRAFT DNS IANA Considerations October 1999
only a response from the primary server for a zone is acceptable.
It is believed that modern DNS implementations ignore this bit.
Assigning a meaning to this bit requires an IETF standards action.
2.2 Opcode Assignment
Currently DNS OpCodes are assigned as follows:
OpCode Name Reference
0 Query [RFC 1035]
1 IQuery (Inverse Query) [RFC 1035]
2 Status [RFC 1035]
3 available for assignment
4 Notify [RFC 1996]
5 Update [RFC 2136]
6-15 available for assignment
New OpCode assignments require an IETF consensus.
2.3 RCODE Assignment
It would appear from the DNS header above that only four bits of
RCODE, or response/error code are available. However, RCODEs can
appear not only at the top level of a DNS response but also inside
TSIG RRs [RFC XXX3] and OPT RRs [RFC 2671]. The OPT RR provides an
eight bit extension resulting in a 12 bit RCODE field and the TSIG RR
has a 16 bit RCODE field.
RCODE Name Reference
0 NoError No Error [RFC 1035]
1 FormErr Format Error [RFC 1035]
2 ServFail Server Failure [RFC 1035]
3 NXDomain Non-Existent Domain [RFC 1035]
4 NotImp Not Implemented [RFC 1035]
5 Refused Query Refused [RFC 1035]
6 YXDomain Name Exists when it should not [RFC 2136]
7 YXRRSet RR Set Exists when it should not [RFC 2136]
8 NXRRSet RR Set that should exist does not [RFC 2136]
9 NotAuth Server Not Authoritative for zone [RFC 2136]
10 NotZone Name not contained in zone [RFC 2136]
11-15 available for assignment
16 BADSIG Signature Failure [RFC XXX3]
D. Eastlake 3rd, E. Brunner, B. Manning [Page 5]
INTERNET-DRAFT DNS IANA Considerations October 1999
17 BADKEY Key not recognized [RFC XXX3]
18 BADTIME Signature out of time window [RFC XXX3]
19-0xFFFF available for assignment
Since it is important that RCODEs be understood for interoperability,
new RCODE assignment requires an IETF consensus.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 6]
INTERNET-DRAFT DNS IANA Considerations October 1999
3. DNS Resource Records
All RRs have the same top level format shown in the figure below
taken from [RFC 1035]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAME is an owner name, i.e., the name of the node to which this
resource record pertains. NAMEs are specific to a CLASS as described
in section 3.2. NAMEs consist of an ordered sequence of one or more
labels each of which has a label type [RFC 1035, 2671]. See also
IANA NAME considerations in section 3.3.
TYPE is a two octet unsigned integer containing one of the RR TYPE
codes. See section 3.1.
CLASS is a two octet unsigned integer containing one of the RR CLASS
codes. See section 3.2.
TTL is a four octet (32 bit) bit unsigned integer that specifies the
number of seconds that the resource record may be cached before the
source of the information should again be consulted. Zero is
interpreted to mean that the RR can only be used for the transaction
in progress.
RDLENGTH is an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
RDATA is a variable length string of octets that constitutes the
resource. The format of this information varies according to the
TYPE and in some cases the CLASS of the resource record.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 7]
INTERNET-DRAFT DNS IANA Considerations October 1999
3.1 RR TYPE IANA Considerations
There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
and MetaTYPEs.
Data TYPEs are the primary means of storing data QTYPES can only be
used in queries. Meta-TYPEs designate transient data associated with
an particular DNS message and in some cases can also be used in
queries. Thus far, data TYPEs have been assigned from 1 upwards plus
the block from 100 through 103 while Q and Meta Types have been
assigned from 255 downwards (??? except for the OPT RR which is
assigned TYPE 41 ???).
There are currently three Meta-TYPEs: TSIG [RFC XXX3], TKEY [RFC
XXX5], and OPT [RFC 2671].
There are currently five QTYPEs: * (all), MAILA, MAILB, AXFR, and
IXFR.
Considerations for the allocation of new RR TYPEs are as follows:
0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
2535] and in other circumstances and must never be allocated
for ordinary use.
0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
TYPEs only by IETF consensus.
0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
Meta TYPEs only by IETF consensus.
0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
consensus.
0x8000 - 0xFEFF - assigned based on RFC publication.
0xFF00 - 0xFFFF - this block is assigned for private experimental
use. Because their use is not coordinated, values/uses may
conflict between different experiments.
3.1.1 Special Note on the OPT RR
The OPT (OPTion) RR, number 41 (???), is specified in [RFC 2671].
Its primary purpose is to extend the effective field size of various
DNS fields including RCODE, label type, OpCode, flag bits, and RDATA
size. In particular, for resolvers and servers that recognize it, it
extends the RCODE field from 4 to 12 bits.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 8]
INTERNET-DRAFT DNS IANA Considerations October 1999
3.1.2 Special Note on the SINK RR
The (Kitchen) SINK RR, number 40, is specified in RFC [XXX2]. It is
designed to accommodate requirements for proprietary RRs and provides
flexible encoding and semantic labeling of the RDATA potion. This
should virtually eliminate the need to allocate RR types codes for
private or proprietary purposes.
3.2 RR CLASS IANA Considerations
DNS CLASSes have been little used but constitute another dimension of
the DNS distributed database. In particular, there is no necessary
relationship between the namespace or roots servers for one CLASS and
those for another CLASS. The same name can have completely different
meanings in different CLASSes. However, as global networking and DNS
have evolved, the IN, or Internet, CLASS has dominated DNS use.
There are two subcategories of DNS CLASSes: normal data containing
classes and QCLASSes that are only meaningful in queries or updates.
The current data class assignments and considerations for future
assignments are as follows:
0x0000 - assignment requires an IETF standards action.
0x0001 - Internet (IN).
0x0002 - available for assignment by IETF consensus as a data CLASS.
0x0003 - Chaos (CH) [Moon 81].
0x0004 - Hesiod (HS) [Dyer 87].
0x0005 - 0x007F - available for assignment by IETF consensus as data
CLASSes only.
0x0080 - 0xFFFD - available for assignment by IETF consensus as
QCLASSes only.
0x00FE - QCLASS None [RFC 2136].
0x00FF - QCLASS Any [RFC 1035].
0x0100 - 0x7FFF - assigned by IETF consensus.
0x8000 - 0xFEFF - assigned by RFC publication.
0xFF00 through 0xFFFE are assigned for private experimental use.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 9]
INTERNET-DRAFT DNS IANA Considerations October 1999
Because their use is not coordinated, it values/uses may
conflict between different experiments.
0xFFFF - can only be assigned by an IETF standards action.
3.3 RR NAME IANA Considerations
DNS NAMEs are sequences of labels [RFC 1035]. The last label in each
NAME is "ROOT" which is the zero length label. By definition, the
null or ROOT label can not be used for any other NAME purpose.
At the present time, there are two categories of label types, data
labels and compression labels. Compression labels are pointers to
data labels elsewhere within an RR or DNS message and are intended to
shorten the wire encoding of NAMEs. The two existing data label
types will be referred to as ASCII and Binary. ASCII labels can, in
fact, include any octet value including zero octets but most current
uses involve only [US-ASCII] For retrieval ASCII labels are defined
to treat upper and lower case letters the same. Binary labels are
bit sequences [RFC 2673].
IANA considerations for label types are given in [RFC 2671].
NAMEs are local to a CLASS. The Hesiod [Dyer 87] and Chaos [Moon 81]
CLASSes are essentially for local use. The IN or Internet CLASS is
thus the only DNS CLASS in global use on the Internet at this time.
The following subsections give IANA considerations for the allocation
of names in the IETF recommended root zone. See also [RFC 1591].
3.3.1 Reserved TLDs in the Internet CLASS
[NOTE: Reserved Top Level DNS Names are BCP 32. The material here
and in the Appendix needs to be made into an update/supplement to BCP
32.]
All Binary label TLDs [RFC 2673] and other new non-ASCII TLD label
data types are reserved.
The remainder of this subsection and 3.3.2 and 3.3.3 refer only to
ASCII labels.
All TLDs including any octets that are not letters, digits, or hyphen
are reserved. Expression of internationalized names in the DNS is an
active area of investigation within the IETF at this time and may
make use of these reserved TLD octet values.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 10]
INTERNET-DRAFT DNS IANA Considerations October 1999
All numeric TLDs from "0" through "4294967295" ( 2**32 -1 ) are
reserved to avoid conflict with IPv4 integer and dotted quad address
notations. While many standards distinguish readable addresses by
surrounding them with square brackets ("[]"), other widely used
standards such as URIs [RFC 2396] do not provide any syntactic way to
distinguish these.
All single octet length top level domain (TLD) names are reserved.
Should the root zone ever get very large, there are technical
solutions involving referral to servers providing splits of the zone
based on the first name octet, which would be eased by having the
single byte TLDs available. In addition, these provide a potential
additional axis for DNS expansion. For like reasons, it is
recommended that within TLD zones or indeed within any zone that is
or might become very large, in the absence of a strong reason to the
contrary, all single octet names be reserved. See Appendix.
Finally, the four ASCII TLDs "example", "invalid", "localhost", and
"test" are reserved as described in [RFC 2606].
Assignment of any of the above reserved names requires an IETF
consensus.
3.3.2 'Country Code' TLDs in the Internet CLASS
Two octet length ASCII label TLDs in the Internet CLASS consisting of
letters are for assignment to geo-political territories. Those (1)
allocated by [ISO 3166-1] and (2) allocated by the Universal Postal
Union [UPU] and reserved in [ISO 3166-1] even though not formally
assigned by [ISO 3166-1], are assigned as so allocated. Two letter
codes reserved by [ISO 3166-1] for local use or the like are also
reserved as TLDs as are two letter TLDs not yet allocated or reserved
by [ISO 3166-1]. A generally recognized acting government of the
territory associated with a "country code" has priority to act as or
designate the registrar for such TLDs. If no such government has
exercised its authority, non-governmental entities may act as the
registrar (see www.iana.org).
Normal diplomatic usage recognizes that special consideration can be
given to founders. For example, at every Olympics, three flags are
equally honored: the Olympic flag, the host nation flag, and the
Greek flag because Greece was the founder of the modern Olympics.
The Universal Postal Union [UPU] requires all stamps used
internationally to indicate the country issuing them except for the
stamps of Great Britain. As the first nation to issue stamps, it is
exempt from this restriction. Similarly, as the founder of the
Internet and due to historical factors, the United States of America
is assigned the three letter TLDs ".gov" and ".mil" in addition to
D. Eastlake 3rd, E. Brunner, B. Manning [Page 11]
INTERNET-DRAFT DNS IANA Considerations October 1999
".us".
Two byte codes consisting of other than letters and not reserved in
3.3.1 above are not currently used by [ISO 3166-1] or the [UPU].
However, to permit possible expansion of the two octet country codes,
they are reserved for future allocation with priority to be given for
usage by [ISO 3166-1]
3.3.3 Other TLDs in the Internet CLASS
IANA manages the ".arpa" and ".int" TLDs. The "arpa" TLD is assigned
for use in the IPv4 inverse mapping and IANA delegates /8 subzones to
holders of a /8 chunk of address space, including the regional
address registries. "int" includes the IPv6 inverse address mapping
which is at "ip6.int", international treaty organizations, and
international registrations at "reg.int". IANA considerations for IP
address assignment are given elsewhere.
Control and assignment of various other existing or prospective
Internet CLASS TLDs and the authority for the creation of new TLDs is
being transferred to the ICANN (www.icann.org) and the DNSO (Domain
Name Support Organization, www.dnso.org). Traditionally ".edu" was
used for educational institutions, ".net" for network infrastructure
organizations, "com" for commercial organizations, and ".org" for
other non-profit organizations.
New registrations in ".edu" are currently restricted to four year or
longer institutions of higher learning.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 12]
INTERNET-DRAFT DNS IANA Considerations October 1999
4. Security Considerations
This document addresses IANA considerations in the allocation of
general DNS parameters, not security. See [RFC 2535] for secure DNS
considerations.
References
[Dyer 87] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
Plan - Name Service, April 1987,
[ISO 3166-1] - "Codes for the representation of names of countries",
<http://www.din.de/gremien/nas/nabd/iso3166ma/>.
[Moon 81] - D. moon, "Chaosnet", A.I. Memo 628, Massachusetts
Institute of Technology Artificial Intelligence Laboratory, June
1981.
[RFC 1034] - P. Mockapetris, "Domain Names - Concepts and
Facilities", STD 13, November 1987.
[RFC 1035] - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987.
[RFC 1591] - J. Postel, "Domain Name System Structure and
Delegation", March 1994.
[RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", August 1996.
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
[RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS
Specification", July 1997.
[RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", August 1998.
[RFC 2434] - "Guidelines for Writing an IANA Considerations Section
in RFCs", T. Narten, H. Alvestrand, October 1998.
[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 13]
INTERNET-DRAFT DNS IANA Considerations October 1999
[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
June 1999.
[RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
1999.
[RFC 2672] - M. Crawford, " Non-Terminal DNS Name Redirection",
August 1999.
[RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
August 1999.
[RFC XXX2] - D. Eastlake, "The Kitchen Sink DNS Resource Record", xxx
1999 (draft-ietf-dnsind-kitchen-sink-*.txt).
[RFC XXX3] - P. Vixie, O. Gundmundsson, D. Eastlake, B. Wellington,
"Secret Key Transaction Signatures for DNS (TSIG)", xxx 1999 (draft-
ietf-dnsind-tsig-*.txt).
[RFC XXX5] - D. Eastlake, "Secret Key Establishment for DNS (TKEY
RR)", xxx 1999 (draft-ietf-dnsind-tkey-00.txt).
[UPU] - Universal Postal Union, <http://www.upu.int>
[US-ASCII - ANSI, "USA Standard Code for Information Interchange",
X3.4, American National Standards Institute: New York, 1968.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 14]
INTERNET-DRAFT DNS IANA Considerations October 1999
Appendix: Single Letter or Digit Labels
As described in Section 3.3.1, single octet ASCII labels should
generally be reserved.
In furtherance of this, on December 1st, 1993, IANA explicitly
reserved all available single letter and single digit second level
domain names in ".com", ".net", and ".org". Existing assignments,
listed below, were not disturbed.
q.com JG (Q225-DOM)
x.com Weinstein & DePaolis (X-DOM)
z.com HomePage.com, Inc (Z87-DOM)
i.net inet solutions pty.ltd. (I274-DOM)
q.net Q Net (Q-DOM)
x.org The Open Group (X57-DOM)
There was no need to explicitly reserve other single octet second
level domain names in these TLDs because such non-letter non-digit
names were not being assigned. There was no need to explicitly
reserve single octet top level domain names because those required
IANA approval in any case.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 15]
INTERNET-DRAFT DNS IANA Considerations October 1999
Authors Addresses
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road
Carmel, NY 10512 USA
Telephone: +1-914-784-7913 (w)
+1-914-276-2668 (h)
fax: +1-914-784-3833 (w)
email: dee3@us.ibm.com
Eric Brunner
Nokia Research Center
3 Burlington Woods Drive, Suite 250
Burlington, MA 01803 USA
Telephone: +1 781-359-5159
fax: +1 781-359-5196
email: brunner@world.std.com
Bill Manning
USC/ISI
4676 Admiralty Way, #1001
Marina del Rey, CA 90292 USA
Telephone: +1 310 822 1511
email: bmanning@isi.edu
Expiration and File Name
This draft expires April 2000.
Its file name is draft-ietf-dnsind-iana-dns-02.txt.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 16]

317
doc/draft/draft-ietf-dnsind-simple-secure-update-01.txt
View File

@@ -1,317 +0,0 @@
DNSIND Working Group Brian Wellington (NAILabs)
INTERNET-DRAFT June 1999
<draft-ietf-dnsind-simple-secure-update-01.txt>
Updates: RFC 2535, RFC 2136, [TSIG]
Replaces: RFC 2137, [update2]
Simple Secure Domain Name System (DNS) Dynamic Update
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
Comments should be sent to the authors or the DNSIND WG mailing list
namedroppers@internic.net.
This draft expires on December 25, 1999.
Copyright Notice
Copyright (C) The Internet Society (1999). All rights reserved.
Abstract
This draft proposes a method for performing secure Domain Name System
(DNS) dynamic updates. The method described here is simple to
Expires December 1999 [Page 1]
INTERNET-DRAFT Simple Secure Dynamic Update June 1999
understand and use, and flexible enough to represent any policy
decisions. Secure communication based on request/transaction
signatures is used to provide authentication and authorization.
1 - Introduction
Dynamic update operations for the Domain Name System are defined in
[RFC2136], but no mechanisms for security are defined. A form of secure
dynamic update is defined in [RFC2137, update2]. Request and
transaction signatures are defined in [TSIG] and [RFC2535].
Familiarity with the DNS system [RFC1034, RFC1035] as well as the
proposals mentioned above is assumed.
1.1 - Overview of DNS Dynamic Update
DNS dynamic update defines a new DNS opcode and a new interpretation of
the DNS message if that opcode is used. An update can specify
insertions or deletions of data, along with prerequisites necessary for
the updates to occur. All tests and changes for a DNS update request
are restricted to a single zone, and are performed at the primary server
for the zone. The primary server for a dynamic zone must increment the
zone SOA serial number when an update occurs or before the next
retrieval of the SOA.
1.2 - Overview of DNS Transaction Security
Transaction signatures (TSIG [TSIG] and SIG(0) [RFC2535]) provide the
means for two processes to authenticate DNS requests and responses sent
between them. A TSIG is generated from a shared secret, and a SIG(0) is
generated from a private key whose public counterpart is stored in DNS.
In both cases, a record containing the message signature is included as
the final resource record in a DNS message. Keyed hashes, used in TSIG,
are simple to calculate and verify, and do not require caching of data.
Public key encryption, as used in SIG(0), is more scalable.
1.3 - Requirement of a message signature
In some cases, DNSSEC SIG records could be used to protect the integrity
of individual RRs or RRsets in the update process. There are several
problems with this, though. First, SIG records do not cover the message
header, so malicious tampering in the header or the removal of records
would be unnoticed. A SIG record would be required in the zone section,
to prevent tampering. SIG records could be created to protect data in
the prerequisite section, but this would imply that the SIG is a
prerequisite, and in some cases, the SIG may be present in DNS and
require no computation. In the update section, signing addition
Expires December 1999 [Page 2]
INTERNET-DRAFT Simple Secure Dynamic Update June 1999
requests is straightforward, but signing delete requests is difficult,
since there may be no remaining set that a SIG would cover.
Message based signatures, using TSIG or SIG(0), avoid these problems,
since only one signature is computed for the message, and this signature
protects the integrity of the entire message. This is also a less
expensive operation.
1.4 - Removal of non-zone key SIG records
The main objective of a DNSSEC capable resolver is the authenticated
retrieval of data. When data is received, a chain of trust is followed
to the root. This chain of trust must include the zone key of the zone
containing the data, but can become overly complicated if host and user
keys are delegated signing authority. In this proposal, only signatures
generated by zone keys are considered relevant to DNSSEC capable
resolvers. This is an update to the DNSSEC specification [RFC2535], and
simplifies the resolution process.
The primary usefulness of host and user keys, with respect to DNSSEC, is
to authenticate dynamic updates. Thus, host and user keys may be used
to generate SIG(0) records to authenticate updates, or be used in the
TKEY [TKEY] process to generate TSIG shared secrets. In both cases, no
SIG records generated by non-zone keys will be present in DNS.
This completely disassociates authentication of an update request from
authentication of the data itself. Authentication of the update message
can be done with either TSIG shared secrets or DNSSEC host or user keys.
Authentication of the data, once it is present in DNS, only involves
DNSSEC zone keys.
1.5 - Signatory strength
[RFC2535] defines the signatory field of a key as the final 4 bits of
the flags field, but does not define its value. This proposal defines
the field as a 4 bit unsigned integer representing strength, where 15 is
strongest. A key of a certain strength can replace data signed by a key
of equal or lesser strength. Data signed by this key can be replaced by
a key with equal or greater strength. Note that this strength is
unrelated to the number of bits in the key.
Expires December 1999 [Page 3]
INTERNET-DRAFT Simple Secure Dynamic Update June 1999
2 - Authentication
TSIG or SIG(0) records MUST be attached to all secure dynamic update
messages. This allows the server to verifiably determine the originator
of the message; the originator is either the other party sharing the
TSIG secret or the host or user that owns the key generating the SIG(0).
Note that SIG(0) signatures MAY NOT be generated by zone keys.
If a SIG(0) is used, the signatory strength can be derived from the
signing KEY. If a TSIG is used that was automatically generated using
TKEY, the signatory strength of the TSIG is declared to be the same as
the KEY used in the TKEY process. If a TSIG is used that was manually
configured, its signatory strength SHOULD be manually configured also
(or left as the default). The key name/strength pair can be used in the
decision of whether to accept the update.
DNSSEC SIG records (other than SIG(0)) may be included in an update
message, but are not used for authentication purposes in the secure
update protocol. If a message fails the authentication test due to an
unauthorized key, the failure is indicated with the REFUSED rcode.
Other TSIG or dynamic update errors are returned unchanged.
3 - Policy
All policy is enforced by the server and configured by the zone
administrator. Policy checks are based on identity, where the identity
is equivalent to the owner (name) of the message signing key. The
signing strength of the key is also important when updating a secure
zone, since the message signing key's strength can be compared to the
strength of the zone key(s).
The server's policy defines criteria which determine if the key used to
sign the update is permitted to update the records requested. By
default, a key cannot make any changes to the zone; the key's scope must
be explicitly enabled. There are several reasons that this process is
implemented in the server and not the protocol (as in [RFC2137,
update2], where the signatory bits of KEY records may define the
policy).
3.1 - Flexibility
Storing policy in the signatory fields of DNS keys is overly
restrictive. Only a fixed number of bits are present, which means that
only a fixed number of policy decisions are representable. There are
many decisions that do not fit into the framework imposed by the
signatory field; a zone administrator cannot effectively impose a policy
not implemented in the draft defining the field.
Expires December 1999 [Page 4]
INTERNET-DRAFT Simple Secure Dynamic Update June 1999
There may be any number of policies applied in the process of
authorization, and there are no restrictions on the scope of these
policies. Implementation of the policies is beyond the scope of this
document.
3.2 - Simplicity
Policy decisions in the server could be used as an adjunct to policy
fields in the KEY records. This could lead to confusion if the policies
are inconsistent. Furthermore, since there is no need to expose
policies and policies need only be present at the primary server for a
zone, a central configuration point is more logical.
3.3 - Extendibility
If a policy is changed, there are no changes made to the DNS protocol or
the data on the wire. This means that new policies can be defined at
any point without adverse effects or interoperability concerns.
3.3 - Recommendations
In many cases, dynamic updates should be restricted by name. An example
would be that updates are allowed only if the name to be updated is
under the name of the message signing key. Since the signatory field
defines a key's signing strength, a simple policy would only allow a key
to update signed data if the message signing key was at least as strong
as the zone key that signed the RRset.
4 - Interaction with DNSSEC
A successful update request may or may not include SIG records for each
RRset. Since SIG records are not used for authentication in this
protocol, they are not required. If the updated zone is signed, the
server will generate SIG records for each updated RRset with a zone key
(which MUST be online), unless the set is already correctly signed by a
zone key. If multiple zone keys are online, the zone key with the
greatest signatory strength less than or equal to that of the update
message signing key is chosen.
If there are any immaterial (to DNSSEC) SIG records present, these are
retained. If there are SIG records that have been generated by an
appropriate zone KEY, these SIGs are verified and retained if the
verification is successful. DNSSEC SIG records generated by any other
KEY are dropped. The server will also, if necessary, generate a new SOA
record and new NXT records, and sign these with a zone key. Unlike
traditional dynamic update, the client is forbidden from updating NXT
records. SOA updates are allowed, since SOA serial advancement policies
can be outside of the scope of the DNS protocol.
Expires December 1999 [Page 5]
INTERNET-DRAFT Simple Secure Dynamic Update June 1999
Multiple zone keys can be useful in conjunction with secure dynamic
update. A strong zone key can be used offline to sign static data,
while a weaker zone key can sign dynamic data. If signed updates are
received with key strengths stronger than the weak zone key, updates
will be allowed only to RRsets signed by the weak zone key. It is
highly recommended that no host or user key be allowed to have a
signatory strength equal to or greater than the strongest zone key.
5 - Security considerations
For a secure zone to support dynamic update, a zone key MUST be online
(unlike [RFC2137]). An online zone key would be required to sign NXT
records even if other signatures were not done online, since allowing
NXT updates is inherently dangerous.
6 - Acknowledgements
The author would like to thank Olafur Gudmundsson, Bob Halley, and Ed
Lewis for review and informative comments.
7 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, ISI, November 1987.
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
& Cisco & DEC, April 1997.
[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC
2137, CyberCash, April 1997.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC
2065, IBM, March 1999.
[TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington
``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
ietf-dnsind-tsig-09.txt, ISC & TISLabs & IBM & TISLabs, June
1999.
[update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic
Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite
Systems Company, August 1998.
Expires December 1999 [Page 6]
INTERNET-DRAFT Simple Secure Dynamic Update June 1999
[TKEY] D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),''
draft-ietf-dnsind-tkey-00.txt, IBM, May 1999.
8 - Author's Address
Brian Wellington
NAILabs
Network Associates
3060 Washington Road (Rt. 97)
Glenwood, MD 21738
+1 443 259 2369
<bwelling@tislabs.com>
Expires December 1999 [Page 7]

927
doc/draft/draft-ietf-dnsind-tkey-01.txt
View File

@@ -1,927 +0,0 @@
DNS Working Group Donald E. Eastlake, 3rd
INTERNET-DRAFT IBM
Expires: April 2000 October 1999
draft-ietf-dnsind-tkey-01.txt
Secret Key Establishment for DNS (TKEY RR)
------ --- ------------- --- --- ----- ---
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnsind-tkey-01.txt, is intended to
be become a Proposed Standard RFC. Distribution of this document is
unlimited. Comments should be sent to the DNS working group mailing
list <namedroppers@internic.net> or to the author.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``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.
Donald E. Eastlake, 3rd [Page 1]
INTERNET-DRAFT The DNS TKEY RR October 19999
Abstract
[draft-ietf-dnsind-tsig-*.txt] provides a means of authenticating and
securing Domain Name System (DNS) queries and responses using shared
secret keys via the TSIG resource record (RR). However, it provides
no mechanism for setting up such keys other than manual exchange.
This document describes a TKEY RR that can be used in a number of
different modes to establish shared secret keys between a DNS
resolver and server.
Acknowledgments
The substantial comments and ideas of the following persons (listed
in alphabetic order) have been incorporated herein and are gratefully
acknowledged:
Olafur Gudmundsson
Stuart Kwan
Brian Wellington
Donald E. Eastlake, 3rd [Page 2]
INTERNET-DRAFT The DNS TKEY RR October 19999
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Acknowledgments............................................2
Table of Contents..........................................3
1. Introduction............................................4
1.1 General Principles.....................................4
1.2 Overview of Contents...................................5
2. The TKEY Resource Record................................6
3. Exchange via Resolver Query.............................7
3.1 Query for Server Assigned Keying.......................8
3.2 Query for Diffie-Hellman Exchanged Keying..............9
3.3 Query for GSS-API Established.........................10
3.4 Query for Querier Assigned Keying.....................10
3.5 Query for TKEY Deletion...............................11
4. Spontaneous Server Inclusion...........................11
4.1 Spontaneous GSS-API Exchange..........................11
4.2 Spontaneous Key Deletion..............................12
5. Methods of Encryption..................................12
6. IANA Considerations....................................12
7. Security Considerations................................13
Changes from Previous Draft...............................14
References................................................15
Author's Address..........................................16
Expiration and File Name..................................16
Donald E. Eastlake, 3rd [Page 3]
INTERNET-DRAFT The DNS TKEY RR October 19999
1. Introduction
The Domain Name System (DNS) is a hierarchical, distributed, highly
available database used for mapping between domain names and
addresses, for email routing, and for other information [RFC 1034,
1035]. It has been extended to provide for public key security and
dynamic update [RFC 2136, RFC 2535]. Familiarity with these RFCs is
assumed.
[draft-ietf-dnsind-tsig-*.txt] provides a means of more efficiently
authenticating and securing DNS messages using shared secret keys via
the TSIG resource record (RR) but provides no mechanism for setting
up such keys other than manual exchange. This document describes a
TKEY RR that can be used in a number of different modes to establish
such shared secret keys between a DNS resolver and server.
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].
1.1 General Principles
TKEY is a meta-RR that is not stored or cached in the DNS and does
not appear in zone files. It supports a variety of modes for the
establishment and deletion of shared secret keys between DNS entities
such as resolvers and servers. The establishment of such a key
requires that state be maintained at both the resolver and the server
and the allocation of the resources to maintain such state may
require mutual agreement. In the absence of such agreement, servers
are free to return errors such as NotImp or Refused for any attempt
to use TKEY and resolvers are free to ignore any TKEY RRs they
receive.
In all cases herein, the term "resolver" includes that part of a
server which makes full and incremental [RFC 1995] zone transfer
queries as well as other queries.
Servers are not required to implement any particular mode or modes of
the defined modes of TKEY shared secret key establishment or deletion
and may return errors such as NotImp for any they do not support. In
the future, based on experience, more modes may be added or some
modes described herein may be made mandatory or deprecated.
The means by which the shared secret keying material, exchanged via
TKEY, is actually used in any particular TSIG algorithm is algorithm
dependent and is defined in connection with that algorithm.
Note that TKEY established keying material and TSIGs that use it are
Donald E. Eastlake, 3rd [Page 4]
INTERNET-DRAFT The DNS TKEY RR October 19999
associated with DNS hosts. They are not necessairly associated with
zones. They may be used to authenticate queries and responses but
they do not provide zone stored DNS data origin or denial
authentication [RFC 2535].
Two modes of TKEY, the server assigned and resolver assigned modes,
perform encryption which may effect their export or
import status for some countries. All other aspects of DNS security,
including the SIG, KEY, NXT, and TSIG RRs and all other currently
defined modes of TKEY perform authentication (signatures and
signature verification) only.
General protection against denial of service via the use of TKEY is
not provided.
Only one TKEY RR may occur in a queryr or response. Between any pair
of hosts, only one set of keying material may be in place at the same
time for any particulary key name. An attempt to establish another
set of keying material at a server for an existing name should return
a BADNAME error.
A reasonable key naming strategy is as follows:
If the key is generated as the result of a query with root as
its owner name, they the server can create a name consisting of
a hash of the key plus the server host name. For example
89n3mdg072pp.host.example.com.
If the key is generated as the result of a query with a non-root
name, say foo.example.net, the use the concatenation of that
with the server host name. For example
foo.example.net.host.example.com.
1.2 Overview of Contents
Section 2 below specifies the TKEY resource record (RR) and provides
a high level description of its constituent fields.
Section 3 discusses key exchange via requests with the Query opcode
for type TKEY. This is applicable to all currently defined TKEY
modes and in some cases in not what would intuitively be called a
"query".
Section 4 discusses spontaneous inclusion of TKEY RRs in responses by
servers. This is applicable to key deletion and to server assigned
modes.
Section 5 describes encryption methods for transmitting secret key
information.
Donald E. Eastlake, 3rd [Page 5]
INTERNET-DRAFT The DNS TKEY RR October 19999
Section 6 covers IANA considerations in assignment of TKEY modes.
Finally, Section 7 touches on some security considerations.
2. The TKEY Resource Record
The TKEY resource record (RR) has the structure given below. Its RR
type code is 249.
Field Type Comment
----- ---- -------
NAME domain see description below
TTYPE u_int16_t TKEY
CLASS u_int16_t ignored, should be zero
TTL u_int32_t SHOULD be zero
RDLEN u_int16_t size of RDATA
RDATA: Algorithm: domain
Inception: u_int32_t
Expiration: u_int32_t
Mode: u_int16_t
Error: u_int16_t
Key Size: u_int16_t
Key Data: octet-stream
Other Size: u_int16_t
Other Data: octet-stream undefined by this protocol
The Name field's meaning differs somewhat with mode and context as
explained in subsequent sections.
The TTL field SHOULD always be zero to be sure that older DNS
implementations do not cache TKEY RRs.
The algorithm name is a domain name with the same meaning as in
[draft-ietf-dnsind-tsig-*.txt]. The algorithm determines how the
secret keying material exchanged using the TKEY RR is actually used
to derive the algorithm specific key that is used.
The inception time and expiration time are in number of seconds since
the beginning of 1 January 1970 GMT ignoring leap seconds treated as
modulo 2**32 using ring arithmetic [RFC 1982]. In messages between a
DNS resolver to a DNS server where these fields are meaningful, they
are either the requested validity interval for the keying material
asked for or specify the validity interval of keying material
provided. See Security Considerations section in reference to replay
attacks.
The mode field specifies the general scheme for key agreement or
Donald E. Eastlake, 3rd [Page 6]
INTERNET-DRAFT The DNS TKEY RR October 19999
purpose of the TKEY DNS message. Note that implementation of TKEY as
a whole and of any particular mode is optional. The following values
of the Mode octet are defined, available, or reserved:
Value Description
----- -----------
0 - reserved
1 server/responder assignment
2 Diffie-Hellman exchange
3 GSS-API negotiation
4 resolver/querier assignment
5 key deletion
6-65534 - available, see IANA considerations section
65535 -reserved
The error code field is an extended RCODE. The following values are
defined:
Value Description
----- -----------
0 - no error
1-15 a DNS RCODE
16 BADSIG
17 BADKEY
18 BADTIME
19 BADMODE
The key data size field is an unsigned 16 bit integer in network
order which specifies the size of the key exchange data field in
octets. The meaning of the key data depends on the mode.
The Other Size and Other Data fields are not used. The RDLEN field
MUST equal the length of the RDATA section through the end of other
data or the RR is to be considered malformed and rejected.
3. Exchange via Resolver Query
One method for a resolver and a server to negotiate about shared
secret key for use in TSIG is through DNS requests from the resolver
which are syntactically queries for type TKEY. Such queries MUST be
accompanied by a TKEY RR in the additional information section to
indicate the mode in use and other information where required or the
resolver and server must have a prior agreement that supplies any
information that would otherwise have had to be conveyed by a TKEY RR
in the query.
For TKEY(s) appearing in a query, the TKEY RR name SHOULD be a domain
locally unique at the resolver (or globally unique), less than 128
octets long, and meaningful to the resolver to distinguish keys
Donald E. Eastlake, 3rd [Page 7]
INTERNET-DRAFT The DNS TKEY RR October 19999
and/or key agreement sessions. (For resolvers not wishing to make
this use of the name, it may be specified as root to minimize
length.) For TKEY(s) appearing in a response to a query, the TKEY RR
name SHOULD be a globally unique server assigned domain. If the TKEY
in a response is the result of a query containing a TKEY with a non-
root name, that query TKEY name SHOULD be incorporated in the
response TKEY name. Specific suggestions are given under some modes
below.
Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
ignore the recursive header bit in TKEY queries they receive.
3.1 Query for Server Assigned Keying
In server assigned keying, the DNS server host generates the keying
material and it is sent to the resolver encrypted under a resolver
host key. See section 5 for description of encryption methods.
A resolver sends a query for type TKEY accompanied by a TKEY RR
specifying the "server assignment" mode and a resolver host KEY RR to
be used in encrypting the response, both in the additional
information section. The TKEY algorithm field is set to the signature
algorithm the resolver plans to use. It is recommended that any "key
data" optionally provided in the query TKEY by the resolver be
strongly mixed with server generated randomness [RFC 1750] to derive
the keying material to be used. The KEY that appears in the query
SHOULD have a zero TTL. It need not be accompanied by a SIG(KEY) and
if the query is signed by the resolver host and that signature is
verified, then any SIG(KEY) provided MAY be ignored for key exchange
purposes. The KEY RR in such a query SHOULD have a name that
corresponds to the resolver host but it is only essential that it be
a public key for which the resolver has the corresponding private key
so it can decrypt the response data.
Accepting and responding to an unsigned query of this sort may drain
some entropy from an entropy pool being maintained by the server and
used for secret key generation and so might enable an entropy
exhaustion attack. In addition, some significant amount of
computational resources may be used in the public key encryption of
response data. To protect against these effects, a server SHOULD
require such a query to be signed and MAY rate limit responses.
The server response contains a TKEY in its answer section with the
server assigned mode and echoes back the KEY RR provided in the query
in its additional information section
If the error field of the response TKEY is non-zero, the query failed
for the reason given. FORMERR is given if the query specified no
Donald E. Eastlake, 3rd [Page 8]
INTERNET-DRAFT The DNS TKEY RR October 19999
encryption key.
If the error field is zero, the key data portion of the response TKEY
RR will be the server assigned keying data encrypted under the public
key in the resolver provided KEY RR. In this case, the name of the
answer TKEY RR will be the server assigned name of the key and SHOULD
be globally unique.
The inception and expiry times in the query TKEY are those requested
for the keying material. The inception and expiry times in the
response TKEY are the maximum period the server will consider the
keying material valid. Servers may pre-expire keys so this is not a
guarantee.
3.2 Query for Diffie-Hellman Exchanged Keying
Diffie-Hellman (DH) key exchange is means whereby two parties can
derive some shared secret information without requiring any secrecy
of the messages they exchange [Schneier]. Provisions have been made
for the storage of DH public keys in the DNS [RFC 2539].
A client sends a query for type TKEY accompanied by a TKEY RR in the
additional information section specifying the "Diffie-Hellman" mode
and accompanied by a KEY RR specifying a client host Diffie-Hellman
key. The TKEY algorithm field is set to the signature algorithm the
resolver plans to use. Any "key data" provided in the TKEY is ignored
by the server.
Accepting and responding to an unsigned query of this sort may use
significant computation at the server; however, if the server
requires that the request be signed, then if no shared secret is in
place to permit a TSIG to be used on the request, it would be
necessary to use a SIG(0) the verification of which would impose its
own computational load.
The server response contains a TKEY in its answer section with the
Diffie-Hellman mode. If the error field is non-zero, the query failed
for the reason given. FORMERR is given if the query included no DH
KEY and BADKEY is given if the query included an incompatible DH KEY.
If the error field is zero, the client host supplied Diffie-Hellman
KEY should be echoed back and a server host Diffie-Hellman KEY RR
will also be present in the response.
Both parties can then calculate the same shared secret quantity from
the pair of Diffie-Hellman keys used [Schneier], provided they use
the same modulus, and the data in the TKEY. The TKEY data is
strongly mixed with the DH result by TBD.
Donald E. Eastlake, 3rd [Page 9]
INTERNET-DRAFT The DNS TKEY RR October 19999
The inception and expiry times in the query TKEY are those requested
for the keying material. The inception and expiry times in the
response TKEY are the maximum period the server will consider the
keying material valid. Servers may pre-expire keys so this is not a
guarantee.
3.3 Query for GSS-API Established
This is described in a separate document [draft-skwan-gss-tsig-*.txt]
which should be seen for the full description. Basically, when an
acceptable symmetric key is not yet in place, the resolver can send a
query for type TKEY with a TKEY specifying the GSS-API mode in the
additional information section and a GSS-API token in the key data
portion. The server responds with a TKEY specifying the GSS-API mode
and a GSS-API token in the key data portion. The resolver and server
feed these tokens to their local GSS implementation and iterate until
an error is encountered or a key (GSS-API session) is established. A
similar exchange can be used to delete a GSS-API session.
Any issues of possible encryption of the GSS-API token data being
transmitted are handled by the GSS-API level. In addition, the GSS-
API level provides its own authentication so that this mode of TKEY
query and response MAY be, but do not need to be, signed with TSIG
or SIG(0).
The inception and expiry time in a GSS-API mode TKEY are ignored.
3.4 Query for Querier Assigned Keying
Optionally, a server can accept resolver assigned keys. The keying
material must be encrypted under a server host key for protection in
transmission as described in Section 5.
The resolver sends an update request to add a TKEY RR that specifies
the keying data with a KEY RR in the additional information section
specifying the server host public key used to encrypt the data. The
name of the key and the keying data are completely controlled by the
sending resolver so a globally unique key name SHOULD be used. The
server SHOULD require that this request be signed with a TSIG, if
there already exists an appropriate shared secret, or a SIG(0) by the
resolver host. The KEY RR used MUST be one for which the server has
the corresponding private key or it will not be able to decrypt the
keying material and will return a FORMERR.
The query TKEY inception and expiry give the time period the querier
intends to consider the keying material valid. The server can return
Donald E. Eastlake, 3rd [Page 10]
INTERNET-DRAFT The DNS TKEY RR October 19999
a lesser time interval to advise that it will not maintain state for
that long.
3.5 Query for TKEY Deletion
Keys established via TKEY can be treated as soft state. Since DNS
transactions are originated by the resolver, the resolver can simply
toss keys, although it may have to go through another key exchange if
it later needs one. Similarly, the server can discard keys although
that will result in an error on receiving a query with a TSIG using
the discarded key.
The key expiration provided in the TKEY and the ability of each party
to discard keys may be adequate but servers may implement key
deletion whereby the server discards a key on receipt from a resolver
of a delete request for a TKEY with the key's name. If the server
has no record of a key with that name, it returns BADNAME.
4. Spontaneous Server Inclusion
A DNS server may include a TKEY RR spontaneously as additional
information in responses. This SHOULD only be done if the server
knows the querier understands TKEY and has this option implemented.
This technique can be used for GSS-API exchange, and to delete a key.
A disadvantage of this technique is that there is no way for the
server to get any immediate error or success indication back and, in
the case of UDP, no way to even know if the DNS response reached the
resolver.
4.1 Spontaneous GSS-API Exchange
A server can spontaneously include in the additional information
section of a response, a GSS-API mode TKEY. The information in the
key data section of such a TKEY is a GSS-API token which SHOULD be
fed by the resolver to its local GSS-API implementation. If such a
response is signed, the signature must verify before processing the
data. To the extent that GSS-API provides its own security, such a
response may not need to be signed. To the extent that GSS-API
handles duplicated messages, such a spontaneous TKEY can be sent
repeatedly, until, perhaps, a response via a GSS-API mode TKEY query
is received.
Donald E. Eastlake, 3rd [Page 11]
INTERNET-DRAFT The DNS TKEY RR October 19999
4.2 Spontaneous Key Deletion
A server can hint to a client that it has deleted a symmetric key by
spontaneously including a TKEY RR in the additional information
section of a response with the key's name and specifying the key
deletion mode. Such a response SHOULD be signed. If authenticated,
it deletes the key with the given name. The inception and expiry
times of the delete TKEY are ignored. Failure by a client to receive
or properly process such additional information in a response would
simply mean that the client might use a key that the server had
discarded and then get an error indication.
5. Methods of Encryption
For the server assigned and resolver assigned key exchange, the
keying material is sent within the key data field of a TKEY RR
encrypted under the public key in an accompanying KEY RR [RFC 2535].
The KEY RR MUST correspond to a name for the destination host such
that the destination host has the corresponding private key to
decrypt the data. The secret keying material being send will
generally be fairly short, usually less than 256 bits, because that
is adequate for very strong protection with modern keyed hash or
symmetric algorithms.
If the KEY RR specifies the RSA algorithm, then the keying material
is encrypted as per the description of RSA encryption in PKCS#1 [RFC
2437]. (Note, the secret keying material being sent is directly RSA
encrypted in PKCS#1 format, It is not "enveloped" under some other
symmetric algorithm.) In the unlikely event that the keying material
will not fit within one RSA modulus of the chosen public key,
additional RSA encryption blocks are included. The length of each
block is clear from the public RSA key specified and the PKCS#1
padding makes it clear what part of the encrypted data is actually
keying material and what part is formatting or the required at least
eight bytes of random [RFC 1750] padding.
6. IANA Considerations
This section is to be interpreted as provided in [RFC 2434].
Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF
can only be assigned by an IETF standards action (and 1 through 5 are
assigned by this Proposed Standard). Special consideration should be
given before the allocation of meaning for Mode field values 0x0000
and 0xFFFF.
Donald E. Eastlake, 3rd [Page 12]
INTERNET-DRAFT The DNS TKEY RR October 19999
Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
are allocated by an IETF consensus.
Mode field values 0x1000 through 0xEFFF are allocated based on RFC
documentation of their use.
Mode values should not be changed when the status of their use
changes. I.E. a mode value assigned for an Experimental Standard
should not be changed later just because that standard's status is
changed to Proposed.
7. Security Considerations
To avoid different interpretations of the inception and expiration
times in TKEY RRs, resolvers and servers exchanging them must have
the same idea of what time it is. One way of doing this is with the
NTP protocol [RFC 2030] but that or any other time synchronization
MUST be done securely.
TKEY queries SHOULD be signed and those using the querier
establishment mode MUST be signed to authenticate their origin.
However, for currently defined modes, relatively little damage will
be done if an unsigned query of this sort is accepted and processed,
as described above, for each mode. In addition, requiring that a TKEY
query be signed by a TSIG (if there exists an acceptable exchanged
key between the parties) or a SIG(0) may itself impose significant
computational requirements on the server, particularly in verifying
SIG(0) public key signatures.
Responses to TKEY queries MUST always have DNS transaction signatures
to protect the integrity of any keying data, error codes, etc. This
signature MUST use a previously established secret (TSIG) or public
(SIG(0)) key and MUST NOT use any key that the response to be
verified is itself providing.
To avoid replay attacks, it is necessary that a response or querier
establishment mode query involving TKEY not be valid if replayed on
the order of 2**32 second (about 136 years) later. To acomplish
this, the keying material used in any TSIG or SIG(0) RR that
authenticates a TKEY message MUST NOT have a lifetime of more then
2**31 - 1 seconds. Thus, on attempted replay, the authenticating
TSIG or SIG(0) RR will not be verifyable due to key expiration and
the replay will fail.
Donald E. Eastlake, 3rd [Page 13]
INTERNET-DRAFT The DNS TKEY RR October 19999
Changes from Previous Draft
Prohibit more than one TKEY in a request or response. Prohibit more
than one key with the same name (even if they have non-overlapping
validity periods).
Spontaneous server inclusion of Diffi-Hellman TKEYs and server
assigned key have been eliminated.
"Update" opcode TKEY operations have all been moved to the "Query"
opcode even if they are not something you would naturally think of as
a query.
Error codes for more error conditions listed explicitly.
More explicit TKEY key naming suggestions.
Donald E. Eastlake, 3rd [Page 14]
INTERNET-DRAFT The DNS TKEY RR October 19999
References
RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities",
STD 13, November 1987.
RFC 1035 - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987.
RFC 1750 - D. Eastlake, S. Crocker & J. Schiller, "Randomness
Recommendations for Security", December 1994.
RFC 1982 - Robert Elz, Randy Bush, "Serial Number Arithmetic",
09/03/1996.
RFC 1995 - masataka Ohta, "Incremental Zone Transfer in DNS", August
1996.
RFC 2030 - D. Mills, "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", October 1996.
RFC 2119 - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
RFC 2136 - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs, October 1998.
RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", October 1998.
RFC 2535 - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
Name System (DNS)", March 1999.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons
draft-ietf-dnssec-update2-*.txt - Donald E. Eastlake 3rd, "Secure
Domain Name System Dynamic Update".
draft-ietf-dnsind-tsig-*.txt - P. Vixie, O. Gudmundsson, D.
Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)".
draft-skwan-gss-tsig-*.txt - S. Kwan, P. Garg, R. Viswanathan, "GSS
Algorithm for TSIG (GSS-TSIG)"
Donald E. Eastlake, 3rd [Page 15]
INTERNET-DRAFT The DNS TKEY RR October 19999
Author's Address
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road, RR #1
Carmel, NY 10512 USA
Telephone: +1 914-276-2668 (h)
+1 914-784-7913 (w)
FAX: +1 914-784-3833 (w)
email: dee3@us.ibm.com
Expiration and File Name
This draft expires October 1999.
Its file name is draft-ietf-dnsind-tkey-01.txt.
Donald E. Eastlake, 3rd [Page 16]

627
doc/draft/draft-ietf-dnsind-tsig-11.txt
View File

@@ -1,627 +0,0 @@
DNSIND Working Group Paul Vixie (Ed.) (ISC)
INTERNET-DRAFT Olafur Gudmundsson (NAILabs)
Donald Eastlake 3rd (IBM)
Brian Wellington (NAILabs)
<draft-ietf-dnsind-tsig-11.txt> July 1999
Amends: RFC 1035
Secret Key Transaction Signatures for DNS (TSIG)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
Abstract
This protocol allows for transaction level authentication using
shared secrets and one way hashing. It can be used to authenticate
dynamic updates as coming from an approved client, or to authenticate
responses as coming from an approved recursive name server.
No provision has been made here for distributing the shared secrets;
it is expected that a network administrator will statically configure
name servers and clients using some out of band mechanism such as
sneaker-net until a secure automated mechanism for key distribution
is available.
Expires January 2000 [Page 1]
INTERNET-DRAFT DNS TSIG July 1999
1 - Introduction
1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated
hierarchical distributed database system that provides information
fundamental to Internet operations, such as name <=> address translation
and mail handling information. DNS has recently been extended [RFC2535]
to provide for data origin authentication, and public key distribution,
all based on public key cryptography and public key based digital
signatures. To be practical, this form of security generally requires
extensive local caching of keys and tracing of authentication through
multiple keys and signatures to a pre-trusted locally configured key.
1.2. One difficulty with the [RFC2535] scheme is that common DNS
implementations include simple ``stub'' resolvers which do not have
caches. Such resolvers typically rely on a caching DNS server on
another host. It is impractical for these stub resolvers to perform
general [RFC2535] authentication and they would naturally depend on
their caching DNS server to perform such services for them. To do so
securely requires secure communication of queries and responses.
[RFC2535] provides public key transaction signatures to support this but
such signatures are very expensive computationally to generate. In
general, these require the same complex public key logic that is
impractical for stubs. This document specifies an efficient secret key
based transaction signature that avoids these difficulties.
1.3. A second area where use of straight [RFC2535] public key based
mechanisms may be impractical is authenticating dynamic update [RFC2136]
requests. [RFC2535] provides for request signatures but with [RFC2535]
they, like transaction signatures, require computationally expensive
public key cryptography and complex authentication logic. Secure Domain
Name System Dynamic Update ([RFC2137]) describes how different keys are
used in dynamically updated zones. This document's secret key based
signatures can be used to authenticate DNS update requests as well as
transaction responses, providing a lightweight alternative to the
protocol described by [RFC2137].
1.4. A further use of this mechanishm is to protect zone transfers. In
this case the data covered would be the whole zone transfer including
any glue records sent. The protocol described by [RFC2535] does not
protect glue records and unsigned records unless SIG(0) (transaction
signature) is used.
Expires January 2000 [Page 2]
INTERNET-DRAFT DNS TSIG July 1999
1.5. The signature mechanism proposed in this document uses shared
secret keys to establish trust relationship between two entities. Such
keys must be protected in a fashion similar to private keys, lest a
third party masquerade as one of the intended parties (forge
signatures). There is an urgent need to provide simple and efficient
authentication between clients and local servers and this proposal
addresses that need. This proposal is unsuitable for general server to
server authentication for servers which speak with many other servers,
since key management would become unwieldy with the number of shared
keys going up quadratically. But it is suitable for many resolvers on
hosts that only talk to few recursive servers.
1.6. A server acting as an indirect caching resolver -- a ``forwarder''
in common usage -- might use transaction signatures when communicating
with its small number of preconfigured ``upstream'' servers. Other uses
of DNS secret key signatures and possible systems for automatic secret
key distribution may be proposed in separate future documents.
1.7. New Assigned Numbers
RRTYPE = TSIG (250)
ERROR = 0..15 (a DNS RCODE)
ERROR = 16 (BADSIG)
ERROR = 17 (BADKEY)
ERROR = 18 (BADTIME)
1.7. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in [RFC 2119].
2 - TSIG RR Format
2.1 TSIG RR Type
To provide secret key signatures, we use a new RR type whose mnemonic is
TSIG and whose type code is 250. TSIG is a meta-RR and can not be
stored. TSIG RRs can be used for authentication between DNS entities
that have established a shared secret key. TSIG RRs are dynamically
computed to cover a particular DNS transaction and are not DNS RRs in
the usual sense.
Expires January 2000 [Page 3]
INTERNET-DRAFT DNS TSIG July 1999
2.2 TSIG Calculation
As the TSIG RRs are related to one DNS request/response, there is no
value in storing or retransmitting them, thus the TSIG RR should be
discarded once it has been used to authenticate DNS message. The only
Message Digest algorithm specified in this document is ``HMAC-MD5'' (see
[RFC1321], [RFC2104]). The ``HMAC-MD5'' algorithm is mandatory to
implement for interoperability. Other algorithms can be specified at a
later date. Names and definitions of new algorithms should be
registered with IANA. All multi-octet integers in TSIG Record are sent
in network byte order (see [RFC1035 2.3.2]).
2.3. Record Format
NAME A domain-like name of the key used. The name should reflect
the names of the hosts and uniquely identify the key among a
set of keys these two hosts may share at any given time. If
hosts A and B in same zone share a key then the key name could
be A-B-<id>.<zone>. If two hosts in different zones share the
key the key name could be <id>.A.<Azone>.B.<Bzone> It should
be possible for more than one key to be in simultaneous use
among a set of interacting hosts. The name only needs to be
meaningful to the communicating hosts but a meaningful
mnemonic name as above is strongly recommended.
The name may be used as a local index to the key involved and
it is recommended that it be globally unique. Where a key is
just shared between two hosts, its name actually only need
only be meaningful to them but it is recommended that the key
name be mnemonic and incorporate the resolver and server host
names in that order.
TYPE TSIG (250: Transaction SIGnature)
CLASS ANY
TTL 0
RdLen (variable)
Expires January 2000 [Page 4]
INTERNET-DRAFT DNS TSIG July 1999
RDATA
Field Name Data Type Notes
------------------------------------------------------------------
Algorithm Name domain-name Name of the algorithm
expressed as a domain name.
Time Signed u_int48_t seconds since 1-Jan-70 UTC.
Fudge u_int16_t seconds of error permitted
in Time Signed.
Signature Size u_int16_t number of octets in Signature.
Signature octet stream defined by Algorithm Name.
Original ID u_int16_t original message ID
Error u_int16_t expanded RCODE covering
signature processing.
Other Len u_int16_t length, in octets, of Other
Data.
Other Data octet stream undefined by this protocol.
2.4. Example
NAME GW-DENVAX-0042.HOME.VIX.COM.
TYPE TSIG
CLASS ANY
TTL 0
RdLen as appropriate
RDATA
Field Name Contents
-------------------------------------------
Algorithm Name HMAC-MD5.SIG-ALG.REG.INT.
Time Signed 853804800
Fudge 300
Signature Size as appropriate
Signature as appropriate
Original ID as appropriate
Error 0 (NOERROR)
Other Len 0
Other Data empty
Expires January 2000 [Page 5]
INTERNET-DRAFT DNS TSIG July 1999
3 - Protocol Operation
3.1. Effects of adding TSIG to outgoing message
Once the outgoing message has been constructed, the keyed message digest
operation can be performed. The resulting message digest will then be
stored in a TSIG which is appended to the additional data section (the
ARCOUNT is incremented to reflect this). Appending a transaction
signature to an DNS message is not allowed to result in a truncated
response; a TCP connection must be used to prevent the truncation. To
force a TCP connection, the server is permitted to return an answer with
no data only TSIG attached and TC bit set and RCODE 0 (NOERROR). The
client should at this point retry the request using TCP (per [RFC1035
4.2.2]).
3.2. TSIG processing on incoming messages
If an incoming message contains a TSIG record, it MUST be the last
record in the additional section. Multiple TSIG records are not
allowed. If a TSIG record is prsent in any other position, the packet
is dropped and a response with RCODE 1 (should be sent). Upon receipt
of a message with a correctly placed TSIG RR, the TSIG RR is copied to a
safe location, removed from the DNS Message, and decremented out of the
DNS Message Headers ARCOUNT. At this point the keyed message digest
operation is performed. If the algorithm name or key name is unknown to
the recipient, or if the message digests do not match, the whole DNS
Message must be discarded. If the message is a query, a response with
RCODE 9 (NOTAUTH) should be sent back to the originator with TSIG ERROR
17 (BADKEY) or TSIG error 16 (BADSIG). If no key is available to sign
this message it must be sent unsigned (Signature Size == 0 and empty
signature). A message to the system operations log should to be
generated, to warn the operations staff of a possible security incident
in progress. Care should be taken to ensure that logging of this type
of event does not open the system to a denial of service attack.
3.3. Time values used in TSIG calculations
The data digested includes the two timer values in the TSIG header in
order to prevent replay attacks. If this were not done an attacker
could replay old messages but update the ``Time Signed'' and ``Fudge''
fields to make the message look new. This data is named ``TSIG
Timers'', and for the purpose of digest calculation they are invoked in
their ``on the wire'' format, in the following order: first Time Signed,
then Fudge. For example:
Expires January 2000 [Page 6]
INTERNET-DRAFT DNS TSIG July 1999
Field Name Value Wire Format Meaning
---------------------------------------------------------------------------
Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997
Fudge 300 01 2C 5 minutes
3.4. TSIG Variables and Coverage
When generating or verifying a transaction signature, the following data
are digested, in network byte order or wire format, as appropriate:
3.4.1. DNS Message
A whole and complete DNS message in wire format, before the TSIG RR has
been added to the additional data section and before the DNS Message
Header's ARCOUNT field has been incremented to contain the TSIG RR. If
the message ID differs from the original message ID, the original
message ID is substituted for the message ID.
3.4.2. TSIG Variables
Source Field Name Notes
------------------------------------------------------------------------
TSIG RR NAME Key name, in canonical wire format
TSIG RR CLASS (Always ANY in the current specification)
TSIG RR TTL (Always 0 in the current specification)
TSIG RDATA Algorithm Name in canonical wire format
TSIG RDATA Time Signed in network byte order
TSIG RDATA Fudge in network byte order
TSIG RDATA Error in network byte order
TSIG RDATA Other Len in network byte order
TSIG RDATA Other Data exactly as transmitted
The RR RDLEN and RDATA Signature Length are not included in the hash
since they are not guaranteed to be knowable before the signature is
generated.
The Original ID field is not included in this section, as it has already
been substituted for the message ID in the DNS header and hashed.
``Canonical wire format'' means uncompressed labels shifted to lower
case. The use of label types other than 00 is not defined for this
specification.
Expires January 2000 [Page 7]
INTERNET-DRAFT DNS TSIG July 1999
3.4.3. Request Signature
Response signatures will include the request signature in their digest.
The request's signature is digested in wire format, including the
following fields:
Field Type Description
---------------------------------------------------------
Signature Length u_int16_t in network byte order
Signature Data octet stream exactly as transmitted
3.5. Padding
Digested components are fed into the hashing function as a continuous
octet stream with no interfield padding.
4 - Protocol Details
4.1. TSIG generation on requests
Client performs the message digest operation and appends TSIG to
additional data section and transmits request to server. The client
must store the message digest from the request while awaiting an answer.
Digest components for requests are:
DNS Message (request)
TSIG Variables (request)
Note that some older name servers will not accept requests with a
nonempty additional data section, but clients should only attempt signed
transactions against servers who are known to support TSIG and share
some secret key with the client -- so, this is not a problem in
practice.
4.2. TSIG on Answers
When a server has generated a response to a signed request, it signs the
response using the same algorithm and key. Digest components are:
Request Signature
DNS Message (response)
TSIG Variables (response)
Expires January 2000 [Page 8]
INTERNET-DRAFT DNS TSIG July 1999
4.3. TSIG on TSIG Error returns
When a server detects an error in TSIG checks relating to the key or
signature, the server should send back an unsigned error message
(Signature Size == 0 and empty signature). If an error is detected that
does not relate to the key or signature, the server should send back a
signed error message. Digest components are:
Request signature (if the request signature validated)
DNS Message (response)
TSIG Variables (response)
The reason that the request is not included in this digest in some cases
is to make it possible for the client to verify the error. If the error
is not a TSIG error the response MUST be generated as specified in
[4.2].
4.4. TSIG on TCP connection
A DNS TCP session can include multiple DNS envelopes. This is, for
example commonly used by AXFR. TSIG on such a connection can be used to
protect the connection from hijacking and provide data integrity. The
TSIG MUST be included on the first and last DNS envelopes. It can be
optionally placed on any intermediary envelopes. It is expensive to
include it on every envelopes, but it MUST be placed on at least every
100'th envelopes. The first envelope is processed as a standard answer,
and subsequent messages have the following digest components:
Prior Digest (running)
DNS Message (current message)
TSIG Timers (current message)
This allows client to rapidly detect when a transfer has been altered
and it can close the connection at that point and retry. Once client
TSIG check fails, the client MUST close the connection. If the client
does not get TSIG frequently enough (as specified above) it SHOULD
assume the connection has been hijacked and it SHOULD close the
connection. Client should treat this the same way as they would any
other interrupted transfer (although the exact behavior is not
specified).
Expires January 2000 [Page 9]
INTERNET-DRAFT DNS TSIG July 1999
4.5. Server TSIG checks
Upon receipt of a message, server will check if there is a TSIG RR. If
one exists, the server is required to return a TSIG RR in the response.
The server MUST perform the following checks in the following order,
check KEY, check TIME values, check Signature.
4.5.1. KEY check and error handling
If a non-forwarding server does not recognize the key used by the client
the server MUST generate an error response with RCODE 9 (NOTAUTH) and
TSIG ERROR 17 (BADKEY). This response should be unsigned as specified
in [4.3]. The server should log the error.
4.5.2. TIME check and error handling
If the server time is outside the time interval specified by the request
(which is: Time Signed, plus/minus Fudge), the server MUST generate an
error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18 (BADTIME). This
response MUST be signed by the same key. It MUST include the client's
current time in the time signed field, the server's current time in the
other data field, and 6 in the other data length field. This is done so
that the client can verify a message with a BADTIME error without the
verification detecting another BADTIME error. The data signed is
specified in [4.3].
4.5.3. Signature check and error handling
If TSIG fails to verify, the server MUST generate an error response as
specified in [4.3] with RCODE of 9 (NOTAUTH) and TSIG ERROR 16 (BADSIG).
This response should be unsigned as specified in [4.3]. The server
should log the error.
4.6. Client processing of answer
When a client receives a response from a server it expects a TSIG from,
it first checks if the TSIG RR is present in the response. Otherwise
the response is treated as having a format error and discarded. The
client then extracts the TSIG, adjusts the ARCOUNT, and calculates the
keyed digest in the same way as the server. If the TSIG does not
validate, that response must be discarded, unless the RCODE is 9
(NOTAUTH), in which case the client should attempt to verify the
response as it was TSIG error as specified in [4.3]. An message
containing an unsigned TSIG record or a TSIG record which fails
verification should not be considered an acceptable response; the client
Expires January 2000 [Page 10]
INTERNET-DRAFT DNS TSIG July 1999
should log an error and continue to wait for a signed response until the
request times out.
4.6.1. Key error handling
If an RCODE on a response is 9 (NOTAUTH), and the response TSIG
validates, and the TSIG key is different from the key used on the
request, then this is a key error. Client should retry the request
using the key specified by server. This should never occur, as a server
should never sign a response with a different key than signed the
request.
4.6.2. Time error handling
If the response RCODE is 9 (NOTAUTH), and TSIG ERROR is 18 (BADTIME) or
the TSIG times in request and answer do not overlap, then this is a TIME
error. This is an indication that client and server are not clock
synchronized. In this case the client should log the event. DNS
resolvers MUST NOT adjust any clocks in the client based on BADTIME
errors, but the server's time in other data field should be logged.
4.6.3. Signature error handling
If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), this
is a signature error, and client MAY retry the request with a new
request ID but it would be better to try a different shared key if one
is available. Client SHOULD keep track of how many times each key has
Signature errors. Clients should log this event.
4.7. Special considerations for forwarding servers
A server acting as a Forwarding Server of a DNS message should check for
the existence of the TSIG record. If the name on the TSIG is not of a
secret that the server shares with the originator the server will
forward the message unchanged including the TSIG. If the name of the
TSIG is of a key this server shares with the originator it processes the
TSIG. If the TSIG passes all checks, the forwarding server has the
obligation of including a TSIG of his own, to the destination or the
next forwarder. If no transaction security is available to the
destination and response has the AD flag (see [RFC2535]), the forwarder
MUST unset the AD flag before adding the TSIG to the answer.
Expires January 2000 [Page 11]
INTERNET-DRAFT DNS TSIG July 1999
5 - Shared Secrets
5.1. Secret keys are very sensitive information and all available steps
should be taken to protect them on every host on which they are stored.
Generally such hosts need to be physically protected. If they are
multi-user machines, great care should be taken that unprivileged users
have no access to keying material. Resolvers usually run unprivileged,
which means all users of a host will usually be able to see whatever
configuration data is used by the resolver.
5.2. A name server usually runs privileged, which means its
configuration data need not be visible to all users of the host. For
this reason, a host that implements transaction signatures should
probably be configured with a ``stub resolver'' and a local caching and
forwarding name server. This presents a special problem for [RFC2136]
which otherwise depends on clients to communicate only with a zone's
authoritative name servers.
5.3. Use of strong random shared secrets is essential to the security of
TSIG. See [RFC1750] for a discussion of this issue. The secret should
be at least as long as the keyed message digest , i.e., 16 bytes for
HMAC-MD5 or 20 bytes for HMAC-SHA1.
6 - Security Considerations
6.1. The approach specified here is computationally much less expensive
than the signatures specified in [RFC2535]. As long as the shared
secret key is not compromised, strong authentication is provided for the
last hop from a local name server to the user resolver.
6.2. Secret keys should be changed periodically. If the client host has
been compromised, the server should suspend the use of all secrets known
to that client. If possible, secrets should be stored in encrypted
form. Secrets should never be transmitted in the clear over any
network. This document does not address the issue on how to distribute
secrets. Secrets should never be shared by more than two entities.
6.3. This mechanism does not authenticate source data, only its
transmission between two parties who share some secret. The original
source data can come from a compromised zone master or can be corrupted
during transit from an authentic zone master to some ``caching
forwarder.'' However, if the server is faithfully performing the full
[RFC2535] security checks, then only security checked data will be
available to the client.
Expires January 2000 [Page 12]
INTERNET-DRAFT DNS TSIG July 1999
7 - IANA Considerations
A new algorithm name should be a valid domain name of the type
algorithm-name.SIG-ALG.REG.INT. This requires an IETF consensus.
Adding new error codes requires an IETF consensus.
IANA must maintain control over the SIG-ALG.REG.INT domain.
7 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1034, ISI, November 1987.
[RFC1321] R. Rivest, ``The MD5 Message-Digest Algorithm,'' RFC 1321,
MIT LCS & RSA Data Security, Inc., April 1992.
[RFC1750] D. Eastlake, S. Crocker, J. Schiller, ``Randomness
Recommendations for Security,'' RFC 1750, DEC, CyberCash &
MIT, December 1995.
[RFC2104] H. Krawczyk, M. Bellare, R. Canetti, ``HMAC-MD5: Keyed-MD5
for Message Authentication,'' RFC 2104 , IBM, UCSD & IBM,
February 1997.
[RFC2119] S. Bradner, ``Key words for use in RFCs to Indicate
Requirement Levels,'' RFC 2119, Harvard, March 1997
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
& Cisco & DEC, April 1997.
[RFC2137] D. Eastlake 3rd ``Secure Domain Name System Dynamic Update,''
CyberCash, April 1997.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC
2535, IBM, March 1999.
Expires January 2000 [Page 13]
INTERNET-DRAFT DNS TSIG July 1999
9 - Authors' Addresses
Paul Vixie Olafur Gudmundsson
Internet Software Consortium NAILabs
950 Charter Street 3060 Washington Road, Route 97
Redwood City, CA 94063 Glenwood, MD 21738
+1 650 779 7001 +1 443 259 2389
<vixie@isc.org> <ogud@tislabs.com>
Donald E. Eastlake 3rd Brian Wellington
IBM NAILabs
65 Shindegan Hill Road, RR #1 3060 Washington Road, Route 97
Carmel, NY 10512 USA Glenwood, MD 21738
+1 914 784 7913 +1 443 259 2369
<dee3@us.ibm.com> <bwelling@tislabs.com>
Expires January 2000 [Page 14]

412
doc/draft/draft-ietf-idn-requirment-00.txt Normal file
View File

@@ -0,0 +1,412 @@
IETF IDN Working Group James Seng
Internet Draft draft-ietf-idn-requirment-00.txt
22nd Feb 2000 Expires 22nd Aug 2000
Requirements of Internationalized Domain Names
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This document describes the requirement for encoding international
characters into DNS names and records. This document is guidance for
developing protocols for internationalized domain names.
1. Introduction
At present, the encoding of Internet domain names is restricted to a
subset of 7-bit ASCII (ISO/IEC 646). HTML, XML, IMAP, FTP, and many
other text based items on the Internet have already been
internationalized. It is important for domain names to be similarly
internationalized.
This document is being discussed on the "idn" mailing list. To join the
list, send a message to <majordomo@ops.ietf.org> with the words
"subscribe idn" in the body of the message. Archives of the mailing
list can also be found at ftp://ops.ietf.org/pub/lists/idn*.
1.1 Definitions and Conventions
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].
"IDN" is used in this document as an abbreviation for "internationalized
domain name". This is defined as a domain name that contains one or more
characters that are outside the set of characters specified as legal
Expires 22nd of August 2000 [Page 1]
Internet Draft Requirements of IDN 22nd Feb 2000
characters for domain names in [RFC1034] Section 3.5.
A master server for a zone holds the main copy of that zone. This copy
is sometimes stored in a zone file. A slave server for a zone holds a
complete copy of the records for that zone. A caching server holds
temporary copies of DNS records; it uses records to answer queries
about domain names. Further explanation of these terms can be found in
[RFC1034] and [RFC1996].
Characters mentioned in this document are identified by their position
in the Unicode character set. The notation U+12AB, for example,
indicates the character at position 12AB (hexadecimal) in the Unicode
character set. Note that the use of this notation is not an indication
of a requirement to use Unicode.
Examples quoted in this document should be considered as a method to
further explain the meanings and principles adopted by the document. It
is not a requirement for the protocol to satisfy the examples.
A character is a member of a set of elements used for organization,
control, or representation of data.
A coded character is a character with its coded representation.
A coded character set ("CCS") is a set of unambiguous rules that
establishes a character set and the relationship between the characters
of the set and their coded representation.
A graphic character or glyph is a character, other than a control
function, that has a visual representation normally handwritten,
printed, or displayed.
A character encoding scheme or "CES" is a mapping from one or more
coded character sets to a set of octets. Some CESs are associated with
a single CCS; for example, UTF-8 applies only to ISO 10646. Other CESs,
such as ISO 2022, are associated with many CCSs.
A charset is a method of mapping a sequence of octets to a sequence of
abstract characters. A charset is, in effect, a combination of one or
more CCS with a CES. Charset names are registered by the IANA according
to procedures documented in RFC 2278.
A language is a way that humans interact. In written form, a language
is expressed in characters. The same set of characters can often be
used in many languages, and many languages can be expressed using
different scripts. A particular charset may have different glyphs
(shapes) depending on the language being used.
2. General Requirements
2.1 Compatibility and Interoperability
The DNS is essential to the entire Internet. Therefore, the protocol
must not damage present DNS interoperability. It must make the minimum
Expires 22nd of August 2000 [Page 2]
Internet Draft Requirements of IDN 22nd Feb 2000
number of changes to existing protocols on all layers of the stack. It
must continue to allow any system anywhere to resolve any domain name.
The protocol must preserve the basic concept and facilities of domain
names as described in [RFC1034]. It must maintain a single, global,
universal, and consistent hierarchical namespace.
The same name resolution request must generate the same response,
regardless of the location or localization settings in the resolver, in
the master server, and in any slave or caching servers involved in the
resolution process.
If the protocol allows more than one charset, it should also allow
creation of caching servers that do not understand the charset in which
a request or response is encoded. Such caching servers should work as
well for IDNs as they do for current domain names. The caching server
performs correctly if it gives the essentially the same answer (without
the authoritative bit) as the master server would have if presented
with the same request.
A caching server must not return data in response to a query that would
not have been returned if the same query had been presented to an
authoritative server. This applies fully for the cases when:
- The caching server does not know about IDN
- The caching server implements the whole specification
- The caching server implements a legal subset of the specification
The protocol should be able to be upgraded at any time with new features
and retain backwards compatibility with the current specification.
The protocol may modify the DNS protocol [RFC1035] and other related
work undertaken by the DNSEXT WG. However, these changes should be as
small as possible and any changes must be approved by the DNSEXT WG.
The protocol should be as simple as possible from the user's
perspective. Ideally, users should not realize that IDN was added on
to the existing DNS.
A fall-back strategy or mechanism based upon ASCII may be needed during
a transition period during deployment and adoption of IDN. Therefore,
if an encoding is not mapped into ASCII, then there should be an ASCII-
only representation compatible with the current DNS and there should be
a way for a program to find the ASCII-only representation for IDN.
The best solution is one that maintains maximum feasible compatibility
with current DNS standards as long as it meets the other requirements
in this document.
2.2 Internationalization
Internationalized characters must be allowed to be represented and used
in DNS names and records. The protocol must specify what charset is used
when resolving domain names and how characters are encoded in DNS
Expires 22nd of August 2000 [Page 3]
Internet Draft Requirements of IDN 22nd Feb 2000
records.
This document does not recommend any charset for I18N. If more than one
charset is used in the protocol, then the protocol must specify all the
charsets being used and for what purpose. A CCS(s) chosen must at
least cover the range of characters as currently defined (and as being
added) by ISO 10646/Unicode.
CES(s) chosen should not encode ASCII characters differently depending
on the other characters in the string. In other words, ASCII
character should remain as specified in [US-ASCII].
The protocol must not invent a new CCS for the purpose of IDN only
and should use existing CES. The charset(s) chosen should also be
non-ambiguous.
The protocol should not make any assumptions where in a domain name
that internationalization might appear. In other words, it should not
differentiate between any part of a domain name because this may impose
a restriction on future internationalization efforts.
The protocol should also not make any localized restrictions in the
protocol. For example, an IDN implementation which only allows domain
names to use a single local script would immediately restrict
multinational organization.
Because of the wide range of devices that use the DNS and the wide
range of characteristics of international scripts, the protocol should
allow more than one method of domain name input and display. However,
there has to be a single way of encoding an internationalized domain
name within the core of the DNS.
2.3 Localization
The protocol must be able to handle localized requirement of different
languages. For example, IDN must be able to handle bidirectional
writing for scripts such as Arabic.
Historically, "." has been the separator of labels in the domain names.
The protocol should not use different separators for different
languages.
Most localization can be handled by the user interface. It should not
matter how the domain names are input or presented, such as in a
reverse order or bidirectional, or with the introduction of a new
separator. However, the final wire format must be in canonical order.
2.4 Canonicalization
Matching rules are a complicated process for IDN. Canonicalization of
characters must follow precise and predictable rules to ensure
consistency. [CHARREQ] is a recommended as a guide on canonicalization.
The DNS has to match a domain name in a request with a domain name held
Expires 22nd of August 2000 [Page 4]
Internet Draft Requirements of IDN 22nd Feb 2000
in one or more zones. It also needs to sort names into order. It is
expected that some sort of canonicalization algorithm will be used as
the first step of this process. This section discusses some of the
properties which will be required of that algorithm.
The canonicalization algorithm might specify operations for case,
ligature, and punctuation folding.
In order to retain backwards compatibility with the current DNS, the
protocol must retain the case-insensitive comparison for US-ASCII as
specified in [RFC1035]. For example, Latin capital letter A (U+0041)
must match Latin small letter A (U+0061). [UTR-21] describes some of
the issues with case mapping.
Case folding must not be locale dependent. For example, Latin capital
letter I (U+0049) case folded to lower case in the Turkish context will
become Latin small letter dotless I (U+0131). But in the English
context, it will become Latin small letter I (U+0069).
If other canonicalization is done, then it must be done before the
domain name is resolved. Further, the canonicalization must be easily
upgrade able as new languages and writing systems are added.
Any conversion (case, ligature folding, punctuation folding, ...) from
what the user enters into a client to what the client asks for
resolution must be done identically on all requests from any client.
If the protocol specifies a canonicalization algorithm, a caching
server should perform correctly regardless of how much (or how little)
of that algorithm it has implemented. [1 request to remove]
If the protocol requires a canonicalization algorithm, all requests
sent to a caching server must already be in the canonical form.
The protocol should avoid inventing a new normalization form provided
a technically sufficient one is available (such as in an ISO standard).
2.5 Operational Issues
Zone files should remain easily editable.
An IDN-capable resolver or server should not generate more traffic than
a non-IDN-capable resolver or server would when resolving an ASCII-only
domain name. The amount of traffic generated when resolving an IDN
should be similar to that generated when resolving an ASCII-only name.
The protocol should add no new centralized administration for the DNS.
A domain administrator should be able to create internationalized names
as easily as adding current domain names.
Within a single zone, the zone manager must be able to define
equivalence rules that suit the purpose of the zone, such as, but not
limited to, and not necessarily, non-ASCII case folding, Unicode
normalizations, Cyrillic/Latin folding, or traditional/simplified
Expires 22nd of August 2000 [Page 5]
Internet Draft Requirements of IDN 22nd Feb 2000
Chinese equivalence. Such defined equivalences must not remove
equivalences that are assumed by (old or local-rule-ignorant) caches.
The character set of a signed zone file should be capable of being the
same as the character set of the unsigned zone file. The protocol must
allow offline DNSSEC signing. It should be possible to look at the
signed file and see that it is the same as the unsigned one.
2.6 Others
The protocol may provide the same DNS resources using internationalized
text as it currently provides using ASCII text.
To get full semantics for IDN, an upgrade of the DNS and related
software may be needed.
3. Technical Analysis
There are many standard protocols and RFCs which are depend on
domain names and have make various assumptions about the characters
in them always conforming to [RFC-1034]. We expect that the protocols
listed below to be affected:
<...list the sets of RFCs which we would like to have an summary...>
RFC821, RFC822, ...
All idn protocol documents must fully detail the expected effects of
leaking of the specified encoding to protocols other than the DNS
resolution protocol. They must also contain a summary of the technical
opinions of the IDN Working Group.
4. Security Considerations
Any solution that meets the requirements in this document must not
be less secure than the current DNS. Specifically, the mapping of
internationalized host names to and from IP addresses must have the
same characteristics as the mapping of today's host names.
Specifying requirements for internationalized domain names does not
itself raise any new security issues. However, any change to the DNS
may affect the security of any protocol that relies on the DNS or on
DNS names. A thorough evaluation of those protocols for security
concerns will be needed when they are developed. In particular, IDNs
must be compatible with DNSSEC.
5. References
[CHARREQ] "Requirements for string identity matching and String
Indexing", http://www.w3.org/TR/WD-charreq, July 1998,
World Wide Web Consortium.
[DNSEXT] "IETF DNS Extensions Working Group",
namedroppers@internic.net, Olafur Gudmundson, Randy Bush.
Expires 22nd of August 2000 [Page 6]
Internet Draft Requirements of IDN 22nd Feb 2000
[RFC1034] "Domain Names - Concepts and Facilities", rfc1034.txt,
November 1987, P. Mockapetris.
[RFC1035] "Domain Names - Implementation and Specification",
rfc1035.txt, November 1987, P. Mockapetris.
[RFC1123] "Requirements for Internet Hosts -- Application and
Support", rfc1123.txt, October 1989, R. Braden.
[RFC1996] "A Mechanism for Prompt Notification of Zone Changes
(DNS NOTIFY)", rfc1996.txt, August 1996, P. Vixie.
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels", rfc2119.txt, March 1997, S. Bradner.
[UNICODE] The Unicode Consortium, "The Unicode Standard -- Version
3.0", ISBN 0-201-61633-5. Described at
http://www.unicode.org/unicode/standard/versions/
Unicode3.0.html
[US-ASCII] Coded Character Set -- 7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[UTR15] "Unicode Normalization Forms", Unicode Technical Report
#15, http://www.unicode.org/unicode/reports/tr15/,
Nov 1999, M. Davis & M. Duerst, Unicode Consortium.
[UTR21] "Case Mappings", Unicode Technical Report #21,
http://www.unicode.org/unicode/reports/tr21/, Dec 1999,
M. Davis, Unicode Consortium.
Appendix A. Acknowledgements
The editor gratefully acknowledges the contributions of:
Harald Tveit Alvestrand <Harald@Alvestrand.no>
Martin Duerst <duerst@w3.org>
Patrik Faltstrom <paf@swip.net>
Andrew Draper <ADRAPER@altera.com>
Bill Manning <bmanning@ISI.EDU>
Paul Hoffman <phoffman@imc.org>
James Seng <jseng@pobox.org.sg>
Randy Bush <randy@psg.com>
Alan Barret <apb@cequrux.com>
Olafur Gudmundsson <ogud@tislabs.com>
Karlsson Kent <keka@im.se>
Dan Oscarsson <Dan.Oscarsson@trab.se>
J. William Semich <bill@mail.nic.nu>
RJ Atkinson <rja@inet.org>
Simon Josefsson <jas+idn@pdc.kth.se>
Ned Freed <ned.freed@innosoft.com>
Expires 22nd of August 2000 [Page 7]