draft-ietf-dnsext-trustupdate-threshold-00.txt

bind 源码 最新实现 linux/unix/windows平台

Network Working Group                                           J. Ihren
Internet-Draft                                             Autonomica AB
Expires: April 18, 2005                                       O. Kolkman
                                                                RIPE NCC
                                                              B. Manning
                                                                  EP.net
                                                        October 18, 2004



  An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for
                         DNSSEC Trust Anchors.
               draft-ietf-dnsext-trustupdate-threshold-00


Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   This Internet-Draft will expire on April 18, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).  All Rights Reserved.


Abstract


   The DNS Security Extensions (DNSSEC) works by validating so called
   chains of authority.  The start of these chains of authority are
   usually public keys that are anchored in the DNS clients.  These keys
   are known as the so called trust anchors.





Ihren, et al.            Expires April 18, 2005                 [Page 1]
Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004



   This memo describes a method how these client trust anchors can be
   replaced using the DNS validation and querying mechanisms (in-band)
   when the key pairs used for signing by zone owner are rolled.


   This memo also describes a method to establish the validity of trust
   anchors for initial configuration, or priming, using out of band
   mechanisms.


Table of Contents


   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Key Signing Keys, Zone Signing Keys and Secure Entry
           Points . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction and Background  . . . . . . . . . . . . . . . . .  5
     2.1   Dangers of Stale Trust Anchors . . . . . . . . . . . . . .  5
   3.  Threshold-based Trust Anchor Rollover  . . . . . . . . . . . .  7
     3.1   The Rollover . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2   Threshold-based Trust Update . . . . . . . . . . . . . . .  8
     3.3   Possible Trust Update States . . . . . . . . . . . . . . .  9
     3.4   Implementation notes . . . . . . . . . . . . . . . . . . . 10
     3.5   Possible transactions  . . . . . . . . . . . . . . . . . . 11
       3.5.1   Single DNSKEY replaced . . . . . . . . . . . . . . . . 12
       3.5.2   Addition of a new DNSKEY (no removal)  . . . . . . . . 12
       3.5.3   Removal of old DNSKEY (no addition)  . . . . . . . . . 12
       3.5.4   Multiple DNSKEYs replaced  . . . . . . . . . . . . . . 12
     3.6   Removal of trust anchors for a trust point . . . . . . . . 12
     3.7   No need for resolver-side overlap of old and new keys  . . 13
   4.  Bootstrapping automatic rollovers  . . . . . . . . . . . . . . 14
     4.1   Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14
       4.1.1   Bootstrapping trust anchors using a priming key  . . . 14
       4.1.2   Distribution of priming keys . . . . . . . . . . . . . 15
   5.  The Threshold Rollover Mechanism vs Priming  . . . . . . . . . 16
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
     6.1   Threshold-based Trust Update Security Considerations . . . 17
     6.2   Priming Key Security Considerations  . . . . . . . . . . . 17
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 20
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 20
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
   B.  Document History . . . . . . . . . . . . . . . . . . . . . . . 23
     B.1   prior to version 00  . . . . . . . . . . . . . . . . . . . 23
     B.2   version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23
       Intellectual Property and Copyright Statements . . . . . . . . 24







Ihren, et al.            Expires April 18, 2005                 [Page 2]
Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004



1.  Terminology


   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
   and "MAY" in this document are to be interpreted as described in
   RFC2119 [1].


   The term "zone" refers to the unit of administrative control in the
   Domain Name System.  In this document "name server" denotes a DNS
   name server that is authoritative (i.e.  knows all there is to know)
   for a DNS zone.  A "zone owner" is the entity responsible for signing
   and publishing a zone on a name server.  The terms "authentication
   chain", "bogus", "trust anchors" and "Island of Security" are defined
   in [4].  Throughout this document we use the term "resolver" to mean
   "Validating Stub Resolvers" as defined in [4].


   We use the term "security apex" as the zone for which a trust anchor
   has been configured (by validating clients) and which is therefore,
   by definition, at the root of an island of security.  The
   configuration of trust anchors is a client side issue.  Therefore a
   zone owner may not always know if their zone has become a security
   apex.


   A "stale anchor" is a trust anchor (a public key) that relates to a
   key that is not used for signing.  Since trust anchors indicate that
   a zone is supposed to be secure a validator will mark the all data in
   an island of security as bogus when all trust anchors become stale.


   It is assumed that the reader is familiar with public key
   cryptography concepts [REF: Schneier Applied Cryptography] and is
   able to distinguish between the private and public parts of a key
   based on the context in which we use the term "key".  If there is a
   possible ambiguity we will explicitly mention if a private or a
   public part of a key is used.


   The term "administrator" is used loosely throughout the text.  In
   some cases an administrator is meant to be a person, in other cases
   the administrator may be a process that has been delegated certain
   responsibilities.


