idnits 2.17.1 draft-ietf-dnssec-simple-update-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([TSIG]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 73: '...but MAY NOT be used for authentication...' RFC 2119 keyword, line 119: '...key (which MUST be online). If there ...' RFC 2119 keyword, line 128: '...ic update, the Zone key MUST be online...' RFC 2119 keyword, line 129: '...(unlike [RFC2137]). The server MUST update the SOA record and MAY...' == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2065, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2136, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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. (Using the creation date from RFC2065, updated by this document, for RFC5378 checks: 1997-01-01) (Using the creation date from RFC2136, updated by this document, for RFC5378 checks: 1995-02-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1998) is 9291 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'TSIG' on line 157 looks like a reference -- Missing reference section? 'RFC2136' on line 147 looks like a reference -- Missing reference section? 'RFC1034' on line 138 looks like a reference -- Missing reference section? 'RFC1035' on line 141 looks like a reference -- Missing reference section? 'RFC2137' on line 151 looks like a reference -- Missing reference section? 'RFC2065' on line 144 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSSEC Working Group Brian Wellington (TISLabs) 3 INTERNET-DRAFT November 1998 5 7 Updates: RFC 2065, RFC 2136, [TSIG] 8 Replaces: RFC 2137, [update2] 10 Simple Secure Domain Name System (DNS) Dynamic Update 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 27 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 28 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 This draft proposes an alternative method for performing secure 33 Domain Name System (DNS) dynamic updates. The method described here 34 is both simple and flexible enough to represent any policy decisions. 35 Secure communication based on request/transaction signatures [TSIG] 36 is used to provide authentication and authorization. 38 1 - Introduction 40 Dynamic update operations for the Domain Name System are defined in 41 [RFC2136], but no mechanisms for security have been defined. Request 42 and transaction signatures are defined in [TSIG]. 44 Familiarity with the DNS system [RFC1034, RFC1035] as well as the 45 proposals mentioned above is assumed. Familiarity with DNS Security 46 [RFC2065, secext2] is assumed in section (4). 48 1.1 - Overview of DNS Dynamic Update 50 DNS dynamic update defines a new DNS opcode and a new interpretation of 51 the DNS message if that opcode is used. An update can specify 52 insertions or deletions of data, along with prerequisites necessary for 53 the updates to occur. All tests and changes for a DNS update request 54 are restricted to a single zone, and are performed at the primary server 55 for the zone. The primary server for a dynamic zone must increment the 56 zone SOA serial number when an update occurs or before the next 57 retrieval of the SOA. 59 1.2 - Overview of DNS Transaction Security 61 [TSIG] provides a means for two processes that share a secret key to 62 authenticate DNS requests and responses sent between them. This is done 63 by appending TSIG digital signature (keyed hash) RRs to those messages. 64 Keyed hashes are simple to calculate and verify, and do not require 65 caching of data. 67 2 - Authentication 69 TSIG records are attached to all secure dynamic update messages. This 70 allows the server to verifiably determine the originator of the message. 71 It can then use this information in the decision of whether to accept 72 the update. DNSSEC SIG records may be included in an update message, 73 but MAY NOT be used for authentication purposes in the update protocol. 75 3 - Policy 77 All policy is dictated by the server and is configurable by the zone 78 administrator. The server's policy defines criteria which determine if 79 the key used to sign the update is permitted to update the records 80 requested. By default, a key cannot make any changes to the zone; the 81 key's scope must be explicitly enabled. There are several reasons that 82 this process is implemented in the server and not the protocol (as in 83 [RFC2137, update2], where the signatory bits of KEY records define the 84 policy). 86 3.1 - Flexibility 88 Storing policy in the signatory fields of DNS keys is overly 89 restrictive. Only a fixed number of bits are present, which means that 90 only a fixed number of policy decisions are representable. There are 91 many decisions that do not fit into the framework imposed by the 92 signatory field; a zone administrator cannot effectively impose a policy 93 not implemented in the draft defining the field. 95 There may be any number of policies applied in the process of 96 authorization, and there are no restrictions on the scope of these 97 policies. Implementation of the policies is beyond the scope of this 98 document. 100 3.2 - Simplicity 102 Policy decisions in the server could be used as an adjunct to policy 103 fields in the KEY records. This could lead to confusion if the policies 104 are inconsistent. Furthermore, since there is no need to expose 105 policies, a central configuration point is more logical. 107 3.3 - Extendibility 109 If a policy is changed, there are no changes made to the DNS protocol or 110 the data on the wire. This means that new policies can be defined at 111 any point without adverse effects or interoperability concerns. 113 4 - Interaction with DNSSEC 115 A successful update request may or may not include SIG records for each 116 RRset. Since SIG records are not used for authentication in this 117 protocol, they are not required. If the updated zone is signed, the 118 server will generate SIG records for each incoming RRset with the Zone 119 key (which MUST be online). If there are any DNSSEC SIG records 120 present, they are dropped. If there are non-DNSSEC SIG records present, 121 these are retained. In any case, SIG records associated with each RRset 122 (that a resolver would use for verification) are generated by the Zone 123 key. The server will also generate a new SOA record and possibly new 124 NXT records, and sign these with the Zone key. 126 5 - Security considerations 128 For a secure zone to support dynamic update, the Zone key MUST be online 129 (unlike [RFC2137]). The server MUST update the SOA record and MAY 130 generate new NXT records (the client is forbidden from updating these 131 records); a Zone key must be available with which to sign these. No 132 additional protection is offered by having the Zone key offline and an 133 Update key online, since compromising any key that can sign the zone's 134 data compromises the zone itself. 136 6 - References 138 [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' 139 RFC 1034, ISI, November 1987. 141 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 142 Specification,'' RFC 1035, ISI, November 1987. 144 [RFC2065] D. Eastlake, C. Kaufman, ``Domain Name System Security 145 Extensions,'' RFC 2065, CyberCash & Iris, January 1997. 147 [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic 148 Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore 149 & Cisco & DEC, April 1997. 151 [RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC 152 2137, CyberCash, April 1997. 154 [secext2] D. Eastlake ``Domain Name System Security Extensions,'' 155 draft-ietf-dnssec-secext2-05.txt, CyberCash, April 1998. 157 [TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake ``Secret Key 158 Transaction Signatures for DNS (TSIG),'' draft-ietf-dnsind- 159 tsig-06.txt, ISC & TIS & CyberCash, September 1998. 161 [update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic 162 Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite 163 Systems Company, August 1998. 165 7 - Author's Address 167 Brian Wellington 168 TISLabs at Network Associates 169 3060 Washington Road, Route 97 170 Glenwood, MD 21738 171 +1 301 854 6889 172