rfc2137.txt

RFC 的详细文档！

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 ([e-mail]>
         Charlie Kaufman <[e-mail]>
         Stuart Kwan <[e-mail]>
         Edward Lewis <[e-mail]>

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