diff --git a/doc/draft/draft-ietf-dnsext-signing-auth-00.txt b/doc/draft/draft-ietf-dnsext-signing-auth-01.txt similarity index 81% rename from doc/draft/draft-ietf-dnsext-signing-auth-00.txt rename to doc/draft/draft-ietf-dnsext-signing-auth-01.txt index a7468bc011..9fbe1497a3 100644 --- a/doc/draft/draft-ietf-dnsext-signing-auth-00.txt +++ b/doc/draft/draft-ietf-dnsext-signing-auth-01.txt @@ -1,8 +1,8 @@ -DNSIND Working Group Brian Wellington (NAILabs) -INTERNET-DRAFT January 2000 +DNSIND Working Group Brian Wellington (Nominum) +INTERNET-DRAFT May 2000 - + 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 - + Nominum, Inc. + 950 Charter Street + Redwood City, CA 94063 + +1 650 779 6022 + 8 - Full Copyright Statement @@ -386,5 +385,6 @@ FITNESS FOR A PARTICULAR PURPOSE." -Expires July 2000 [Page 7] + +Expires November 2000 [Page 7] diff --git a/doc/draft/draft-ietf-dnsext-simple-secure-update-00.txt b/doc/draft/draft-ietf-dnsext-simple-secure-update-01.txt similarity index 83% rename from doc/draft/draft-ietf-dnsext-simple-secure-update-00.txt rename to doc/draft/draft-ietf-dnsext-simple-secure-update-01.txt index cd49664e29..1034426ab9 100644 --- a/doc/draft/draft-ietf-dnsext-simple-secure-update-00.txt +++ b/doc/draft/draft-ietf-dnsext-simple-secure-update-01.txt @@ -1,14 +1,14 @@ DNSIND Working Group Brian Wellington (NAILabs) -INTERNET-DRAFT January 2000 +INTERNET-DRAFT May 2000 - + 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 - + Nominum, Inc. + 950 Charter Street + Redwood City, CA 94063 + +1 650 779 6022 + 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]