draft-ietf-dnsext-simple-secure-update-00.txt   draft-ietf-dnsext-simple-secure-update-01.txt 
DNSIND Working Group Brian Wellington (NAILabs) DNSIND Working Group Brian Wellington (NAILabs)
<draft-ietf-dnsext-simple-secure-update-00.txt> <draft-ietf-dnsext-simple-secure-update-01.txt>
Updates: RFC 2535, RFC 2136, Updates: RFC 2535, RFC 2136,
Replaces: RFC 2137, [update2] Replaces: RFC 2137, [update2]
Simple Secure Domain Name System (DNS) Dynamic Update Secure Domain Name System (DNS) Dynamic Update
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Comments should be sent to the authors or the DNSIND WG mailing list Comments should be sent to the authors or the DNSIND WG mailing list
namedroppers@internic.net. namedroppers@internic.net.
This draft expires on July 31, 2000. This draft expires on November 12, 2000.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All rights reserved. Copyright (C) The Internet Society (2000). All rights reserved.
Abstract Abstract
This document proposes a method for performing secure Domain Name This document proposes a method for performing secure Domain Name
System (DNS) dynamic updates. The method described here is intended System (DNS) dynamic updates. The method described here is intended
to be flexible and useful while requiring as few changes to the to be flexible and useful while requiring as few changes to the
skipping to change at page 3, line 7 skipping to change at page 3, line 7
responses sent between them. A TSIG MAC (message authentication code) responses sent between them. A TSIG MAC (message authentication code)
is derived from a shared secret, and a SIG(0) is generated from a is derived from a shared secret, and a SIG(0) is generated from a
private key whose public counterpart is stored in DNS. In both cases, a private key whose public counterpart is stored in DNS. In both cases, a
record containing the message signature/MAC is included as the final record containing the message signature/MAC is included as the final
resource record in a DNS message. Keyed hashes, used in TSIG, are resource record in a DNS message. Keyed hashes, used in TSIG, are
inexpensive to calculate and verify. Public key encryption, as used in inexpensive to calculate and verify. Public key encryption, as used in
SIG(0), is more scalable as the public keys are stored in DNS. SIG(0), is more scalable as the public keys are stored in DNS.
1.3 - Comparison of data authentication and message authentication 1.3 - Comparison of data authentication and message authentication
Message based authentication, using TSIG or SIG(0), provides protection
for the entire message with a single signing and single verification
which, in the case of TSIG, is a relatively inexpensive MAC creation and
check. For update requests, this signature can establish, based on
policy or key negotation, the authority to make the request.
DNSSEC SIG records can be used to protect the integrity of individual DNSSEC SIG records can be used to protect the integrity of individual
RRs or RRsets in an update message. However, this cannot sufficiently RRs or RRsets in a DNS message with the authority of the zone owner.
protect the dynamic update request. However, this cannot sufficiently protect the dynamic update request.
Using SIG records to secure RRsets in an update request is incompatible
with the design of update, as described below, and would in any case
require multiple expensive public key signatures and verifcations.
SIG records do not cover the message header, which includes record SIG records do not cover the message header, which includes record
counts. Therefore, it is possibly to maliciously insert or remove counts. Therefore, it is possibly to maliciously insert or remove
RRsets without causing a verification failure. RRsets in an update request without causing a verification failure.
A SIG record can be used to protect the contents of the zone section (an
SOA record). Including such a SIG record in the zone section violates
the dynamic update protocol.
If SIG records were used to protect the prerequisite section, it would If SIG records were used to protect the prerequisite section, it would
be impossible to determine whether the SIGs themselves were a be impossible to determine whether the SIGs themselves were a
prerequisite or simply used for validation. prerequisite or simply used for validation.
In the update section, signing requests to add an RRset is In the update section of an update request, signing requests to add an
straightforward, and this signature could be permanently used to protect RRset is straightforward, and this signature could be permanently used
the data, as specified in [RFC2535]. However, if an RRset is deleted, to protect the data, as specified in [RFC2535]. However, if an RRset is
there is no data for a SIG to cover. deleted, there is no data for a SIG to cover.
Requiring SIGs in the zone, prerequisite, and update sections might be a
feasible solution. Multiple signatures would be generated and verified
for each update, though, which requires considerable processing time.
Message based authentication, using TSIG or SIG(0), avoids all of these
problems. Only one signature/MAC is generated for the entire message,
and it protects the integrity of the message header and all sections, as
well as having the advantage that only one verification is performed.
1.4 - Data and message signatures 1.4 - Data and message signatures
As specified in [signing-auth], the DNSSEC validation process performed As specified in [signing-auth], the DNSSEC validation process performed
by a resolver MUST NOT process any non-zone keys unless local policy by a resolver MUST NOT process any non-zone keys unless local policy
dictates otherwise. When performing secure dynamic update, all zone dictates otherwise. When performing secure dynamic update, all zone
data modified in a signed zone MUST be signed by a relevant zone key. data modified in a signed zone MUST be signed by a relevant zone key.
This completely disassociates authentication of an update request from This completely disassociates authentication of an update request from
authentication of the data itself. authentication of the data itself.
skipping to change at page 8, line 7 skipping to change at page 7, line 50
& 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.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC [RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC
2065, IBM, March 1999. 2065, IBM, March 1999.
[TSIG] P. Vixie (Ed.), O. Gudmundsson, D. Eastlake, B. Wellington [TSIG] P. Vixie (Ed.), O. Gudmundsson, D. Eastlake, B. Wellington
``Secret Key Transaction Signatures for DNS (TSIG),'' draft- ``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
ietf-dnsind-tsig-13.txt, ISC & NAILabs & IBM & NAILabs, ietf-dnsext-tsig-00.txt, ISC & NAILabs & IBM & NAILabs, March
December 1999. 2000.
[TKEY] D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),'' [TKEY] D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),''
draft-ietf-dnsind-tkey-03.txt, IBM, December 1999. draft-ietf-dnsext-tkey-02.txt, IBM, April 2000.
[signing-auth] [signing-auth]
B. Wellington ``Domain Name System Security (DNSSEC) Signing B. Wellington ``Domain Name System Security (DNSSEC) Signing
Authority,'' draft-ietf-dnsext-signing-auth-00.txt, NAILabs, Authority,'' draft-ietf-dnsext-signing-auth-01.txt, Nominum,
January 2000. May 2000.
8 - Author's Address 8 - Author's Address
Brian Wellington Brian Wellington
NAILabs Nominum, Inc.
Network Associates 950 Charter Street
3060 Washington Road (Rt. 97) Redwood City, CA 94063
Glenwood, MD 21738 +1 650 779 6022
+1 443 259 2369 <Brian.Wellington@nominum.com>
<bwelling@tislabs.com>
9 - Full Copyright Statement 9 - Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/