diff options
Diffstat (limited to 'doc/rfc/rfc3007.txt')
| -rw-r--r-- | doc/rfc/rfc3007.txt | 507 |
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc3007.txt b/doc/rfc/rfc3007.txt new file mode 100644 index 0000000..1697475 --- /dev/null +++ b/doc/rfc/rfc3007.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group B. Wellington +Request for Comments: 3007 Nominum +Updates: 2535, 2136 November 2000 +Obsoletes: 2137 +Category: Standards Track + + + Secure Domain Name System (DNS) Dynamic Update + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This document proposes a method for performing secure Domain Name + System (DNS) dynamic updates. The method described here is intended + to be flexible and useful while requiring as few changes to the + protocol as possible. The authentication of the dynamic update + message is separate from later DNSSEC validation of the data. Secure + communication based on authenticated requests and transactions is + used to provide authorization. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +1 - Introduction + + This document defines a means to secure dynamic updates of the Domain + Name System (DNS), allowing only authorized sources to make changes + to a zone's contents. The existing unsecured dynamic update + operations form the basis for this work. + + Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update + [RFC2136] is helpful and is assumed by this document. In addition, + knowledge of DNS security extensions [RFC2535], SIG(0) transaction + security [RFC2535, RFC2931], and TSIG transaction security [RFC2845] + is recommended. + + + + +Wellington Standards Track [Page 1] + +RFC 3007 Secure Dynamic Update November 2000 + + + This document updates portions of RFC 2535, in particular section + 3.1.2, and RFC 2136. This document obsoletes RFC 2137, an alternate + proposal for secure dynamic update, due to implementation experience. + +1.1 - Overview of DNS Dynamic Update + + DNS dynamic update defines a new DNS opcode and a new interpretation + of the DNS message if that opcode is used. An update can specify + insertions or deletions of data, along with prerequisites necessary + for the updates to occur. All tests and changes for a DNS update + request are restricted to a single zone, and are performed at the + primary server for the zone. The primary server for a dynamic zone + must increment the zone SOA serial number when an update occurs or + before the next retrieval of the SOA. + +1.2 - Overview of DNS Transaction Security + + Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0) + [RFC2535, RFC2931] records allow two DNS entities to authenticate DNS + requests and responses sent between them. A TSIG MAC (message + authentication code) is derived from a shared secret, and a SIG(0) is + generated from a private key whose public counterpart is stored in + DNS. In both cases, a record containing the message signature/MAC is + included as the final resource record in a DNS message. Keyed + hashes, used in TSIG, are inexpensive to calculate and verify. + Public key encryption, as used in SIG(0), is more scalable as the + public keys are stored in DNS. + +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 negotiation, the authority to make + the request. + + DNSSEC SIG records can be used to protect the integrity of individual + 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 + verifications. + + + + + + +Wellington Standards Track [Page 2] + +RFC 3007 Secure Dynamic Update November 2000 + + + SIG records do not cover the message header, which includes record + counts. Therefore, it is possible to maliciously insert or remove + 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 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 + + As specified in [RFC3008], the DNSSEC validation process performed by + a resolver MUST NOT process any non-zone keys unless local policy + dictates otherwise. When performing secure dynamic update, all zone + data modified in a signed zone MUST be signed by a relevant zone key. + This completely disassociates authentication of an update request + from authentication of the data itself. + + The primary usefulness of host and user keys, with respect to DNSSEC, + is to authenticate messages, including dynamic updates. Thus, host + and user keys MAY be used to generate SIG(0) records to authenticate + updates and MAY be used in the TKEY [RFC2930] 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. + + Authentication of data, once it is present in DNS, only involves + DNSSEC zone keys and signatures generated by them. + +1.5 - Signatory strength + + [RFC2535, section 3.1.2] defines the signatory field of a key as the + final 4 bits of the flags field, but does not define its value. This + proposal leaves this field undefined. Updating [RFC2535], this field + SHOULD be set to 0 in KEY records, and MUST be ignored. + +2 - Authentication + + TSIG or SIG(0) records MUST be included in all secure dynamic update + messages. This allows the server to verifiably determine the + originator of a message. If the message contains authentication in + the form of a SIG(0), the identity of the sender (that is, the + principal) is the owner of the KEY RR that generated the SIG(0). If + the message contains a TSIG generated by a statically configured + + + +Wellington Standards Track [Page 3] + +RFC 3007 Secure Dynamic Update November 2000 + + + shared secret, the principal is the same as or derived from the + shared secret name. If the message contains a TSIG generated by a + dynamically configured shared secret, the principal is the same as + the one that authenticated the TKEY process; if the TKEY process was + unauthenticated, no information is known about the principal, and the + associated TSIG shared secret MUST NOT be used for secure dynamic + update. + + SIG(0) signatures SHOULD NOT be generated by zone keys, since + transactions are initiated by a host or user, not a zone. + + DNSSEC SIG records (other than SIG(0)) MAY be included in an update + message, but MUST NOT be used to authenticate the update request. + + If an update fails because it is signed with an unauthorized key, the + 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. + +3 - Policy + + All policy is configured by the zone administrator and enforced by + the zone's primary name server. Policy dictates the authorized + actions that an authenticated principal can take. Policy checks are + based on the principal and the desired action, where the principal is + derived from the message signing key and applied to dynamic update + messages signed with that key. + + The server's policy defines criteria which determine if the key used + to 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. + + 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 + signatory field). Policy is only relevant in the server applying it, + so there is no reason to expose it. Finally, a change in policy or a + new type of policy should not affect the DNS protocol or data format, + and should not cause interoperability failures. + +3.1 - Standard policies + + Implementations SHOULD allow access control policies to use the + principal as an authorization token, and MAY also allow policies to + grant permission to a signed message regardless of principal. + + + + + +Wellington Standards Track [Page 4] + +RFC 3007 Secure Dynamic Update November 2000 + + + A common practice would be to restrict the permissions of a principal + by domain name. That is, a principal could be permitted to add, + delete, or modify entries corresponding to one or more domain names. + Implementations SHOULD allow per-name access control, and SHOULD + provide a concise representation of the principal's own name, its + subdomains, and all names in the zone. + + Additionally, a server SHOULD allow restricting updates by RR type, + so that a principal could add, delete, or modify specific record + types at certain names. Implementations SHOULD allow per-type access + control, and SHOULD provide concise representations of all types and + all "user" types, where a user type is defined as one that does not + affect the operation of DNS itself. + +3.1.1 - User types + + User types include all data types except SOA, NS, SIG, and NXT. SOA + and NS records SHOULD NOT be modified by normal users, since these + types create or 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 was deleted. Note that these records + are not forbidden, but not recommended for normal users. + + NXT records MUST NOT be created, modified, or deleted by dynamic + update, as their update may cause instability in the protocol. This + is an update to RFC 2136. + + Issues concerning updates of KEY records are discussed in the + Security Considerations section. + +3.2 - Additional policies + + Users are free to implement any policies. Policies may be as + specific or general as desired, and as complex as desired. They may + depend on the principal or any other characteristics of the signed + message. + +4 - Interaction with DNSSEC + + Although this protocol does not change the way updates to secure + zones are processed, there are a number of issues that should be + clarified. + + + + + + + + +Wellington Standards Track [Page 5] + +RFC 3007 Secure Dynamic Update November 2000 + + +4.1 - Adding SIGs + + An authorized update request MAY include SIG records with each RRset. + Since SIG records (except SIG(0) records) MUST NOT be used for + authentication of the update message, they are not required. + + If a principal is authorized to update SIG records and there are SIG + records in the update, the SIG records are added without + verification. The server MAY examine SIG records and drop SIGs with + a temporal validity period in the past. + +4.2 - Deleting SIGs + + If a principal is authorized to update SIG records and the update + specifies the deletion of SIG records, the server MAY choose to + override the authority and refuse the update. For example, the + server may allow all SIG records not generated by a zone key to be + deleted. + +4.3 - Non-explicit updates to SIGs + + If the updated zone is secured, the RRset affected by an update + operation MUST, at the completion of the update, be signed in + accordance with the zone's signing policy. This will usually require + one or more SIG records to be generated by one or more zone keys + whose private components MUST be online [RFC3008]. + + When the contents of an RRset are updated, the server MAY delete all + associated SIG records, since they will no longer be valid. + +4.4 - Effects on the zone + + If any changes are made, the server MUST, if necessary, generate a + new SOA record and new NXT records, and sign these with the + appropriate zone keys. Changes to NXT records by secure dynamic + update are explicitly forbidden. SOA updates are allowed, since the + maintenance of SOA parameters is outside of the scope of the DNS + protocol. + +5 - Security Considerations + + This document requires that a zone key and possibly other + cryptographic secret material be held in an on-line, network- + connected host, most likely a name server. This material is at the + mercy of host security to remain a secret. Exposing this secret puts + DNS data at risk of masquerade attacks. The data at risk is that in + both zones served by the machine and delegated from this machine. + + + + +Wellington Standards Track [Page 6] + +RFC 3007 Secure Dynamic Update November 2000 + + + Allowing updates of KEY records may lead to undesirable results, + since a principal may be allowed to insert a public key without + holding the private key, and possibly masquerade as the key owner. + +6 - Acknowledgements + + The author would like to thank the following people for review and + informative comments (in alphabetical order): + + Harald Alvestrand + Donald Eastlake + Olafur Gudmundsson + Andreas Gustafsson + Bob Halley + Stuart Kwan + Ed Lewis + +7 - References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound, + "Dynamic Updates in the Domain Name System", RFC 2136, + April 1997. + + [RFC2137] Eastlake, D., "Secure Domain Name System Dynamic Update", + RFC 2137, April 1997. + + [RFC2535] Eastlake, G., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Signatures for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + + [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) + Signing Authority", RFC 3008, November 2000. + + + + +Wellington Standards Track [Page 7] + +RFC 3007 Secure Dynamic Update November 2000 + + +8 - Author's Address + + Brian Wellington + Nominum, Inc. + 950 Charter Street + Redwood City, CA 94063 + + Phone: +1 650 381 6022 + EMail: Brian.Wellington@nominum.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wellington Standards Track [Page 8] + +RFC 3007 Secure Dynamic Update November 2000 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + 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 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Wellington Standards Track [Page 9] + |