idnits 2.17.1 draft-ietf-dnsext-simple-secure-update-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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? == 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 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 120: '...by a resolver MUST NOT process any non...' RFC 2119 keyword, line 122: '...in a signed zone MUST be signed by a r...' RFC 2119 keyword, line 128: '...user keys MAY be used to generate SIG(...' RFC 2119 keyword, line 129: '...and MAY be used in the TKEY [TKEY] process to generate TSIG shared...' RFC 2119 keyword, line 140: '...0 in KEY records, and MUST be ignored....' (23 more instances...) == 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 RFC2136, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2535, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? 'RFC1034' on line 292 looks like a reference -- Missing reference section? 'RFC1035' on line 295 looks like a reference -- Missing reference section? 'RFC2136' on line 298 looks like a reference -- Missing reference section? 'RFC2535' on line 305 looks like a reference -- Missing reference section? 'TSIG' on line 308 looks like a reference -- Missing reference section? 'TKEY' on line 313 looks like a reference -- Missing reference section? 'RFC2137' on line 302 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSIND Working Group Brian Wellington (NAILabs) 2 4 Updates: RFC 2535, RFC 2136, 5 Replaces: RFC 2137, [update2] 7 Secure Domain Name System (DNS) Dynamic Update 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 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 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Comments should be sent to the authors or the DNSIND WG mailing list 31 namedroppers@internic.net. 33 This draft expires on November 12, 2000. 35 Copyright Notice 37 Copyright (C) The Internet Society (2000). All rights reserved. 39 Abstract 41 This document proposes a method for performing secure Domain Name 42 System (DNS) dynamic updates. The method described here is intended 43 to be flexible and useful while requiring as few changes to the 44 protocol as possible. The authentication of the dynamic update 45 message is separate from later DNSSEC validation of the data. Secure 46 communication based on authenticated requests and transactions is 47 used to provide authorization. 49 1 - Introduction 51 This document defines a means to secure dynamic updates of the Domain 52 Name System (DNS), allowing only authorized sources to make changes to a 53 zone's contents. The existing unsecured dynamic update operations form 54 the basis for this work. 56 Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update 57 [RFC2136] is helpful and is assumed by this document. In addition, 58 knowledge of DNS security extensions [RFC2535], SIG(0) transaction 59 security [RFC2535], and TSIG transaction security [TSIG] is recommended. 61 This document updates portions of RFC 2535, in particular section 3.1.2. 62 This document obsoletes RFC 2137, an alternate proposal for secure 63 dynamic update, due to implementation experience. 65 1.1 - Overview of DNS Dynamic Update 67 DNS dynamic update defines a new DNS opcode and a new interpretation of 68 the DNS message if that opcode is used. An update can specify 69 insertions or deletions of data, along with prerequisites necessary for 70 the updates to occur. All tests and changes for a DNS update request 71 are restricted to a single zone, and are performed at the primary server 72 for the zone. The primary server for a dynamic zone must increment the 73 zone SOA serial number when an update occurs or before the next 74 retrieval of the SOA. 76 1.2 - Overview of DNS Transaction Security 78 Exchanges of DNS messages which include TSIG [TSIG] or SIG(0) [RFC2535] 79 records allow two DNS entities to authenticate DNS requests and 80 responses sent between them. A TSIG MAC (message authentication code) 81 is derived from a shared secret, and a SIG(0) is generated from a 82 private key whose public counterpart is stored in DNS. In both cases, a 83 record containing the message signature/MAC is included as the final 84 resource record in a DNS message. Keyed hashes, used in TSIG, are 85 inexpensive to calculate and verify. Public key encryption, as used in 86 SIG(0), is more scalable as the public keys are stored in DNS. 88 1.3 - Comparison of data authentication and message authentication 90 Message based authentication, using TSIG or SIG(0), provides protection 91 for the entire message with a single signing and single verification 92 which, in the case of TSIG, is a relatively inexpensive MAC creation and 93 check. For update requests, this signature can establish, based on 94 policy or key negotation, the authority to make the request. 96 DNSSEC SIG records can be used to protect the integrity of individual 97 RRs or RRsets in a DNS message with the authority of the zone owner. 98 However, this cannot sufficiently protect the dynamic update request. 100 Using SIG records to secure RRsets in an update request is incompatible 101 with the design of update, as described below, and would in any case 102 require multiple expensive public key signatures and verifcations. 104 SIG records do not cover the message header, which includes record 105 counts. Therefore, it is possibly to maliciously insert or remove 106 RRsets in an update request without causing a verification failure. 108 If SIG records were used to protect the prerequisite section, it would 109 be impossible to determine whether the SIGs themselves were a 110 prerequisite or simply used for validation. 112 In the update section of an update request, signing requests to add an 113 RRset is straightforward, and this signature could be permanently used 114 to protect the data, as specified in [RFC2535]. However, if an RRset is 115 deleted, there is no data for a SIG to cover. 117 1.4 - Data and message signatures 119 As specified in [signing-auth], the DNSSEC validation process performed 120 by a resolver MUST NOT process any non-zone keys unless local policy 121 dictates otherwise. When performing secure dynamic update, all zone 122 data modified in a signed zone MUST be signed by a relevant zone key. 123 This completely disassociates authentication of an update request from 124 authentication of the data itself. 126 The primary usefulness of host and user keys, with respect to DNSSEC, is 127 to authenticate messages, including dynamic updates. Thus, host and 128 user keys MAY be used to generate SIG(0) records to authenticate updates 129 and MAY be used in the TKEY [TKEY] process to generate TSIG shared 130 secrets. In both cases, no SIG records generated by non-zone keys will 131 be used in a DNSSEC validation process unless local policy dictates. 132 Authentication of data, once it is present in DNS, only involves DNSSEC 133 zone keys and signatures generated by them. 135 1.5 - Signatory strength 137 [RFC2535, section 3.1.2] defines the signatory field of a key as the 138 final 4 bits of the flags field, but does not define its value. This 139 proposal leaves this field undefined. Updating [RFC2535], this field 140 SHOULD be set to 0 in KEY records, and MUST be ignored. 142 2 - Authentication 144 TSIG or SIG(0) records MUST be included in all secure dynamic update 145 messages. This allows the server to verifiably determine the originator 146 of a message. If the message contains authentication in the form of a 147 SIG(0), the identity of the sender (that is, the principal) is the owner 148 of the KEY RR that generated the SIG(0). If the message contains a TSIG 149 generated by a statically configured shared secret, the principal is the 150 same as or derived from the shared secret name. If the message contains 151 a TSIG generated by a dynamically configured shared secret, the 152 principal is the same as the one that authenticated the TKEY process; if 153 the TKEY process was unauthenticated, no information is known about the 154 principal, and the associated TSIG shared secret MUST NOT be used for 155 secure dynamic update. 157 SIG(0) signatures SHOULD NOT be generated by zone keys, since 158 transactions are initiated by a host or user, not a zone. 160 DNSSEC SIG records (other than SIG(0)) MAY be included in an update 161 message, but MUST NOT be used to authenticate the update request. 163 If an update fails because it is signed with an unauthorized key, the 164 server MUST indicate failure by returning a message with RCODE REFUSED. 165 Other TSIG, SIG(0), or dynamic update errors are returned as specified 166 in the appropriate protocol description. 168 3 - Policy 170 All policy is configured by the zone administrator and enforced by the 171 zone's primary name server. Policy dictates the authorized actions that 172 an authenticated principal can take. Policy checks are based on the 173 principal and the desired action, where the principal is derived from 174 the message signing key and applied to dynamic update messages signed 175 with that key. 177 The server's policy defines criteria which determine if the key used to 178 sign the update is permitted to perform the requested updates. By 179 default, a principal MUST NOT be permitted to make any changes to zone 180 data; any permissions MUST be enabled though configuration. 182 The policy is fully implemented in the primary zone server's 183 configuration for several reasons. This removes limitations imposed by 184 encoding policy into a fixed number of bits (such as the KEY RR's 185 signatory field). Policy is only relevant in the server applying it, so 186 there is no reason to expose it. Finally, a change in policy or a new 187 type of policy should not affect the DNS protocol or data format, and 188 should not cause interoperability failures. 190 3.1 - Standard policies 192 Implementations SHOULD allow access control policies to use the 193 principal as an authorization token, and MAY also allow policies to 194 grant permission to a signed message regardless of principal. 196 A common practice would be to restrict the permissions of a principal by 197 domain name. That is, a principal could be permitted to add, delete, or 198 modify entries corresponding to one or more domain names. 199 Implementations SHOULD allow per-name access control, and SHOULD provide 200 a concise representation of the principal's own name, its subdomains, 201 and all names in the zone. 203 Additionally, a server SHOULD restrict updates by RR type, so that a 204 principal could add, delete, or modify specific record types at certain 205 names. Implementations SHOULD allow per-type access control, and SHOULD 206 provide concise representations of all types and all ``user'' types, 207 where a user type is defined as one that does not affect the operation 208 of DNS itself. 210 3.1.1 - User types 212 User types include all data types except SOA, NS, SIG, and NXT. SOA and 213 NS SHOULD NOT be modified by normal users, since these types create or 214 modify delegation points. The addition of SIG records can lead to 215 attacks resulting in additional workload for resolvers, and the deletion 216 of SIG records could lead to extra work for the server if the zone SIG 217 was deleted. Note that these records are not forbidden, but not 218 recommended for normal users. 220 NXT records MUST NOT be created, modified, or deleted by dynamic update, 221 as their update may cause instability in the protocol. This is an 222 update to RFC 2136. 224 Issues concerning updates of KEY records are discussed in the Security 225 Considerations section. 227 3.2 - Additional policies 229 Users are free to implement any policies. Policies may be as specific 230 or general as desired, and as complex as desired. They may depend on 231 the principal or any other characteristics of the signed message. 233 4 - Interaction with DNSSEC 235 An authorized update request MAY include SIG records with each RRset. 236 Since SIG records (except SIG(0) records) MUST NOT be used for 237 authentication of the update message, they are not required. If the 238 updated zone is secured, the data affected by an update operation MUST 239 be secured by one or more SIG records. For each RRset, if the update 240 includes a valid signature by a zone key, this signature SHOULD be 241 reused. Otherwise, the server MUST generate SIG records with one or 242 more zone keys (of which the private components MUST be online). If 243 multiple zone keys are online and an RRset requires a signature, a SIG 244 MUST be generated by at least one of the zone keys. 246 If a principal is authorized to add SIG records and there are SIG 247 records in the request, the following rules are applied. If the SIG was 248 generated by a zone key for the relevant zone, verification is attempted 249 (the public key must be available if the determination that it is a zone 250 key was made). If successful, the SIG is retained; otherwise, the SIG 251 is dropped. Otherwise, the SIG is retained without verification, since 252 it is considered immaterial to the DNSSEC validation process. The 253 server MAY examine SIG records and drop SIGs with a temporal validity 254 period in the past. At the completion of the update process, each 255 updated RRset must be signed in accordance with the zone's signing 256 policy; the SIGs must either be included in the update or generated by 257 the server. 259 The server MUST also, if necessary, generate a new SOA record and new 260 NXT records, and sign these with the appropriate zone keys. NXT records 261 are explicitly forbidden. SOA updates are allowed, since the 262 maintenance of SOA parameters is outside of the scope of the DNS 263 protocol. 265 5 - Security considerations 267 This document requires that a zone key and possibly other cryptographic 268 secret material be held in an on-line, network-connected host, most 269 likely a name server. This material is at the mercy of host security to 270 remain a secret. Exposing this secret puts DNS data at risk of 271 masquerade attacks. The data at risk is that in both zones served by 272 the machine and delegated from this machine. 274 Allowing updates of KEY records may lead to undesirable results, since a 275 principal may be allowed to insert a public key without holding the 276 private key, and possibly masquerade as the key owner. 278 6 - Acknowledgements 280 The author would like to thank the following people for review and 281 informative comments (in alphabetical order): 283 Donald Eastlake 284 Olafur Gudmundsson 285 Andreas Gustafsson 286 Bob Halley 287 Stuart Kwan 288 Ed Lewis 290 7 - References 292 [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' 293 RFC 1034, ISI, November 1987. 295 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 296 Specification,'' RFC 1035, ISI, November 1987. 298 [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic 299 Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore 300 & Cisco & DEC, April 1997. 302 [RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC 303 2137, CyberCash, April 1997. 305 [RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC 306 2065, IBM, March 1999. 308 [TSIG] P. Vixie (Ed.), O. Gudmundsson, D. Eastlake, B. Wellington 309 ``Secret Key Transaction Signatures for DNS (TSIG),'' draft- 310 ietf-dnsext-tsig-00.txt, ISC & NAILabs & IBM & NAILabs, March 311 2000. 313 [TKEY] D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),'' 314 draft-ietf-dnsext-tkey-02.txt, IBM, April 2000. 316 [signing-auth] 317 B. Wellington ``Domain Name System Security (DNSSEC) Signing 318 Authority,'' draft-ietf-dnsext-signing-auth-01.txt, Nominum, 319 May 2000. 321 8 - Author's Address 323 Brian Wellington 324 Nominum, Inc. 325 950 Charter Street 326 Redwood City, CA 94063 327 +1 650 779 6022 328 330 9 - Full Copyright Statement 332 Copyright (C) The Internet Society (2000). All Rights Reserved. 334 This document and translations of it may be copied and furnished to 335 others, and derivative works that comment on or otherwise explain it or 336 assist in its implmentation may be prepared, copied, published and 337 distributed, in whole or in part, without restriction of any kind, 338 provided that the above copyright notice and this paragraph are included 339 on all such copies and derivative works. However, this document itself 340 may not be modified in any way, such as by removing the copyright notice 341 or references to the Internet Society or other Internet organizations, 342 except as needed for the purpose of developing Internet standards in 343 which case the procedures for copyrights defined in the Internet 344 Standards process must be followed, or as required to translate it into 345 languages other than English. 347 The limited permissions granted above are perpetual and will not be 348 revoked by the Internet Society or its successors or assigns. 350 This document and the information contained herein is provided on an "AS 351 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 352 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 353 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 354 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 355 FITNESS FOR A PARTICULAR PURPOSE."