diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc2137.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc2137.txt | 619 |
1 files changed, 0 insertions, 619 deletions
diff --git a/contrib/bind9/doc/rfc/rfc2137.txt b/contrib/bind9/doc/rfc/rfc2137.txt deleted file mode 100644 index ceb3613..0000000 --- a/contrib/bind9/doc/rfc/rfc2137.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -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] - |
