ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

update

Browse Source
This commit is contained in:
Bob Halley
1999-05-12 23:54:09 +00:00
parent 6112b0e8fa
commit 651441f5f6
3 changed files with 0 additions and 1263 deletions
Download Patch File Download Diff File Expand all files Collapse all files

464
doc/draft/draft-ietf-dnssec-indirect-key-01.txt
View File

@@ -1,464 +0,0 @@
INTERNET-DRAFT Indirect KEY RRs
November 1997
Expires May 1998
Indirect KEY RRs in the Domain Name System
-------- --- --- -- --- ------ ---- ------
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnssec-indirect-key-01.txt, is
intended to be become a Proposed Standard RFC. Distribution of this
document is unlimited. Comments should be sent to the DNSSEC mailing
list <dns-security@tis.com> or to the author.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (East USA), ftp.isi.edu (West USA),
nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).
Abstract
RFC 2065 defines a means for storing cryptogrpahic public keys in the
Domain Name System. An additional code point is defined for the KEY
resource record (RR) algorithm field to indicate that the key itself
is not stored in the KEY RR but is pointed to by the KEY RR.
Encodings to indicate different types of key and pointer formats are
specified.
Donald E. Eastlake 3rd [Page 1]
INTERNET-DRAFT Indirect KEY RRs
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. The Indirect KEY RR Algorithm...........................4
2.1 The Target Type Field..................................4
2.2 The Target Algorithm Field.............................5
2.3 The Hash Fields........................................5
3. Performance Considerations..............................7
4. Security Considerations.................................7
References.................................................8
Author's Address...........................................8
Expiration and File Name...................................8
Donald E. Eastlake 3rd [Page 2]
INTERNET-DRAFT Indirect KEY RRs
1. Introduction
The Domain Name System (DNS) security extensions [RFC 2065] provide
for the general storage of public keys in the domain name system via
the KEY resource record (RR). These KEY RRs are used in support of
DNS security and may be used to support other security protocols.
KEY RRs can be associated with users, zones, and hosts or other end
entities named in the DNS.
For reasons given below, in many cases it will be desireable to store
a key or keys elsewhere and merely point to it from the KEY RR.
Indirect key storage makes it possible to point to a key service via
a URL, to have a compact pointer to a larger key or set of keys, to
point to a certificate either inside DNS [see draft-ietf-dnssec-
certs-*.txt] or outside the DNS, and where appropriate, to store a
key or key set applicable to many DNS entries in some place and point
to it from those entries.
However, to simplify DNSSEC implementation, this technique MUST NOT
be used for KEY RRs used in for verification in DNSSEC.
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT Indirect KEY RRs
2. The Indirect KEY RR Algorithm
Domain Name System (DNS) KEY Resource Record (RR) [RFC 2065]
algorithm number 252 is defined as the indirect key algorithm. This
algorithm MAY NOT be used for zone keys in support of DNS security.
All KEYs used in DNSSEC validation must be stored directly in the
DNS.
When the algorithm byte of a KEY RR has thae value 252, the "public
key" portion of the RR is formated as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| target type | target alg. | hash type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash size | hash (variable size) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
| /
/ pointer (varible size) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
2.1 The Target Type Field
Target type specifies the type of the key containing data being
pointed at.
Target types 0 and 65535 are reserved.
Target type 1 indicates that the pointer is a domain name from which
KEY RRs [RFC 2065] should be retrieved. Name compression in the
pointer field is prohibited.
Target type 2 indicates that the pointer is a null terminated
character string which is a URL [RFC 1738]. For exisiting data
transfer URL schemes, such as ftp, http, shttp, etc., the data is the
same as the public key portion of a KEY RR. (New URL schmes may be
defined which return multiple keys.)
Target type 2 indicates that the pointer is a domain name from which
CERT RRs [draft-ietf-dnssec-certs-*.txt] should be retrieved. Name
compression in the pointer field is prohibiited.
Target type 3 indicates that the pointer is a null terminated
character string which is a URL [RFC 1738]. For exisiting data
transfer URL schemes, such as ftp, http, shttp, etc., the data is the
same as the entire RDATA portion of a CERT RR [draft-ietf-dnssec-
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT Indirect KEY RRs
certs-*.txt]. (New URL schmes may be defined which return multiple
such data blocks.)
Target type 4 indicates that the pointer is a null terminated
character string which is a URL [RFC 1738]. For exisiting data
transfer URL schemes, such as ftp, http, shttp, etc., the data is a
PKCS#1 format key. (New URL schmes may be defined which return
multiple keys.)
The target types 5 through 255 are available for assignment by IANA.
Target type 256 through 511 (i.e., 256 + n) indicate that the pointer
is a null terminated character string which is a URL [RFC 1738]. For
exisiting data transfer URL schemes, such as ftp, http, shttp, etc.,
the data is a certificate of the type indicated by a CERT RR [draft-
ietf-dnssec-certs-*.txt] certificate type of n. That is, target
types 257, 258, and 259 are PKIX, SPKI, and PGP certificates and
target types 509 and 510 are URL and OID private certificate types.
(New URL schmes may be defined which return multiple such
certificates.)
Target types 512 through 65534 are available for assignment by IANA.
2.2 The Target Algorithm Field
The algorithm field is as defined in RFC 2065. if non-zero, it
specifies the algorithm type of the target key or keys pointed. If
zero, it does not specify what algorithm the target key or keys apply
to.
2.3 The Hash Fields
If the indirecting KEY RR is retrieved from an appropriately secure
DNS zone with a resolver implementing DNS security, then there would
be a high level of confidence in the entire value of the KEY RR
including any direct keys. This may or may not be true of any
indirect key pointed to. If that key is embodied in a certificate or
retrieved via a secure protocol such as SHTTP, it may also be secure.
But an indirecting KEY RR could, for example, simply have an FTP URL
pointing to a binary key stored elsewhere, the retrieval of which
would not be secure.
The hash option in algorithm 252 KEY RRs provides a means of
extending the security of the indirecting KEY RR to the actual key
material pointed at. By inclduing a hash in a secure indirecting RR,
this secure hash can be checked against the hash of the actual keying
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT Indirect KEY RRs
material
Type Hash Algorithm
---- --------------
0 indicates no hash present
1 MD5 [RFC 1321]
2 SHA-1
3 RIPEMD
4-254 available for assignment
255 reserved
The hash size field is an unsigned octet count of the hash size. For
some hash algorithms it may be fixed by the algorithm choice but this
will not always be the case. For example, hash size is used to
distinguish between RIPEMD-128 (16 octets) and RIPEMD-160 (20
octets). If the hash algorithm is 0, the hash size MUST be zero and
no hash octets are present.
The hash field itself is variable size with its length specified by
the hash size field.
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT Indirect KEY RRs
3. Performance Considerations
With current public key technology, an indirect key will sometimes be
shorter than the keying material it points at. This may improve DNS
permformace in the retrieval of the initial KEY RR. However, an
additional retrieval step then needs to be done to get the actualy
keying material which must be added to the overall time to get the
public key.
4. Security Considerations
The indirecting step of using an indirect KEY RR adds complexity and
additional steps where security could go wrong. If the indirect key
RR was retrieved from a zone that was insecure for the resolver, you
have no security. If the indirect key RR, although secure itself,
point to a key which can not be securely retrieved and is not
validatated by a secure hash in the indirect key RR, you have no
security.
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT Indirect KEY RRs
References
PKCS#1
RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities",
STD 13, November 1987.
RFC 1035 - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987.
RFC 1321 - R. Rivest, "The MD5 Message-Digest Algorithm", April 1992.
RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform
Resource Locators (URL)", December 1994.
RFC 2065 - D. Eastlake, C. Kaufman, "Domain Name System Security
Extensions", 01/03/1997.
draft-ietf-dnssec-certs-*.txt
Author's Address
Donald E. Eastlake 3rd
CyberCash, Inc.
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 978 287 4877
+1 703 620-4200 (main office, Reston, VA)
FAX: +1 978 371 7148
EMail: dee@cybercash.com
Expiration and File Name
This draft expires May 1998.
Its file name is draft-ietf-dnssec-indirect-key-01.txt.
Donald E. Eastlake 3rd [Page 8]

