upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-03-11 02:30:44 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

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

Browse source
This commit is contained in:
cvs2git 2004-03-09 06:30:19 +00:00
commit 8faaceeac3
20 changed files with 11688 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

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]

1555
doc/draft/draft-ietf-dnsext-mdns-29.txt Normal file
View file

File diff suppressed because it is too large Load diff

1120
doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt Normal file
View file

File diff suppressed because it is too large Load diff

1288
doc/draft/draft-ietf-dnsop-dnssec-operational-practices-00.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

300
doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt Normal file
View file

@ -0,0 +1,300 @@
Internet Engineering Task Force A.Durand
INTERNET-DRAFT SUN Microsystems,inc.
November, 24, 2003 J. Ihren
Expires May 25, 2004 Autonomica
DNS IPv6 transport operational guidelines
<draft-ietf-dnsop-ipv6-transport-guidelines-01.txt>
Status of this Memo
This memo provides information to the Internet community. It does not
specify an Internet standard of any kind. This memo is in full
conformance with all provisions of Section 10 of RFC2026
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
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo provides guidelines and Best Current Practice to operate
DNS in a world where queries and responses are carried in a mixed
environment of IPv4 and IPv6 networks.
Acknowledgment
This document is the result of many conversations that happened in
the DNS community at IETF and elsewhere since 2001. During that
period of time, a number of Internet drafts have been published to
clarify various aspects of the issues at stake. This document focuses
on the conclusion of those discussions.
The authors would like to acknowledge the role of Pekka Savola in his
thorough review of the document.
1. Terminology
The phrase "IPv4 name server" indicates a name server available over
IPv4 transport. It does not imply anything about what DNS data is
served. Likewise, "IPv6 name server" indicates a name server
available over IPv6 transport. The phrase "dual-stack DNS server"
indicates a DNS server that is actually configured to run both
protocols, IPv4 and IPv6, and not merely a server running on a system
capable of running both but actually configured to run only one.
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 [2119].
2. Introduction to the Problem of Name Space Fragmentation:
following the referral chain
The caching resolver that tries to look up a name starts out at the
root, and follows referrals until it is referred to a nameserver that
is authoritative for the name. If somewhere down the chain of
referrals it is referred to a nameserver that is only accessible over
an unavailable type of transport, a traditional nameserver is unable
to finish the task.
When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
only a matter of time until this starts to happen. The complete DNS
hierarchy then starts to fragment into a graph where authoritative
nameservers for certain nodes are only accessible over a certain
transport. What is feared is that a node using only a particular
version of IP, querying information about another node using the same
version of IP can not do it because, somewhere in the chain of
servers accessed during the resolution process, one or more of them
will only be accessible with the other version of IP.
With all DNS data only available over IPv4 transport everything is
simple. IPv4 resolvers can use the intended mechanism of following
referrals from the root and down while IPv6 resolvers have to work
through a "translator", i.e. they have to use a second name server on
a so-called "dual stack" host as a "forwarder" since they cannot
access the DNS data directly.
With all DNS data only available over IPv6 transport everything would
be equally simple, with the exception of old legacy IPv4 name servers
having to switch to a forwarding configuration.
However, the second situation will not arise in a foreseeable time.
Instead, it is expected that the transition will be from IPv4 only to
a mixture of IPv4 and IPv6, with DNS data of theoretically three
categories depending on whether it is available only over IPv4
transport, only over IPv6 or both.
Having DNS data available on both transports is the best situation.
The major question is how to ensure that it as quickly as possible
becomes the norm. However, while it is obvious that some DNS data
will only be available over v4 transport for a long time it is also
obvious that it is important to avoid fragmenting the name space
available to IPv4 only hosts. I.e. during transition it is not
acceptable to break the name space that we presently have available
for IPv4-only hosts.
3. Policy Based Avoidance of Name Space Fragmentation
Today there are only a few DNS "zones" on the public Internet that
are available over IPv6 transport, and most of them can be regarded
as "experimental". However, as soon as the root and top level domains
are available over IPv6 transport, it is reasonable to expect that it
will become more common to have zones served by IPv6 servers.
Having those zones served only by IPv6-only name server would not be
a good development, since this will fragment the previously
unfragmented IPv4 name space and there are strong reasons to find a
mechanism to avoid it.
The RECOMMENDED approach to maintain name space continuity is to use
administrative policies, as described in the next section.
4. DNS IPv6 Transport RECOMMENDED Guidelines
In order to preserve name space continuity, the following administrative
policies are RECOMMENDED:
- every recursive DNS server SHOULD be either IPv4-only or dual
stack,
- every single DNS zone SHOULD be served by at least one IPv4
reachable DNS server.
This rules out IPv6-only DNS servers performing full recursion and
DNS zones served only by IPv6-only DNS servers. However, one could
very well design a configuration where a chain of IPv6 only DNS
servers forward queries to a set of dual stack DNS servers actually
performing those recursive queries. This approach could be revisited
if/when translation techniques between IPv4 and IPv6 were to be
widely deployed.
In order to help enforcing the second point, the optional operational
zone validation processes SHOULD ensure that there is at least one
IPv4 address record available for the name servers of any child
delegations within the zone.
5. Security Considerations
Being a critical piece of the Internet infrastructure, the DNS is a
potential value target and thus should be protected. Great care
should be taken not to weaken the security of DNS while introducing
IPv6 operation.
Keeping the DNS name space from fragmenting is a critical thing for
the availability and the operation of the Internet; this memo
addresses this issue by clear and simple operational guidelines.
The RECOMMENDED guidelines are compatible with the operation of
DNSSEC and do not introduce any new security issues.
6. Author Addresses
Alain Durand
SUN Microsystems, Inc
17 Network circle UMPK17-202
Menlo Park, CA, 94025
USA
Mail: Alain.Durand@sun.com
Johan Ihren
Autonomica
Bellmansgatan 30
SE-118 47 Stockholm, Sweden
Mail: johani@autonomica.se
7. Normative References
[2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8. 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 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.

447
doc/draft/draft-ietf-dnsop-key-rollover-requirements-00.txt Normal file
View file

@ -0,0 +1,447 @@
DNSOP G. Guette
Internet-Draft IRISA/INRIA Rennes
Expires: August 8, 2004 O. Courtay
ENST-Bretagne
February 8, 2004
Requirements for Automated Key Rollover in DNSsec
draft-ietf-dnsop-key-rollover-requirements-00
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 8, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes problems that appear during an automated
rollover and gives the requirements for the design of communication
between parent zone and child zone in an automated rollover process.
This document is essentially about key rollover, the rollover of
one other Resource Record present at delegation point (NS RR) is
also discussed.
Guette & Courtay Expires August 8, 2004 [Page 1]
Internet-Draft Automated Rollover Requirements February 2004
1. Introduction
The DNS security extensions (DNSsec) [1] uses public-key cryptography
and digital signatures. It stores the public keys in KEY Resource
Records (RRs). Because old keys and frequently used keys are
vulnerable, they must be changed periodically. In DNSsec this is the
case for Zone Signing Keys (ZSKs) and Key Signing Keys (KSKs) [2, 4].
Automation of key rollover process is necessary for large zones
because inside a large zone, there are too many changes to handle for
a single administrator.
Let us consider for example a zone with one million child zones among
which only 10% of secured child zones. If the child zones change their
keys once a year on average, that implies 300 changes per day for the
parent zone. All these changes are hard to manage manually.
Automated rollover is optional and resulting from an agreement
between the administrator of the parent zone and the administrator of
the child zone. Of course, key rollover can also be done manually by
administrators.
This document describes the requirements for the design of messages
of automated key rollover process.
2. The Key Rollover Process
Key rollover consists in replacing the DNSsec keys used to sign
resource records in a given DNS zone file. There are two types of
rollover, ZSK rollover and KSK rollover.
In ZSK rollover, all changes are local to the zone that changes its
key: there is no need to contact other zones (e.g. parent zone) to
propagate the performed changes because this type of key have no
associated DS records in the parent zone.
In KSK rollover, new DS RR(s) MUST be created and stored in the
parent zone. In consequence, the child zone MUST contact its parent
zone and notify it about the KSK change(s).
Manual key rollover exists and works [3]. The key rollover is built
from two parts of different nature:
- An algorithm that generates new keys. It could be local to the
zone
- The interaction between parent and child zone
In this document we focus on the interaction between parent and
child zone servers.
One example of manual key rollover is:
Child zone creates a new KSK, waiting for the creation of the DS
Guette & Courtay Expires August 8, 2004 [Page 2]
Internet-Draft Automated Rollover Requirements February 2004
record in its parent zone and then child zone deletes old key.
In manual rollover, communications are managed by the zone
administrators and the security of these communications is out of
scope of DNSsec.
Automated key rollover MUST use a secure communication between parent
and child zone. In this document we concentrate our efforts on
defining interactions between entities present in key rollover
process that are not explicitly defined in manual key rollover
method.
3. Basic Requirements
The main constraint to respect during a key rollover is that the
chain of trust MUST be preserved. Even if a resolver retrieve some RRs
from recursive name server. Every RR MUST be verifiable at any time,
every message exchanged during rollover MUST be authenticated and
data integrity MUST be guaranteed.
Two entities are present during a KSK rollover: the child zone and
its parent zone. These zones are generally managed by different
administrators. These administrators MUST agree on some parameters
like availability of automated rollover, the maximum delay between
notification of changes in the child zone and the resigning of the
parent zone. The child zone needs to know this delay to schedule its
changes.
During an automated rollover process, data are transmitted between
the primary name server of the parent and the the primary name server
of the child zone.
The reason is that the IP address of the primary name server is easy
to obtain.
Other solutions based on machine dedicated to the rollover are not
suitable solutions because of the difficulty to obtain the IP
addresses of the dedicated machine in an automated manner.
4. Messages authentication and information exchanged
Every exchanged message MUST be authenticated and the authentication
tool MUST be a DNSsec tool such as TSIG [5], SIG(0) [6] or DNSsec
request with verifiable SIG records.
Once the changes related to a KSK are made in a child zone, this zone
Guette & Courtay Expires August 8, 2004 [Page 3]
Internet-Draft Automated Rollover Requirements February 2004
MUST notify its parent zone in order to create the new DS RR and
store this DS RR in parent zone file.
The parent zone MUST receive all the child Keys that needs the
creation of an associated DS RRs in the parent zone.
Some errors could occur during transmission between child zone and
parent zone. Key rollover solution MUST be fault tolerant, i.e. at
any time the rollover MUST be in a consistent state and all RRs MUST
be verifiable, even if an error occurs. That is to say that it MUST
remains a valid chain of trust.
5. Emergency Rollover
A key of a zone might be compromised and this key MUST be changed as
soon as possible. Fast changes could break the chain of trust. The
part of DNS tree having this zone as apex can become unverifiable,
but the break of the chain of trust is necessary if we want to no one
can use the compromised key to spoof DNS data.
Parent zone behavior after an emergency rollover in one of its child
zone is an open discussion.
Should we define:
- an EMERGENCY flag. When a child zone does an emergency KSK change,
it uses the EMERGENCY flag to notify its parents that the chain of
trust is broken and will stay broken until right DS creation and a
parent zone resigning.
- a maximum time delay after next parent zone resigning, we ensure
that after this delay the parent zone is resigned and the right DS
is created.
- that no pre-defined behavior for the parent zone is needed
6. Other Resource Record concerned by automatic rollover
NS records are also present at delegation point, so when the child
zone changes some NS records, the corresponding records at
delegation point in parent zone MUST be updated. NS records are
concerned by rollover and this rollover could be automated too. In
this case, when the child zone notifies its parent zone that some NS
records have been changed, the parent zone MUST verify that these NS
records are present in child zone before doing any changes in its own
zone file. This allow to avoid inconsistency between NS records at
delegation point and NS records present in the child zone.
Guette & Courtay Expires August 8, 2004 [Page 4]
Internet-Draft Automated Rollover Requirements February 2004
7. Security consideration
This document describes requirements to design an automated key
rollover in DNSsec based on DNSsec security. In the same way the, as
plain DNSsec, the automatic key rollover contains no mechanism
protecting against denial of service (DoS) resistant. The security
level obtain after an automatic key rollover, is the security level
provided by DNSsec.
8. Acknowledgments
The authors want to acknowledge Mohsen Souissi, Bernard Cousin,
Bertrand Leonard and members of IDsA project for their contribution
to this document.
Normative references
[1] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[2] Gudmundsson, O., "Delegation Signer Resource Record",
draft-ietf-dnsext-delegation-signer-15 (work in progress),
June 2003.
[3] Kolkman, O. and Gieben, R., "DNSSEC key operations",
draft-ietf-dnsext-operational-practices (work in progress),
June 2003.
[4] Kolkman, O. and Schlyter, J., "KEY RR Secure Entry Point Flag"
draft-ietf-dnsext-keyrr-key-signing-flag-10 (work in progress),
September 2003.
[5] Vixie, P., Gudmundsson, O., Eastlake, D., and Wellington, B.,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[6] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s)",
RFC 2931, September 2000.
[7] Eastlake, D.,"DNS Security Operational Considerations", RFC
2541, March 1999.
Guette & Courtay Expires August 8, 2004 [Page 5]
Internet-Draft Automated Rollover Requirements October 2003
Author's Addresses
Gilles Guette
IRISA/INRIA Rennes
Campus Universitaire de Beaulieu
35042 Rennes France
Phone : (33) 02 99 84 71 32
Fax : (33) 02 99 84 25 29
E-mail : gguette@irisa.fr
Olivier Courtay
ENST-Bretagne
2, rue de la ch‚taigneraie
35512 Cesson C‰vign‰ CEDEX France
Phone : (33) 02 99 84 71 31
Fax : (33) 02 99 84 25 29
olivier.courtay@enst-bretagne.fr
Guette & Courtay Expires August 8, 2004 [Page 6]
Internet-Draft Automated Rollover Requirements February 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 (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
Guette & Courtay Expires August 8, 2004 [Page 7]
Internet-Draft Automated Rollover Requirements February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Guette & Courtay Expires August 8, 2004 [Page 8]

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

File diff suppressed because it is too large Load diff

42
doc/draft/update Normal file
View file

@ -0,0 +1,42 @@
#!/bin/sh
for i
do
z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'`
if test -n "$z"
then
i="$z"
fi
if test -f "$i"
then
continue
fi
pat=`echo "$i" | sed 's/...txt/??.txt/'`
old=`echo $pat 2> /dev/null`
if test "X$old" != "X$pat"
then
newer=0
for j in $old
do
if test $j ">" $i
then
newer=1
fi
done
if test $newer = 1
then
continue;
fi
fi
if fetch "http://www.ietf.org/internet-drafts/$i"
then
cvs add "$i"
if test "X$old" != "X$pat"
then
rm $old
cvs delete $old
else
old=
fi
cvs commit -m "new draft" $i $old
fi
done

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

File diff suppressed because it is too large Load diff

14
lib/bind/port/cygwin/Makefile.in Normal file
View file

@ -0,0 +1,14 @@
# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
# Copyright (C) 2002 Internet Software Consortium.
#
# Permission to use, copy, modify, and distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
# PERFORMANCE OF THIS SOFTWARE.

47
lib/bind/port/cygwin/include/Makefile.in Normal file
View file

@ -0,0 +1,47 @@
# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
# Copyright (C) 2002 Internet Software Consortium.
#
# Permission to use, copy, modify, and distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
# PERFORMANCE OF THIS SOFTWARE.
# $Id: Makefile.in,v 1.2 2004/03/05 05:07:59 marka Exp $
srcdir = @srcdir@
VPATH = @srcdir@
top_srcdir = @top_srcdir@
HEADERS= ansi_realloc.h assert.h paths.h
AHEADERS= asm/socket.h
NHEADERS= net/route.h
SHEADERS= sys/bitypes.h sys/cdefs.h sys/mbuf.h sys/socket.h sys/un.h sys/wait.h
all:
@BIND9_MAKE_RULES@
installdirs:
$(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${includedir}/asm \
${DESTDIR}${includedir}/net ${DESTDIR}${includedir}/sys
install:: installdirs
for i in ${HEADERS}; do \
${INSTALL_DATA} ${srcdir}/$$i ${DESTDIR}${includedir}; \
done
for i in ${AHEADERS}; do \
${INSTALL_DATA} ${srcdir}/$$i ${DESTDIR}${includedir}/asm; \
done
for i in ${NHEADERS}; do \
${INSTALL_DATA} ${srcdir}/$$i ${DESTDIR}${includedir}/net; \
done
for i in ${SHEADERS}; do \
${INSTALL_DATA} ${srcdir}/$$i ${DESTDIR}${includedir}/sys; \
done

22
lib/bind/port/cygwin/include/ansi_realloc.h Normal file
View file

@ -0,0 +1,22 @@
/*
* Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
* Copyright (c) 1997,1999 by Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
* OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
#include <stddef.h>
#define realloc __ansi_realloc
void *__ansi_realloc(void *ptr, size_t size);

6
lib/bind/port/cygwin/include/net/route.h Normal file
View file

@ -0,0 +1,6 @@
#ifndef ROUTE_H
#define ROUTE_H 1
/* Dummy include for CYGWIN */
#endif

6
lib/bind/port/cygwin/include/nlist.h Normal file
View file

@ -0,0 +1,6 @@
#ifndef NLIST_H
#define NLIST_H 1
/* Dummy include for CYGWIN */
#endif

37
lib/bind/port/cygwin/include/sys/bitypes.h Normal file
View file

@ -0,0 +1,37 @@
/*
* Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
* Copyright (c) 1996,1999 by Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
* OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
#ifndef __BIT_TYPES_DEFINED__
#define __BIT_TYPES_DEFINED__
/*
* Basic integral types. Omit the typedef if
* not possible for a machine/compiler combination.
*/
typedef /*signed*/ char int8_t;
typedef unsigned char u_int8_t;
typedef short int16_t;
typedef unsigned short u_int16_t;
typedef int int32_t;
typedef unsigned int u_int32_t;
# if 0 /* don't fight with these unless you need them */
typedef long long int64_t;
typedef unsigned long long u_int64_t;
# endif
#endif /* __BIT_TYPES_DEFINED__ */

6
lib/bind/port/cygwin/include/sys/mbuf.h Normal file
View file

@ -0,0 +1,6 @@
#ifndef MBUF_H
#define MBUF_H 1
/* Dummy include for CYGWIN */
#endif