1.1  Key Signing Keys, Zone Signing Keys and Secure Entry Points


   Although the DNSSEC protocol does not make a distinction between
   different keys the operational practice is that a distinction is made
   between zone signing keys and key signing keys.  A key signing key is
   used to exclusively sign the DNSKEY Resource Record (RR) set at the
   apex of a zone and the zone signing keys sign all the data in the
   zone (including the DNSKEY RRset at the apex).





Ihren, et al.            Expires April 18, 2005                 [Page 3]
Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004



   Keys that are intended to be used as the start of the authentication
   chain for a particular zone, either because they are pointed to by a
   parental DS RR or because they are configured as a trust anchor, are
   called Secure Entry Point (SEP) keys.  In practice these SEP keys
   will be key signing keys.


   In order for the mechanism described herein to work the keys that are
   intended to be used as secure entry points MUST have the SEP [2] flag
   set.  In the examples it is assumed that keys with the SEP flag set
   are used as key signing keys and thus exclusively sign the DNSKEY
   RRset published at the apex of the zone.









































Ihren, et al.            Expires April 18, 2005                 [Page 4]
Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004



2.  Introduction and Background


   When DNSSEC signatures are validated the resolver constructs a chain
   of authority from a pre-configured trust anchor to the DNSKEY
   Resource Record (RR), which contains the public key that validates
   the signature stored in an RRSIG RR.  DNSSEC is designed so that the
   administrator of a resolver can validate data in multiple islands of
   security by configuring multiple trust anchors.


   It is expected that resolvers will have more than one trust anchor
   configured.  Although there is no deployment experience it is not
   unreasonable to expect resolvers to be configured with a number of
   trust anchors that varies between order 1 and order 1000.  Because
   zone owners are expected to roll their keys, trust anchors will have
   to be maintained (in the resolver end) in order not to become stale.


   Since there is no global key maintenance policy for zone owners and
   there are no mechanisms in the DNS to signal the key maintenance
   policy it may be very hard for resolvers administrators to keep their
   set of trust anchors up to date.  For instance, if there is only one
   trust anchor configured and the key maintenance policy is clearly
   published, through some out of band trusted channel, then a resolver
   administrator can probably keep track of key rollovers and update the
   trust anchor manually.  However, with an increasing number of trust
   anchors all rolled according to individual policies that are all
   published through different channels this soon becomes an
   unmanageable problem.


