idnits 2.17.1 draft-ietf-dnsext-simple-secure-update-02.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: ---------------------------------------------------------------------------- ** 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 abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 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 RFC2535, updated by this document, for RFC5378 checks: 1997-07-24) -- 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 (October 2000) is 8566 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? 'RFC2119' on line 54 looks like a reference -- Missing reference section? 'RFC1034' on line 311 looks like a reference -- Missing reference section? 'RFC1035' on line 314 looks like a reference -- Missing reference section? 'RFC2136' on line 317 looks like a reference -- Missing reference section? 'RFC2535' on line 324 looks like a reference -- Missing reference section? 'RFC2931' on line 334 looks like a reference -- Missing reference section? 'RFC2845' on line 327 looks like a reference -- Missing reference section? 'RFC2930' on line 331 looks like a reference -- Missing reference section? 'RFC2137' on line 321 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSEXT Working Group Brian Wellington (Nominum) 2 INTERNET-DRAFT October 2000 4 6 Updates: RFC 2535, RFC 2136 7 Replaces: RFC 2137 9 Secure Domain Name System (DNS) Dynamic Update 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Comments should be sent to the authors or the DNSEXT WG mailing list 33 namedroppers@ops.ietf.org. 35 This draft expires on April 2, 2000. 37 Copyright Notice 39 Copyright (C) The Internet Society (2000). All rights reserved. 41 Abstract 43 This document proposes a method for performing secure Domain Name 44 System (DNS) dynamic updates. The method described here is intended 45 to be flexible and useful while requiring as few changes to the 46 protocol as possible. The authentication of the dynamic update 47 message is separate from later DNSSEC validation of the data. Secure 48 communication based on authenticated requests and transactions is 49 used to provide authorization. 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 1 - Introduction 57 This document defines a means to secure dynamic updates of the Domain 58 Name System (DNS), allowing only authorized sources to make changes to a 59 zone's contents. The existing unsecured dynamic update operations form 60 the basis for this work. 62 Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update 63 [RFC2136] is helpful and is assumed by this document. In addition, 64 knowledge of DNS security extensions [RFC2535], SIG(0) transaction 65 security [RFC2535, RFC2931], and TSIG transaction security [RFC2845] is 66 recommended. 68 This document updates portions of RFC 2535, in particular section 3.1.2, 69 and RFC 2136. This document obsoletes RFC 2137, an alternate proposal 70 for secure dynamic update, due to implementation experience. 72 1.1 - Overview of DNS Dynamic Update 74 DNS dynamic update defines a new DNS opcode and a new interpretation of 75 the DNS message if that opcode is used. An update can specify 76 insertions or deletions of data, along with prerequisites necessary for 77 the updates to occur. All tests and changes for a DNS update request 78 are restricted to a single zone, and are performed at the primary server 79 for the zone. The primary server for a dynamic zone must increment the 80 zone SOA serial number when an update occurs or before the next 81 retrieval of the SOA. 83 1.2 - Overview of DNS Transaction Security 85 Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0) 86 [RFC2535, RFC2931] records allow two DNS entities to authenticate DNS 87 requests and responses sent between them. A TSIG MAC (message 88 authentication code) is derived from a shared secret, and a SIG(0) is 89 generated from a private key whose public counterpart is stored in DNS. 90 In both cases, a record containing the message signature/MAC is included 91 as the final resource record in a DNS message. Keyed hashes, used in 92 TSIG, are inexpensive to calculate and verify. Public key encryption, 93 as used in SIG(0), is more scalable as the public keys are stored in 94 DNS. 96 1.3 - Comparison of data authentication and message authentication 98 Message based authentication, using TSIG or SIG(0), provides protection 99 for the entire message with a single signing and single verification 100 which, in the case of TSIG, is a relatively inexpensive MAC creation and 101 check. For update requests, this signature can establish, based on 102 policy or key negotation, the authority to make the request. 104 DNSSEC SIG records can be used to protect the integrity of individual 105 RRs or RRsets in a DNS message with the authority of the zone owner. 106 However, this cannot sufficiently protect the dynamic update request. 108 Using SIG records to secure RRsets in an update request is incompatible 109 with the design of update, as described below, and would in any case 110 require multiple expensive public key signatures and verifcations. 112 SIG records do not cover the message header, which includes record 113 counts. Therefore, it is possibly to maliciously insert or remove 114 RRsets in an update request without causing a verification failure. 116 If SIG records were used to protect the prerequisite section, it would 117 be impossible to determine whether the SIGs themselves were a 118 prerequisite or simply used for validation. 120 In the update section of an update request, signing requests to add an 121 RRset is straightforward, and this signature could be permanently used 122 to protect the data, as specified in [RFC2535]. However, if an RRset is 123 deleted, there is no data for a SIG to cover. 125 1.4 - Data and message signatures 127 As specified in [signing-auth], the DNSSEC validation process performed 128 by a resolver MUST NOT process any non-zone keys unless local policy 129 dictates otherwise. When performing secure dynamic update, all zone 130 data modified in a signed zone MUST be signed by a relevant zone key. 131 This completely disassociates authentication of an update request from 132 authentication of the data itself. 134 The primary usefulness of host and user keys, with respect to DNSSEC, is 135 to authenticate messages, including dynamic updates. Thus, host and 136 user keys MAY be used to generate SIG(0) records to authenticate updates 137 and MAY be used in the TKEY [RFC2930] process to generate TSIG shared 138 secrets. In both cases, no SIG records generated by non-zone keys will 139 be used in a DNSSEC validation process unless local policy dictates. 141 Authentication of data, once it is present in DNS, only involves DNSSEC 142 zone keys and signatures generated by them. 144 1.5 - Signatory strength 146 [RFC2535, section 3.1.2] defines the signatory field of a key as the 147 final 4 bits of the flags field, but does not define its value. This 148 proposal leaves this field undefined. Updating [RFC2535], this field 149 SHOULD be set to 0 in KEY records, and MUST be ignored. 151 2 - Authentication 153 TSIG or SIG(0) records MUST be included in all secure dynamic update 154 messages. This allows the server to verifiably determine the originator 155 of a message. If the message contains authentication in the form of a 156 SIG(0), the identity of the sender (that is, the principal) is the owner 157 of the KEY RR that generated the SIG(0). If the message contains a TSIG 158 generated by a statically configured shared secret, the principal is the 159 same as or derived from the shared secret name. If the message contains 160 a TSIG generated by a dynamically configured shared secret, the 161 principal is the same as the one that authenticated the TKEY process; if 162 the TKEY process was unauthenticated, no information is known about the 163 principal, and the associated TSIG shared secret MUST NOT be used for 164 secure dynamic update. 166 SIG(0) signatures SHOULD NOT be generated by zone keys, since 167 transactions are initiated by a host or user, not a zone. 169 DNSSEC SIG records (other than SIG(0)) MAY be included in an update 170 message, but MUST NOT be used to authenticate the update request. 172 If an update fails because it is signed with an unauthorized key, the 173 server MUST indicate failure by returning a message with RCODE REFUSED. 174 Other TSIG, SIG(0), or dynamic update errors are returned as specified 175 in the appropriate protocol description. 177 3 - Policy 179 All policy is configured by the zone administrator and enforced by the 180 zone's primary name server. Policy dictates the authorized actions that 181 an authenticated principal can take. Policy checks are based on the 182 principal and the desired action, where the principal is derived from 183 the message signing key and applied to dynamic update messages signed 184 with that key. 186 The server's policy defines criteria which determine if the key used to 187 sign the update is permitted to perform the requested updates. By 188 default, a principal MUST NOT be permitted to make any changes to zone 189 data; any permissions MUST be enabled though configuration. 191 The policy is fully implemented in the primary zone server's 192 configuration for several reasons. This removes limitations imposed by 193 encoding policy into a fixed number of bits (such as the KEY RR's 194 signatory field). Policy is only relevant in the server applying it, so 195 there is no reason to expose it. Finally, a change in policy or a new 196 type of policy should not affect the DNS protocol or data format, and 197 should not cause interoperability failures. 199 3.1 - Standard policies 201 Implementations SHOULD allow access control policies to use the 202 principal as an authorization token, and MAY also allow policies to 203 grant permission to a signed message regardless of principal. 205 A common practice would be to restrict the permissions of a principal by 206 domain name. That is, a principal could be permitted to add, delete, or 207 modify entries corresponding to one or more domain names. 208 Implementations SHOULD allow per-name access control, and SHOULD provide 209 a concise representation of the principal's own name, its subdomains, 210 and all names in the zone. 212 Additionally, a server SHOULD restrict updates by RR type, so that a 213 principal could add, delete, or modify specific record types at certain 214 names. Implementations SHOULD allow per-type access control, and SHOULD 215 provide concise representations of all types and all ``user'' types, 216 where a user type is defined as one that does not affect the operation 217 of DNS itself. 219 3.1.1 - User types 221 User types include all data types except SOA, NS, SIG, and NXT. SOA and 222 NS SHOULD NOT be modified by normal users, since these types create or 223 modify delegation points. The addition of SIG records can lead to 224 attacks resulting in additional workload for resolvers, and the deletion 225 of SIG records could lead to extra work for the server if the zone SIG 226 was deleted. Note that these records are not forbidden, but not 227 recommended for normal users. 229 NXT records MUST NOT be created, modified, or deleted by dynamic update, 230 as their update may cause instability in the protocol. This is an 231 update to RFC 2136. 233 Issues concerning updates of KEY records are discussed in the Security 234 Considerations section. 236 3.2 - Additional policies 238 Users are free to implement any policies. Policies may be as specific 239 or general as desired, and as complex as desired. They may depend on 240 the principal or any other characteristics of the signed message. 242 4 - Interaction with DNSSEC 244 Although this protocol does not change the way updates to secure zones 245 are processed, there are a number of issues that should be clarified. 247 4.1 - Adding SIGs 248 An authorized update request MAY include SIG records with each RRset. 249 Since SIG records (except SIG(0) records) MUST NOT be used for 250 authentication of the update message, they are not required. 252 If a principal is authorized to update SIG records and there are SIG 253 records in the update, the SIG records are added without verification. 254 The server MAY examine SIG records and drop SIGs with a temporal 255 validity period in the past. 257 4.2 - Deleting SIGs 259 If a principal is authorized to update SIG records and the update 260 specifies the deletion of SIG records, the server MAY choose to override 261 the authority and refuse the update. For example, the server may allow 262 all SIG records not generated by a zone key to be deleted. 264 4.3 - Non-explicit updates to SIGs 266 If the updated zone is secured, the RRset affected by an update 267 operation MUST, at the completion of the update, be signed in accordance 268 with the zone's signing policy. This will usually require one or more 269 SIG records to be generated by one or more zone keys whose private 270 components MUST be online [signing-auth]. 272 When the contents of an RRset are updated, the server MAY delete all 273 associated SIG records, since they will no longer be valid. 275 4.4 - Effects on the zone 277 If any changes are made, the server MUST, if necessary, generate a new 278 SOA record and new NXT records, and sign these with the appropriate zone 279 keys. Changes to NXT records by secure dynamic update are explicitly 280 forbidden. SOA updates are allowed, since the maintenance of SOA 281 parameters is outside of the scope of the DNS protocol. 283 5 - Security considerations 285 This document requires that a zone key and possibly other cryptographic 286 secret material be held in an on-line, network-connected host, most 287 likely a name server. This material is at the mercy of host security to 288 remain a secret. Exposing this secret puts DNS data at risk of 289 masquerade attacks. The data at risk is that in both zones served by 290 the machine and delegated from this machine. 292 Allowing updates of KEY records may lead to undesirable results, since a 293 principal may be allowed to insert a public key without holding the 294 private key, and possibly masquerade as the key owner. 296 6 - Acknowledgements 298 The author would like to thank the following people for review and 299 informative comments (in alphabetical order): 301 Harald Alvestrand 302 Donald Eastlake 303 Olafur Gudmundsson 304 Andreas Gustafsson 305 Bob Halley 306 Stuart Kwan 307 Ed Lewis 309 7 - References 311 [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' 312 RFC 1034, ISI, November 1987. 314 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 315 Specification,'' RFC 1035, ISI, November 1987. 317 [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic 318 Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore 319 & Cisco & DEC, April 1997. 321 [RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC 322 2137, CyberCash, April 1997. 324 [RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC 325 2535, IBM, March 1999. 327 [RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington ``Secret 328 Key Transaction Signatures for DNS (TSIG),'' RFC 2845, ISC & 329 NAILabs & Motorola & Nominum, May 2000. 331 [RFC2930] D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),'' 332 RFC 2930, Motorola, September 2000. 334 [RFC2931] D. Eastlake ``DNS Request and Transaction Signatures ( 335 SIG(0)s ),'' RFC 2931, Motorola, September 2000. 337 [signing-auth] 338 B. Wellington ``Domain Name System Security (DNSSEC) Signing 339 Authority,'' draft-ietf-dnsext-signing-auth-02.txt, Nominum, 340 October 2000. 342 8 - Author's Address 344 Brian Wellington 345 Nominum, Inc. 346 950 Charter Street 347 Redwood City, CA 94063 348 +1 650 779 6022 349 351 9 - Full Copyright Statement 353 Copyright (C) The Internet Society (2000). All Rights Reserved. 355 This document and translations of it may be copied and furnished to 356 others, and derivative works that comment on or otherwise explain it or 357 assist in its implmentation may be prepared, copied, published and 358 distributed, in whole or in part, without restriction of any kind, 359 provided that the above copyright notice and this paragraph are included 360 on all such copies and derivative works. However, this document itself 361 may not be modified in any way, such as by removing the copyright notice 362 or references to the Internet Society or other Internet organizations, 363 except as needed for the purpose of developing Internet standards in 364 which case the procedures for copyrights defined in the Internet 365 Standards process must be followed, or as required to translate it into 366 languages other than English. 368 The limited permissions granted above are perpetual and will not be 369 revoked by the Internet Society or its successors or assigns. 371 This document and the information contained herein is provided on an "AS 372 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 373 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 374 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 375 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 376 FITNESS FOR A PARTICULAR PURPOSE."