Commit 94551f13 authored by Andreas Gustafsson's avatar Andreas Gustafsson
Browse files

00->01

parent e823f5d4
DNSIND Working Group Brian Wellington (TISLabs)
INTERNET-DRAFT April 1999
<draft-ietf-dnsind-simple-secure-update-00.txt>
MAY Updates: RFC 2535, RFC 2136, [TSIG]
MAY Replaces: RFC 2137, [update2]
DNSIND Working Group Brian Wellington (NAILabs)
INTERNET-DRAFT June 1999
<draft-ietf-dnsind-simple-secure-update-01.txt>
Updates: RFC 2535, 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
......@@ -33,37 +30,37 @@ Status of this Memo
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.
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.
This draft expires on December 25, 1999.
Copyright Notice
Copyright (C) The Internet Society (1999). All rights reserved.
Abstract
This draft proposes a method for performing secure Domain Name System
(DNS) dynamic updates. The method described here is simple to
Expires December 1999 [Page 1]
Expires October 1999 [Page 1]
INTERNET-DRAFT Simple Secure Dynamic Update April 1999
INTERNET-DRAFT Simple Secure Dynamic Update June 1999
understand and use, and flexible enough to represent any policy
decisions. Secure communication based on request/transaction
signatures is used to provide authentication and authorization.
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].
[RFC2136], but no mechanisms for security are defined. A form of secure
dynamic update is defined in [RFC2137, update2]. Request and
transaction signatures are defined in [TSIG] and [RFC2535].
Familiarity with the DNS system [RFC1034, RFC1035] as well as the
proposals mentioned above is assumed. Familiarity with DNS Security
[RFC2535] is assumed in section (4).
proposals mentioned above is assumed.
1.1 - Overview of DNS Dynamic Update
......@@ -78,49 +75,114 @@ 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.
Transaction signatures (TSIG [TSIG] and SIG(0) [RFC2535]) provide the
means for two processes to authenticate DNS requests and responses sent
between them. A TSIG is generated 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 is included as
the final resource record in a DNS message. Keyed hashes, used in TSIG,
are simple to calculate and verify, and do not require caching of data.
Public key encryption, as used in SIG(0), is more scalable.
1.3 - Requirement of a message signature
In some cases, DNSSEC SIG records could be used to protect the integrity
of individual RRs or RRsets in the update process. There are several
problems with this, though. First, SIG records do not cover the message
header, so malicious tampering in the header or the removal of records
would be unnoticed. A SIG record would be required in the zone section,
to prevent tampering. SIG records could be created to protect data in
the prerequisite section, but this would imply that the SIG is a
prerequisite, and in some cases, the SIG may be present in DNS and
require no computation. In the update section, signing addition
Expires December 1999 [Page 2]
INTERNET-DRAFT Simple Secure Dynamic Update June 1999
requests is straightforward, but signing delete requests is difficult,
since there may be no remaining set that a SIG would cover.
Message based signatures, using TSIG or SIG(0), avoid these problems,
since only one signature is computed for the message, and this signature
protects the integrity of the entire message. This is also a less
expensive operation.
1.4 - Removal of non-zone key SIG records
The main objective of a DNSSEC capable resolver is the authenticated
retrieval of data. When data is received, a chain of trust is followed
to the root. This chain of trust must include the zone key of the zone
containing the data, but can become overly complicated if host and user
keys are delegated signing authority. In this proposal, only signatures
generated by zone keys are considered relevant to DNSSEC capable
resolvers. This is an update to the DNSSEC specification [RFC2535], and
simplifies the resolution process.
The primary usefulness of host and user keys, with respect to DNSSEC, is
to authenticate dynamic updates. Thus, host and user keys may be used
to generate SIG(0) records to authenticate updates, or 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 present in DNS.
This completely disassociates authentication of an update request from
authentication of the data itself. Authentication of the update message
can be done with either TSIG shared secrets or DNSSEC host or user keys.
Authentication of the data, once it is present in DNS, only involves
DNSSEC zone keys.
1.5 - Signatory strength
[RFC2535] defines the signatory field of a key as the final 4 bits of
the flags field, but does not define its value. This proposal defines
the field as a 4 bit unsigned integer representing strength, where 15 is
strongest. A key of a certain strength can replace data signed by a key
of equal or lesser strength. Data signed by this key can be replaced by
a key with equal or greater strength. Note that this strength is
unrelated to the number of bits in the key.
Expires December 1999 [Page 3]
INTERNET-DRAFT Simple Secure Dynamic Update June 1999
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 October 1999 [Page 2]
INTERNET-DRAFT Simple Secure Dynamic Update April 1999
TSIG or SIG(0) records MUST be attached to all secure dynamic update
messages. This allows the server to verifiably determine the originator
of the message; the originator is either the other party sharing the
TSIG secret or the host or user that owns the key generating the SIG(0).
Note that SIG(0) signatures MAY NOT be generated by zone keys.
If a SIG(0) is used, the signatory strength can be derived from the
signing KEY. If a TSIG is used that was automatically generated using
TKEY, the signatory strength of the TSIG is declared to be the same as
the KEY used in the TKEY process. If a TSIG is used that was manually
configured, its signatory strength SHOULD be manually configured also
(or left as the default). The key name/strength pair can be used in the
decision of whether to accept the update.
DNSSEC SIG records (other than SIG(0)) may be included in an update
message, but are not used for authentication purposes in the secure
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
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).
All policy is enforced by the server and configured by the zone
administrator. Policy checks are based on identity, where the identity
is equivalent to the owner (name) of the message signing key. The
signing strength of the key is also important when updating a secure
zone, since the message signing key's strength can be compared to the
strength of the zone key(s).
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
......@@ -131,6 +193,10 @@ 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.
Expires December 1999 [Page 4]
INTERNET-DRAFT Simple Secure Dynamic Update June 1999
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
......@@ -141,7 +207,8 @@ document.
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.
policies and policies need only be present at the primary server for a
zone, a central configuration point is more logical.
3.3 - Extendibility
......@@ -149,51 +216,61 @@ 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.
3.3 - Recommendations
Expires October 1999 [Page 3]
INTERNET-DRAFT Simple Secure Dynamic Update April 1999
In many cases, dynamic updates should be restricted by name. An example
would be that updates are allowed only if the name to be updated is
under the name of the message signing key. Since the signatory field
defines a key's signing strength, a simple policy would only allow a key
to update signed data if the message signing key was at least as strong
as the zone key that signed the RRset.
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.
server will generate SIG records for each updated RRset with a zone key
(which MUST be online), unless the set is already correctly signed by a
zone key. If multiple zone keys are online, the zone key with the
greatest signatory strength less than or equal to that of the update
message signing key is chosen.
If there are any immaterial (to DNSSEC) SIG records present, these are
retained. If there are SIG records that have been generated by an
appropriate zone KEY, these SIGs are verified and retained if the
verification is successful. DNSSEC SIG records generated by any other
KEY are dropped. The server will also, if necessary, generate a new SOA
record and new NXT records, and sign these with a zone key. Unlike
traditional dynamic update, the client is forbidden from updating NXT
records. SOA updates are allowed, since SOA serial advancement policies
can be outside of the scope of the DNS protocol.
Expires December 1999 [Page 5]
INTERNET-DRAFT Simple Secure Dynamic Update June 1999
Multiple zone keys can be useful in conjunction with secure dynamic
update. A strong zone key can be used offline to sign static data,
while a weaker zone key can sign dynamic data. If signed updates are
received with key strengths stronger than the weak zone key, updates
will be allowed only to RRsets signed by the weak zone key. It is
highly recommended that no host or user key be allowed to have a
signatory strength equal to or greater than the strongest zone key.
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.
For a secure zone to support dynamic update, a zone key MUST be online
(unlike [RFC2137]). An online zone key would be required to sign NXT
records even if other signatures were not done online, since allowing
NXT updates is inherently dangerous.
6 - References
6 - Acknowledgements
The author would like to thank Olafur Gudmundsson, Bob Halley, and Ed
Lewis for review and informative comments.
7 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
RFC 1034, ISI, November 1987.
......@@ -213,66 +290,28 @@ that can sign the zone's data compromises the zone itself.
[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.
Expires October 1999 [Page 4]
INTERNET-DRAFT Simple Secure Dynamic Update April 1999
ietf-dnsind-tsig-09.txt, ISC & TISLabs & IBM & TISLabs, June
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
Expires December 1999 [Page 6]
INTERNET-DRAFT Simple Secure Dynamic Update June 1999
[TKEY] D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),''
draft-ietf-dnsind-tkey-00.txt, IBM, May 1999.
8 - Author's Address
Brian Wellington
TISLabs at Network Associates
3060 Washington Road, Route 97
NAILabs
Network Associates
3060 Washington Road (Rt. 97)
Glenwood, MD 21738
+1 443 259 2369
<bwelling@tislabs.com>
Expires October 1999 [Page 5]
Expires December 1999 [Page 7]
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment