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

added new drafts

Browse Source
This commit is contained in:
Andreas Gustafsson 2001-04-02 17:14:10 +00:00
parent 9de63e99af
commit 6277b6cbb5
2 changed files with 850 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

354
doc/draft/draft-ietf-dnsext-parent-sig-00.txt Normal file
View File

@ -0,0 +1,354 @@
INTERNET-DRAFT R. Gieben
DNSEXT Working Group NLnet Labs
Expires September 2001 T. Lindgreen
NLnet Labs
Parent's SIG over child's KEY
draft-ietf-dnsext-parent-sig-00.txt
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.
Comments should be sent to the authors or the DNSEXT WG mailing
list namedroppers@ops.ietf.org.
Copyright Notice
Copyright (C) The Internet Society (2001). All rights reserved.
Abstract
When dealing with large amounts of keys the procedures to update a
zone and to sign a zone need to be clearly defined and practically
possible. The current idea is to have the KEY RR and the parent's
SIG to reside in the child's zone and perhaps also in the parent's
zone. We feel that this would lead to very complicated procedures for
large TLDs. We propose an alternative scheme in which the parent zone
stores the parent's signature over the child's key and also a copy of
the child's key itself.
The advantage of this proposal is that all signatures signed by a
key are in the same zone file as the producing key. This allows for a
simple key rollover and resigning mechanism. For large TLDs this is
extremely important.
Internet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 2]
We further discuss the impact on a secure aware resolver/forwarder
and the impact on the authority of KEYs and the NXT record.
Table of Contents
Status of This Document....................................2
Abstract...................................................2
Table of Contents..........................................3
1 Introduction.............................................3
2 Proposal.................................................4
3 Impact on a secure aware resolver/forwarder..............4
3.1 Impact of key rollovers on resolver/forwarder..........4
4 Key rollovers............................................5
4.1 Scheduled key rollover.................................5
4.2 Unscheduled key rollover...............................5
5 Zone resigning...........................................6
6. Consequences for KEY and NXT records....................6
6.1. KEY bit in NXT records................................6
6.2. Authority of KEY records..............................6
7. Security Considerations.................................6
Authors' Addresses.........................................7
References.................................................7
Full Copyright Statement...................................7
1. Introduction
Within a CENTR working group NLnet Labs is researching the impact
of DNSSEC on the ccTLDs and gTLDs.
In this document we are considering a secure zone, somewhere under
a secure entry point and on-tree [1] validation between the secure
entry point and the zone in question. The resolver we are
considering is security aware and is preconfigured with the KEY of
the secure entry point.
RFC 2535 [3] states that a zone key must be present in the apex of
a zone. This can be in the at the delegation point in the parent's
zonefile (normally the case for null keys), or in the child's
zonefile, or in both. This key is only valid if it is signed by the
parent, so there is also the question where this signature is
located.
The original idea was to have the KEY RR and the parent's SIG to
reside in the child's zone and perhaps also in the parent's zone.
There is a draft proposal [4], that describes how a keyrollover can
be handled.
At NLnet Labs we found that storing the parent's signature over
the child's key in the child's zone:
- makes resigning a KEY by the parent difficult
Internet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 3]
- makes a scheduled keyrollover very complicated
- makes an unscheduled keyrollover virtually impossible
We propose an alternative scheme in which the parent's signature
over the child's key is only stored in the parent's zone, i.e. where
the signing key resides. This would solve the above problems.
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 [2].
2. Proposal
The core of the new proposal is that the parent zone stores the
parent's signature over the child's key and also a copy of the
child's key itself. The child zone also contains its zonekey, where
it is selfsigned.
The advantage of this proposal is that all signatures signed by a
key are in the same zone file as the producing key. This allows for a
simple key rollover and resigning mechanism. For large TLD's this is
extremely important. A disadvantage would be that not all the
information concerning one zone is stored at that zone, namely the
(parent) SIG RR. Note that the same argument can be applied to a
zone's NULL key, which is also stored at the parent.
3. Impact on a secure aware resolver/forwarder
The resolver must be aware of the fact that the parent is more
authoritative than a child when it comes to deciding whether a zone
is secured or not.
Without caching and with on-tree validation, a resolver will
always start its search at a secure entry point. In this way it can
determine whether it must expect SIG records or not.
Considering caching in a secure aware resolver or forwarder. If
information of a secure zone is cached, its validated KEY should also
be cached.
If the KEY record expires, because the KEY TTL expires or because
the SIG is no longer valid, the KEY should be discarded. The resolver
or forwarder should then also discard other data concerning the zone
because it is no longer validated and possible bad data should not be
cached.
3.1. Impact of key rollovers on resolver/forwarder
When a zone is in the process of a key rollover, there could be a
discrepancy between the KEY and the SIG in the apex of the zone and
the KEY and SIG that are stored in the cache of a resolver.
Internet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 4]
Suppose a resolver has cached the NS, KEY and SIG records of a
zone. Next a request comes for an A record in that zone. Also the
zone is in the process of a keyrollover and already has new keys in
its zone. The resolver receives an answer consisting of the A record
and a SIG over the A record. It uses the tag field in the SIG to
determine if it has a KEY which is suitable to validate the SIG. If
it does not has such a KEY the resolver must ask the parent of the
zone for a new KEY and then try it again. Now the resolver has 2
keys for the zone, according to the tag field in the SIG it can use
either one.
If the new key also does not validate the SIG the zone is marked
bad. If the KEY found at the parent is the NULL key the resolver
knows that the child is considered insecure. This could for instance
be in the case the private key of the zone is stolen.
4. Key rollovers
Private keys can be stolen or a key can become over used. In both
cases a new key must be signed and distributed. This event is called
keyrollover. We further distinguish between a scheduled and an
unscheduled key rollover. A scheduled rollover is announced before
hand. An unscheduled key rollover is needed when a private key is
compromised.
4.1. Scheduled key rollover
When the signatures, produced by the key to be rolled over, are
all in one zone file, there are two parties involved. Let us look at
an example where a TLD rolls over its zone key. The new key needs to
be signed with the root's key before it can be used to sign the TLD
zone and the zone keys of the TLD's children. The steps that need to
be taken by TLD and root are:
- the TLD adds the new key to its keyset in its zonefile. This
zone and keyset are signed with the old zonekey
- then the TLD signals the parent
- the root copies the new keyset, consisting of the both new
and the old key, in its zonefile, resigns it and signals the
TLD
- the TLD removes the old key from its keyset, resigns its zone
with the new key, and signals the the root
- the root copies the new keyset, now consisting of the new key
only, and resigns it
4.2. Unscheduled key rollover
Although nobody hopes that this will ever happen, we must be able
to cope with possible key compromises. When such an event occurs, an
immediate keyrollover is needed and must be completed in the shortest
possible time. With two parties involved, it will still be awkward,
but not impossible to update two zonefiles overnight. "Out-of-band"
communication between the two parties will be necessary, since the
compromised old key can not be trusted. We think that between two
Internet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 5]
parties this is doable, but this complicated procedure is beyond the
scope of this document. [5]
5. Zone resigning
Resigning a TLD is necessary before the current signatures expire.
When all SIG records, produced by the TLD's zone key are kept in the
TLD's zonefile, and only there, such a resign session is trivial, as
only one party (the TLD) and one zonefile is involved.
6. Consequences for KEY and NXT records
A key record is only present in a child zone to facilitate a key
rollover. A resolver should therefore be aware that the zonekey of a
child zone is actually stored in the parent's zone. This also affects
the NXT record and the authority of KEY resource records.
6.1. KEY bit in NXT records
RFC 2535 [3], section 5.2 states:
" The NXT RR type bit map format currently defined is one bit per
RR type present for the owner name. A one bit indicates that at
least one RR of that type is present for the owner name. A zero
indicates that no such RR is present. [....] "
With a KEY still present in a child zone we do not see a compelling
reason to change this default behavior.
6.2. Authority of KEY records
The parent of a zone generates the signature for the key belonging
to that zone. By making that signature available the parent publicly
states that the child zone is trustworthy: when it comes to security
in DNSSEC the parent is more authoritative than the child.
From this we conclude that a parent zone MUST set the authority
bit to 1 and child zones MUST set this bit to 0 when dealing with
KEYs from that child zone.
A secure entry point has a selfsigned key and thus has no parent who
is more authoritative on that key. This is not a problem. If a
resolver knows that a secure entry point is a secure entry point it
must have its key preconfigured. There is no need for a parent in
this scenario, because the resolver itself can check the security of
that zone. A interesting consequence of this is that nobody, but the
resolver is authoritative for a key belonging to a secure entry
point. This authority must established via some out of band
mechanism, like publishing keys in a newspaper.
7. Security Considerations
This whole document is about security.
Internet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 6]
Authors' Addresses
R. Gieben
Stichting NLnet Labs
Kruislaan 419
1098 VA Amsterdam
miek@nlnetlabs.nl
T. Lindgreen
Stichting NLnet Labs
Kruislaan 419
1098 VA Amsterdam
ted@nlnetlabs.nl
References
[1] Lewis, E. "DNS Security Extension Clarification on Zone Status",
www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-04.txt
[2] Bradner, S. "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119
www.ietf.org/rfc/rfc2119.txt
[3] Eastlake, D. "DNS Security Extensions", RFC 2535
www.ietf.org/rfc/rfc2535.txt
[4] Andrews, M., Eastlake, D. "Domain Name System (DNS) Security Key Rollover"
www.ietf.org/internet-drafts/draft-ietf-dnsop-rollover-01.txt
[5] Gieben, R. "Chain of trust"
secnl.nlnetlabs.nl/thesis/thesis.html
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise explain
it 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.
Internet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 7]
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.

