draft-ietf-dnssec-simple-update-00.txt   draft-ietf-dnssec-simple-update-01.txt 
DNSSEC Working Group Brian Wellington (TISLabs) DNSSEC Working Group Brian Wellington (TISLabs)
<draft-ietf-dnssec-simple-update-00.txt> <draft-ietf-dnssec-simple-update-01.txt>
Updates: RFC 2065, RFC 2136, [TSIG] Updates: RFC 2065, RFC 2136, [TSIG]
Replaces: RFC 2137, [update2] Replaces: RFC 2137, [update2]
Simple Secure Domain Name System (DNS) Dynamic Update Simple Secure Domain Name System (DNS) Dynamic Update
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, all provisions of Section 10 of RFC2026.
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. 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 are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To view the entire list of current Internet-Drafts, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific The list of Internet-Draft Shadow Directories can be accessed at
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). http://www.ietf.org/shadow.html
Abstract Abstract
This draft proposes an alternative method for performing secure This draft proposes an alternative method for performing secure
Domain Name System (DNS) dynamic updates. The method described here Domain Name System (DNS) dynamic updates. The method described here
is both simple and flexible enough to represent any policy decisions. is both simple and flexible enough to represent any policy decisions.
Secure communication based on request/transaction signatures [TSIG] Secure communication based on request/transaction signatures [TSIG]
is used to provide authentication and authorization. is used to provide authentication and authorization.
1 - Introduction 1 - Introduction
skipping to change at page 3, line 4 skipping to change at page 2, line 41
Keyed hashes are simple to calculate and verify, and do not require Keyed hashes are simple to calculate and verify, and do not require
caching of data. caching of data.
2 - Authentication 2 - Authentication
TSIG records are attached to all secure dynamic update messages. This TSIG records are attached to all secure dynamic update messages. This
allows the server to verifiably determine the originator of the message. allows the server to verifiably determine the originator of the message.
It can then use this information in the decision of whether to accept 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, the update. DNSSEC SIG records may be included in an update message,
but MAY NOT be used for authentication purposes in the update protocol. 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.
3 - Policy 3 - Policy
All policy is dictated by the server and is configurable by the zone All policy is dictated by the server and is configurable by the zone
administrator. The server's policy defines criteria which determine if administrator. The server's policy defines criteria which determine if
the key used to sign the update is permitted to update the records 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 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 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 this process is implemented in the server and not the protocol (as in
[RFC2137, update2], where the signatory bits of KEY records define the [RFC2137, update2], where the signatory bits of KEY records may define
policy). the policy).
3.1 - Flexibility 3.1 - Flexibility
Storing policy in the signatory fields of DNS keys is overly Storing policy in the signatory fields of DNS keys is overly
restrictive. Only a fixed number of bits are present, which means that restrictive. Only a fixed number of bits are present, which means that
only a fixed number of policy decisions are representable. There are only a fixed number of policy decisions are representable. There are
many decisions that do not fit into the framework imposed by the many decisions that do not fit into the framework imposed by the
signatory field; a zone administrator cannot effectively impose a policy signatory field; a zone administrator cannot effectively impose a policy
not implemented in the draft defining the field. not implemented in the draft defining the field.
skipping to change at page 4, line 11 skipping to change at page 4, line 11
If a policy is changed, there are no changes made to the DNS protocol or 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 the data on the wire. This means that new policies can be defined at
any point without adverse effects or interoperability concerns. any point without adverse effects or interoperability concerns.
4 - Interaction with DNSSEC 4 - Interaction with DNSSEC
A successful update request may or may not include SIG records for each A successful update request may or may not include SIG records for each
RRset. Since SIG records are not used for authentication in this RRset. Since SIG records are not used for authentication in this
protocol, they are not required. If the updated zone is signed, the protocol, they are not required. If the updated zone is signed, the
server will generate SIG records for each incoming RRset with the Zone server will generate SIG records for each incoming RRset with the Zone
key (which MUST be online). If there are any DNSSEC SIG records key (which MUST be online). If there are any non-DNSSEC SIG records
present, they are dropped. If there are non-DNSSEC SIG records present, present, they are retained. If there are SIG records that have been
these are retained. In any case, SIG records associated with each RRset generated by the appropriate zone KEY, these SIGs are verified and
(that a resolver would use for verification) are generated by the Zone retained if the verification is successful. DNSSEC SIG records
key. The server will also generate a new SOA record and possibly new generated by other KEYs are dropped. The server will generate SIG
NXT records, and sign these with the Zone key. 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 5 - Security considerations
For a secure zone to support dynamic update, the Zone key MUST be online For a secure zone to support dynamic update, the Zone key MUST be online
(unlike [RFC2137]). The server MUST update the SOA record and MAY (unlike [RFC2137]). No additional protection is offered by having the
generate new NXT records (the client is forbidden from updating these Zone key offline and an Update key online, since compromising any key
records); a Zone key must be available with which to sign these. No that can sign the zone's data compromises the zone itself.
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 6 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
RFC 1034, ISI, November 1987. RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and [RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, ISI, November 1987. Specification,'' RFC 1035, ISI, November 1987.
[RFC2065] D. Eastlake, C. Kaufman, ``Domain Name System Security [RFC2065] D. Eastlake, C. Kaufman, ``Domain Name System Security
Extensions,'' RFC 2065, CyberCash & Iris, January 1997. Extensions,'' RFC 2065, CyberCash & Iris, January 1997.
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
& Cisco & DEC, April 1997. & Cisco & DEC, April 1997.
[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC [RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC
2137, CyberCash, April 1997. 2137, CyberCash, April 1997.
[secext2] D. Eastlake ``Domain Name System Security Extensions,'' [secext2] D. Eastlake ``Domain Name System Security Extensions,''
draft-ietf-dnssec-secext2-05.txt, CyberCash, April 1998. draft-ietf-dnssec-secext2-07.txt, IBM, December 1998.
[TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake ``Secret Key [TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington
Transaction Signatures for DNS (TSIG),'' draft-ietf-dnsind- ``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
tsig-06.txt, ISC & TIS & CyberCash, September 1998. ietf-dnsind-tsig-08.txt, ISC & TISLabs & IBM & TISLabs,
February 1999.
[update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic [update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic
Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite
Systems Company, August 1998. Systems Company, August 1998.
7 - Author's Address 7 - Author's Address
Brian Wellington Brian Wellington
TISLabs at Network Associates TISLabs at Network Associates
3060 Washington Road, Route 97 3060 Washington Road, Route 97
Glenwood, MD 21738 Glenwood, MD 21738
+1 301 854 6889 +1 443 259 2369
<bwelling@tis.com> <bwelling@tislabs.com>
 End of changes. 10 change blocks. 
28 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/