446 lines
17 KiB
Plaintext
446 lines
17 KiB
Plaintext
DNSIND Working Group Brian Wellington (NAILabs)
|
||
INTERNET-DRAFT May 2000
|
||
|
||
<draft-ietf-dnsext-simple-secure-update-01.txt>
|
||
|
||
Updates: RFC 2535, RFC 2136,
|
||
Replaces: RFC 2137, [update2]
|
||
|
||
|
||
|
||
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
|
||
|
||
Comments should be sent to the authors or the DNSIND WG mailing list
|
||
namedroppers@internic.net.
|
||
|
||
This draft expires on November 12, 2000.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2000). All rights reserved.
|
||
|
||
|
||
Abstract
|
||
|
||
This document proposes a method for performing secure Domain Name
|
||
System (DNS) dynamic updates. The method described here is intended
|
||
|
||
|
||
|
||
Expires November 2000 [Page 1]
|
||
|
||
INTERNET-DRAFT Secure Dynamic Update May 2000
|
||
|
||
|
||
to be flexible and useful while requiring as few changes to the
|
||
protocol as possible. The authentication of the dynamic update
|
||
message is separate from later DNSSEC validation of the data. Secure
|
||
communication based on authenticated requests and transactions is
|
||
used to provide authorization.
|
||
|
||
|
||
1 - Introduction
|
||
|
||
This document defines a means to secure dynamic updates of the Domain
|
||
Name System (DNS), allowing only authorized sources to make changes to a
|
||
zone's contents. The existing unsecured dynamic update operations form
|
||
the basis for this work.
|
||
|
||
Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update
|
||
[RFC2136] is helpful and is assumed by this document. In addition,
|
||
knowledge of DNS security extensions [RFC2535], SIG(0) transaction
|
||
security [RFC2535], and TSIG transaction security [TSIG] is recommended.
|
||
|
||
This document updates portions of RFC 2535, in particular section 3.1.2.
|
||
This document obsoletes RFC 2137, an alternate proposal for secure
|
||
dynamic update, due to implementation experience.
|
||
|
||
|
||
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
|
||
|
||
Exchanges of DNS messages which include TSIG [TSIG] or SIG(0) [RFC2535]
|
||
records allow two DNS entities to authenticate DNS requests and
|
||
responses sent between them. A TSIG MAC (message authentication code)
|
||
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
|
||
record containing the message signature/MAC is included as the final
|
||
resource record in a DNS message. Keyed hashes, used in TSIG, are
|
||
inexpensive to calculate and verify. Public key encryption, as used in
|
||
SIG(0), is more scalable as the public keys are stored in DNS.
|
||
|
||
|
||
|
||
|
||
Expires November 2000 [Page 2]
|
||
|
||
INTERNET-DRAFT Secure Dynamic Update May 2000
|
||
|
||
|
||
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
|
||
RRs or RRsets in a DNS message with the authority of the zone owner.
|
||
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
|
||
counts. Therefore, it is possibly to maliciously insert or remove
|
||
RRsets in an update request without causing a verification failure.
|
||
|
||
If SIG records were used to protect the prerequisite section, it would
|
||
be impossible to determine whether the SIGs themselves were a
|
||
prerequisite or simply used for validation.
|
||
|
||
In the update section of an update request, signing requests to add an
|
||
RRset is straightforward, and this signature could be permanently used
|
||
to protect the data, as specified in [RFC2535]. However, if an RRset is
|
||
deleted, there is no data for a SIG to cover.
|
||
|
||
|
||
1.4 - Data and message signatures
|
||
|
||
As specified in [signing-auth], the DNSSEC validation process performed
|
||
by a resolver MUST NOT process any non-zone keys unless local policy
|
||
dictates otherwise. When performing secure dynamic update, all zone
|
||
data modified in a signed zone MUST be signed by a relevant zone key.
|
||
This completely disassociates authentication of an update request from
|
||
authentication of the data itself.
|
||
|
||
The primary usefulness of host and user keys, with respect to DNSSEC, is
|
||
to authenticate messages, including dynamic updates. Thus, host and
|
||
user keys MAY be used to generate SIG(0) records to authenticate updates
|
||
and MAY be used in the TKEY [TKEY] process to generate TSIG shared
|
||
secrets. In both cases, no SIG records generated by non-zone keys will
|
||
be used in a DNSSEC validation process unless local policy dictates.
|
||
Authentication of data, once it is present in DNS, only involves DNSSEC
|
||
zone keys and signatures generated by them.
|
||
|
||
|
||
|
||
|
||
Expires November 2000 [Page 3]
|
||
|
||
INTERNET-DRAFT Secure Dynamic Update May 2000
|
||
|
||
|
||
1.5 - Signatory strength
|
||
|
||
[RFC2535, section 3.1.2] defines the signatory field of a key as the
|
||
final 4 bits of the flags field, but does not define its value. This
|
||
proposal leaves this field undefined. Updating [RFC2535], this field
|
||
SHOULD be set to 0 in KEY records, and MUST be ignored.
|
||
|
||
2 - Authentication
|
||
|
||
TSIG or SIG(0) records MUST be included in all secure dynamic update
|
||
messages. This allows the server to verifiably determine the originator
|
||
of a message. If the message contains authentication in the form of a
|
||
SIG(0), the identity of the sender (that is, the principal) is the owner
|
||
of the KEY RR that generated the SIG(0). If the message contains a TSIG
|
||
generated by a statically configured shared secret, the principal is the
|
||
same as or derived from the shared secret name. If the message contains
|
||
a TSIG generated by a dynamically configured shared secret, the
|
||
principal is the same as the one that authenticated the TKEY process; if
|
||
the TKEY process was unauthenticated, no information is known about the
|
||
principal, and the associated TSIG shared secret MUST NOT be used for
|
||
secure dynamic update.
|
||
|
||
SIG(0) signatures SHOULD NOT be generated by zone keys, since
|
||
transactions are initiated by a host or user, not a zone.
|
||
|
||
DNSSEC SIG records (other than SIG(0)) MAY be included in an update
|
||
message, but MUST NOT be used to authenticate the update request.
|
||
|
||
If an update fails because it is signed with an unauthorized key, the
|
||
server MUST indicate failure by returning a message with RCODE REFUSED.
|
||
Other TSIG, SIG(0), or dynamic update errors are returned as specified
|
||
in the appropriate protocol description.
|
||
|
||
3 - Policy
|
||
|
||
All policy is configured by the zone administrator and enforced by the
|
||
zone's primary name server. Policy dictates the authorized actions that
|
||
an authenticated principal can take. Policy checks are based on the
|
||
principal and the desired action, where the principal is derived from
|
||
the message signing key and applied to dynamic update messages signed
|
||
with that key.
|
||
|
||
The server's policy defines criteria which determine if the key used to
|
||
sign the update is permitted to perform the requested updates. By
|
||
default, a principal MUST NOT be permitted to make any changes to zone
|
||
data; any permissions MUST be enabled though configuration.
|
||
|
||
|
||
|
||
|
||
|
||
Expires November 2000 [Page 4]
|
||
|
||
INTERNET-DRAFT Secure Dynamic Update May 2000
|
||
|
||
|
||
The policy is fully implemented in the primary zone server's
|
||
configuration for several reasons. This removes limitations imposed by
|
||
encoding policy into a fixed number of bits (such as the KEY RR's
|
||
signatory field). Policy is only relevant in the server applying it, so
|
||
there is no reason to expose it. Finally, a change in policy or a new
|
||
type of policy should not affect the DNS protocol or data format, and
|
||
should not cause interoperability failures.
|
||
|
||
|
||
3.1 - Standard policies
|
||
|
||
Implementations SHOULD allow access control policies to use the
|
||
principal as an authorization token, and MAY also allow policies to
|
||
grant permission to a signed message regardless of principal.
|
||
|
||
A common practice would be to restrict the permissions of a principal by
|
||
domain name. That is, a principal could be permitted to add, delete, or
|
||
modify entries corresponding to one or more domain names.
|
||
Implementations SHOULD allow per-name access control, and SHOULD provide
|
||
a concise representation of the principal's own name, its subdomains,
|
||
and all names in the zone.
|
||
|
||
Additionally, a server SHOULD restrict updates by RR type, so that a
|
||
principal could add, delete, or modify specific record types at certain
|
||
names. Implementations SHOULD allow per-type access control, and SHOULD
|
||
provide concise representations of all types and all ``user'' types,
|
||
where a user type is defined as one that does not affect the operation
|
||
of DNS itself.
|
||
|
||
|
||
3.1.1 - User types
|
||
|
||
User types include all data types except SOA, NS, SIG, and NXT. SOA and
|
||
NS SHOULD NOT be modified by normal users, since these types create or
|
||
modify delegation points. The addition of SIG records can lead to
|
||
attacks resulting in additional workload for resolvers, and the deletion
|
||
of SIG records could lead to extra work for the server if the zone SIG
|
||
was deleted. Note that these records are not forbidden, but not
|
||
recommended for normal users.
|
||
|
||
NXT records MUST NOT be created, modified, or deleted by dynamic update,
|
||
as their update may cause instability in the protocol. This is an
|
||
update to RFC 2136.
|
||
|
||
Issues concerning updates of KEY records are discussed in the Security
|
||
Considerations section.
|
||
|
||
|
||
|
||
|
||
|
||
Expires November 2000 [Page 5]
|
||
|
||
INTERNET-DRAFT Secure Dynamic Update May 2000
|
||
|
||
|
||
3.2 - Additional policies
|
||
|
||
Users are free to implement any policies. Policies may be as specific
|
||
or general as desired, and as complex as desired. They may depend on
|
||
the principal or any other characteristics of the signed message.
|
||
|
||
4 - Interaction with DNSSEC
|
||
|
||
An authorized update request MAY include SIG records with each RRset.
|
||
Since SIG records (except SIG(0) records) MUST NOT be used for
|
||
authentication of the update message, they are not required. If the
|
||
updated zone is secured, the data affected by an update operation MUST
|
||
be secured by one or more SIG records. For each RRset, if the update
|
||
includes a valid signature by a zone key, this signature SHOULD be
|
||
reused. Otherwise, the server MUST generate SIG records with one or
|
||
more zone keys (of which the private components MUST be online). If
|
||
multiple zone keys are online and an RRset requires a signature, a SIG
|
||
MUST be generated by at least one of the zone keys.
|
||
|
||
If a principal is authorized to add SIG records and there are SIG
|
||
records in the request, the following rules are applied. If the SIG was
|
||
generated by a zone key for the relevant zone, verification is attempted
|
||
(the public key must be available if the determination that it is a zone
|
||
key was made). If successful, the SIG is retained; otherwise, the SIG
|
||
is dropped. Otherwise, the SIG is retained without verification, since
|
||
it is considered immaterial to the DNSSEC validation process. The
|
||
server MAY examine SIG records and drop SIGs with a temporal validity
|
||
period in the past. At the completion of the update process, each
|
||
updated RRset must be signed in accordance with the zone's signing
|
||
policy; the SIGs must either be included in the update or generated by
|
||
the server.
|
||
|
||
The server MUST also, if necessary, generate a new SOA record and new
|
||
NXT records, and sign these with the appropriate zone keys. NXT records
|
||
are explicitly forbidden. SOA updates are allowed, since the
|
||
maintenance of SOA parameters is outside of the scope of the DNS
|
||
protocol.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Expires November 2000 [Page 6]
|
||
|
||
INTERNET-DRAFT Secure Dynamic Update May 2000
|
||
|
||
|
||
5 - Security considerations
|
||
|
||
This document requires that a zone key and possibly other cryptographic
|
||
secret material be held in an on-line, network-connected host, most
|
||
likely a name server. This material is at the mercy of host security to
|
||
remain a secret. Exposing this secret puts DNS data at risk of
|
||
masquerade attacks. The data at risk is that in both zones served by
|
||
the machine and delegated from this machine.
|
||
|
||
Allowing updates of KEY records may lead to undesirable results, since a
|
||
principal may be allowed to insert a public key without holding the
|
||
private key, and possibly masquerade as the key owner.
|
||
|
||
6 - Acknowledgements
|
||
|
||
The author would like to thank the following people for review and
|
||
informative comments (in alphabetical order):
|
||
|
||
Donald Eastlake
|
||
Olafur Gudmundsson
|
||
Andreas Gustafsson
|
||
Bob Halley
|
||
Stuart Kwan
|
||
Ed Lewis
|
||
|
||
|
||
7 - 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.
|
||
|
||
[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.
|
||
|
||
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC
|
||
2065, IBM, March 1999.
|
||
|
||
[TSIG] P. Vixie (Ed.), O. Gudmundsson, D. Eastlake, B. Wellington
|
||
``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
|
||
ietf-dnsext-tsig-00.txt, ISC & NAILabs & IBM & NAILabs, March
|
||
2000.
|
||
|
||
|
||
|
||
Expires November 2000 [Page 7]
|
||
|
||
INTERNET-DRAFT Secure Dynamic Update May 2000
|
||
|
||
|
||
[TKEY] D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),''
|
||
draft-ietf-dnsext-tkey-02.txt, IBM, April 2000.
|
||
|
||
[signing-auth]
|
||
B. Wellington ``Domain Name System Security (DNSSEC) Signing
|
||
Authority,'' draft-ietf-dnsext-signing-auth-01.txt, Nominum,
|
||
May 2000.
|
||
|
||
8 - Author's Address
|
||
|
||
|
||
Brian Wellington
|
||
Nominum, Inc.
|
||
950 Charter Street
|
||
Redwood City, CA 94063
|
||
+1 650 779 6022
|
||
<Brian.Wellington@nominum.com>
|
||
|
||
|
||
9 - Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2000). 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 implmentation 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."
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Expires November 2000 [Page 8]
|
||
|