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

updated drafts

Browse Source
This commit is contained in:
Andreas Gustafsson
2000-05-17 18:44:08 +00:00
parent df834113a3
commit 559e5654ce
2 changed files with 134 additions and 190 deletions
Download Patch File Download Diff File Expand all files Collapse all files

98
doc/draft/draft-ietf-dnsext-signing-auth-00.txt → doc/draft/draft-ietf-dnsext-signing-auth-01.txt
View File

@@ -1,8 +1,8 @@
DNSIND Working Group Brian Wellington (NAILabs)
INTERNET-DRAFT January 2000
DNSIND Working Group Brian Wellington (Nominum)
INTERNET-DRAFT May 2000
<draft-ietf-dnsext-signing-auth-00.txt>
<draft-ietf-dnsext-signing-auth-01.txt>
Updates: RFC 2535
@@ -35,7 +35,7 @@ Status of this Memo
Comments should be sent to the authors or the DNSIND WG mailing list
namedroppers@internic.net.
This draft expires on July 31, 2000.
This draft expires on November 12, 2000.
Copyright Notice
@@ -50,9 +50,9 @@ Abstract
Expires July 2000 [Page 1]
Expires November 2000 [Page 1]
INTERNET-DRAFT DNSSEC Signing Authority January 2000
INTERNET-DRAFT DNSSEC Signing Authority May 2000
secure resolution process. Specifically, this affects the
@@ -64,8 +64,8 @@ INTERNET-DRAFT DNSSEC Signing Authority January 2000
This document defines additional restrictions on DNSSEC signatures (SIG)
records relating to their authority to sign associated data. The intent
is to establish a standard policy followed by a secure resolver; this
policy can be augmented by local rules. This builds upon [RFC2535] and
updates section 2.3.6.
policy can be augmented by local rules. This builds upon [RFC2535],
updating section 2.3.6 of that document.
The most significant change is that in a secure zone, zone data is
required to be signed by the zone key.
@@ -90,7 +90,8 @@ necessary.
SIGs may also be used for transaction security. In this case, a SIG
record with a type covered field of 0 is attached to a message, and is
used to protect message integrity. This is referred to as a SIG(0).
used to protect message integrity. This is referred to as a SIG(0)
[RFC2535].
The following sections define requirements for all of the fields of a
SIG record. These requirements MUST be met in order for a DNSSEC
@@ -105,10 +106,9 @@ SIG, there are requirements that it MUST meet.
Expires July 2000 [Page 2]
Expires November 2000 [Page 2]
INTERNET-DRAFT DNSSEC Signing Authority January 2000
INTERNET-DRAFT DNSSEC Signing Authority May 2000
2.1 - Type Covered
@@ -153,8 +153,8 @@ that future algorithms will impose contraints.
The signer's name field of a data SIG MUST contain the name of the zone
to which the data and signature belong. The combination of signer's
name, key tag, and algorithm MUST identify a zone key if the SIG is to
be considered material. As this document defines a standard policy,
this can be overriden by local configuration.
be considered material. This document defines a standard policy for
DNSSEC validation; local policy may override the standard policy.
There are no restrictions on the signer field of a SIG(0) record. The
combination of signer's name, key tag, and algorithm MUST identify a key
@@ -162,15 +162,15 @@ if this SIG(0) is to be processed.
Expires July 2000 [Page 3]
Expires November 2000 [Page 3]
INTERNET-DRAFT DNSSEC Signing Authority January 2000
INTERNET-DRAFT DNSSEC Signing Authority May 2000
2.8 - Signature
There are no restrictions on the signature field. The signature will be
verified at some point, but does not need to be examined prior to pre-
verified at some point, but does not need to be examined prior to
verification unless a future algorithm imposes constraints.
3 - The Signing KEY Record
@@ -189,9 +189,9 @@ generated the signature until the verification is performed.
3.1 - Type Flags
The signing KEY record MUST have a flags value of 00 or 01
(authentication allowed, confidentiality optional) [RFC2535, 3.1.2]. If
a key is not permitted to authenticate data, a DNSSEC resolver MUST NOT
trust any signature that it generates.
(authentication allowed, confidentiality optional) [RFC2535, 3.1.2]. A
DNSSEC resolver MUST only trust signatures generated by keys that are
permitted to authenticate data.
3.2 - Name Flags
@@ -208,29 +208,29 @@ MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535, section
ignore all keys that are not zone keys unless local policy dictates
otherwise.
The primary reason that host and/or user keys were allowed to generate
material DNSSEC signatures was to allow dynamic update without online
zone keys. The desire to avoid online signing keys cannot be achieved,
though, because they are necessary to sign NXT and SOA sets [SSU].
These online zone keys can sign any incoming data, thus removing the
need for host/user key signatures stored in the DNS.
The primary reason that RFC 2535 allows host and user keys to generate
material DNSSEC signatures is to allow dynamic update without online
zone keys; that is, avoid storing private keys in an online server. The
desire to avoid online signing keys cannot be achieved, though, because
they are necessary to sign NXT and SOA sets [SSU]. These online zone
keys can sign any incoming data. Removing the goal of having no online
keys removes the reason to allow host and user keys to generate material
Expires July 2000 [Page 4]
Expires November 2000 [Page 4]
INTERNET-DRAFT DNSSEC Signing Authority January 2000
INTERNET-DRAFT DNSSEC Signing Authority May 2000
This simplifies the validation process. If data must be signed by a
zone key, determining whether a key is authorized to sign an RRset
requires finding the enclosing zone of the RRset, and following a chain
of trusted zone keys to a known trusted key (which may be the DNS root
key). If host and user keys were permitted to generate material
signatures, following a chain of trust to a trusted DNSSEC key could
involve any number of non-zone keys and a non-trivial amount of work to
determine if all such keys have the proper authority.
signatures. in the DNS.
Limiting material signatures to zone keys simplifies the validation
process. The length of the verification chain is bounded by the name's
label depth. The authority of a key is clearly defined; a resolver does
not need to make a potentially complicated decision to determine whether
a key can sign data. amount of work to determine if all such keys have
the proper authority.
Finally, there is no additional flexibility granted by allowing
host/user key generated material signatures. As long as users and hosts
@@ -274,9 +274,9 @@ record.
Expires July 2000 [Page 5]
Expires November 2000 [Page 5]
INTERNET-DRAFT DNSSEC Signing Authority January 2000
INTERNET-DRAFT DNSSEC Signing Authority May 2000
4 - Security considerations
@@ -317,7 +317,7 @@ informative comments (in alphabetical order):
[SSU] B. Wellington, ``Simple Secure Domain Name System (DNS)
Dynamic Update,'' draft-ietf-dnsext-simple-secure-
update-00.txt, NAILabs, January 2000.
update-01.txt, Nominum, May 2000.
@@ -330,21 +330,20 @@ informative comments (in alphabetical order):
Expires July 2000 [Page 6]
Expires November 2000 [Page 6]
INTERNET-DRAFT DNSSEC Signing Authority January 2000
INTERNET-DRAFT DNSSEC Signing Authority May 2000
7 - Author's Address
Brian Wellington
NAILabs
Network Associates
3060 Washington Road (Rt. 97)
Glenwood, MD 21738
+1 443 259 2369
<bwelling@tislabs.com>
Nominum, Inc.
950 Charter Street
Redwood City, CA 94063
+1 650 779 6022
<Brian.Wellington@nominum.com>
8 - Full Copyright Statement
@@ -386,5 +385,6 @@ FITNESS FOR A PARTICULAR PURPOSE."
Expires July 2000 [Page 7]
Expires November 2000 [Page 7]

