doc: Add RFC documents

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]
+