diff options
Diffstat (limited to 'doc/rfc/rfc2137.txt')
| -rw-r--r-- | doc/rfc/rfc2137.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc2137.txt b/doc/rfc/rfc2137.txt new file mode 100644 index 0000000..ceb3613 --- /dev/null +++ b/doc/rfc/rfc2137.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group D. Eastlake 3rd +Request for Comments: 2137 CyberCash, Inc. +Updates: 1035 April 1997 +Category: Standards Track + + + Secure Domain Name System 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. + +Abstract + + Domain Name System (DNS) protocol extensions have been defined to + authenticate the data in DNS and provide key distribution services + [RFC2065]. DNS Dynamic Update operations have also been defined + [RFC2136], but without a detailed description of security for the + update operation. This memo describes how to use DNSSEC digital + signatures covering requests and data to secure updates and restrict + updates to those authorized to perform them as indicated by the + updater's possession of cryptographic keys. + +Acknowledgements + + The contributions of the following persons (who are listed in + alphabetic order) to this memo are gratefully acknowledged: + + Olafur Gudmundsson (ogud@tis.com> + Charlie Kaufman <Charlie_Kaufman@iris.com> + Stuart Kwan <skwan@microsoft.com> + Edward Lewis <lewis@tis.com> + +Table of Contents + + 1. Introduction............................................2 + 1.1 Overview of DNS Dynamic Update.........................2 + 1.2 Overview of DNS Security...............................2 + 2. Two Basic Modes.........................................3 + 3. Keys....................................................5 + 3.1 Update Keys............................................6 + 3.1.1 Update Key Name Scope................................6 + 3.1.2 Update Key Class Scope...............................6 + 3.1.3 Update Key Signatory Field...........................6 + + + +Eastlake Standards Track [Page 1] + +RFC 2137 SDNSDU April 1997 + + + 3.2 Zone Keys and Update Modes.............................8 + 3.3 Wildcard Key Punch Through.............................9 + 4. Update Signatures.......................................9 + 4.1 Update Request Signatures..............................9 + 4.2 Update Data Signatures................................10 + 5. Security Considerations................................10 + References................................................10 + Author's Address..........................................11 + +1. Introduction + + Dynamic update operations have been defined for the Domain Name + System (DNS) in RFC 2136, but without a detailed description of + security for those updates. Means of securing the DNS and using it + for key distribution have been defined in RFC 2065. + + This memo proposes techniques based on the defined DNS security + mechanisms to authenticate DNS updates. + + Familiarity with the DNS system [RFC 1034, 1035] is assumed. + Familiarity with the DNS security and dynamic update proposals will + be helpful. + +1.1 Overview of DNS Dynamic Update + + DNS dynamic update defines a new DNS opcode, new DNS request and + response structure if that opcode is used, and new error codes. An + update can specify complex combinations of deletion and insertion + (with or without pre-existence testing) of resource records (RRs) + with one or more owner names; however, all testing and changes for + any particular DNS update request are restricted to a single zone. + Updates occur at the primary server for a zone. + + The primary server for a secure dynamic zone must increment the zone + SOA serial number when an update occurs or the next time the SOA is + retrieved if one or more updates have occurred since the previous SOA + retrieval and the updates themselves did not update the SOA. + +1.2 Overview of DNS Security + + DNS security authenticates data in the DNS by also storing digital + signatures in the DNS as SIG resource records (RRs). A SIG RR + provides a digital signature on the set of all RRs with the same + owner name and class as the SIG and whose type is the type covered by + the SIG. The SIG RR cryptographically binds the covered RR set to + the signer, time signed, signature expiration date, etc. There are + one or more keys associated with every secure zone and all data in + the secure zone is signed either by a zone key or by a dynamic update + + + +Eastlake Standards Track [Page 2] + +RFC 2137 SDNSDU April 1997 + + + key tracing its authority to a zone key. + + DNS security also defines transaction SIGs and request SIGs. + Transaction SIGs appear at the end of a response. Transaction SIGs + authenticate the response and bind it to the corresponding request + with the key of the host where the responding DNS server is. Request + SIGs appear at the end of a request and authenticate the request with + the key of the submitting entity. + + Request SIGs are the primary means of authenticating update requests. + + DNS security also permits the storage of public keys in the DNS via + KEY RRs. These KEY RRs are also, of course, authenticated by SIG + RRs. KEY RRs for zones are stored in their superzone and subzone + servers, if any, so that the secure DNS tree of zones can be + traversed by a security aware resolver. + +2. Two Basic Modes + + A dynamic secure zone is any secure DNS zone containing one or more + KEY RRs that can authorize dynamic updates, i.e., entity or user KEY + RRs with the signatory field non-zero, and whose zone KEY RR + signatory field indicates that updates are implemented. There are two + basic modes of dynamic secure zone which relate to the update + strategy, mode A and mode B. A summary comparison table is given + below and then each mode is described. + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 3] + +RFC 2137 SDNSDU April 1997 + + + SUMMARY OF DYNAMIC SECURE ZONE MODES + + CRITERIA: | MODE A | MODE B + =========================+====================+=================== + Definition: | Zone Key Off line | Zone Key On line + =========================+====================+=================== + Server Workload | Low | High + -------------------------+--------------------+------------------- + Static Data Security | Very High | Medium-High + -------------------------+--------------------+------------------- + Dynamic Data Security | Medium | Medium-High + -------------------------+--------------------+------------------- + Key Restrictions | Fine grain | Coarse grain + -------------------------+--------------------+------------------- + Dynamic Data Temporality | Transient | Permanent + -------------------------+--------------------+------------------- + Dynamic Key Rollover | No | Yes + -------------------------+--------------------+------------------- + + For mode A, the zone owner key and static zone master file are always + kept off-line for maximum security of the static zone contents. + + As a consequence, any dynamicly added or changed RRs are signed in + the secure zone by their authorizing dynamic update key and they are + backed up, along with this SIG RR, in a separate online dynamic + master file. In this type of zone, server computation is minimized + since the server need only check signatures on the update data and + request, which have already been signed by the updater, generally a + much faster operation than signing data. However, the AXFR SIG and + NXT RRs which covers the zone under the zone key will not cover + dynamically added data. Thus, for type A dynamic secure zones, zone + transfer security is not automatically provided for dynamically added + RRs, where they could be omitted, and authentication is not provided + for the server denial of the existence of a dynamically added type. + Because the dynamicly added RRs retain their update KEY signed SIG, + finer grained control of updates can be implemented via bits in the + KEY RR signatory field. Because dynamic data is only stored in the + online dynamic master file and only authenticated by dynamic keys + which expire, updates are transient in nature. Key rollover for an + entity that can authorize dynamic updates is more cumbersome since + the authority of their key must be traceable to a zone key and so, in + general, they must securely communicate a new key to the zone + authority for manual transfer to the off line static master file. + NOTE: for this mode the zone SOA must be signed by a dynamic update + key and that private key must be kept on line so that the SOA can be + changed for updates. + + + + + +Eastlake Standards Track [Page 4] + +RFC 2137 SDNSDU April 1997 + + + For mode B, the zone owner key and master file are kept on-line at + the zone primary server. When authenticated updates succeed, SIGs + under the zone key for the resulting data (including the possible NXT + type bit map changes) are calculated and these SIG (and possible NXT) + changes are entered into the zone and the unified on-line master + file. (The zone transfer AXFR SIG may be recalculated for each + update or on demand when a zone transfer is requested and it is out + of date.) + + As a consequence, this mode requires considerably more computational + effort on the part of the server as the public/private keys are + generally arranged so that signing (calculating a SIG) is more effort + than verifying a signature. The security of static data in the zone + is decreased because the ultimate state of the static data being + served and the ultimate zone authority private key are all on-line on + the net. This means that if the primary server is subverted, false + data could be authenticated to secondaries and other + servers/resolvers. On the other hand, this mode of operation means + that data added dynamically is more secure than in mode A. Dynamic + data will be covered by the AXFR SIG and thus always protected during + zone transfers and will be included in NXT RRs so that it can be + falsely denied by a server only to the same extent that static data + can (i.e., if it is within a wild card scope). Because the zone key + is used to sign all the zone data, the information as to who + originated the current state of dynamic RR sets is lost, making + unavailable the effects of some of the update control bits in the KEY + RR signatory field. In addition, the incorporation of the updates + into the primary master file and their authentication by the zone key + makes then permanent in nature. Maintaining the zone key on-line + also means that dynamic update keys which are signed by the zone key + can be dynamically updated since the zone key is available to + dynamically sign new values. + + NOTE: The Mode A / Mode B distinction only effects the validation + and performance of update requests. It has no effect on retrievals. + One reasonable operational scheme may be to keep a mostly static main + zone operating in Mode A and have one or more dynamic subzones + operating in Mode B. + +3. Keys + + Dynamic update requests depend on update keys as described in section + 3.1 below. In addition, the zone secure dynamic update mode and + availability of some options is indicated in the zone key. Finally, + a special rule is used in searching for KEYs to validate updates as + described in section 3.3. + + + + + +Eastlake Standards Track [Page 5] + +RFC 2137 SDNSDU April 1997 + + +3.1 Update Keys + + All update requests to a secure zone must include signatures by one + or more key(s) that together can authorize that update. In order for + the Domain Name System (DNS) server receiving the request to confirm + this, the key or keys must be available to and authenticated by that + server as a specially flagged KEY Resource Record. + + The scope of authority of such keys is indicated by their KEY RR + owner name, class, and signatory field flags as described below. In + addition, such KEY RRs must be entity or user keys and not have the + authentication use prohibited bit on. All parts of the actual update + must be within the scope of at least one of the keys used for a + request SIG on the update request as described in section 4. + +3.1.1 Update Key Name Scope + + The owner name of any update authorizing KEY RR must (1) be the same + as the owner name of any RRs being added or deleted or (2) a wildcard + name including within its extended scope (see section 3.3) the name + of any RRs being added or deleted and those RRs must be in the same + zone. + +3.1.2 Update Key Class Scope + + The class of any update authorizing KEY RR must be the same as the + class of any RR's being added or deleted. + +3.1.3 Update Key Signatory Field + + The four bit "signatory field" (see RFC 2065) of any update + authorizing KEY RR must be non-zero. The bits have the meanings + described below for non-zone keys (see section 3.2 for zone type + keys). + + UPDATE KEY RR SIGNATORY FIELD BITS + + 0 1 2 3 + +-----------+-----------+-----------+-----------+ + | zone | strong | unique | general | + +-----------+-----------+-----------+-----------+ + + Bit 0, zone control - If nonzero, this key is authorized to attach, + detach, and move zones by creating and deleting NS, glue A, and + zone KEY RR(s). If zero, the key can not authorize any update + that would effect such RRs. This bit is meaningful for both + type A and type B dynamic secure zones. + + + + +Eastlake Standards Track [Page 6] + +RFC 2137 SDNSDU April 1997 + + + NOTE: do not confuse the "zone" signatory field bit with the + "zone" key type bit. + + Bit 1, strong update - If nonzero, this key is authorized to add and + delete RRs even if there are other RRs with the same owner name + and class that are authenticated by a SIG signed with a + different dynamic update KEY. If zero, the key can only + authorize updates where any existing RRs of the same owner and + class are authenticated by a SIG using the same key. This bit + is meaningful only for type A dynamic zones and is ignored in + type B dynamic zones. + + Keeping this bit zero on multiple KEY RRs with the same or + nested wild card owner names permits multiple entities to exist + that can create and delete names but can not effect RRs with + different owner names from any they created. In effect, this + creates two levels of dynamic update key, strong and weak, where + weak keys are limited in interfering with each other but a + strong key can interfere with any weak keys or other strong + keys. + + Bit 2, unique name update - If nonzero, this key is authorized to add + and update RRs for only a single owner name. If there already + exist RRs with one or more names signed by this key, they may be + updated but no new name created until the number of existing + names is reduced to zero. This bit is meaningful only for mode + A dynamic zones and is ignored in mode B dynamic zones. This bit + is meaningful only if the owner name is a wildcard. (Any + dynamic update KEY with a non-wildcard name is, in effect, a + unique name update key.) + + This bit can be used to restrict a KEY from flooding a zone with + new names. In conjunction with a local administratively imposed + limit on the number of dynamic RRs with a particular name, it + can completely restrict a KEY from flooding a zone with RRs. + + Bit 3, general update - The general update signatory field bit has no + special meaning. If the other three bits are all zero, it must + be one so that the field is non-zero to designate that the key + is an update key. The meaning of all values of the signatory + field with the general bit and one or more other signatory field + bits on is reserved. + + All the signatory bit update authorizations described above only + apply if the update is within the name and class scope as per + sections 3.1.1 and 3.1.2. + + + + + +Eastlake Standards Track [Page 7] + +RFC 2137 SDNSDU April 1997 + + +3.2 Zone Keys and Update Modes + + Zone type keys are automatically authorized to sign anything in their + zone, of course, regardless of the value of their signatory field. + For zone keys, the signatory field bits have different means than + they they do for update keys, as shown below. The signatory field + MUST be zero if dynamic update is not supported for a zone and MUST + be non-zero if it is. + + ZONE KEY RR SIGNATORY FIELD BITS + + 0 1 2 3 + +-----------+-----------+-----------+-----------+ + | mode | strong | unique | general | + +-----------+-----------+-----------+-----------+ + + Bit 0, mode - This bit indicates the update mode for this zone. Zero + indicates mode A while a one indicates mode B. + + Bit 1, strong update - If nonzero, this indicates that the "strong" + key feature described in section 3.1.3 above is implemented and + enabled for this secure zone. If zero, the feature is not + available. Has no effect if the zone is a mode B secure update + zone. + + Bit 2, unique name update - If nonzero, this indicates that the + "unique name" feature described in section 3.1.3 above is + implemented and enabled for this secure zone. If zero, this + feature is not available. Has no effect if the zone is a mode B + secure update zone. + + Bit 3, general - This bit has no special meeting. If dynamic update + for a zone is supported and the other bits in the zone key + signatory field are zero, it must be a one. The meaning of zone + keys where the signatory field has the general bit and one or + more other bits on is reserved. + + If there are multiple dynamic update KEY RRs for a zone and zone + policy is in transition, they might have different non-zero signatory + fields. In that case, strong and unique name restrictions must be + enforced as long as there is a non-expired zone key being advertised + that indicates mode A with the strong or unique name bit on + respectively. Mode B updates MUST be supported as long as there is a + non-expired zone key that indicates mode B. Mode A updates may be + treated as mode B updates at server option if non-expired zone keys + indicate that both are supported. + + + + + +Eastlake Standards Track [Page 8] + +RFC 2137 SDNSDU April 1997 + + + A server that will be executing update operations on a zone, that is, + the primary master server, MUST not advertize a zone key that will + attract requests for a mode or features that it can not support. + +3.3 Wildcard Key Punch Through + + Just as a zone key is valid throughout the entire zone, update keys + with wildcard names are valid throughout their extended scope, within + the zone. That is, they remain valid for any name that would match + them, even existing specific names within their apparent scope. + + If this were not so, then whenever a name within a wildcard scope was + created by dynamic update, it would be necessary to first create a + copy of the KEY RR with this name, because otherwise the existence of + the more specific name would hide the authorizing KEY RR and would + make later updates impossible. An updater could create such a KEY RR + but could not zone sign it with their authorizing signer. They would + have to sign it with the same key using the wildcard name as signer. + Thus in creating, for example, one hundred type A RRs authorized by a + *.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100 + KEYs, and 200 SIGs would have to be created as opposed to merely 100 + As and 100 SIGs with key punch through. + +4. Update Signatures + + Two kinds of signatures can appear in updates. Request signatures, + which are always required, cover the entire request and authenticate + the DNS header, including opcode, counts, etc., as well as the data. + Data signatures, on the other hand, appear only among the RRs to be + added and are only required for mode A operation. These two types of + signatures are described further below. + +4.1 Update Request Signatures + + An update can effect multiple owner names in a zone. It may be that + these different names are covered by different dynamic update keys. + For every owner name effected, the updater must know a private key + valid for that name (and the zone's class) and must prove this by + appending request SIG RRs under each such key. + + As specified in RFC 2065, a request signature is a SIG RR occurring + at the end of a request with a type covered field of zero. For an + update, request signatures occur in the Additional information + section. Each request SIG signs the entire request, including DNS + header, but excluding any other request SIG(s) and with the ARCOUNT + in the DNS header set to what it wold be without the request SIGs. + + + + + +Eastlake Standards Track [Page 9] + +RFC 2137 SDNSDU April 1997 + + +4.2 Update Data Signatures + + Mode A dynamic secure zones require that the update requester provide + SIG RRs that will authenticate the after update state of all RR sets + that are changed by the update and are non-empty after the update. + These SIG RRs appear in the request as RRs to be added and the + request must delete any previous data SIG RRs that are invalidated by + the request. + + In Mode B dynamic secure zones, all zone data is authenticated by + zone key SIG RRs. In this case, data signatures need not be included + with the update. A resolver can determine which mode an updatable + secure zone is using by examining the signatory field bits of the + zone KEY RR (see section 3.2). + +5. Security Considerations + + Any zone permitting dynamic updates is inherently less secure than a + static secure zone maintained off line as recommended in RFC 2065. If + nothing else, secure dynamic update requires on line change to and + re-signing of the zone SOA resource record (RR) to increase the SOA + serial number. This means that compromise of the primary server host + could lead to arbitrary serial number changes. + + Isolation of dynamic RRs to separate zones from those holding most + static RRs can limit the damage that could occur from breach of a + dynamic zone's security. + +References + + [RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security + Extensions", RFC 2065, CyberCash, Iris, January 1997. + + [RFC2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specifications", STD 13, RFC 1035, November 1987. + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + + + + + + + + +Eastlake Standards Track [Page 10] + +RFC 2137 SDNSDU April 1997 + + +Author's Address + + Donald E. Eastlake, 3rd + CyberCash, Inc. + 318 Acton Street + Carlisle, MA 01741 USA + + Phone: +1 508-287-4877 + +1 508-371-7148 (fax) + +1 703-620-4200 (main office, Reston, Virginia, USA) + EMail: dee@cybercash.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 11] + |