upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-04-24 07:41:10 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

This commit was manufactured by cvs2git to create branch 'v9_3'.

Browse source
This commit is contained in:
cvs2git 2004-02-27 20:44:10 +00:00
commit 135366a29d
28 changed files with 15650 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
bin/tests/system/checknames/clean.sh Normal file
View file

@ -0,0 +1,5 @@
rm -f dig.out.ns?.test*
rm -f nsupdate.out.test*
rm -f ns1/*.example.db
rm -f ns1/*.update.db
rm -f ns1/*.update.db.jnl

10
bin/tests/system/checknames/ns1/fail.example.db.in Normal file
View file

@ -0,0 +1,10 @@
; Copyright
; $Id: fail.example.db.in,v 1.2 2004/02/27 20:44:07 marka Exp $
$TTL 300
@ SOA ns1.fail.example. hostmaster.fail.example. (
1 3600 1200 604800 3600 )
NS ns1.fail.example.
ns1.fail.example. A 10.53.0.1
xx_xx.fail.example. A 127.0.0.1

9
bin/tests/system/checknames/ns1/fail.update.db.in Normal file
View file

@ -0,0 +1,9 @@
; Copyright
; $Id: fail.update.db.in,v 1.2 2004/02/27 20:44:07 marka Exp $
$TTL 300
@ SOA ns1.fail.update. hostmaster.fail.update. (
1 3600 1200 604800 3600 )
NS ns1.fail.update.
ns1.fail.update. A 10.53.0.1

11
bin/tests/system/checknames/ns1/ignore.example.db.in Normal file
View file

@ -0,0 +1,11 @@
; Copyright
; $Id: ignore.example.db.in,v 1.2 2004/02/27 20:44:07 marka Exp $
$TTL 300
@ SOA ns1.ignore.example. hostmaster.ignore.example. (
1 3600 1200 604800 3600 )
NS ns1.ignore.example.
ns1.ignore.example. A 10.53.0.1
yy_yy.ignore.example. A 10.53.0.1
mx.ignore.example. MX 10 zz_zz.ignore.example.

9
bin/tests/system/checknames/ns1/ignore.update.db.in Normal file
View file

@ -0,0 +1,9 @@
; Copyright
; $Id: ignore.update.db.in,v 1.2 2004/02/27 20:44:07 marka Exp $
$TTL 300
@ SOA ns1.ignore.update. hostmaster.ignore.update. (
1 3600 1200 604800 3600 )
NS ns1.ignore.update.
ns1.ignore.update. A 10.53.0.1

61
bin/tests/system/checknames/ns1/named.conf Normal file
View file

@ -0,0 +1,61 @@
/*
* Copyright
*/
/* $Id: named.conf,v 1.2 2004/02/27 20:44:08 marka Exp $ */
options {
query-source address 10.53.0.1;
notify-source 10.53.0.1;
transfer-source 10.53.0.1;
port 5300;
pid-file "named.pid";
listen-on { 10.53.0.1; };
listen-on-v6 { none; };
recursion no;
notify yes;
};
zone "." {
type master;
file "root.db";
};
zone "ignore.example" {
type master;
file "ignore.example.db";
check-names ignore;
};
zone "warn.example" {
type master;
file "warn.example.db";
check-names warn;
};
zone "fail.example" {
type master;
file "fail.example.db";
check-names fail;
};
zone "ignore.update" {
type master;
file "ignore.update.db";
allow-update { any; };
check-names ignore;
};
zone "warn.update" {
type master;
file "warn.update.db";
allow-update { any; };
check-names warn;
};
zone "fail.update" {
type master;
file "fail.update.db";
allow-update { any; };
check-names fail;
};

23
bin/tests/system/checknames/ns1/root.db Normal file
View file

@ -0,0 +1,23 @@
; Copyright
; $Id: root.db,v 1.2 2004/02/27 20:44:08 marka Exp $
$TTL 300
@ SOA ns1. hostmaster.warn.example. (
1 3600 1200 604800 3600 )
NS ns1.
ns1. A 10.53.0.1
;
ignore.example. NS ns1.ignore.example.
ns1.ignore.example. A 10.53.0.1
warn.example. NS ns1.warn.example.
ns1.warn.example. A 10.53.0.1
fail.example. NS ns1.fail.example.
ns1.fail.example. A 10.53.0.1
;
ignore.update. NS ns1.ignore.update.
ns1.ignore.update. A 10.53.0.1
warn.update. NS ns1.warn.update.
ns1.warn.update. A 10.53.0.1
fail.update. NS ns1.fail.update.
ns1.fail.update. A 10.53.0.1

10
bin/tests/system/checknames/ns1/warn.example.db.in Normal file
View file

@ -0,0 +1,10 @@
; Copyright
; $Id: warn.example.db.in,v 1.2 2004/02/27 20:44:08 marka Exp $
$TTL 300
@ SOA ns1.warn.example. hostmaster.warn.example. (
1 3600 1200 604800 3600 )
NS ns1.warn.example.
ns1.warn.example. A 10.53.0.1
xx_xx.warn.example. A 10.53.0.1

9
bin/tests/system/checknames/ns1/warn.update.db.in Normal file
View file

@ -0,0 +1,9 @@
; Copyright
; $Id: warn.update.db.in,v 1.2 2004/02/27 20:44:08 marka Exp $
$TTL 300
@ SOA ns1.warn.update. hostmaster.warn.update. (
1 3600 1200 604800 3600 )
NS ns1.warn.update.
ns1.warn.update. A 10.53.0.1

23
bin/tests/system/checknames/ns2/named.conf Normal file
View file

@ -0,0 +1,23 @@
/*
* Copyright
*/
/* $Id: named.conf,v 1.2 2004/02/27 20:44:08 marka Exp $ */
options {
query-source address 10.53.0.2;
notify-source 10.53.0.2;
transfer-source 10.53.0.2;
port 5300;
pid-file "named.pid";
listen-on { 10.53.0.2; };
listen-on-v6 { none; };
recursion yes;
check-names response warn;
notify yes;
};
zone "." {
type hint;
file "root.hints";
};

7
bin/tests/system/checknames/ns2/root.hints Normal file
View file

@ -0,0 +1,7 @@
; Copyright
; $Id: root.hints,v 1.2 2004/02/27 20:44:09 marka Exp $
$TTL 300
. NS ns1.
ns1. A 10.53.0.1

23
bin/tests/system/checknames/ns3/named.conf Normal file
View file

@ -0,0 +1,23 @@
/*
* Copyright
*/
/* $Id: named.conf,v 1.2 2004/02/27 20:44:09 marka Exp $ */
options {
query-source address 10.53.0.3;
notify-source 10.53.0.3;
transfer-source 10.53.0.3;
port 5300;
pid-file "named.pid";
listen-on { 10.53.0.3; };
listen-on-v6 { none; };
recursion yes;
check-names response fail;
notify yes;
};
zone "." {
type hint;
file "root.hints";
};

7
bin/tests/system/checknames/ns3/root.hints Normal file
View file

@ -0,0 +1,7 @@
; Copyright
; $Id: root.hints,v 1.2 2004/02/27 20:44:09 marka Exp $
$TTL 300
. NS ns1.
ns1. A 10.53.0.1

7
bin/tests/system/checknames/setup.sh Normal file
View file

@ -0,0 +1,7 @@
cp ns1/ignore.example.db.in ns1/ignore.example.db
cp ns1/warn.example.db.in ns1/warn.example.db
cp ns1/fail.example.db.in ns1/fail.example.db
cp ns1/ignore.update.db.in ns1/ignore.update.db
cp ns1/warn.update.db.in ns1/warn.update.db
cp ns1/fail.update.db.in ns1/fail.update.db

122
bin/tests/system/checknames/tests.sh Normal file
View file

@ -0,0 +1,122 @@
#!/bin/sh
#
# Copyright
# $Id: tests.sh,v 1.2 2004/02/27 20:44:06 marka Exp $
SYSTEMTESTTOP=..
. $SYSTEMTESTTOP/conf.sh
status=0
n=1
DIGOPTS="+tcp +noadd +nosea +nostat +nocmd -p 5300"
# Entry should exist.
echo "I: check for failure from on zone load for 'check-names fail;' ($n)"
ret=0
$DIG $DIGOPTS fail.example. @10.53.0.1 a > dig.out.ns1.test$n || ret=1
grep SERVFAIL dig.out.ns1.test$n > /dev/null || ret=1
grep 'xx_xx.fail.example: bad owner name (check-names)' ns1/named.run > /dev/null || ret=1
if [ $ret != 0 ]; then echo "I:failed"; fi
status=`expr $status + $ret`
n=`expr $n + 1`
# Entry should exist.
echo "I: check for warnings from on zone load for 'check-names warn;' ($n)"
ret=0
grep 'xx_xx.warn.example: bad owner name (check-names)' ns1/named.run > /dev/null || ret=1
if [ $ret != 0 ]; then echo "I:failed"; fi
status=`expr $status + $ret`
n=`expr $n + 1`
# Entry should not exist.
echo "I: check for warnings from on zone load for 'check-names ignore;' ($n)"
ret=1
grep 'yy_yy.ignore.example: bad owner name (check-names)' ns1/named.run || ret=0
if [ $ret != 0 ]; then echo "I:failed"; fi
status=`expr $status + $ret`
n=`expr $n + 1`
# Entry should exist
echo "I: check that 'check-names response warn;' works ($n)"
ret=0
$DIG $DIGOPTS yy_yy.ignore.example. @10.53.0.1 a > dig.out.ns1.test$n || ret=1
$DIG $DIGOPTS yy_yy.ignore.example. @10.53.0.2 a > dig.out.ns2.test$n || ret=1
$PERL ../digcomp.pl dig.out.ns1.test$n dig.out.ns2.test$n || ret=1
grep "check-names warning yy_yy.ignore.example/A/IN" ns2/named.run > /dev/null || ret=1
if [ $ret != 0 ]; then echo "I:failed"; fi
status=`expr $status + $ret`
n=`expr $n + 1`
# Entry should exist
echo "I: check that 'check-names response (owner) fails;' works ($n)"
ret=0
$DIG $DIGOPTS yy_yy.ignore.example. @10.53.0.1 a > dig.out.ns1.test$n || ret=1
$DIG $DIGOPTS yy_yy.ignore.example. @10.53.0.3 a > dig.out.ns3.test$n || ret=1
grep NOERROR dig.out.ns1.test$n > /dev/null || ret=1
grep REFUSED dig.out.ns3.test$n > /dev/null || ret=1
grep "check-names failure yy_yy.ignore.example/A/IN" ns3/named.run > /dev/null || ret=1
if [ $ret != 0 ]; then echo "I:failed"; fi
status=`expr $status + $ret`
n=`expr $n + 1`
# Entry should exist
echo "I: check that 'check-names response (rdata) fails;' works ($n)"
ret=0
$DIG $DIGOPTS mx.ignore.example. @10.53.0.1 MX > dig.out.ns1.test$n || ret=1
$DIG $DIGOPTS mx.ignore.example. @10.53.0.3 MX > dig.out.ns3.test$n || ret=1
grep NOERROR dig.out.ns1.test$n > /dev/null || ret=1
grep SERVFAIL dig.out.ns3.test$n > /dev/null || ret=1
grep "check-names failure mx.ignore.example/MX/IN" ns3/named.run > /dev/null || ret=1
if [ $ret != 0 ]; then echo "I:failed"; fi
status=`expr $status + $ret`
n=`expr $n + 1`
echo "I: check that updates to 'check-names fail;' are rejected ($n)"
ret=0
not=1
$NSUPDATE -d <<END> nsupdate.out.test$n 2>&1 || not=0
server 10.53.0.1 5300
update add xxx_xxx.fail.update. 600 A 10.10.10.1
send
END
if [ $not != 0 ]; then ret=1; fi
$DIG $DIGOPTS xxx_xxx.fail.update @10.53.0.1 A > dig.out.ns1.test$n || ret=1
grep "xxx_xxx.fail.update/A: bad owner name (check-names)" ns1/named.run > /dev/null || ret=1
grep NXDOMAIN dig.out.ns1.test$n > /dev/null || ret=1
if [ $ret != 0 ]; then echo "I:failed"; fi
status=`expr $status + $ret`
n=`expr $n + 1`
echo "I: check that updates to 'check-names warn;' succeed and are logged ($n)"
ret=0
$NSUPDATE -d <<END> nsupdate.out.test$n 2>&1|| ret=1
server 10.53.0.1 5300
update add xxx_xxx.warn.update. 600 A 10.10.10.1
send
END
$DIG $DIGOPTS xxx_xxx.warn.update @10.53.0.1 A > dig.out.ns1.test$n || ret=1
grep "xxx_xxx.warn.update/A: bad owner name (check-names)" ns1/named.run > /dev/null || ret=1
grep NOERROR dig.out.ns1.test$n > /dev/null || ret=1
if [ $ret != 0 ]; then echo "I:failed"; fi
status=`expr $status + $ret`
n=`expr $n + 1`
echo "I: check that updates to 'check-names ignore;' succeed and are not logged ($n)"
ret=0
not=1
$NSUPDATE -d <<END> nsupdate.out.test$n 2>&1 || ret=1
server 10.53.0.1 5300
update add xxx_xxx.ignore.update. 600 A 10.10.10.1
send
END
grep "xxx_xxx.ignore.update/A.*(check-names)" ns1/named.run > /dev/null || not=0
if [ $not != 0 ]; then ret=1; fi
$DIG $DIGOPTS xxx_xxx.ignore.update @10.53.0.1 A > dig.out.ns1.test$n || ret=1
grep NOERROR dig.out.ns1.test$n > /dev/null || ret=1
if [ $ret != 0 ]; then echo "I:failed"; fi
status=`expr $status + $ret`
n=`expr $n + 1`
exit $status