2.1  Dangers of Stale Trust Anchors


   Whenever a SEP key at a security apex is rolled there exists a danger
   that "stale anchors" are created.  A stale anchor is a trust anchor
   (i.e.  a public key configured in a validating resolver) that relates
   to a private key that is no longer used for signing.


   The problem with a stale anchors is that they will (from the
   validating resolvers point of view) prove data to be false even
   though it is actually correct.  This is because the data is either
   signed by a new key or is no longer signed and the resolver expects
   data to be signed by the old (now stale) key.


   This situation is arguably worse than not having a trusted key
   configured for the secure entry point, since with a stale key no
   lookup is typically possible (presuming that the default
   configuration of a validating recursive nameserver is to not give out
   data that is signed but failed to verify.


   The danger of making configured trust anchors become stale anchors




Ihren, et al.            Expires April 18, 2005                 [Page 5]
Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004



   may be a reason for zone owners not to roll their keys.  If a
   resolver is configured with many trust anchors that need manual
   maintenance it may be easy to not notice a key rollover at a security
   apex, resulting in a stale anchor.


   In Section 3 this memo sets out a lightweight, in-DNS, mechanism to
   track key rollovers and modify the configured trust anchors
   accordingly.  The mechanism is stateless and does not need protocol
   extensions.  The proposed design is that this mechanism is
   implemented as a "trust updating machine" that is run entirely
   separate from the validating resolver except that the trust updater
   will have influence over the trust anchors used by the latter.


   In Section 4 we describe a method [Editors note: for now only the
   frame work and a set of requirements] to install trust anchors.  This
   method can be used at first configuration or when the trust anchors
   became stale (typically due to a failure to track several rollover
   events).


   The choice for which domains trust anchors are to be configured is a
   local policy issue.  So is the choice which trust anchors has
   prevalence if there are multiple chains of trust to a given piece of
   DNS data (e.g.  when a parent zone and its child both have trust
   anchors configured).  Both issues are out of the scope of this
   document.



























Ihren, et al.            Expires April 18, 2005                 [Page 6]
Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004



3.  Threshold-based Trust Anchor Rollover


3.1  The Rollover


   When a key pair is replaced all signatures (in DNSSEC these are the
   RRSIG records) created with the old key will be replaced by new
   signatures created by the new key.  Access to the new public key is
   needed to verify these signatures.


   Since zone signing keys are in "the middle" of a chain of authority
   they can be verified using the signature made by a key signing key.
   Rollover of zone signing keys is therefore transparent to validators
   and requires no action in the validator end.


   But if a key signing key is rolled a resolver can determine its
   authenticity by either following the authorization chain from the
   parents DS record, an out-of-DNS authentication mechanism or by
   relying on other trust anchors known for the zone in which the key is
   rolled.


   The threshold trust anchor rollover mechanism (or trust update),
   described below, is based on using existing trust anchors to verify a
   subset of the available signatures.  This is then used as the basis
   for a decision to accept the new keys as valid trust anchors.


   Our example pseudo zone below contains a number of key signing keys
   numbered 1 through Y and two zone signing keys A and B.  During a key
   rollover key 2 is replaced by key Y+1.  The zone content changes
   from:


          example.com.  DNSKEY key1
          example.com.  DNSKEY key2
          example.com.  DNSKEY key3
          ...
          example.com.  DNSKEY keyY


          example.com.  DNSKEY keyA
          example.com.  DNSKEY keyB


          example.com.  RRSIG DNSKEY ... (key1)
          example.com.  RRSIG DNSKEY ... (key2)
          example.com.  RRSIG DNSKEY ... (key3)
          ...
          example.com.  RRSIG DNSKEY ... (keyY)
          example.com.  RRSIG DNSKEY ... (keyA)
          example.com.  RRSIG DNSKEY ... (keyB)


    to:




Ihren, et al.            Expires April 18, 2005                 [Page 7]
Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004



          example.com.  DNSKEY key1
          example.com.  DNSKEY key3
          ...
          example.com.  DNSKEY keyY
          example.com.  DNSKEY keyY+1


          example.com.  RRSIG DNSKEY ... (key1)
          example.com.  RRSIG DNSKEY ... (key3)
          ...
          example.com.  RRSIG DNSKEY ... (keyY)
          example.com.  RRSIG DNSKEY ... (keyY+1)
          example.com.  RRSIG DNSKEY ... (keyA)
          example.com.  RRSIG DNSKEY ... (keyB)


   When the rollover becomes visible to the verifying stub resolver it
   will be able to verify the RRSIGs associated with key1, key3 ...
   keyY.  There will be no RRSIG by key2 and the RRSIG by keyY+1 will
   not be used for validation, since that key is previously unknown and
   therefore not trusted.


   Note that this example is simplified.  Because of operational
   considerations described in [5] having a period during which the two
   key signing keys are both available is necessary.


3.2  Threshold-based Trust Update


   The threshold-based trust update algorithm applies as follows.  If
   for a particular secure entry point
   o  if the DNSKEY RRset in the zone has been replaced by a more recent
      one (as determined by comparing the RRSIG inception dates)
   and
   o  if at least M configured trust anchors directly verify the related
      RRSIGs over the new DNSKEY RRset
   and
   o  the number of configured trust anchors that verify the related
      RRSIGs over the new DNSKEY RRset exceed a locally defined minimum
      number that should be greater than one
   then all the trust anchors for the particular secure entry point are
   replaced by the set of keys from the zones DNSKEY RRset that have the
   SEP flag set.


   The choices for the rollover acceptance policy parameter M is left to
   the administrator of the resolver.  To be certain that a rollover is
   accepted up by resolvers using this mechanism zone owners should roll
   as few SEP keys at a time as possible (preferably just one).  That
   way they comply to the most strict rollover acceptance policy of
   M=N-1.