496
doc/draft/draft-ietf-dnsext-parent-stores-zone-keys-00.txt Normal file
View File

@ -0,0 +1,496 @@
INTERNET-DRAFT R. Gieben
DNSEXT Working Group NLnet Labs
Expires September 2001 T. Lindgreen
NLnet Labs
Parent stores the child's zone KEYs
draft-ietf-dnsext-parent-stores-zone-keys-00.txt
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.
Comments should be sent to the authors or the DNSEXT WG mailing
list namedroppers@ops.ietf.org.
This document updates RFC 2535 [2].
Copyright Notice
Copyright (C) The Internet Society (2001). All rights reserved.
Abstract
When dealing with large amounts of keys the procedures to update a
zone and to sign a zone need to be clearly defined and practically
possible. The current idea is to have the zone KEY RR and the
parent's SIG to reside in the child's zone and perhaps also in the
parent's zone. Operational experiences have prompted us to develop an
alternative scheme in which the parent zone stores the parent's
signature over the child's key and also the child's key itself.
The advantage of this scheme is that all signatures signed by a key
are in the same zone file as the producing key. This allows for a
Gieben Expires September 2001 [Page 2]
Internet Draft Parent Stores Zone KEYS March 2001
simple key rollover and resigning mechanism. For large TLDs this is
extremely important.
Besides the operational advantages, this also obsoletes the NULL key,
as the absence of child's zone KEY, which is securely verified by the
absence of the KEY-bit in the corresponding NXT RR, now unambiguously
indicates that the child is not secured by this parent.
We further discuss the impact on a secure aware resolver/forwarder
and the impact on the authority of KEYs and the NXT record.
Table of Contents
Status of This Document....................................2
Abstract...................................................2
Table of Contents..........................................3
1 Introduction.............................................3
2 Proposal.................................................4
2.1. TTL of the KEY and SIG at the parent..................4
2.2. No NULL KEY...........................................5
3 Impact on a secure aware resolver/forwarder..............5
3.1 Impact of key rollovers on resolver/forwarder..........5
4 Scheduled key rollover...................................6
5 Unscheduled key rollover.................................6
6 Zone resigning...........................................7
7. Consequences for KEY and NXT records....................7
7.1. KEY bit in NXT records................................7
7.2. Authority of KEY records..............................8
7.3. Selecting KEY sets....................................8
8. The zone-KEY and local KEY records......................8
9. Security Considerations.................................8
Authors' Addresses.........................................9
References.................................................9
Full Copyright Statement...................................9
1. Introduction
Within a CENTR working group NLnet Labs is researching the impact of
DNSSEC on the ccTLDs and gTLDs.
In this document we are considering a secure zone, somewhere under a
secure entry point and on-tree [1] validation between the secure
entry point and the zone in question. The resolver we are
considering is security aware and is preconfigured with the KEY of
the secure entry point. We also make a distinction between a
scheduled and a unscheduled key rollover. A scheduled rollover is
announced before hand. An unscheduled key rollover is needed when a
private key is compromised.
Gieben Expires September 2001 [Page 3]
Internet Draft Parent Stores Zone KEYS March 2001
RFC 2535 [2] states that a zone KEY must be present in the apex of a
zone. This can be in the at the delegation point in the parent's
zonefile, or in the child's zonefile, or in both. This key is only
valid if it is signed by the parent, so there is also the question
where this signature and this zone KEY are located.
The original idea was to have the zone KEY RR and the parent's SIG to
reside in the child's zone and perhaps also in the parent's zone.
There is a draft proposal [3], that describes how a keyrollover can
be handled.
At NLnet Labs we found that storing the parent's signature over the
child's zone KEY in the child's zone:
- makes resigning a KEY by the parent difficult
- makes a scheduled keyrollover very complicated
- makes an unscheduled keyrollover virtually impossible
We propose an alternative scheme in which the parent's signature over
the child's zone KEY and the child's zone KEY itself are only stored
in the parent's zone, i.e. where the signing key resides. This would
solve the above problems and also obsoletes the NULL KEY.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
2. Proposal
The core of the new proposal is that the parent zone stores the
parent's signature over the child's zone KEY and also the child's
zone KEY itself. The child zone may also contain its zone KEY, in
which case is must be selfsigned.
The main advantage of this proposal is that all signatures signed by
a key are in the same zone file as the producing key. This allows for
a simple key rollover and resigning mechanism. For large TLDs this is
extremely important. A disadvantage would be that not all the
information concerning one zone is stored at that zone, this is
covered in section 7.2.
A parent running DNSSEC SHOULD NOT refuse a request from a child to
include and sign its key, but can ask for certain conditions to be
met. These condition could include a fee, sufficient authentication,
signing a non liability clause, the conditions specified in section 8
of this document, etc.
2.1. TTL of the KEY and SIG at the parent
Each zone in DNS expresses in its SOA record the maximum and minimum
TTL values that they allow in the zone. Thus it is possible that the
parent will sign with a value that is unacceptable to the child. The
Gieben Expires September 2001 [Page 4]
Internet Draft Parent Stores Zone KEYS March 2001
parent MUST follow the TTL request of the child as long as that is
within the allowed range for the parent.
2.2. No NULL KEY
This proposal obsoletes the NULL KEY. If there is no child KEY at the
parent, which can be securely verified by inspecting the the unset
KEY-bit in the corresponding NXT RR, the child is not secured by this
parent (of course, the child can then still be secured off-tree).
This updates section 3.1.2 "The zone KEY RR Flag Field" of RFC 2535,
it says:
" 11: If both bits are one, the "no key" value, there is no key
information and the RR stops after the algorithm octet.
By the use of this "no key" value, a signed zone KEY RR can
authenticatably assert that, for example, a zone is not
secured. See section 3.4 below. "
As we don't have a NULL KEY anymore this is obsoleted.
Section 3.4 "Determination of Zone Secure/Unsecured Status":
" A zone KEY RR with the "no-key" type field value (both key type
flag bits 0 and 1 on) indicates that the zone named is unsecured
while a zone KEY RR with a key present indicates that the zone named
is secure. The secured versus unsecured status of a zone may vary
with different cryptographic algorithms. Even for the same
algorithm, conflicting zone KEY RRs may be present. "
This is rewritten as:
" A zone is considered secured by on-tree validation [1] when the
there is a zone KEY from that zone present at its parent. If there
is no zone KEY present, and the resolver is also unaware of
alternative algorithms used and/or possible off-tree validation, the
zone is considered unsecured. "
3. Impact on a secure aware resolver/forwarder
The resolver must be aware of the fact that the parent is more
authoritative than a child when it comes to deciding whether a zone
is secured or not.
Without caching and with on-tree validation, a resolver will always
start its search at a secure entry point. In this way it can
determine whether it must expect SIG records or not.
Considering caching in a secure aware resolver or forwarder. If
information of a secure zone is cached, its validated KEY should also
be cached.
3.1. Impact of key rollovers on resolver/forwarder
When a zone is in the process of a key rollover, there could be a
Gieben Expires September 2001 [Page 5]
Internet Draft Parent Stores Zone KEYS March 2001
discrepancy between the KEY and the SIG in the apex of the zone and
the KEY and SIG that are stored in the cache of a resolver.
Suppose a resolver has cached the NS, KEY and SIG records of a zone.
Next a request comes for an A record in that zone. Also the zone is
in the process of a key rollover and already has new keys in its
zone. The resolver receives an answer consisting of the A record and
a SIG over the A record. It uses the tag field in the SIG to
determine if it has a KEY which is suitable to validate the SIG. If
it does not has such a KEY the resolver must ask the parent of the
zone for a new KEY and then try it again. Now the resolver has 2
keys for the zone, according to the tag field in the SIG it can use
either one.
If the new key also does not validate the SIG the zone is marked bad.
If the parent indicates by having a not set KEY-bit in the NXT RR
that there is no KEY for this zone, the child must be considered
unsecured by this parent, despite the appearance of an (old) KEY in
the cache. This could for instance happen after an emergency request
from the child, who has suffered a key compromise, and has decided to
prefer being unsecured over either dropping of the Internet or being
exposed to have verifiable secure info added by the key-compromiser
to their zone information.
4. Scheduled key rollover
When the signatures, produced by the key to be rolled over, are all
in one zone file, there are two parties involved. Let us look at an
example where a TLD rolls over its zone KEY. The new key needs to be
signed with the root's key before it can be used to sign the TLD zone
and the zone KEYs of the TLD's children. The steps that need to be
taken by TLD and root are:
- the TLD adds the new key to its KEY set in its zonefile. This
zone and KEY set are signed with the old zone KEY
- then the TLD signals the parent
- the root copies the new KEY set, consisting of the both new and
the old key, in its zonefile, resigns it and signals the TLD
- the TLD removes the old key from its KEY set, resigns its zone
with the new KEY, and signals the the root
- the root copies the new KEY set, now consisting of the new key
only, and resigns it
Note that this procedure is immune to fake signals and spoofing
attacks (as long as there is no key compromise):
- on a fake signal either way the action becomes a null-action as
the new KEY set is identical to the existing one.
- a spoofed new KEY set will not validate with the existing KEY
that the parent holds.
5. Unscheduled key rollover
Gieben Expires September 2001 [Page 6]
Internet Draft Parent Stores Zone KEYS March 2001
Although nobody hopes that this will ever happen, we must be able to
cope with possible key compromises. When such an event occurs, an
immediate keyrollover is needed and must be completed in the shortest
possible time. With two parties involved, it will still be awkward,
but not impossible to update two zonefiles overnight. "Out-of-band"
communication between the two parties will be necessary, since the
compromised old key can not be trusted. We think that between two
parties this is doable, but this complicated procedure [5] is beyond
the scope of this document.
An alternative to an emergency key-rollover is becoming unsecured as
an emercengy measure. This has already been mentioned above in
section 3.1. This only involves an emergency change in the parents
zonefile (deleting the child's zone KEY), and allows the child and
its underlying zones time to clean up before becoming secured again,
without dropping from the Internet or being exposed to having secured
but false zone information.
6. Zone resigning
Resigning a TLD is necessary before the current signatures expire.
When all SIGs (produced by the TLD's zone KEY) and the child KEY
records, are kept in the TLD's zonefile, such a resign session is
trivial, as only one party (the TLD) and one zonefile are involved.
7. Consequences for KEY and NXT records
There are two reasons to have of the child's zone KEY not only at the
parent but also in the child's own zonefile:
1. to facilitate a key-rollover
2. to prevent local lookups for local information to suffer
from possible loss of access to its outside parent
To cope with 1, secure aware resolvers MUST be aware that during a
key-rollover there may be a conflict, and that in that case the
parent always holds the active KEY set. To cope with 2, the local
resolver/caching forwarder should be preconfigured with the zone-KEY
and thus looks at its own zone as were it a secure entry-point. For
both things to work, the zone-KEY set must be selfsigned in the child
zonefile.
7.1. KEY bit in NXT records
RFC 2535 [3], section 5.2 states:
" The NXT RR type bit map format currently defined is one bit per
RR type present for the owner name. A one bit indicates that at
least one RR of that type is present for the owner name. A zero
indicates that no such RR is present. [....] "
As the zone KEY is present in a child zone, and signed by the
zone KEY (thus selfsigned), the definition of NXT RR type bit states
Gieben Expires September 2001 [Page 7]
Internet Draft Parent Stores Zone KEYS March 2001
in RFC 2535 [3], section 5.2 that the KEY bit must be set. We do not
see a compelling reason to change this default behavior.
7.2. Authority of KEY records
The parent of a zone generates the signature for the key belonging to
that zone. By making that signature available the parent publicly
states that the child zone is trustworthy: when it comes to security
in DNSSEC the parent is more authoritative than the child.
From this we conclude that a parent zone MUST set the authority bit
to 1 and child zones MUST set this bit to 0 when dealing with KEYs
from that child zone.This also causes resolvers to pick up and cache
the right KEY set, in case it finds conflicting KEY sets during a
key-rollover.
Some zones have no parent to make it authoritatively secure, for
instance, the root. To be secure anyway it must be defined a secure
entry point. If a resolver knows that a secure entry point is a
secure entry point it must have its key preconfigured. There is no
need for a parent in this scenario, because the resolver itself can
check the security of that zone. A interesting consequence of this is
that nobody is authoritative for a key belonging to a secure entry
point. This authority must established via some out of band
mechanism, like publishing it in a newspaper.
7.3. Selecting KEY sets
As the zone KEY set is present in two places, there may be a
possibility to find conflicting KEY sets, and this will at least
really happen during a key-rollover.
With one exception, a resolver MUST always select the KEY set from
the parent in case of a conflict, as this is the active KEY set. For
this reason, the parent sets the AA-bit on requests, while the child
does not.
The one exception is when a resolver regards the child's zone as a
secure-entry point, in which case it has the zone KEY preconfigured.
In other words: a preconfigured KEY has even more authority then what
a parent says. Specifying a zone as a secure entry-point makes sense
for a local resolver in its own local zone.
8. The zone KEY and local KEY records.
It must be recognized that the zone KEY RR, which is signed by a
non-local organisation, is something special. The external signature
over the public part of the key provides the local zone-administrator
with the authority to use the corresponding private part to sign
everything local, and thus to make his/her own zone secure. Please
also note that the external signer, and NOT the local zone is
authoritative for the zone KEY RRset.
Gieben Expires September 2001 [Page 8]
Internet Draft Parent Stores Zone KEYS March 2001
Part of the RRs that the zone-administrator may wish to sign are KEY
RRs for local use, for instance for IPSEC.
To make sure, that the local zone is authoritative for its own local
KEY RRs, and that they get not exported and signed externally, these
local KEY records SHOULD not be part of the zone KEY RRset.
Therefore, they SHOULD be placed under a label in the zonefile, f.i.
keys.child.parent.
Besides being kept clear of local KEY records, the zone KEY RRset
SHOULD also be kept clear of any other obsolete or otherwise not
strictly needed KEY records, because this increases the number of
possible key compromise attacks and also increases the size of the
parents zone file unnecessarily.
In other words: the KEY RRset with the toplevel label of a zone
SHOULD only contain its active zone KEY, unless a key-rollover is in
progress. During a keyrollover a new KEY RR must be added to this
RRset. Once the new KEY becomes the active zone KEY, the old KEY
becomes obsolete and SHOULD be removed as soon as practically
possible.
9. Security Considerations
This document addresses the operational difficulties that arise if
DNSSEC is deployed as it stands now, with the child's zone KEY not
stored at the parent. By putting that key in the parent's zone the
communication between the two is kept to a minimum thus reducing the
risk of errors. All security considerations from RFC 2535 apply.
Authors' Addresses
R. Gieben T. Lindgreen
Stichting NLnet Labs Stichting NLnet Labs
Kruislaan 419 Kruislaan 419
1098 VA Amsterdam 1098 VA Amsterdam
miek@nlnetlabs.nl ted@nlnetlabs.nl
References
[1] Lewis, E. "DNS Security Extension Clarification on Zone
Status", RFC 3090
www.ietf.org/rfc/rfc3090.txt
[2] Bradner, S. "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119
www.ietf.org/rfc/rfc2119.txt
[3] Eastlake, D. "DNS Security Extensions", RFC 2535
www.ietf.org/rfc/rfc2535.txt
[4] Andrews, M., Eastlake, D. "Domain Name System (DNS) Security
Gieben Expires September 2001 [Page 9]
Internet Draft Parent Stores Zone KEYS March 2001
Key Rollover"
www.ietf.org/internet-drafts/draft-ietf-dnsop-rollover-01.txt
[5] Gieben, R. "Chain of trust"
secnl.nlnetlabs.nl/thesis/thesis.html
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise explain
it 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.