895
doc/draft/draft-ietf-dnsext-dns-threats-06.txt Normal file
View file

@ -0,0 +1,895 @@
Network Working Group D. Atkins
draft-ietf-dnsext-dns-threats-06.txt IHTFP Consulting
R. Austein
ISC
February 2004
Threat Analysis of the Domain Name System
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>.
Abstract
Although the DNS Security Extensions (DNSSEC) have been under
development for most of the last decade, the IETF has never written
down the specific set of threats against which DNSSEC is designed to
protect. Among other drawbacks, this cart-before-the-horse situation
has made it difficult to determine whether DNSSEC meets its design
goals, since its design goals are not well specified. This note
attempts to document some of the known threats to the DNS, and, in
doing so, attempts to measure to what extent (if any) DNSSEC is a
useful tool in defending against these threats.
Atkins & Austein Expires 21 August 2004 [Page 1]
draft-ietf-dnsext-dns-threats-06.txt February 2004
1. Introduction
The earliest organized work on DNSSEC within the IETF was an open
design team meeting organized by members of the DNS working group in
November 1993 at the 28th IETF meeting in Houston. The broad
outlines of DNSSEC as we know it today are already clear in Jim
Galvin's summary of the results of that meeting [Galvin93]:
- While some participants in the meeting were interested in
protecting against disclosure of DNS data to unauthorized parties,
the design team made an explicit decision that "DNS data is
`public'", and ruled all threats of data disclosure explicitly out
of scope for DNSSEC.
- While some participants in the meeting were interested in
authentication of DNS clients and servers as a basis for access
control, this work was also ruled out of scope for DNSSEC per se.
- Backwards compatibility and co-existence with "insecure DNS" was
listed as an explicit requirement.
- The resulting list of desired security services was
1) data integrity, and
2) data origin authentication.
- The design team noted that a digital signature mechanism would
support the desired services.
While a number of detail decisions were yet to be made (and in some
cases remade after implementation experience) over the subsequent
decade, the basic model and design goals have remained fixed.
Nowhere, however, does any of the DNSSEC work attempt to specify in
any detail the sorts of attacks against which DNSSEC is intended to
protect, or the reasons behind the list of desired security services
that came out of the Houston meeting. For that, we have to go back
to a paper originally written by Steve Bellovin in 1990 but not
published until 1995, for reasons that Bellovin explained in the
paper's epilogue [Bellovin95].
While it may seem a bit strange to publish the threat analysis a
decade after starting work on the protocol designed to defend against
it, that is nevertheless what this note attempts to do. Better late
than never.
This note assumes that the reader is familiar with both the DNS and
with DNSSEC, and does not attempt to provide a tutorial on either.
The DNS documents most relevant to the subject of this note are:
Atkins & Austein Expires 21 August 2004 [Page 2]
draft-ietf-dnsext-dns-threats-06.txt February 2004
[RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308],
[RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535].
For purposes of discussion, this note uses the term "DNSSEC" to refer
to the core hierarchical public key and signature mechanism specified
in the DNSSEC documents, and refers to TKEY and TSIG as separate
mechanisms, even though channel security mechanisms such as TKEY and
TSIG are also part of the larger problem of "securing DNS" and thus
are often considered part of the overall set of "DNS security
extensions". This is an arbitrary distinction that in part reflects
the way in which the protocol has evolved (introduction of a
putatively simpler channel security model for certain operations such
as zone transfers and dynamic update requests), and perhaps should be
changed in a future revision of this note.
2. Known Threats
There are several distinct classes of threats to the DNS, most of
which are DNS-related instances of more general problems, but a few
of which are specific to peculiarities of the DNS protocol.
2.1. Packet Interception
Some of the simplest threats against DNS are various forms of packet
interception: monkey-in-the-middle attacks, eavesdropping on requests
combined with spoofed responses that beat the real response back to
the resolver, and so forth. In any of these scenarios, the attacker
can simply tell either party (usually the resolver) whatever it wants
that party to believe. While packet interception attacks are far
from unique to DNS, DNS's usual behavior of sending an entire query
or response in a single unsigned, unencrypted UDP packet makes these
attacks particularly easy for any bad guy with the ability to
intercept packets on a shared or transit network.
To further complicate things, the DNS query the attacker intercepts
may just be a means to an end for the attacker: the attacker might
even choose to return the correct result in the answer section of a
reply message while using other parts of the message to set the stage
for something more complicated, for example, a name-based attack (see
below).
While it certainly would be possible to sign DNS messages using a
channel security mechanism such as TSIG or IPsec, or even to encrypt
them using IPsec, this would not be a very good solution. First,
this approach would impose a fairly high processing cost per DNS
message, as well as a very high cost associated with establishing and
maintaining bilateral trust relationships between all the parties
that might be involved in resolving any particular query. For
Atkins & Austein Expires 21 August 2004 [Page 3]
draft-ietf-dnsext-dns-threats-06.txt February 2004
heavily used name servers (such as the servers for the root zone),
this cost would almost certainly be prohibitively high. Even more
important, however, is that the underlying trust model in such a
design would be wrong, since at best it would only provide a hop-by-
hop integrity check on DNS messages and would not provide any sort of
end-to-end integrity check between the producer of DNS data (the zone
administrator) and the consumer of DNS data (the application that
triggered the query).
By contrast, DNSSEC (when used properly) does provide an end-to-end
data integrity check, and is thus a much better solution for this
class of problems during basic DNS lookup operations.
TSIG does have its place in corners of the DNS protocol where there's
a specific trust relationship between a particular client and a
particular server, such as zone transfer, dynamic update, or a
resolver (stub or otherwise) that is not going to check all the
DNSSEC signatures itself.
Note that DNSSEC does not provide any protection against modification
of the DNS message header, so any properly paranoid resolver must:
- Perform all of the DNSSEC signature checking on its own,
- Use TSIG (or some equivalent mechanism) to ensure the integrity of
its communication with whatever name servers it chooses to trust,
or
- Resign itself to the possibility of being attacked via packet
interception (and via other techniques discussed below).
2.2. ID Guessing and Query Prediction
Since DNS is for the most part used over UDP/IP, it is relatively
easy for an attacker to generate packets which will match the
transport protocol parameters. The ID field in the DNS header is
only a 16-bit field and the server UDP port associated with DNS is a
well-known value, so there are only 2**32 possible combinations of ID
and client UDP port for a given client and server. This is not a
particularly large range, and is not sufficient to protect against a
brute force search; furthermore, in practice both the client UDP port
and the ID can often be predicted from previous traffic, and it is
not uncommon for the client port to be a known fixed value as well
(due to firewalls or other restrictions), thus frequently reducing
the search space to a range smaller than 2**16.
By itself, ID guessing is not enough to allow an attacker to inject
bogus data, but combined with knowledge (or guesses) about QNAMEs and
Atkins & Austein Expires 21 August 2004 [Page 4]
draft-ietf-dnsext-dns-threats-06.txt February 2004
QTYPEs for which a resolver might be querying, this leaves the
resolver only weakly defended against injection of bogus responses.
Since this attack relies on predicting a resolver's behavior, it's
most likely to be successful when the victim is in a known state,
whether because the victim rebooted recently, or because the victim's
behavior has been influenced by some other action by the attacker, or
because the victim is responding (in a predictable way) to some third
party action known to the attacker.
This attack is both more and less difficult for the attacker than the
simple interception attack described above: more difficult, because
the attack only works when the attacker guesses correctly; less
difficult, because the attacker doesn't need to be on a transit or
shared network.
In most other respects, this attack is similar to a packet
interception attack. A resolver that checks DNSSEC signatures will
be able to detect the forged response; resolvers that do not
themselves perform DNSSEC signature checking should use TSIG or some
equivalent mechanism to ensure the integrity of their communication
with a recursing name server that does perform DNSSEC signature
checking.
2.3. Name Games
Perhaps the most interesting class of DNS-specific threats are the
name-based attacks. There are several variations within this class,
sometimes called "cache poisoning" or "fake authority" attacks. What
all of these attacks have in common is that they all involve DNS RRs
whose RDATA portion (right hand side) includes a DNS name. Any such
RR is, at least in principle, a hook that lets an attacker feed bad
data into a victim's cache, thus potentially subverting subsequent
decisions based on DNS names.
The worst examples in this class of RRs are CNAME, NS, and DNAME RRs,
because they can redirect a victim's query to a location of the
attacker's choosing. RRs like MX and SRV are somewhat less
dangerous, but in principle they can also be used to trigger further
lookups at a location of the attacker's choosing.
The general form of a name-based attack is something like this:
- Victim issues a query, perhaps at the instigation of the attacker
or some third party; in some cases the query itself may be
unrelated to the name under attack (that is, the attacker is just
using this query as a means to inject false information about some
other name).
Atkins & Austein Expires 21 August 2004 [Page 5]
draft-ietf-dnsext-dns-threats-06.txt February 2004
- Attacker injects response, whether via packet interception, query
guessing, or by being a legitimate name server that's involved at
some point in the process of answering the query that the victim
issued.
- Attacker's response includes one or more RRs with DNS names in
their RDATA; depending on which particular form this attack takes,
the object may be to inject false data associated with those names
into the victim's cache via the Additional section of this
response, or may be to redirect the next stage of the query to a
server of the attacker's choosing (in order to inject more complex
lies into the victim's cache than will fit easily into a single
response, or in order to place the lies in the Authority or Answer
section of a response where they will have a better chance of
sneaking past a resolver's defenses).
Any attacker who can insert resource records into a victim's cache
can almost certainly do some kind of damage, so there are cache
poisoning attacks which are not name-based attacks in the sense
discussed here. However, in the case of name-based attacks, the
cause and effect relationship between the initial attack and the
eventual result may be significantly more complex than in the other
forms of cache poisoning, so name-based attacks merit special
attention.
The common thread in all of the name-based attacks is that response
messages allow the attacker to introduce arbitrary DNS names of the
attacker's choosing and provide further information that the attacker
claims is associated with those names; unless the victim has better
knowledge of the data associated with those names, the victim is
going to have a hard time defending against this class of attacks.
This class of attack is particularly insidious given that it's quite
easy for an attacker to provoke a victim into querying for a
particular name of the attacker's choosing, for example, by embedding
a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail
to the victim. If the victim's mail reading program attempts to
follow such a link, the result will be a DNS query for a name chosen
by the attacker.
DNSSEC should provide a good defense against most (all?) variations
on this class of attack. By checking signatures, a resolver can
determine whether the data associated with a name really was inserted
by the delegated authority for that portion of the DNS name space
(more precisely, a resolver can determine whether the entity that
injected the data had access to an allegedly secret key whose
corresponding public key appears at an expected location in the DNS
name space with an expected chain of parental signatures that start
Atkins & Austein Expires 21 August 2004 [Page 6]
draft-ietf-dnsext-dns-threats-06.txt February 2004
with a public key of which the resolver has prior knowledge).
DNSSEC signatures do not cover glue records, so there's still a
possibility of a name-based attack involving glue, but with DNSSEC it
is possible to detect the attack by temporarily accepting the glue in
order to fetch the signed authoritative version of the same data,
then checking the signatures on the authoritative version.
2.4. Betrayal By Trusted Server
Another variation on the packet interception attack is the trusted
server that turns out not to be so trustworthy, whether by accident
or by intent. Many client machines are only configured with stub
resolvers, and use trusted servers to perform all of their DNS
queries on their behalf. In many cases the trusted server is
furnished by the user's ISP and advertised to the client via DHCP or
PPP options. Besides accidental betrayal of this trust relationship
(via server bugs, successful server break-ins, etc), the server
itself may be configured to give back answers that are not what the
user would expect (whether in an honest attempt to help the user or
to further some other goal such as furthering a business partnership
between the ISP and some third party).
This problem is particularly acute for frequent travelers who carry
their own equipment and expect it to work in much the same way no
matter which network it's plugged into at any given moment (and no
matter what brand of middle boxes a particular hotel chain might have
installed when adding network drops in every guest room...).
While the obvious solution to this problem would be for the client to
choose a more trustworthy server, in practice this may not be an
option for the client. In many network environments a client machine
has only a limited set of recursive name servers from which to
choose, and none of them may be particularly trustworthy. In extreme
cases, port filtering or other forms of packet interception may
prevent the client host from being able to run an iterative resolver
even if the owner of the client machine is willing and able to do so.
Thus, while the initial source of this problem is not a DNS protocol
attack per se, this sort of betrayal is a threat to DNS clients, and
simply switching to a different recursive name server is not an
adequate defense.
Viewed strictly from the DNS protocol standpoint, the only difference
between this sort of betrayal and a packet interception attack is
that in this case the client has voluntarily sent its request to the
attacker. The defense against this is the same as with a packet
interception attack: the resolver must either check DNSSEC signatures
itself or use TSIG (or equivalent) to authenticate the server that it
Atkins & Austein Expires 21 August 2004 [Page 7]
draft-ietf-dnsext-dns-threats-06.txt February 2004
has chosen to trust. Note that use of TSIG does not by itself
guarantee that a name server is at all trustworthy: all TSIG can do
is help a resolver protect its communication with a name server that
it has already decided to trust for other reasons. Protecting a
resolver's communication with a server that's giving out bogus
answers is not particularly useful.
Also note that if the stub resolver does not trust the name server
that is doing work on its behalf and wants to check the DNSSEC
signatures itself, the resolver really does need to have independent
knowledge of the DNSSEC public key(s) it needs in order to perform
the check (usually the public key for the root zone, but in some
cases knowledge of additional keys may also be appropriate).
It is difficult to escape the conclusion that a properly paranoid
resolver must always perform its own signature checking, and that
this rule even applies to stub resolvers.
2.5. Denial of Service
As with any network service (or, indeed, almost any service of any
kind in any domain of discourse), DNS is vulnerable to denial of
service attacks. DNSSEC does not help this, and may in fact make the
problem worse for resolvers that check signatures, since checking
signatures both increases the processing cost per DNS message and in
some cases can also increase the number of messages needed to answer
a query. TSIG (and similar mechanisms) have equivalent problems.
DNS servers are also at risk of being used as denial of service
amplifiers, since DNS response packets tend to be significantly
longer than DNS query packets. Unsurprisingly, DNSSEC doesn't help
here either.
2.6. Authenticated Denial of Domain Names
Much discussion has taken place over the question of authenticated
denial of domain names. The particular question is whether there is
a requirement for authenticating the non-existence of a name. The
issue is whether the resolver should be able to detect when an
attacker removes RRs from a response.
General paranoia aside, the existence of RR types whose absence
causes an action other than immediate failure (such as missing MX and
SRV RRs, which fail over to A RRs) constitutes a real threat.
Arguably, in some cases, even the immediate failure of a missing RR
might be considered a problem. The question remains: how serious is
this threat? Clearly the threat does exist; general paranoia says
that some day it'll be on the front page of some major newspaper,
Atkins & Austein Expires 21 August 2004 [Page 8]
draft-ietf-dnsext-dns-threats-06.txt February 2004
even if we cannot conceive of a plausible scenario involving this
attack today. This implies that some mitigation of this risk is
required.
Note that it's necessary to prove the non-existence of applicable
wildcard RRs as part of the authenticated denial mechanism, and that,
in a zone that is more than one label deep, such a proof may require
proving the non-existence of multiple discrete sets of wildcard RRs.
DNSSEC does include mechanisms which make it possible to determine
which authoritative names exist in a zone, and which authoritative
resource record types exist at those names. The DNSSEC protections
do not cover non-authoritative data such as glue records.
2.7. Wildcards
Much discussion has taken place over whether and how to provide data
integrity and data origin authentication for "wildcard" DNS names.
Conceptually, RRs with wildcard names are patterns for synthesizing
RRs on the fly according to the matching rules described in section
4.3.2 of RFC 1034. While the rules that control the behavior of
wildcard names have a few quirks that can make them a trap for the
unwary zone administrator, it's clear that a number of sites make
heavy use of wildcard RRs, particularly wildcard MX RRs.
In order to provide the desired services for wildcard RRs, we need to
do two things:
- We need a way to attest to the existence of the wildcard RR itself
(that is, we need to show that the synthesis rule exists), and
- We need a way to attest to the non-existence of any RRs which, if
they existed, would make the wildcard RR irrelevant according to
the synthesis rules that govern the way in which wildcard RRs are
used (that is, we need to show that the synthesis rule is
applicable).
Note that this makes the wildcard mechanisms dependent upon the
authenticated denial mechanism described in the previous section.
DNSSEC includes mechanisms along the lines described above, which
make it possible for a resolver to verify that a name server applied
the wildcard expansion rules correctly when generating an answer.
3. Weaknesses of DNSSEC
DNSSEC has some problems of its own:
Atkins & Austein Expires 21 August 2004 [Page 9]
draft-ietf-dnsext-dns-threats-06.txt February 2004
- DNSSEC is complex to implement, and includes some nasty edge cases
at the zone cuts that require very careful coding. Testbed
experience to date suggests that trivial zone configuration errors
or expired keys can cause serious problems for a DNSSEC-aware
resolver, and that the current protocol's error reporting
capabilities may leave something to be desired.
- DNSSEC significantly increases the size of DNS response packets;
among other issues, this makes DNSSEC-aware DNS servers even more
effective as denial of service amplifiers.
- DNSSEC answer validation increases the resolver's work load, since
a DNSSEC-aware resolver will need to perform signature validation
and in some cases will also need to issue further queries. This
increased workload will also increase the time it takes to get an
answer back to the original DNS client, which is likely to trigger
both timeouts and re-queries in some cases. (Arguably, many
current DNS clients are already too impatient even before taking
the further delays that DNSSEC will impose into account, but that's
a separate topic for another document....)
- Like DNS itself, DNSSEC's trust model is almost totally
hierarchical. While DNSSEC does allow resolvers to have special
additional knowledge of public keys beyond those for the root, in
the general case the root key is the one that matters. Thus any
compromise in any of the zones between the root and a particular
target name can damage DNSSEC's ability to protect the integrity of
data owned by that target name. This is not a change, since
insecure DNS has the same model.
- Key rollover at the root is really hard. Work to date has not even
come close to adequately specifying how the root key rolls over, or
even how it's configured in the first place.
- DNSSEC creates a requirement of loose time synchronization between
the validating resolver and the entity creating the DNSSEC
signatures. Prior to DNSSEC, all time-related actions in DNS could
be performed by a machine that only knew about "elapsed" or
"relative" time. Because the validity period of a DNSSEC signature
is based on "absolute" time, a validating resolver must have the
same concept of absolute time as the zone signer in order to
determine whether the signature is within its validity period or
has expired. An attacker that can change a resolver's opinion of
the current absolute time can fool the resolver using expired
signatures. An attacker that can change the zone signer's opinion
of the current absolute time can fool the zone signer into
generating signatures whose validity period does not match what the
signer intended.
Atkins & Austein Expires 21 August 2004 [Page 10]
draft-ietf-dnsext-dns-threats-06.txt February 2004
- The possible existence of wildcard RRs in a zone complicates the
authenticated denial mechanism considerably. For most of the
decade that DNSSEC has been under development these issues were
poorly understood. At various times there have been questions as
to whether the authenticated denial mechanism is completely
airtight and whether it would be worthwhile to optimize the
authenticated denial mechanism for the common case in which
wildcards are not present in a zone, but the main problem is just
the inherent complexity of the wildcard mechanism itself. This
complexity probably makes the code for generating and checking
authenticated denial attestations somewhat fragile, but since the
alternative of giving up wildcards entirely is not practical due to
widespread use, we are going to have to live with wildcards, and
the question just becomes one of whether or not the proposed
optimizations would make DNSSEC's mechanisms more or less fragile.
- Even with DNSSEC, the class of attacks discussed in section 2.4 is
not easy to defeat. In order for DNSSEC to be effective in this
case, it must be possible to configure the resolver to expect
certain categories of DNS records to be signed, which may require
manual configuration of the resolver, especially during the initial
DNSSEC rollout period when the resolver cannot reasonably expect
the root and TLD zones to be signed.
4. Topics for Future Work
This section lists a few subjects not covered above which probably
need additional study, additional mechanisms, or both.
4.1. Interactions With Other Protocols
The above discussion has concentrated exclusively on attacks within
the boundaries of the DNS protocol itself, since those are the
problems against (some of) which DNSSEC was intended to protect.
There are, however, other potential problems at the boundaries where
DNS interacts with other protocols.
4.2. Securing DNS Dynamic Update
DNS dynamic update opens a number of potential problems when combined
with DNSSEC. Dynamic update of a non-secure zone can use TSIG to
authenticate the updating client to the server. While TSIG does not
scale very well (it requires manual configuration of shared keys
between the DNS name server and each TSIG client), it works well in a
limited or closed environment such as a DHCP server updating a local
DNS name server.
Atkins & Austein Expires 21 August 2004 [Page 11]
draft-ietf-dnsext-dns-threats-06.txt February 2004
Major issues arise when trying to use dynamic update on a secure
zone. TSIG can similarly be used in a limited fashion to
authenticate the client to the server, but TSIG only protects DNS
transactions, not the actual data, and the TSIG is not inserted into
the DNS zone, so resolvers cannot use the TSIG as a way of verifying
the changes to the zone. This means that either:
a) The updating client must have access to a zone-signing key in
order to sign the update before sending it to the server, or
b) The DNS name server must have access to an online zone-signing key
in order to sign the update.
In either case, a zone-signing key must be available to create signed
RRsets to place in the updated zone. The fact that this key must be
online (or at least available) is a potential security risk.
Dynamic update also requires an update to the SERIAL field of the
zone's SOA RR. In theory, this could also be handled via either of
the above options, but in practice (a) would almost certainly be
extremely fragile, so (b) is the only workable mechanism.
There are other threats in terms of describing the policy of who can
make what changes to which RRsets in the zone. The current access
control scheme in Secure Dynamic Update is fairly limited. There is
no way to give fine-grained access to updating DNS zone information
to multiple entities, each of whom may require different kinds of
access. For example, Alice may need to be able to add new nodes to
the zone or change existing nodes, but not remove them; Bob may need
to be able to remove zones but not add them; Carol may need to be
able to add, remove, or modify nodes, but only A records.
Scaling properties of the key management problem here are a
particular concern that needs more study.
4.3. Securing DNS Zone Replication
As discussed in previous sections, DNSSEC per se attempts to provide
data integrity and data origin authentication services on top of the
normal DNS query protocol. Using the terminology discussed in
[RFC3552], DNSSEC provides "object security" for the normal DNS query
protocol. For purposes of replicating entire DNS zones, however,
DNSSEC does not provide object security, because zones include
unsigned NS RRs and glue at delegation points. Use of TSIG to
protect zone transfer (AXFR or IXFR) operations provides "channel
security", but still does not provide object security for complete
zones, so the trust relationships involved in zone transfer are still
very much a hop-by-hop matter of name server operators trusting other
Atkins & Austein Expires 21 August 2004 [Page 12]
draft-ietf-dnsext-dns-threats-06.txt February 2004
name server operators, rather than an end-to-end matter of name
server operators trusting zone administrators.
Zone object security was not an explicit design goal of DNSSEC, so
failure to provide this service should not be a surprise.
Nevertheless, there are some zone replication scenarios for which
this would be a very useful additional service, so this seems like a
useful area for future work. In theory it should not be difficult to
zone object security as a backwards compatible enhancement to the
existing DNSSEC model, but the DNSEXT WG has not yet discussed either
the desirability of or the requirements for such an enhancement.
5. Conclusion
Based on the above analysis, the DNSSEC extensions do appear to solve
a set of problems that do need to be solved, and are worth deploying.
Security Considerations
This entire document is about security considerations of the DNS.
The authors believe that deploying DNSSEC will help to address some,
but not all, of the known threats to the DNS.
IANA Considerations
None.
Acknowledgments
This note is based both previous published works by others and on a
number of discussions both public and private over a period of many
years, but particular thanks go to Jaap Akkerhuis, Steve Bellovin,
Dan Bernstein, Randy Bush, Steve Crocker, Olafur Gudmundsson, Russ
Housley, Rip Loomis, Allison Mankin, Paul Mockapetris, Thomas Narten
Mans Nilsson, Pekka Savola, Paul Vixie, Xunhua Wang, and any other
members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups whose
names and contributions the authors have forgotten, none of whom are
responsible for what the authors did with their ideas.
As with any work of this nature, the authors of this note acknowledge
that we are standing on the toes of those who have gone before us.
Readers interested in this subject may also wish to read
[Bellovin95], [Schuba93], and [Vixie95].
Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
RFC 1034, November 1987.
Atkins & Austein Expires 21 August 2004 [Page 13]
draft-ietf-dnsext-dns-threats-06.txt February 2004
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", RFC 1035, November 1987.
[RFC1123] Braden, R., Editor, "Requirements for Internet Hosts -
Application and Support", RFC 1123, October 1989.
[RFC2181] Elz, R., and R. Bush, "Clarifications to the DNS
Specification" RFC 2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)"
RFC 2308, March 1998.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)" RFC 2845, May 2000.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)"
RFC 2930, September 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update" RFC 3007, November 2000.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
Informative References
[RFC3552] Rescorla, E., Korver, B., and the Internet Architecture
Board, "Guidelines for Writing RFC Text on Security
Considerations", RFC 3552, July 2003.
[Bellovin95] Bellovin, S., "Using the Domain Name System for System
Break-Ins", Proceedings of the Fifth Usenix Unix Security
Symposium, June 1995.
[Galvin93] Design team meeting summary message posted to dns-
security@tis.com mailing list by Jim Galvin on 19 November 1993.
[Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name
System Protocol", Master's thesis, Purdue University Department
of Computer Sciences, August 1993.
[Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of
the Fifth Usenix Unix Security Symposium, June 1995.
Atkins & Austein Expires 21 August 2004 [Page 14]
draft-ietf-dnsext-dns-threats-06.txt February 2004
Authors' addresses:
Derek Atkins
IHTFP Consulting, Inc.
6 Farragut Ave
Somerville, MA 02144
USA
Email: derek@ihtfp.com
Rob Austein
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
Email: sra@isc.org
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
Atkins & Austein Expires 21 August 2004 [Page 15]
draft-ietf-dnsext-dns-threats-06.txt February 2004
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Atkins & Austein Expires 21 August 2004 [Page 16]

442
doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt Normal file
View file

@ -0,0 +1,442 @@
INTERNET-DRAFT Samuel Weiler
Expires: June 2004 December 15, 2003
Updates: RFC 2535, [DS]
Legacy Resolver Compatibility for Delegation Signer
draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
Status of this Memo
This document is an Internet-Draft and is subject to 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Comments should be sent to the author or to the DNSEXT WG mailing
list: namedroppers@ops.ietf.org
Abstract
As the DNS Security (DNSSEC) specifications have evolved, the
syntax and semantics of the DNSSEC resource records (RRs) have
changed. Many deployed nameservers understand variants of these
semantics. Dangerous interactions can occur when a resolver that
understands an earlier version of these semantics queries an
authoritative server that understands the new delegation signer
semantics, including at least one failure scenario that will cause
an unsecured zone to be unresolvable. This document changes the
type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
avoid those interactions.
Changes between 05 and 06:
Signifigantly reworked the IANA section -- went back to one
algorithm registry.
Removed Diffie-Hellman from the list of zone-signing algorithms
(leaving only DSA, RSA/SHA-1, and private algorithms).
Added a DNSKEY flags field registry.
Changes between 04 and 05:
IESG approved publication.
Cleaned up an internal reference in the acknowledgements section.
Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference.
Changed the names of both new registries. Added algorithm
mnemonics to the new zone signing algorithm registry. Minor
rewording in the IANA section for clarity.
Cleaned up formatting of references. Replaced unknown-rr draft
references with RFC3597. Bumped DS version number.
Changes between 03 and 04:
Clarified that RRSIG(0) may be defined by standards action.
Created a new algorithm registry and renamed the old algorithm
registry for SIG(0) only. Added references to the appropriate
crypto algorithm and format specifications.
Several minor rephrasings.
Changes between 02 and 03:
KEY (as well as SIG) retained for SIG(0) use only.
Changes between 01 and 02:
SIG(0) still uses SIG, not RRSIG. Added 2931 reference.
Domain names embedded in NSECs and RRSIGs are not compressible and
are not downcased. Added unknown-rrs reference (as informative).
Simplified the last paragraph of section 3 (NSEC doesn't always
signal a negative answer).
Changed the suggested type code assignments.
Added 2119 reference.
Added definitions of "unsecure delegation" and "unsecure referral",
since they're not clearly defined elsewhere.
Moved 2065 to informative references, not normative.
1. Introduction
The DNSSEC protocol has been through many iterations whose syntax
and semantics are not completely compatible. This has occurred as
part of the ordinary process of proposing a protocol, implementing
it, testing it in the increasingly complex and diverse environment
of the Internet, and refining the definitions of the initial
Proposed Standard. In the case of DNSSEC, the process has been
complicated by DNS's criticality and wide deployment and the need
to add security while minimizing daily operational complexity.
A weak area for previous DNS specifications has been lack of detail
in specifying resolver behavior, leaving implementors largely on
their own to determine many details of resolver function. This,
combined with the number of iterations the DNSSEC spec has been
through, has resulted in fielded code with a wide variety of
behaviors. This variety makes it difficult to predict how a
protocol change will be handled by all deployed resolvers. The
risk that a change will cause unacceptable or even catastrophic
failures makes it difficult to design and deploy a protocol change.
One strategy for managing that risk is to structure protocol
changes so that existing resolvers can completely ignore input that
might confuse them or trigger undesirable failure modes.
This document addresses a specific problem caused by Delegation
Signer's [DS] introduction of new semantics for the NXT RR that are
incompatible with the semantics in RFC 2535 [RFC2535]. Answers
provided by DS-aware servers can trigger an unacceptable failure
mode in some resolvers that implement RFC 2535, which provides a
great disincentive to sign zones with DS. The changes defined in
this document allow for the incremental deployment of DS.
1.1 Terminology
In this document, the term "unsecure delegation" means any
delegation for which no DS record appears at the parent. An
"unsecure referral" is an answer from the parent containing an NS
RRset and a proof that no DS record exists for that name.
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].
1.2 The Problem
Delegation Signer introduces new semantics for the NXT RR that are
incompatible with the semantics in RFC 2535. In RFC 2535, NXT
records were only required to be returned as part of a
non-existence proof. With DS, an unsecure referral returns, in
addition to the NS, a proof of non-existence of a DS RR in the form
of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was
to interpret a response with both an NS and an NXT in the authority
section, RCODE=0, and AA=0. Some widely deployed 2535-aware
resolvers interpret any answer with an NXT as a proof of
non-existence of the requested record. This results in unsecure
delegations being invisible to 2535-aware resolvers and violates
the basic architectural principle that DNSSEC must do no harm --
the signing of zones must not prevent the resolution of unsecured
delegations.
2. Possible Solutions
This section presents several solutions that were considered.
Section 3 describes the one selected.
2.1. Change SIG, KEY, and NXT type codes
To avoid the problem described above, legacy (RFC2535-aware)
resolvers need to be kept from seeing unsecure referrals that
include NXT records in the authority section. The simplest way to
do that is to change the type codes for SIG, KEY, and NXT.
The obvious drawback to this is that new resolvers will not be able
to validate zones signed with the old RRs. This problem already
exists, however, because of the changes made by DS, and resolvers
that understand the old RRs (and have compatibility issues with DS)
are far more prevalent than 2535-signed zones.
2.2. Change a subset of type codes
The observed problem with unsecure referrals could be addressed by
changing only the NXT type code or another subset of the type codes
that includes NXT. This has the virtue of apparent simplicity, but
it risks introducing new problems or not going far enough. It's
quite possible that more incompatibilities exist between DS and
earlier semantics. Legacy resolvers may also be confused by seeing
records they recognize (SIG and KEY) while being unable to find
NXTs. Although it may seem unnecessary to fix that which is not
obviously broken, it's far cleaner to change all of the type codes
at once. This will leave legacy resolvers and tools completely
blinded to DNSSEC -- they will see only unknown RRs.
2.3. Replace the DO bit
Another way to keep legacy resolvers from ever seeing DNSSEC
records with DS semantics is to have authoritative servers only
send that data to DS-aware resolvers. It's been proposed that
assigning a new EDNS0 flag bit to signal DS-awareness (tentatively
called "DA"), and having authoritative servers send DNSSEC data
only in response to queries with the DA bit set, would accomplish
this. This bit would presumably supplant the DO bit described in
RFC 3225.
This solution is sufficient only if all 2535-aware resolvers zero
out EDNS0 flags that they don't understand. If one passed through
the DA bit unchanged, it would still see the new semantics, and it
would probably fail to see unsecure delegations. Since it's
impractical to know how every DNS implementation handles unknown
EDNS0 flags, this is not a universal solution. It could, though,
be considered in addition to changing the RR type codes.
2.4. Increment the EDNS version
Another possible solution is to increment the EDNS version number
as defined in RFC 2671 [RFC2671], on the assumption that all
existing implementations will reject higher versions than they
support, and retain the DO bit as the signal for DNSSEC awareness.
This approach has not been tested.
2.5. Do nothing
There is a large deployed base of DNS resolvers that understand
DNSSEC as defined by the standards track RFC 2535 and RFC 2065
and, due to under specification in those documents, interpret any
answer with an NXT as a non-existence proof. So long as that is
the case, zone owners will have a strong incentive to not sign any
zones that contain unsecure delegations, lest those delegations be
invisible to such a large installed base. This will dramatically
slow DNSSEC adoption.
Unfortunately, without signed zones there's no clear incentive for
operators of resolvers to upgrade their software to support the new
version of DNSSEC, as defined in [DS]. Historical data suggests
that resolvers are rarely upgraded, and that old nameserver code
never dies.
Rather than wait years for resolvers to be upgraded through natural
processes before signing zones with unsecure delegations,
addressing this problem with a protocol change will immediately
remove the disincentive for signing zones and allow widespread
deployment of DNSSEC.
3. Protocol changes
This document changes the type codes of SIG, KEY, and NXT. This
approach is the cleanest and safest of those discussed above,
largely because the behavior of resolvers that receive unknown type
codes is well understood. This approach has also received the most
testing.
To avoid operational confusion, it's also necessary to change the
mnemonics for these RRs. DNSKEY will be the replacement for KEY,
with the mnemonic indicating that these keys are not for
application use, per [RFC3445]. RRSIG (Resource Record SIGnature)
will replace SIG, and NSEC (Next SECure) will replace NXT. These
new types completely replace the old types, except that SIG(0)
[RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.
The new types will have exactly the same syntax and semantics as
specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for
the following:
1) Consistent with [RFC3597], domain names embedded in
RRSIG and NSEC RRs MUST NOT be compressed,
2) Embedded domain names in RRSIG and NSEC RRs are not downcased
for purposes of DNSSEC canonical form and ordering nor for
equality comparison, and
3) An RRSIG with a type-covered field of zero has undefined
semantics. The meaning of such a resource record may only be
defined by IETF Standards Action.
If a resolver receives the old types, it SHOULD treat them as
unknown RRs and SHOULD NOT assign any special meaning to them or
give them any special treatment. It MUST NOT use them for DNSSEC
validations or other DNS operational decision making. For example,
a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to
validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone,
they MUST NOT receive special treatment. As an example, if a SIG
is included in a signed zone, there MUST be an RRSIG for it.
Authoritative servers may wish to give error messages when loading
zones containing SIG or NXT records (KEY records may be included
for SIG(0) or TKEY).
As a clarification to previous documents, some positive responses,
particularly wildcard proofs and unsecure referrals, will contain
NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as
negative answers merely because they contain an NSEC.
4. IANA Considerations
4.1 DNS Resource Record Types
This document updates the IANA registry for DNS Resource Record
Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
DNSKEY RRs, respectively.
Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
TKEY [RFC2930] use only.
Type 30 (NXT) should be marked as Obsolete.
4.2 DNS Security Algorithm Numbers
To allow zone signing (DNSSEC) and transaction security mechanisms
(SIG(0) and TKEY) to use different sets of algorithms, the existing
"DNS Security Algorithm Numbers" registry is modified to include
the applicability of each algorithm. Specifically, two new columns
are added to the registry, showing whether each algorithm may be
used for zone signing, transaction security mechanisms, or both.
Only algorithms usable for zone signing may be used in DNSKEY,
RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG
may be used in SIG and KEY RRs.
All currently defined algorithms remain usable for transaction
security mechanisms. Only RSA/SHA-1, DSA/SHA-1, and private
algorithms (types 253 and 254) may be used for zone signing. Note
that the registry does not contain the requirement level of each
algorithm, only whether or not an algorithm may be used for the
given purposes. For example, RSA/MD5, while allowed for
transaction security mechanisms, is NOT RECOMMENDED, per RFC3110.
Additionally, the presentation format algorithm mnemonics from
RFC2535 Section 7 are added to the registry. This document assigns
RSA/SHA-1 the mnemonic RSASHA1.
As before, assignment of new algorithms in this registry requires
IETF Standards Action. Additionally, modification of algorithm
mnemonics or applicability requires IETF Standards Action.
Documents defining a new algorithm must address the applicability
of the algorithm and should assign a presentation mnemonic to the
algorithm.
4.3 DNSKEY Flags
Like the KEY resource record, DNSKEY contains a 16-bit flags field.
This document creates a new registry for the DNSKEY flags field.
Initially, this registry only contains an assignment for bit 7 (the
ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF
Standards Action.
4.4 DNSKEY Protocol Octet
Like the KEY resource record, DNSKEY contains an eight bit protocol
field. The only defined value for this field is 3 (DNSSEC). No
other values are allowed, hence no IANA registry is needed for this
field.
5. Security Considerations
The changes introduced here do not materially affect security.
The implications of trying to use both new and legacy types
together are not well understood, and attempts to do so would
probably lead to unintended and dangerous results.
Changing type codes will leave code paths in legacy resolvers that
are never exercised. Unexercised code paths are a frequent source
of security holes, largely because those code paths do not get
frequent scrutiny.
Doing nothing, as described in section 2.5, will slow DNSSEC
deployment. While this does not decrease security, it also fails
to increase it.
6. Normative references
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[DS] Gudmundsson, O., "Delegation Signer Resource Record",
draft-ietf-dnsext-delegation-signer-15.txt, work in
progress, June 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s)", RFC 2931, September 2000.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
System (DNS)", RFC 2436, March 1999.
[RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", RFC 2539, March 1999.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the
Domain Name System (DNS)", RFC 3110, May 2001.
7. Informative References
[RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, January 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001.
[RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning,
"Domain Name System (DNS) IANA Considerations", BCP 42,
RFC 2929, September 2000.
[RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
Record (RR) Types", RFC 3597, September 2003.
8. Acknowledgments
The changes introduced here and the analysis of alternatives had
many contributors. With apologies to anyone overlooked, those
include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
Lewis, Bill Manning, and Suzanne Woolf.
Thanks to Jakob Schlyter and Mark Andrews for identifying the
incompatibility described in section 1.2.
In addition to the above, the author would like to thank Scott
Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
comments.
9. Author's Address
Samuel Weiler
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
USA
weiler@tislabs.com

1401
doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt Normal file
View file

File diff suppressed because it is too large Load diff

3249
doc/draft/draft-ietf-dnsext-dnssec-protocol-05.txt Normal file
View file

File diff suppressed because it is too large Load diff

2073
doc/draft/draft-ietf-dnsext-dnssec-records-07.txt Normal file
View file

File diff suppressed because it is too large Load diff

560
doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt Normal file
View file

@ -0,0 +1,560 @@
DNS Extensions O. Kolkman
Internet-Draft RIPE NCC
Expires: June 17, 2004 J. Schlyter
E. Lewis
ARIN
December 18, 2003
DNSKEY RR Secure Entry Point Flag
draft-ietf-dnsext-keyrr-key-signing-flag-12
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.
This Internet-Draft will expire on June 17, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
With the Delegation Signer (DS) resource record the concept of a
public key acting as a secure entry point has been introduced. During
exchanges of public keys with the parent there is a need to
differentiate secure entry point keys from other public keys in the
DNSKEY resource record (RR) set. A flag bit in the DNSKEY RR is
defined to indicate that DNSKEY is to be used as a secure entry
point. The flag bit is intended to assist in operational procedures
to correctly generate DS resource records, or to indicate what
DNSKEYs are intended for static configuration. The flag bit is not to
Kolkman, et al. Expires June 17, 2004 [Page 1]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
be used in the DNS verification protocol. This document updates RFC
2535 and RFC 3445.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Secure Entry Point (SEP) Flag . . . . . . . . . . . . . . . 4
3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . . 5
4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Internationalization Considerations . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
Normative References . . . . . . . . . . . . . . . . . . . . . . 7
Informative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . 9
Kolkman, et al. Expires June 17, 2004 [Page 2]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
1. Introduction
"All keys are equal but some keys are more equal than others" [6]
With the definition of the Delegation Signer Resource Record (DS RR)
[5] it has become important to differentiate between the keys in the
DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
other keys in the DNSKEY RR set. We refer to these public keys as
Secure Entry Point (SEP) keys. A SEP key either used to generate a
DS RR or is distributed to resolvers that use the key as the root of
a trusted subtree[3].
In early deployment tests, the use of two (kinds of) key pairs for
each zone has been prevalent. For one kind of key pair the private
key is used to sign just the zone's DNSKEY resource record (RR) set.
Its public key is intended to be referenced by a DS RR at the parent
or configured statically in a resolver. The private key of the other
kind of key pair is used to sign the rest of the zone's data sets.
The former key pair is called a key-signing key (KSK) and the latter
is called a zone-signing key (ZSK). In practice there have been
usually one of each kind of key pair, but there will be multiples of
each at times.
It should be noted that division of keys pairs into KSK's and ZSK's
is not mandatory in any definition of DNSSEC, not even with the
introduction of the DS RR. But, in testing, this distinction has
been helpful when designing key roll over (key super-cession)
schemes. Given that the distinction has proven helpful, the labels
KSK and ZSK have begun to stick.
There is a need to differentiate the public keys for the key pairs
that are used for key signing from keys that are not used key signing
(KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
be sent for generating DS RRs, which DNSKEYs are to be distributed to
resolvers, and which keys are fed to the signer application at the
appropriate time.
In other words, the SEP bit provides an in-band method to communicate
a DNSKEY RR's intended use to third parties. As an example we present
3 use cases in which the bit is useful:
The parent is a registry, the parent and the child use secured DNS
queries and responses, with a preexisting trust-relation, or plain
DNS over a secured channel to exchange the child's DNSKEY RR
sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset
the SEP bit can be used to isolate the DNSKEYs for which a DS RR
needs to be created.
Kolkman, et al. Expires June 17, 2004 [Page 3]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
An administrator has configured a DNSKEY as root for a trusted
subtree into security aware resolver. Using a special purpose tool
that queries for the KEY RRs from that domain's apex, the
administrator will be able to notice the roll over of the trusted
anchor by a change of the subset of KEY RRs with the DS flag set.
A signer might use the SEP bit on the public key to determine
which private key to use to exclusively sign the DNSKEY RRset and
which private key to use to sign the other RRsets in the zone.
As demonstrated in the above examples it is important to be able to
differentiate the SEP keys from the other keys in a DNSKEY RR set in
the flow between signer and (parental) key-collector and in the flow
between the signer and the resolver configuration. The SEP flag is to
be of no interest to the flow between the verifier and the
authoritative data store.
The reason for the term "SEP" is a result of the observation that the
distinction between KSK and ZSK key pairs is made by the signer, a
key pair could be used as both a KSK and a ZSK at the same time. To
be clear, the term SEP was coined to lessen the confusion caused by
the overlap. ( Once this label was applied, it had the side effect of
removing the temptation to have both a KSK flag bit and a ZSK flag
bit.)
The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
"RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
interpreted as described in RFC2119 [1].
2. The Secure Entry Point (SEP) Flag
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |S| protocol | algorithm |
| |E| | |
| |P| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DNSKEY RR Format
Kolkman, et al. Expires June 17, 2004 [Page 4]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
This document assigns the 15'th bit in the flags field as the secure
entry point (SEP) bit. If the the bit is set to 1 the key is
intended to be used as secure entry point key. One SHOULD NOT assign
special meaning to the key if the bit is set to 0. Operators can
recognize the secure entry point key by the even or odd-ness of the
decimal representation of the flag field.
3. DNSSEC Protocol Changes
The bit MUST NOT be used during the resolving and verification
process. The SEP flag is only used to provide a hint about the
different administrative properties of the key and therefore the use
of the SEP flag does not change the DNS resolution protocol or the
resolution process.
4. Operational Guidelines
The SEP bit is set by the key-pair-generator and MAY be used by the
zone signer to decide whether the public part of the key pair is to
be prepared for input to a DS RR generation function. The SEP bit is
recommended to be set (to 1) whenever the public key of the key pair
will be distributed to the parent zone to build the authentication
chain or if the public key is to be distributed for static
configuration in verifiers.
When a key pair is created, the operator needs to indicate whether
the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within
the data that is used to compute the 'key tag field' in the SIG RR,
changing the SEP bit will change the identity of the key within DNS.
In other words, once a key is used to generate signatures, the
setting of the SEP bit is to remain constant. If not, a verifier will
not be able to find the relevant KEY RR.
When signing a zone, it is intended that the key(s) with the SEP bit
set (if such keys exist) are used to sign the KEY RR set of the zone.
The same key can be used to sign the rest of the zone data too. It
is conceivable that not all keys with a SEP bit set will sign the
DNSKEY RR set, such keys might be pending retirement or not yet in
use.
When verifying a RR set, the SEP bit is not intended to play a role.
How the key is used by the verifier is not intended to be a
consideration at key creation time.
Although the SEP flag provides a hint on which public key is to be
used as trusted root, administrators can choose to ignore the fact
that a DNSKEY has its SEP bit set or not when configuring a trusted
root for their resolvers.
Kolkman, et al. Expires June 17, 2004 [Page 5]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
Using the SEP flag a key roll over can be automated. The parent can
use an existing trust relation to verify DNSKEY RR sets in which a
new DNSKEY RR with the SEP flag appears.
5. Security Considerations
As stated in Section 3 the flag is not to be used in the resolution
protocol or to determine the security status of a key. The flag is to
be used for administrative purposes only.
No trust in a key should be inferred from this flag - trust MUST be
inferred from an existing chain of trust or an out-of-band exchange.
Since this flag might be used for automating public key exchanges, we
think the following consideration is in place.
Automated mechanisms for roll over of the DS RR might be vulnerable
to a class of replay attacks. This might happen after a public key
exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
SEP flag set, is sent to the parent. The parent verifies the DNSKEY
RR set with the existing trust relation and creates the new DS RR
from the DNSKEY RR that the current DS RR is not pointing to. This
key exchange might be replayed. Parents are encouraged to implement a
replay defense. A simple defense can be based on a registry of keys
that have been used to generate DS RRs during the most recent roll
over. These same considerations apply to entities that configure keys
in resolvers.
6. IANA Considerations
The flag bits in the DNSKEY RR are assigned by IETF consensus and
registered in the DNSKEY Flags registry (created by [4]). This
document assigns the 15th bit in the DNSKEY RR as the Secure Entry
Point (SEP) bit.
7. Internationalization Considerations
Although SEP is a popular acronym in many different languages, there
are no internationalization considerations.
8. Acknowledgments
The ideas documented in this document are inspired by communications
we had with numerous people and ideas published by other folk. Among
others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
have contributed ideas and provided feedback.
Kolkman, et al. Expires June 17, 2004 [Page 6]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
This document saw the light during a workshop on DNSSEC operations
hosted by USC/ISI in August 2002.
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[3] Lewis, E., "DNS Security Extension Clarification on Zone
Status", RFC 3090, March 2001.
[4] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
in progress), October 2003.
Informative References
[5] Gudmundsson, O., "Delegation Signer Resource Record",
draft-ietf-dnsext-delegation-signer-15 (work in progress), June
2003.
[6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
Story", ISBN 0151002177 (50th anniversary edition), April 1996.
Authors' Addresses
Olaf M. Kolkman
RIPE NCC
Singel 256
Amsterdam 1016 AB
NL
Phone: +31 20 535 4444
EMail: olaf@ripe.net
URI: http://www.ripe.net/
Jakob Schlyter
Karl Gustavsgatan 15
Goteborg SE-411 25
Sweden
EMail: jakob@schlyter.se
Kolkman, et al. Expires June 17, 2004 [Page 7]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
Edward P. Lewis
ARIN
3635 Concorde Parkway Suite 200
Chantilly, VA 20151
US
Phone: +1 703 227 9854
EMail: edlewis@arin.net
URI: http://www.arin.net/
Kolkman, et al. Expires June 17, 2004 [Page 8]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Kolkman, et al. Expires June 17, 2004 [Page 9]
Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kolkman, et al. Expires June 17, 2004 [Page 10]

503
doc/draft/draft-ietf-dnsext-nsec-rdata-03.txt Normal file
View file

@ -0,0 +1,503 @@
DNS Extensions Working Group J. Schlyter, Ed.
Internet-Draft December 19, 2003
Updates: RFC 2535, RFC TCR (if approved)
Expires: June 18, 2004
DNSSEC NSEC RDATA Format
draft-ietf-dnsext-nsec-rdata-03.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.
This Internet-Draft will expire on June 18, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document defines updates the NSEC resource record RDATA format
to cover all type codes.
Schlyter Expires June 18, 2004 [Page 1]
Internet-Draft DNSSEC NSEC RDATA Format December 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 3
2.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 4
2.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 4
2.1.2 The List of Type Bit Map(s) Field . . . . . . . . . . . . . 4
2.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 5
2.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 5
2.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . 6
Normative References . . . . . . . . . . . . . . . . . . . . 6
Informational References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . 7
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . 8
Schlyter Expires June 18, 2004 [Page 2]
Internet-Draft DNSSEC NSEC RDATA Format December 2003
1. Introduction
The NSEC [5] Resource Record (RR) is used for authenticated proof of
the non-existence of DNS owner names and types. The RDATA format for
the NSEC RR, as described in RFC 2535 [2], had a limitation in that,
without using a yet undefined extension mechanism, the the RDATA
could only carry information about the existence of the first 127
types.
To prevent the introduction of an extension mechanism into a deployed
base of DNSSEC aware servers and resolvers, once the first 127 type
codes are allocated, this document redefines the wire format of the
"Type Bit Map" field in the NSEC RDATA to cover the full RR type
space.
This document introduces a new format for the type bit map. The
properties of the type bit map format are that it can cover the full
possible range of typecodes; that it is relatively economic in the
amount of space it uses for the common case of a few types with an
owner name; that it can represent owner names with all possible type
present in packets of approximately 8.5 kilobytes; that the
representation is simple to implement. Efficient searching of the
type bitmap for the presence of certain types is not a requirement.
For convenience and completeness this document presents the syntax
and semantics for the NSEC RR based on the specification in RFC 2535
[2] and as updated by RFC TCR [5], thereby not introducing changes
except for the syntax of the type bit map.
[Editors note: this is the text that is to be copied into
draft-ietf-dnssec-dnssec-records]
This document updates RFC 2535 [2] and RFC TCR [5].
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].
2. The NSEC Resource Record
The NSEC resource record lists two separate things: the owner name of
the next authoritative RRset in the canonical ordering of the zone,
and the set of RR types present at the NSEC RR's owner name. The
complete set of NSEC RRs in a zone both indicate which authoritative
RRsets exist in a zone and also form a chain of authoritative owner
names in the zone. This information is used to provide authenticated
denial of existence for DNS data, as described in RFC 2535 [2].
Schlyter Expires June 18, 2004 [Page 3]
Internet-Draft DNSSEC NSEC RDATA Format December 2003
The type value for the NSEC RR is 47.
The NSEC RR RDATA format is class independent and defined for all
classes.
The NSEC RR has no special TTL requirements.
2.1 NSEC RDATA Wire Format
The RDATA of the NSEC RR is as shown below:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next Domain Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ List of Type Bit Map(s) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.1 The Next Domain Name Field
The Next Domain Name field contains the owner name of the next
authoritative RRset in the canonical ordering of the zone. The value
of the Next Domain Name field in the last NSEC record in the zone is
the name of the zone apex (the owner name of the zone's SOA RR).
2.1.2 The List of Type Bit Map(s) Field
The RR type space is split into 256 window blocks, each representing
the low-order 8 bits of the 16-bit RR type space. Each block that has
at least one active RR type is encoded using a single octet window
number (from 0 to 255), a single octet bitmap length (from 1 to 32)
indicating the number of octets used for the window block's bitmap,
and up to 32 octets (256 bits) of bitmap.
Blocks are present in the NSEC RR RDATA in increasing numerical
order.
"|" denotes concatenation
Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
Each bitmap encodes the low-order 8 bits of RR types within the
window block, in network bit order. The first bit is bit 0. For
window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
to RR type 2 (NS), and so forth. For window block 1, bit 1
corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
Schlyter Expires June 18, 2004 [Page 4]
Internet-Draft DNSSEC NSEC RDATA Format December 2003
1, it indicates that an RRset of that type is present for the NSEC
RR's owner name. If a bit is set to 0, it indicates that no RRset of
that type is present for the NSEC RR's owner name.
Since bit 0 in window block 0 refers to the non-existing RR type 0,
it MUST be set to 0. After verification, the validator MUST ignore
the value of bit 0 in window block 0.
Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [3]
(section 3.1) or within the range reserved for assignment only to
QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
zone data. If encountered, they must be ignored upon reading.
Blocks with no types present MUST NOT be included. Trailing zero
octets in the bitmap MUST be omitted. The length of each block's
bitmap is determined by the type code with the largest numerical
value, within that block, among the set of RR types present at the
NSEC RR's owner name. Trailing zero octets not specified MUST be
interpretted as zero octets.
2.1.3 Inclusion of Wildcard Names in NSEC RDATA
If a wildcard owner name appears in a zone, the wildcard label ("*")
is treated as a literal symbol and is treated the same as any other
owner name for purposes of generating NSEC RRs. Wildcard owner names
appear in the Next Domain Name field without any wildcard expansion.
RFC 2535 [2] describes the impact of wildcards on authenticated
denial of existence.
2.2 The NSEC RR Presentation Format
The presentation format of the RDATA portion is as follows:
The Next Domain Name field is represented as a domain name.
The List of Type Bit Map(s) Field is represented as a sequence of RR
type mnemonics. When the mnemonic is not known, the TYPE
representation as described in RFC 3597 [4] (section 5) MUST be used.
2.3 NSEC RR Example
The following NSEC RR identifies the RRsets associated with
alfa.example.com. and identifies the next authoritative name after
alfa.example.com.
alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC TYPE1234
The first four text fields specify the name, TTL, Class, and RR type
Schlyter Expires June 18, 2004 [Page 5]
Internet-Draft DNSSEC NSEC RDATA Format December 2003
(NSEC). The entry host.example.com. is the next authoritative name
after alfa.example.com. in canonical order. The A, MX, RRSIG and NSEC
mnemonics indicate there are A, MX, RRSIG, NSEC and TYPE1234 RRsets
associated with the name alfa.example.com.
The RDATA section of the NSEC RR above would be encoded as:
0x04 'h' 'o' 's' 't'
0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
0x03 'c' 'o' 'm' 0x00
0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x20
Assuming that the resolver can authenticate this NSEC record, it
could be used to prove that beta.example.com does not exist, or could
be used to prove there is no AAAA record associated with
alfa.example.com. Authenticated denial of existence is discussed in
RFC 2535 [2].
3. IANA Considerations
This document introduces no new IANA considerations, because all of
the protocol parameters used in this document have already been
assigned by RFC TCR [5].
4. Security Considerations
The change introducted here does not affect security, since it only
updates the RDATA format and encoding.
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[3] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name
System (DNS) IANA Considerations", BCP 42, RFC 2929, September
2000.
[4] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
Types", RFC 3597, September 2003.
Schlyter Expires June 18, 2004 [Page 6]
Internet-Draft DNSSEC NSEC RDATA Format December 2003
[5] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
in progress), October 2003.
Informational References
[6] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[7] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
Author's Address
Jakob Schlyter (editor)
Karl Gustavsgatan 15
Goteborg SE-411 25
Sweden
EMail: jakob@schlyter.se
Appendix A. Acknowledgements
The encoding described in this document was initially proposed by
Mark Andrews. Other encodings where proposed by David Blacka and
Michael Graff.
Schlyter Expires June 18, 2004 [Page 7]
Internet-Draft DNSSEC NSEC RDATA Format December 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Schlyter Expires June 18, 2004 [Page 8]
Internet-Draft DNSSEC NSEC RDATA Format December 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schlyter Expires June 18, 2004 [Page 9]

1235
doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt Normal file
View file

File diff suppressed because it is too large Load diff

1233
doc/draft/draft-ietf-dnsop-ipv6-dns-issues-04.txt Normal file
View file

File diff suppressed because it is too large Load diff

505
doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt Normal file
View file

@ -0,0 +1,505 @@
IETF DNSOP Working Group Y. Morishita
Internet-Draft JPRS
Expires: July 11, 2004 T. Jinmei
Toshiba
January 11, 2004
Common Misbehavior against DNS Queries for IPv6 Addresses
draft-ietf-dnsop-misbehavior-against-aaaa-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.
This Internet-Draft will expire on July 11, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
There is some known misbehavior of DNS authoritative servers when
they are queried for AAAA resource records. Such behavior can block
IPv4 communication which should actually be available, cause a
significant delay in name resolution, or even make a denial of
service attack. This memo describes details of the known cases and
discusses the effect of the cases.
1. Introduction
Many DNS clients (resolvers) that support IPv6 first search for AAAA
Resource Records (RRs) of a target host name, and then for A RRs of
Morishita & Jinmei Expires July 11, 2004 [Page 1]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
the same name. This fallback mechanism is based on the DNS
specifications, which if not obeyed by authoritative servers can
produce unpleasant results. In some cases, for example, a web browser
fails to connect to a web server it could otherwise. In the following
sections, this memo describes some typical cases of the misbehavior
and its (bad) effects.
Note that the misbehavior is not specific to AAAA RRs. In fact, all
known examples also apply to the cases of queries for MX, NS, and SOA
RRs. The authors even believe this can be generalized for all types
of queries other than those for A RRs. In this memo, however, we
concentrate on the case for AAAA queries, since the problem is
particularly severe for resolvers that support IPv6, which thus
affects many end users. Resolvers at end users normally send A and/or
AAAA queries only, and so the problem for the other cases is
relatively minor.
2. Network Model
In this memo, we assume a typical network model of name resolution
environment using DNS. It consists of three components; stub
resolvers, caching servers, and authoritative servers. A stub
resolver issues a recursive query to a caching server, which then
handles the entire name resolution procedure recursively. The caching
server caches the result of the query as well as sends the result to
the stub resolver. The authoritative servers respond to queries for
names for which they have the authority, normally in a non-recursive
manner.
3. Expected Behavior
Suppose that an authoritative server has an A RR but not a AAAA RR
for a host name. Then the server should return a response to a query
for a AAAA RR of the name with the RCODE being 0 (indicating no
error) and with an empty answer section [1]. Such a response
indicates that there is at least one RR of a different type than AAAA
for the queried name, and the stub resolver can then look for A RRs.
This way, the caching server can cache the fact that the queried name
does not have a AAAA RR (but may have other types of RRs), and thus
can improve the response time to further queries for a AAAA RR of the
name.
4. Problematic Behaviors
There are some known cases at authoritative servers that do not
conform to the expected behavior. This section describes those
problematic cases.
Morishita & Jinmei Expires July 11, 2004 [Page 2]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
4.1 Return NXDOMAIN
This type of server returns a response with the RCODE being 3
(NXDOMAIN) to a query for a AAAA RR, indicating it does not have any
RRs of any type for the queried name.
With this response, the stub resolver may immediately give up and
never fall back. Even if the resolver retries with a query for an A
RR, the negative response for the name has been cached in the caching
server, and the caching server will simply return the negative
response. As a result, the stub resolver considers this as a fatal
error in name resolution.
There have been several known examples of this behavior, but all the
examples that the authors know have changed their behavior as of this
writing.
4.2 Return NOTIMP
Other authoritative servers return a response with the RCODE being 4
(NOTIMP), indicating the servers do not support the requested type of
query.
This case is less harmful than the previous one; if the stub resolver
falls back to querying for an A RR, the caching server will process
the query correctly and return an appropriate response.
In this case, the caching server does not cache the fact that the
queried name has no AAAA RR, resulting in redundant queries for AAAA
RRs in the future. The behavior will waste network bandwidth and
increase the load of the authoritative server.
Using SERVFAIL or FORMERR would cause the same effect, though the
authors have not seen such implementations yet.
4.3 Return a Broken Response
Another different type of authoritative servers returns broken
responses to AAAA queries. A known behavior of this category is to
return a response whose RR type is AAAA, but the length of the RDATA
is 4 bytes. The 4-byte data looks like the IPv4 address of the
queried host name. That is, the RR in the answer section would be
described like this:
www.bad.example. 600 IN AAAA 192.0.2.1
which is, of course, bogus (or at least meaningless).
Morishita & Jinmei Expires July 11, 2004 [Page 3]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
A widely deployed caching server implementation transparently returns
the broken response (as well as caches it) to the stub resolver.
Another known server implementation parses the response by
themselves, and sends a separate response with the RCODE being 2
(SERVFAIL).
In either case, the broken response does not affect queries for an A
RR of the same name. If the stub resolver falls back to A queries, it
will get an appropriate response.
The latter case, however, causes the same bad effect as that
described in the previous section: redundant queries for AAAA RRs.
4.4 Make Lame Delegation
Some authoritative servers respond to AAAA queries in a way causing
lame delegation. In this case the parent zone specifies that the
authoritative server should have the authority of a zone, but the
server does not return an authoritative response for AAAA queries
within the zone (i.e., the AA bit in the response is not set). On the
other hand, the authoritative server returns an authoritative
response for A queries.
When a caching server asks the server for AAAA RRs in the zone, it
recognizes the delegation is lame, and return a response with the
RCODE being 2 (SERVFAIL) to the stub resolver.
Furthermore, some caching servers record the authoritative server as
lame for the zone and will not use it for a certain period of time.
With this type of caching server, even if the stub resolver falls
back to querying for an A RR, the caching server will simply return a
response with the RCODE being SERVFAIL, since all the servers are
known to be "lame."
There is also an implementation that relaxes the behavior a little
bit. It basically tries to avoid using the lame server, but still
continues to try it as a last resort. With this type of caching
server, the stub resolver will get a correct response if it falls
back after SERVFAIL. However, this still causes redundant AAAA
queries as explained in the previous sections.
4.5 Ignore Queries for AAAA
Some authoritative severs seem to ignore queries for a AAAA RR,
causing a delay at the stub resolver to fall back to a query for an A
RR. This behavior may even cause a fatal timeout at the resolver.
Morishita & Jinmei Expires July 11, 2004 [Page 4]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
5. Security Considerations
The CERT/CC pointed out that the response with NXDOMAIN described in
Section 4.1 can be used for a denial of service attack [2]. The same
argument applies to the case of "lame delegation" described in
Section 4.4 with a certain type of caching server.
6. Acknowledgements
Erik Nordmark encouraged the authors to publish this document as an
Internet Draft. Akira Kato and Paul Vixie reviewed a preliminary
version of this document. Pekka Savola carefully reviewed a previous
version and provided detailed comments.
Informative References
[1] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC
1034, November 1987.
[2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from
AAAA queries could cause denial-of-service conditions", March
2003, <http://www.kb.cert.org/vuls/id/714121>.
Authors' Addresses
MORISHITA Orange Yasuhiro
Research and Development Department, Japan Registry Service Co.,Ltd.
Fuundo Bldg 3F, 1-2 Kanda-Ogawamachi
Chiyoda-ku, Tokyo 101-0052
Japan
EMail: yasuhiro@jprs.co.jp
JINMEI Tatuya
Corporate Research & Development Center, Toshiba Corporation
1 Komukai Toshiba-cho, Saiwai-ku
Kawasaki-shi, Kanagawa 212-8582
Japan
EMail: jinmei@isl.rdc.toshiba.co.jp
Appendix A. Live Examples
In this appendix, we show concrete implementations and domain names
that may cause problematic cases so that the behavior can be
reproduced in a practical environment. The examples are for
Morishita & Jinmei Expires July 11, 2004 [Page 5]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
informational purposes only, and the authors do not intend to accuse
any implementations or zone administrators.
The behavior described in Section 4.2 (return NOTIMP) can be found by
looking for a AAAA RR of www.css.vtext.com at 66.174.3.4.
The behavior described in Section 4.3 (broken responses) can be seen
by querying for a AAAA RR of "www.gslb.mainichi.co.jp," which is an
alias of "www.mainichi.co.jp," at 210.173.172.2. The same behavior
can be found with the name "vip.alt.ihp.sony.co.jp," an alias of
"www.sony.co.jp," at 210.139.255.204.
The behavior described in Section 4.4 (lame delegation) can be found
by querying for a AAAA RR of "www.ual.com" at 209.87.113.4.
The behavior described in Section 4.5 (ignore queries) can be seen by
trying to ask for a AAAA RR of "ad.3jp.doubleclick.net," which is an
alias of "ad.jp.doubleclick.net," at 210.153.90.9.
Many authoritative server implementations show the expected behavior
described in Section 3. Some DNS load balancers reportedly have a
problematic behavior shown in Section 4, but the authors do not have
a concrete example. The CERT/CC provides a list of implementations
that behave as described in Section 4.1 [2].
The BIND9 caching server implementation is an example of the latter
cases described in Section 4.3 and Section 4.4, respectively. The
BIND8 caching server implementation is an example of the former case
described in Section 4.3. As for the issue shown in Section 4.4,
BIND8 caching servers prior to 8.3.5 show the behavior described as
the former case in this section. The versions 8.3.5 and later of
BIND8 caching server behave like the BIND9 caching server
implementation with this matter.
Regarding resolver implementations, the authors are only familiar
with the ones derived from the BIND implementation. These
implementations always fall back regardless of the RCODE; NXDOMAIN,
NOTIMP, or SERVFAIL. It even falls back when getting a broken
response. However, the behavior does not help the situation in the
NXDOMAIN case (see Section 4.1). Lame delegation (Section 4.4) also
causes a fatal error at the resolver side if the resolver is using
some older versions of BIND8 caching server.
The authors hear that a stub resolver routine implemented in some web
browsers interprets the broken response described in Section 4.3 as a
fatal error and does not fall back to A queries. However, we have not
confirmed this information.
Morishita & Jinmei Expires July 11, 2004 [Page 6]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
Appendix B. Change History
Changes since draft-morishita-dnsop-misbehavior-against-aaaa-00 are:
o Made a separate appendix and moved live examples to appendix so
that we can remove them when this document is (ever) officially
published.
o Revised some live examples based on the recent status.
o Noted in introduction that the misbehavior is not specific to AAAA
and that this document still concentrates on the AAAA case.
o Changed the section title of "delegation loop" to "lame
delegation" in order to reflect the essential point of the issue.
Wording on this matter was updated accordingly.
o Updated the Acknowledgements list.
o Changed the reference category from normative to informative (this
is an informational document after all).
o Changed the draft name to an IETF dnsop working group document (as
agreed).
o Applied several editorial fixes.
Morishita & Jinmei Expires July 11, 2004 [Page 7]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Morishita & Jinmei Expires July 11, 2004 [Page 8]
Internet-Draft Common Misbehavior against AAAA Queries January 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Morishita & Jinmei Expires July 11, 2004 [Page 9]

951
doc/draft/draft-ietf-ipseckey-rr-09.txt Normal file
View file

@ -0,0 +1,951 @@
IPSECKEY WG M. Richardson
Internet-Draft SSW
|Expires: August 1, 2004 February 2004
A Method for Storing IPsec Keying Material in DNS
| draft-ietf-ipseckey-rr-09.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.
| This Internet-Draft will expire on August 1, 2004.
Copyright Notice
| Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
| This document describes a new resource record for Domain Name System
| (DNS). This record may be used to store public keys for use in IP
| security (IPsec) systems. The record also includes provisions for
| indicating what system should be contacted when establishing an IPsec
| tunnel with the entity in question.
This record replaces the functionality of the sub-type #1 of the KEY
Resource Record, which has been obsoleted by RFC3445.
|Richardson Expires August 1, 2004 [Page 1]
|Internet-Draft Storing IPsec keying material in DNS February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
| 1.2 Use of reverse (in-addr.arpa) map . . . . . . . . . . . . . . 3
| 1.3 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . . 3
| 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 5
| 2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 5
| 2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 5
| 2.3 RDATA format - gateway type . . . . . . . . . . . . . . . . . 5
| 2.4 RDATA format - algorithm type . . . . . . . . . . . . . . . . 6
| 2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 6
| 2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . . 6
| 3. Presentation formats . . . . . . . . . . . . . . . . . . . . . 8
| 3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 8
| 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
| 4.1 Active attacks against unsecured IPSECKEY resource records . . 10
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
| 6. Intellectual Property Claims . . . . . . . . . . . . . . . . . 13
| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
| Normative references . . . . . . . . . . . . . . . . . . . . . 15
| Non-normative references . . . . . . . . . . . . . . . . . . . 16
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
| Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
|Richardson Expires August 1, 2004 [Page 2]
|Internet-Draft Storing IPsec keying material in DNS February 2004
1. Introduction
It postulated that there is an end system desiring to establish an
IPsec tunnel with some remote entity on the network. This system,
having only a DNS name of some kind (forward, reverse or even
user@FQDN) needs a public key to authenticate the remote entity. It
also desires some guidance about whether to contact the entity
directly, or whether to contact another entity, as the gateway to
that desired entity.
The IPSECKEY RR provides a storage mechanism for such items as the
public key, and the gateway information.
The type number for the IPSECKEY RR is TBD.
1.1 Overview
The IPSECKEY resource record (RR) is used to publish a public key
that is to be associated with a Domain Name System (DNS) name for use
with the IPsec protocol suite. This can be the public key of a
host, network, or application (in the case of per-port keying).
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 [7].
|1.2 Use of reverse (in-addr.arpa) map
| Often a security gateway will only have access to the IP address to
| which communication is desired. It will not know the forward name.
| As such, it will frequently be the case that the IP address will be
| used an index into the reverse map.
| The lookup is done in the usual fashion as for PTR records. The IP
| address' octets (IPv4) or nibbles (IPv6) are reversed and looked up
| under the .arpa. zone. Any CNAMEs or DNAMEs found SHOULD be
| followed.
| Note: even when the IPsec function is the end-host, often only the
| application will know the forward name used. While the case where
| the application knows the forward name is common, the user could
| easily have typed in a literal IP address. This storage mechanism
| does not preclude using the forward name when it is available, but
| does not require it.
|1.3 Usage Criteria
An IPSECKEY resource record SHOULD be used in combination with DNSSEC
|Richardson Expires August 1, 2004 [Page 3]
|Internet-Draft Storing IPsec keying material in DNS February 2004
unless some other means of authenticating the IPSECKEY resource
record is available.
It is expected that there will often be multiple IPSECKEY resource
records at the same name. This will be due to the presence of
multiple gateways and the need to rollover keys.
This resource record is class independent.
|Richardson Expires August 1, 2004 [Page 4]
|Internet-Draft Storing IPsec keying material in DNS February 2004
2. Storage formats
2.1 IPSECKEY RDATA format
The RDATA for an IPSECKEY RR consists of a precedence value, a
gateway type, a public key, algorithm type, and an optional gateway
address.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| precedence | gateway type | algorithm | gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ +
~ gateway ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
2.2 RDATA format - precedence
This is an 8-bit precedence for this record. This is interpreted in
the same way as the PREFERENCE field described in section 3.3.9 of
RFC1035 [2].
Gateways listed in IPSECKEY records with lower precedence are to be
attempted first. Where there is a tie in precedence, the order
should be non-deterministic.
2.3 RDATA format - gateway type
The gateway type field indicates the format of the information that
is stored in the gateway field.
The following values are defined:
0 No gateway is present
1 A 4-byte IPv4 address is present
2 A 16-byte IPv6 address is present
3 A wire-encoded domain name is present. The wire-encoded format is
self-describing, so the length is implicit. The domain name MUST
NOT be compressed. (see section 3.3 of RFC1035 [2]).
|Richardson Expires August 1, 2004 [Page 5]
|Internet-Draft Storing IPsec keying material in DNS February 2004
2.4 RDATA format - algorithm type
The algorithm type field identifies the public key's cryptographic
algorithm and determines the format of the public key field.
A value of 0 indicates that no key is present.
The following values are defined:
1 A DSA key is present, in the format defined in RFC2536 [10]
2 A RSA key is present, in the format defined in RFC3110 [11]
2.5 RDATA format - gateway
The gateway field indicates a gateway to which an IPsec tunnel may be
created in order to reach the entity named by this resource record.
There are three formats:
A 32-bit IPv4 address is present in the gateway field. The data
portion is an IPv4 address as described in section 3.4.1 of RFC1035
[2]. This is a 32-bit number in network byte order.
A 128-bit IPv6 address is present in the gateway field. The data
portion is an IPv6 address as described in section 2.2 of RFC3596
[13]. This is a 128-bit number in network byte order.
The gateway field is a normal wire-encoded domain name, as described
in section 3.3 of RFC1035 [2]. Compression MUST NOT be used.
2.6 RDATA format - public keys
Both of the public key types defined in this document (RSA and DSA)
inherit their public key formats from the corresponding KEY RR
formats. Specifically, the public key field contains the algorithm-
specific portion of the KEY RR RDATA, which is all of the KEY RR DATA
after the first four octets. This is the same portion of the KEY RR
that must be specified by documents that define a DNSSEC algorithm.
Those documents also specify a message digest to be used for
generation of SIG RRs; that specification is not relevant for
IPSECKEY RR.
Future algorithms, if they are to be used by both DNSSEC (in the KEY
RR) and IPSECKEY, are likely to use the same public key encodings in
both records. Unless otherwise specified, the IPSECKEY public key
field will contain the algorithm-specific portion of the KEY RR RDATA
|Richardson Expires August 1, 2004 [Page 6]
|Internet-Draft Storing IPsec keying material in DNS February 2004
for the corresponding algorithm. The algorithm must still be
designated for use by IPSECKEY, and an IPSECKEY algorithm type number
(which might be different than the DNSSEC algorithm number) must be
assigned to it.
The DSA key format is defined in RFC2536 [10]
The RSA key format is defined in RFC3110 [11], with the following
changes:
The earlier definition of RSA/MD5 in RFC2065 limited the exponent and
modulus to 2552 bits in length. RFC3110 extended that limit to 4096
bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on
RSA public keys, other than the 65535 octet limit imposed by the two-
octet length encoding. This length extension is applicable only to
IPSECKEY and not to KEY RRs.
|Richardson Expires August 1, 2004 [Page 7]
|Internet-Draft Storing IPsec keying material in DNS February 2004
3. Presentation formats
3.1 Representation of IPSECKEY RRs
IPSECKEY RRs may appear in a zone data master file. The precedence,
gateway type and algorithm and gateway fields are REQUIRED. The
base64 encoded public key block is OPTIONAL; if not present, then the
public key field of the resource record MUST be construed as being
zero octets in length.
The algorithm field is an unsigned integer. No mnemonics are
defined.
If no gateway is to be indicated, then the gateway type field MUST be
zero, and the gateway field MUST be "."
The Public Key field is represented as a Base64 encoding of the
Public Key. Whitespace is allowed within the Base64 text. For a
definition of Base64 encoding, see RFC3548 [6] Section 5.2.
The general presentation for the record as as follows:
IN IPSECKEY ( precedence gateway-type algorithm
gateway base64-encoded-public-key )
3.2 Examples
An example of a node 192.0.2.38 that will accept IPsec tunnels on its
own behalf.
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2
192.0.2.38
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
An example of a node, 192.0.2.38 that has published its key only.
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2
.
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
An example of a node, 192.0.2.38 that has delegated authority to the
node 192.0.2.3.
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2
192.0.2.3
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
|Richardson Expires August 1, 2004 [Page 8]
|Internet-Draft Storing IPsec keying material in DNS February 2004
An example of a node, 192.0.1.38 that has delegated authority to the
node with the identity "mygateway.example.com".
38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2
mygateway.example.com.
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has
delegated authority to the node 2001:0DB8:c000:0200:2::1
$ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa.
0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2
2001:0DB8:0:8002::2000:1
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
|Richardson Expires August 1, 2004 [Page 9]
|Internet-Draft Storing IPsec keying material in DNS February 2004
4. Security Considerations
This entire memo pertains to the provision of public keying material
for use by key management protocols such as ISAKMP/IKE (RFC2407) [8].
The IPSECKEY resource record contains information that SHOULD be
communicated to the end client in an integral fashion - i.e. free
from modification. The form of this channel is up to the consumer of
the data - there must be a trust relationship between the end
consumer of this resource record and the server. This relationship
may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to
another secure source, a secure local channel on the host, or some
combination of the above.
The keying material provided by the IPSECKEY resource record is not
sensitive to passive attacks. The keying material may be freely
disclosed to any party without any impact on the security properties
of the resulting IPsec session: IPsec and IKE provide for defense
against both active and passive attacks.
Any derivative standard that makes use of this resource record MUST
carefully document their trust model, and why the trust model of
DNSSEC is appropriate, if that is the secure channel used.
4.1 Active attacks against unsecured IPSECKEY resource records
This section deals with active attacks against the DNS. These
attacks require that DNS requests and responses be intercepted and
changed. DNSSEC is designed to defend against attacks of this kind.
The first kind of active attack is when the attacker replaces the
keying material with either a key under its control or with garbage.
If the attacker is not able to mount a subsequent man-in-the-middle
attack on the IKE negotiation after replacing the public key, then
this will result in a denial of service, as the authenticator used by
IKE would fail.
If the attacker is able to both to mount active attacks against DNS
and is also in a position to perform a man-in-the-middle attack on
IKE and IPsec negotiations, then the attacker will be in a position
to compromise the resulting IPsec channel. Note that an attacker
must be able to perform active DNS attacks on both sides of the IKE
negotiation in order for this to succeed.
The second kind of active attack is one in which the attacker
replaces the the gateway address to point to a node under the
attacker's control. The attacker can then either replace the public
|Richardson Expires August 1, 2004 [Page 10]
|Internet-Draft Storing IPsec keying material in DNS February 2004
key or remove it, thus providing an IPSECKEY record of its own to
match the gateway address.
This later form creates a simple man-in-the-middle since the attacker
can then create a second tunnel to the real destination. Note that,
as before, this requires that the attacker also mount an active
attack against the responder.
Note that the man-in-the-middle can not just forward cleartext
packets to the original destination. While the destination may be
willing to speak in the clear, replying to the original sender, the
sender will have already created a policy expecting ciphertext.
Thus, the attacker will need to intercept traffic from both sides.
In some cases, the attacker may be able to accomplish the full
intercept by use of Network Addresss/Port Translation (NAT/NAPT)
technology.
| Note that risk of a man-in-the-middle attack mediated by the IPSECKEY
| RR only applies to cases where the gateway field of the IPSECKEY RR
| indicates a different entity than the owner name of the IPSECKEY RR.
| An active attack on the DNS that caused the wrong IP address to be
| retrieved (via forged A RR), and therefore the wrong QNAME to be
| queried would also result in a man-in-the-middle attack. This
| situation exists independantly of whether or not the IPSECKEY RR is
| used.
| In cases where the end-to-end integrity of the IPSECKEY RR is
| suspect, the end client MUST restrict its use of the IPSECKEY RR to
| cases where the RR owner name matches the content of the gateway
| field.
|Richardson Expires August 1, 2004 [Page 11]
|Internet-Draft Storing IPsec keying material in DNS February 2004
5. IANA Considerations
This document updates the IANA Registry for DNS Resource Record Types
by assigning type X to the IPSECKEY record.
This document creates two new IANA registries, both specific to the
IPSECKEY Resource Record:
This document creates an IANA registry for the algorithm type field.
Values 0, 1 and 2 are defined in Section 2.4. Algorithm numbers 3
through 255 can be assigned by IETF Consensus (see RFC2434 [5]).
This document creates an IANA registry for the gateway type field.
Values 0, 1, 2 and 3 are defined in Section 2.3. Gateway type
numbers 4 through 255 can be assigned by Standards Action (see
RFC2434 [5]).
|Richardson Expires August 1, 2004 [Page 12]
|Internet-Draft Storing IPsec keying material in DNS February 2004
6. Intellectual Property Claims
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
|Richardson Expires August 1, 2004 [Page 13]
|Internet-Draft Storing IPsec keying material in DNS February 2004
7. Acknowledgments
My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
Austein, and Olafur Gurmundsson who reviewed this document carefully.
Additional thanks to Olafur Gurmundsson for a reference
implementation.
|Richardson Expires August 1, 2004 [Page 14]
|Internet-Draft Storing IPsec keying material in DNS February 2004
Normative references
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[4] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, January 1997.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
|Richardson Expires August 1, 2004 [Page 15]
|Internet-Draft Storing IPsec keying material in DNS February 2004
Non-normative references
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[9] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[11] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
System (DNS)", RFC 3110, May 2001.
[12] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record (RR)", RFC 3445, December 2002.
[13] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS
Extensions to Support IP Version 6", RFC 3596, October 2003.
Author's Address
Michael C. Richardson
Sandelman Software Works
470 Dawson Avenue
Ottawa, ON K1Z 5V7
CA
EMail: mcr@sandelman.ottawa.on.ca
URI: http://www.sandelman.ottawa.on.ca/
|Richardson Expires August 1, 2004 [Page 16]
|Internet-Draft Storing IPsec keying material in DNS February 2004
Full Copyright Statement
| Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
|Richardson Expires August 1, 2004 [Page 17]

1200
doc/draft/draft-ietf-ipv6-node-requirements-08.txt Normal file
View file

File diff suppressed because it is too large Load diff

1067
doc/rfc/rfc3658.txt Normal file
View file

File diff suppressed because it is too large Load diff