521
doc/draft/draft-ietf-dnssec-rollover-00.txt
View File

@@ -1,521 +0,0 @@
INTERNET-DRAFT DNSSEC Key Rollover
October 1998
Expires April 1999
Domain Name System (DNS) Security Key Rollover
------ ---- ------ ----- -------- --- --------
Donald E. Eastlake 3rd, Mark Andrews
Status of This Document
This draft, file name draft-ietf-dnssec-rollover-00.txt, is intended
to be become a Proposed Standard RFC. Distribution of this document
is unlimited. Comments should be sent to the DNS security mailing
list <dns-security@tis.com> or to the authors.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
Practical deployment of Domain Name System (DNS) security with good
cryptologic practice will involve large volumes of key rollover
traffic. A standard format and protocol for such messages is
specified.
D. Eastlake 3rd, M. Andrews [Page 1]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. Key Rollover Scenarios..................................3
3. Rollover Operation......................................4
3.1 Rollover to Parent.....................................4
3.2 Rollover to Children...................................5
4. Rollover NOTIFY.........................................6
5. Security Considerations.................................7
References.................................................8
Authors Address............................................8
Expiration and File Name...................................9
D. Eastlake 3rd, M. Andrews [Page 2]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
1. Introduction
The Domain Name System (DNS) [RFC 1034, RFC 1035] is the global
hierarchical replicated distributed database system for Internet
addressing, mail proxy, and other information. The DNS has been
extended to include digital signatures and cryptographic keys as
described in [draft-ietf-dnssec-secext2-*].
The principle security service provided for DNS data is data origin
authentication. The owner of each zone signs the data in that zone
with a private key known only to the zone owner. Anyone that knows
the corresponding public key can then authenticate that zone data is
from the zone owner. To avoid having to preconfigure resolvers with
all zone's public keys, keys are stored in the DNS with each zone's
key signed by its parent (if the parent is secure).
To obtain high levels of security, keys must be periodically changed,
or "rolled over". The longer a private key is used, the more likely
it is to be compromised due to cryptanalysis, accident, or treachery
[draft-ietf-dnssec-secops-*.txt].
In a widely deployed DNS security system, the volume of update
traffic will be large. Just consider the .com zone. If only 10% of
its children are secure and change their keys only once a year, you
are talking about hundreds of thousands of new child public keys that
must be securely sent to the .com manager to sign and return with
their new parent signature. And when .com rolls over its private
key, it will needs to send hundreds of thousands of new signatures on
the existing child public keys to the child zones.
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in RFC 2119.
2. Key Rollover Scenarios
Although DNSSEC provides for the storage of other keys in the DNS for
a variety of purposes, DNSSEC zone keys are included solely for the
purpose of being retrieved to authenticate DNSSEC signatures. Thus,
when a zone key is being rolled over, the old public key should be
left in the zone, along with the addition of the new public key, for
as long as it will reasonably be needed to authenticate old
signatures that have been cached or are held by applications. If
DNSSEC were universally deployed and all DNS server's clocks were
synchronized and zone transfers were instantaneous etc., it might be
possible to avoid ever having duplicate old/new KEY RRsets but they
will be necessary in practical cases. Security aware DNS servers
decrease the TTL of secure RRs served as the expiration of their
authenticating SIG(s) approaches but some dithered fudge must
D. Eastlake 3rd, M. Andrews [Page 3]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
generally be left due to clock skew and to avoid massive load on
large zones due to the signatures on their entire contents expiring
simultaneously.
Assume a zone with a secure parent and secure children wishes to role
over its KEY RRset. This RRset would probably be one KEY RR per
crypto algorithm used to secure the zone, but for this scenario, we
will simply assume it is one KEY RR. The old KEY RR and two SIG RRs
will exist at the apex of the zone and these RRs may also exist at
the leaf node for this zone in its parent. The contents of the zone
and the zone KEY RRs of its secure children will have SIGs under the
old key.
The zone owner needs to communicate with its parent to obtain a new
parental signature covering both the old and new KEY RRs and covering
just the new KEY RR. It would probably want to obtain these in
advance so that it can install them at the right time along with its
new SIG RRs covering the content of the zone. Finally, it needs to
give new SIG RRs to its children that cover their KEY RRs if it has
these, or signal its children to ask for such SIG RRs.
3. Rollover Operation
Rollover operations use a DNS request syntactically identical to the
UPDATE request [RFC 2136] except that the operation is ROLLOVER which
is equal to TBD. Considerations for such request to the parent and
children of a zone are given in the subsections.
[This draft does not currently consider cross-certification key
rollover.]
3.1 Rollover to Parent
A zone rolling over its KEY RRset sends a ROLLOVER command to the
parent. The Zone should be specified as the parent zone and no
Prerequisites are included. The Update section has the KEY RRset on
which the parent signature is requested along with the requesting
zone's SIG(s) under its old KEY(s) as RRs to be added to the parent
zone. The inception and expiration times in this SIG are the
requested inception and expiration times for the parent SIG.
If the ROLLOVER command is erroneous or violates parental policy, an
Error response is returned.
If the ROLLOVER command is OK and the parent can sign online, its
response may include the new parent SIG(s) in the Update section.
D. Eastlake 3rd, M. Andrews [Page 4]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
This response MUST be sent to the originator of the request.
If the parent can not sign online, it should return a response with
an empty Update section and queue the SIG(s) calculation request.
This response MUST be sent to the originator of the request.
Regardless of whether the server has sent the new signatures above,
it MUST, once it has calculated the new SIG(s), send a ROLLOVER to
the child zone using the DNS port (53) and the server selection
algorithm defined in RFC 2136, Section 4. This ROLLOVER reqeust
contains the KEY RRset that triggered it and the new SIG(s). This
downward ROLLOVER request is distinguished from those in Section 3.2
below in that the Zone section is the parental zone.
The reason for sending the ROLLOVER request regardless of whether the
new SIG RR(s) were sent in the original response is to provide an
indication to the operators of the zone in the event someone is
trying to hijack the zone.
Although the parent zone need not hold or serve the child's key, the
ROLLOVER command MUST NOT actually update the parent zone. A later
UPDATE command can be used to actually put the new KEY into the
parent zone if desired and supported by parent policy.
This document does not cover the question of parental policy on key
rollovers. Parents may have restrictions on how far into the future
they will sign KEY RRsets, what algorithms or key lengths they will
support, might require payment for the service, etc. The signing of
a future KEY by a parent is, to some extent a granting to the
controller of the child private key of future authoritative existence
even if the child zone ownership should change. The only effective
way of invalidating such future signed child public keys would be for
the parent to roll over its key(s), which might be an expensive
operation.
3.2 Rollover to Children
When a zone is going to rollover its key(s), it needs to re-sign the
zone keys of any secure children under its new key(s).
If the parent holds the KEY RRset for the child (whether or not it
actually serves it from the parent zone), it can simply do a ROLLOVER
request to to child specifying the child as the Zone in the request
and the new SIG(KEY)s to be added in the Update section. The
inception and expiration times in the SIG(s) indicate the time during
which the parent will be utilizing the new parent key. It is up to
the child when and how it adds the new parental SIG(s). The ROLLOVER
request may optionally indicate the deletion of old parental SIG(s)
D. Eastlake 3rd, M. Andrews [Page 5]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
but SHOULD only do so if the corresponding key is being withdrawn by
the parent in advance of the expiration time in the old SIG(s). It
is up to the child when and how it deletes the old parental SIG(s).
Even if the expiration of the old SIG(s) equals the inception time of
the new SIG(s), the child should serve both signatures for a fudge
time to account for clock skew.
A ROLLOVER request is used instead of an UPDATE because serves may
wish to support ROLLOVER via special techniques, such as notification
to the operator, even when they have not implemented UPDATE. With
adequate advance notice, even manual cut and paste editing of the
master file and restarting of a DNS server process could work.
If the parent does not retain knowledge of the child KEY RRset, then
the parent simply notifies the child via a ROLLOVER NOTIFY (see
Section 4 below) that the parent KEY(s) have changed. The child then
proceeds to do an upward ROLLOVER request to obtain the new parental
SIG(s). (This requires that a different method, such as TSIG, be
used to secure such ROLLOVER requests since we are assuming the
parent does not have authoritative knowledge of the child public key.
See Section 5 below.)
The NOTIFY technique MAY also be used by parents who retain knowledge
of their children's KEY RRsets.
4. Rollover NOTIFY
A ROLLOVER NOTIFY informs a child zone that the parent zone want it
to resubmit its keys for resigning.
A ROLLOVER NOTIFY MUST be signed and if not signed a BADAUTH response
generated.
A ROLLOVER NOTIFY is a NOTIFY reqeust [RFC 1996] that has a QTYPE of
SIG and the owner name of the child zone. The answer section is
empty.
The ROLLOVER NOTIFY can be sent to any of the nameservers for the
child using the nameserver selection algorithm defined in RFC 2136,
Section 4.
Nameservers for the child zone receiving a ROLLOVER NOTIFY query will
forward the ROLLOVER NOTIFY in the saem manner as an UPDATE is
forwarded.
Unless the master server is configured to initiate an automatic
ROLLOVER it MUST seek to inform its operators that a ROLLOVER NOTIFY
request has been received. This could be done by a number of methods
D. Eastlake 3rd, M. Andrews [Page 6]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
including generating a log message, generating an email request to
the child zone's SOA RNAME or any other method defined in the
server's configuration for the zone. The default should be to send
mail to the zone's SOA RNAME. Care should be taken to rate limit
these message so prevent them being used to facilitate a denial of
service attack.
Once the message has been sent (or suppressed) to the child zone's
administrator the master server for the child zone is free to respond
to the ROLLOVER NOTIFY request.
5. Security Considerations
The security of ROLLOVER or UPDATE requests is essential, otherwise
false children could steal parental authorization or a false parent
could cause a child to install an invalid signature on its zone key,
etc.
A ROLLOVER request can be authentication by request SIG(s)under the
old zone KEY(s) of the requestor [draft-ietf-dnssec-secext2-*.txt].
The response SHOULD have transaction SIG(s) under the old zone KEY(s)
of the responder. (This public key security could be used to
rollover a zone to the unsecured state but at that point it would
generally not be possible to roll back without manual intervention.)
Alternatively, if there is a prior arrangement between a child and a
parent, ROLLOVER requests and responses can be secured and
authenticated using TSIG [draft-ietf-dnssec-tsig-*.txt]. (TSIG
security could be used to rollover a zone to unsecured and to
rollover an unsecured zone to the secured state.)
A server that implements online signing SHOULD have the ability to
black list a zone and force manual processing or demand that a
particular signature be used to generate the ROLLOVER request. This
it to allow ROLLOVER to be used even after a private key has been
compromised.
D. Eastlake 3rd, M. Andrews [Page 7]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
References
[RFC 1034] - P. Mockapetris, "Domain names - concepts and
facilities", 11/01/1987.
[RFC 1035] - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987.
[RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", August 1996.
[RFC 2136] - Dynamic Updates in the Domain Name System (DNS UPDATE).
P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997.
[draft-ietf-dnsind-tsig-*.txt]
[draft-ietf-dnssec-update2-*.txt]
[draft-ietf-dnssec-secext2-*.txt]
[draft-ietf-dnssec-secops-*.txt]
Authors Address
Donald E. Eastlake 3rd
IBM
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 978-287-4877
+1 914-784-7913
FAX: +1 978-371-7148
EMail: dee3@us.ibm.com
Mark Andrews
Internet Software Consortium
1 Seymour Street
Dundas Valley, NSW 2117
AUSTRALIA
Telephone: +61-2-9871-4742
Email: marka@isc.org
D. Eastlake 3rd, M. Andrews [Page 8]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
Expiration and File Name
This draft expires in April 1999.
Its file name is draft-ietf-dnssec-rollover-00.txt.
D. Eastlake 3rd, M. Andrews [Page 9]

278
doc/draft/draft-ietf-dnssec-simple-update-01.txt
View File

@@ -1,278 +0,0 @@
DNSSEC Working Group Brian Wellington (TISLabs)
INTERNET-DRAFT February 1999
<draft-ietf-dnssec-simple-update-01.txt>
Updates: RFC 2065, RFC 2136, [TSIG]
Replaces: RFC 2137, [update2]
Simple Secure Domain Name System (DNS) Dynamic Update
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This draft proposes an alternative method for performing secure
Domain Name System (DNS) dynamic updates. The method described here
is both simple and flexible enough to represent any policy decisions.
Secure communication based on request/transaction signatures [TSIG]
is used to provide authentication and authorization.
Expires August 1999 [Page 1]
INTERNET-DRAFT Simple Secure Dynamic Update February 1999
1 - Introduction
Dynamic update operations for the Domain Name System are defined in
[RFC2136], but no mechanisms for security have been defined. Request
and transaction signatures are defined in [TSIG].
Familiarity with the DNS system [RFC1034, RFC1035] as well as the
proposals mentioned above is assumed. Familiarity with DNS Security
[RFC2065, secext2] is assumed in section (4).
1.1 - Overview of DNS Dynamic Update
DNS dynamic update defines a new DNS opcode and a new interpretation of
the DNS message if that opcode is used. An update can specify
insertions or deletions of data, along with prerequisites necessary for
the updates to occur. All tests and changes for a DNS update request
are restricted to a single zone, and are performed at the primary server
for the zone. The primary server for a dynamic zone must increment the
zone SOA serial number when an update occurs or before the next
retrieval of the SOA.
1.2 - Overview of DNS Transaction Security
[TSIG] provides a means for two processes that share a secret key to
authenticate DNS requests and responses sent between them. This is done
by appending TSIG digital signature (keyed hash) RRs to those messages.
Keyed hashes are simple to calculate and verify, and do not require
caching of data.
2 - Authentication
TSIG records are attached to all secure dynamic update messages. This
allows the server to verifiably determine the originator of the message.
It can then use this information in the decision of whether to accept
the update. DNSSEC SIG records may be included in an update message,
but MAY NOT be used for authentication purposes in the update protocol.
If a message fails the authentication test due to an unauthorized key,
the failure is indicated with the REFUSED rcode. Other TSIG or dynamic
update errors are returned unchanged.
Expires August 1999 [Page 2]
INTERNET-DRAFT Simple Secure Dynamic Update February 1999
3 - Policy
All policy is dictated by the server and is configurable by the zone
administrator. The server's policy defines criteria which determine if
the key used to sign the update is permitted to update the records
requested. By default, a key cannot make any changes to the zone; the
key's scope must be explicitly enabled. There are several reasons that
this process is implemented in the server and not the protocol (as in
[RFC2137, update2], where the signatory bits of KEY records may define
the policy).
3.1 - Flexibility
Storing policy in the signatory fields of DNS keys is overly
restrictive. Only a fixed number of bits are present, which means that
only a fixed number of policy decisions are representable. There are
many decisions that do not fit into the framework imposed by the
signatory field; a zone administrator cannot effectively impose a policy
not implemented in the draft defining the field.
There may be any number of policies applied in the process of
authorization, and there are no restrictions on the scope of these
policies. Implementation of the policies is beyond the scope of this
document.
3.2 - Simplicity
Policy decisions in the server could be used as an adjunct to policy
fields in the KEY records. This could lead to confusion if the policies
are inconsistent. Furthermore, since there is no need to expose
policies, a central configuration point is more logical.
3.3 - Extendibility
If a policy is changed, there are no changes made to the DNS protocol or
the data on the wire. This means that new policies can be defined at
any point without adverse effects or interoperability concerns.
Expires August 1999 [Page 3]
INTERNET-DRAFT Simple Secure Dynamic Update February 1999
4 - Interaction with DNSSEC
A successful update request may or may not include SIG records for each
RRset. Since SIG records are not used for authentication in this
protocol, they are not required. If the updated zone is signed, the
server will generate SIG records for each incoming RRset with the Zone
key (which MUST be online). If there are any non-DNSSEC SIG records
present, they are retained. If there are SIG records that have been
generated by the appropriate zone KEY, these SIGs are verified and
retained if the verification is successful. DNSSEC SIG records
generated by other KEYs are dropped. The server will generate SIG
records for each set with the Zone key, unless one has already been
verified. The server will also generate a new SOA record and possibly
new NXT records, and sign these with the Zone key.
The server MUST update the SOA record and MAY generate new NXT records
when an update is received. Unlike traditional dynamic update, the
client is forbidden from updating SOA 1 NXT records.
5 - Security considerations
For a secure zone to support dynamic update, the Zone key MUST be online
(unlike [RFC2137]). No additional protection is offered by having the
Zone key offline and an Update key online, since compromising any key
that can sign the zone's data compromises the zone itself.
6 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, ISI, November 1987.
[RFC2065] D. Eastlake, C. Kaufman, ``Domain Name System Security
Extensions,'' RFC 2065, CyberCash & Iris, January 1997.
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
& Cisco & DEC, April 1997.
[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC
2137, CyberCash, April 1997.
[secext2] D. Eastlake ``Domain Name System Security Extensions,''
draft-ietf-dnssec-secext2-07.txt, IBM, December 1998.
Expires August 1999 [Page 4]
INTERNET-DRAFT Simple Secure Dynamic Update February 1999
[TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington
``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
ietf-dnsind-tsig-08.txt, ISC & TISLabs & IBM & TISLabs,
February 1999.
[update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic
Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite
Systems Company, August 1998.
7 - Author's Address
Brian Wellington
TISLabs at Network Associates
3060 Washington Road, Route 97
Glenwood, MD 21738
+1 443 259 2369
<bwelling@tislabs.com>
Expires August 1999 [Page 5]