226
doc/draft/draft-ietf-dnsext-simple-secure-update-00.txt → doc/draft/draft-ietf-dnsext-simple-secure-update-01.txt
View File

@@ -1,14 +1,14 @@
DNSIND Working Group Brian Wellington (NAILabs)
INTERNET-DRAFT January 2000
INTERNET-DRAFT May 2000
<draft-ietf-dnsext-simple-secure-update-00.txt>
<draft-ietf-dnsext-simple-secure-update-01.txt>
Updates: RFC 2535, RFC 2136,
Replaces: RFC 2137, [update2]
Simple Secure Domain Name System (DNS) Dynamic Update
Secure Domain Name System (DNS) Dynamic Update
Status of this Memo
@@ -35,7 +35,7 @@ Status of this Memo
Comments should be sent to the authors or the DNSIND WG mailing list
namedroppers@internic.net.
This draft expires on July 31, 2000.
This draft expires on November 12, 2000.
Copyright Notice
@@ -49,9 +49,9 @@ Abstract
Expires July 2000 [Page 1]
Expires November 2000 [Page 1]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
INTERNET-DRAFT Secure Dynamic Update May 2000
to be flexible and useful while requiring as few changes to the
@@ -105,42 +105,39 @@ SIG(0), is more scalable as the public keys are stored in DNS.
Expires July 2000 [Page 2]
Expires November 2000 [Page 2]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
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 an update message. However, this cannot sufficiently
protect the dynamic update request.
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 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.
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, 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.
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.
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
@@ -158,18 +155,17 @@ 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.
Expires July 2000 [Page 3]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
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
@@ -203,25 +199,6 @@ 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.
Expires July 2000 [Page 4]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
3 - Policy
All policy is configured by the zone administrator and enforced by the
@@ -236,6 +213,15 @@ 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
@@ -270,14 +256,6 @@ of DNS itself.
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
Expires July 2000 [Page 5]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
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
@@ -292,6 +270,14 @@ 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
@@ -326,18 +312,28 @@ 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
Expires July 2000 [Page 6]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
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
@@ -382,37 +378,35 @@ informative comments (in alphabetical order):
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC
2065, IBM, March 1999.
Expires July 2000 [Page 7]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
[TSIG] P. Vixie (Ed.), O. Gudmundsson, D. Eastlake, B. Wellington
``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
ietf-dnsind-tsig-13.txt, ISC & NAILabs & IBM & NAILabs,
December 1999.
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-dnsind-tkey-03.txt, IBM, December 1999.
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-00.txt, NAILabs,
January 2000.
Authority,'' draft-ietf-dnsext-signing-auth-01.txt, Nominum,
May 2000.
8 - Author's Address
Brian Wellington
NAILabs
Network Associates
3060 Washington Road (Rt. 97)
Glenwood, MD 21738
+1 443 259 2369
<bwelling@tislabs.com>
Nominum, Inc.
950 Charter Street
Redwood City, CA 94063
+1 650 779 6022
<Brian.Wellington@nominum.com>
9 - Full Copyright Statement
@@ -438,14 +432,6 @@ 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
Expires July 2000 [Page 8]
INTERNET-DRAFT Simple Secure Dynamic Update January 2000
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."
@@ -455,47 +441,5 @@ FITNESS FOR A PARTICULAR PURPOSE."
Expires July 2000 [Page 9]
Expires November 2000 [Page 8]