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

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

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



   The value of M has an upper bound, limited by the number of of SEP
   keys a zone owner publishes (i.e.  N).  But there is also a lower
   bound, since it will not be safe to base the trust in too few
   signatures.  The corner case is M=1 when any validating RRSIG will be
   sufficient for a complete replacement of the trust anchors for that
   secure entry point.  This is not a recommended configuration, since
   that will allow an attacker to initiate rollover of the trust anchors
   himself given access to just one compromised key.  Hence M should in
   be strictly larger than 1 as shown by the third requirement above.


   If the rollover acceptance policy is M=1 then the result for the
   rollover in our example above should be that the local database of
   trust anchors is updated by removing key "key2" from and adding key
   "keyY+1" to the key store.


3.3  Possible Trust Update States


   We define five states for trust anchor configuration at the client
   side.
   PRIMING: There are no trust anchors configured.  There may be priming
      keys available for initial priming of trust anchors.
   IN-SYNC: The set of trust anchors configured exactly matches the set
      of SEP keys used by the zone owner to sign the zone.
   OUT-OF-SYNC: The set of trust anchors is not exactly the same as the
      set of SEP keys used by the zone owner to sign the zone but there
      are enough SEP key in use by the zone owner that is also in the
      trust anchor configuration.
   UNSYNCABLE: There is not enough overlap between the configured trust
      anchors and the set of SEP keys used to sign the zone for the new
      set to be accepted by the validator (i.e.  the number of
      signatures that verify is not sufficient).
   STALE: There is no overlap between the configured trust anchors and
      the set of SEP keys used to sign the zone.  Here validation of
      data is no longer possible and hence we are in a situation where
      the trust anchors are stale.


   Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of
   the automatic trust update mechanism.  The PRIMING state is where a
   validator is located before acquiring an up-to-date set of trust
   anchors.  The transition from PRIMING to IN-SYNC is manual (see
   Section 4 below).


   Example: assume a secure entry point with four SEP keys and a
   validator with the policy that it will accept any update to the set
   of trust anchors as long as no more than two signatures fail to
   validate (i.e.  M >= N-2) and at least two signature does validate
   (i.e.  M >= 2).  In this case the rollover of a single key will move
   the validator from IN-SYNC to OUT-OF-SYNC.  When the trust update




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



   state machine updates the trust anchors it returns to state IN-SYNC.


   If if for some reason it fails to update the trust anchors then the
   next rollover (of a different key) will move the validator from
   OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys
   that are configured as trust anchors and that is sufficient to accpt
   an automatic update of the trust anchors.


   The UNSYNCABLE state is where a validator is located if it for some
   reason fails to incorporate enough updates to the trust anchors to be
   able to accept new updates according to its local policy.  In this
   example (i.e.  with the policy specified above) this will either be
   because M < N-2 or M < 2, which does not suffice to authenticate a
   successful update of trust anchors.


   Continuing with the previous example where two of the four SEP keys
   have already rolled, but the validator has failed to update the set
   of trust anchors.  When the third key rolls over there will only be
   one trust anchor left that can do successful validation.  This is not
   sufficient to enable automatic update of the trust anchors, hence the
   new state is UNSYNCABLE.  Note, however, that the remaining
   up-to-date trust anchor is still enough to do successful validation
   so the validator is still "working" from a DNSSEC point of view.


   The STALE state, finally, is where a validator ends up when it has
   zero remaining current trust anchors.  This is a dangerous state,
   since the stale trust anchors will cause all validation to fail.  The
   escape is to remove the stale trust anchors and thereby revert to the
   PRIMING state.


3.4  Implementation notes


   The DNSSEC protocol specification ordains that a DNSKEY to which a DS
   record points should be self-signed.  Since the keys that serve as
   trust anchors and the keys that are pointed to by DS records serve
   the same purpose, they are both secure entry points, we RECOMMEND
   that zone owners who want to facilitate the automated rollover scheme
   documented herein self-sign DNSKEYs with the SEP bit set and that
   implementation check that DNSKEYs with the SEP bit set are
   self-signed.


   In order to maintain a uniform way of determining that a keyset in
   the zone has been replaced by a more recent set the automatic trust
   update machine SHOULD only accept new DNSKEY RRsets if the
   accompanying RRSIGs show a more recent inception date than the
   present set of trust anchors.  This is also needed as a safe guard
   against possible replay attacks where old updates are replayed
   "backwards" (i.e.  one change at a time, but going in the wrong




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



   direction, thereby luring the validator into the UNSYNCABLE and
   finally STALE states).


   In order to be resilient against failures the implementation should
   collect the DNSKEY RRsets from (other) authoritative servers if
   verification of the self signatures fails.


   The threshold-based trust update mechanism SHOULD only be applied to
   algorithms, as represented in the algorithm field in the DNSKEY/RRSIG
   [3], that the resolver is aware of.  In other words the SEP keys of
   unknown algorithms should not be used when counting the number of
   available signatures (the N constant) and the SEP keys of unknown
   algorithm should not be entered as trust anchors.


   When in state UNSYNCABLE or STALE manual intervention will be needed
   to return to the IN-SYNC state.  These states should be flagged.  The
   most appropriate action is human audit possibly followed by
   re-priming (Section 4) the keyset (i.e.  manual transfer to the
   PRIMING state through removal of the configured trust anchors).


   An implementation should regularly probe the the authoritative
   nameservers for new keys.  Since there is no mechanism to publish
   rollover frequencies this document RECOMMENDS zone owners not to roll
   their key signing keys more often than once per month and resolver
   administrators to probe for key rollsovers (and apply the threshold
   criterion for acceptance of trust update) not less often than once
   per month.  If the rollover frequency is higher than the probing
   frequency then trust anchors may become stale.  The exact relation
   between the frequencies depends on the number of SEP keys rolled by
   the zone owner and the value M configured by the resolver
   administrator.


   In all the cases below a transaction where the threshold criterion is
   not satisfied should be considered bad (i.e.  possibly spoofed or
   otherwise corrupted data).  The most appropriate action is human
   audit.


   There is one case where a "bad" state may be escaped from in an
   automated fashion.  This is when entering the STALE state where all
   DNSSEC validation starts to fail.  If this happens it is concievable
   that it is better to completely discard the stale trust anchors
   (thereby reverting to the PRIMING state where validation is not
   possible).  A local policy that automates removal of stale trust
   anchors is therefore suggested.


3.5  Possible transactions






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



3.5.1  Single DNSKEY replaced


   This is probably the most typical transaction on the zone owners
   part.  The result should be that if the threshold criterion is
   satisfied then the key store is updated by removal of the old trust
   anchor and addition of the new key as a new trust anchor.  Note that
   if the DNSKEY RRset contains exactly M keys replacement of keys is
   not possible, i.e.  for automatic rollover to work M must be stricly
   less than N.


3.5.2  Addition of a new DNSKEY (no removal)


   If the threshold criterion is satisfied then the new key is added as
   a configured trust anchor.  Not more than N-M keys can be added at
   once, since otherwise the algorithm will fail.


3.5.3  Removal of old DNSKEY (no addition)


   If the threshold criterion is satisfied then the old key is removed
   from being a configured trust anchor.  Note that it is not possible
   to reduce the size of the DNSKEY RRset to a size smaller than the
   minimum required value for M.


3.5.4  Multiple DNSKEYs replaced


   Arguably it is not a good idea for the zone administrator to replace
   several keys at the same time, but from the resolver point of view
   this is exactly what will happen if the validating resolver for some
   reason failed to notice a previous rollover event.


   Not more than N-M keys can be replaced at one time or the threshold
   criterion will not be satisfied.  Or, expressed another way: as long
   as the number of changed keys is less than or equal to N-M the
   validator is in state OUT-OF-SYNC.  When the number of changed keys
   becomes greater than N-M the state changes to UNSYNCABLE and manual
   action is needed.


3.6  Removal of trust anchors for a trust point


   If the parent of a secure entry point gets signed and it's trusted
   keys get configured in the key store of the validating resolver then
   the configured trust anchors for the child should be removed entirely
   unless explicitly configured (in the utility configuration) to be an
   exception.


   The reason for such a configuration would be that the resolver has a
   local policy that requires maintenance of trusted keys further down
   the tree hierarchy than strictly needed from the point of view.




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



   The default action when the parent zone changes from unsigned to
   signed should be to remove the configured trust anchors for the
   child.  This form of "garbage collect" will ensure that the automatic
   rollover machinery scales as DNSSEC deployment progresses.


3.7  No need for resolver-side overlap of old and new keys


   It is worth pointing out that there is no need for the resolver to
   keep state about old keys versus new keys, beyond the requirement of
   tracking signature inception time for the covering RRSIGs as
   described in Section 3.4.


   From the resolver point of view there are only trusted and not
   trusted keys.  The reason is that the zone owner needs to do proper
   maintenance of RRSIGs regardless of the resolver rollover mechanism
   and hence must ensure that no key rolled out out the DNSKEY set until
   there cannot be any RRSIGs created by this key still legally cached.


   Hence the rollover mechanism is entirely stateless with regard to the
   keys involved: as soon as the resolver (or in this case the rollover
   tracking utility) detects a change in the DNSKEY RRset (i.e.  it is
   now in the state OUT-OF-SYNC) with a sufficient number of matching
   RRSIGs the configured trust anchors are immediately updated (and
   thereby the machine return to state IN-SYNC).  I.e.  the rollover
   machine changes states (mostly oscillating between IN-SYNC and
   OUT-OF-SYNC), but the status of the DNSSEC keys is stateless.


























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



4.  Bootstrapping automatic rollovers


   It is expected that with the ability to automatically roll trust
   anchors at trust points will follow a diminished unwillingness to
   roll these keys, since the risks associated with stale keys are
   minimized.


   The problem of "priming" the trust anchors, or bringing them into
   sync (which could happen if a resolver is off line for a long period
   in which a set of SEP keys in a zone 'evolve' away from its trust
   anchor configuration) remains.


   For (re)priming we can rely on out of band technology and we propose
   the following framework.


4.1  Priming Keys


   If all the trust anchors roll somewhat frequently (on the order of
   months or at most about a year) then it will not be possible to
   design a device, or a software distribution that includes trust
   anchors, that after being manufactured is put on a shelf for several
   key rollover periods before being brought into use (since no trust
   anchors that were known at the time of manufacture remain active).


   To alleviate this we propose the concept of "priming keys".  Priming
   keys are ordinary DNSSEC Key Signing Keys with the characteristic
   that
   o  The private part of a priming key signs the DNSKEY RRset at the
      security apex, i.e.  at least one RRSIG DNSKEY is created by a
      priming key rather than by an "ordinary" trust anchor
   o  the public parts of priming keys are not included in the DNSKEY
      RRset.  Instead the public parts of priming keys are only
      available out-of-band.
   o  The public parts of the priming keys have a validity period.
      Within this period they can be used to obtain trust anchors.
   o  The priming key pairs are long lived (relative to the key rollover
      period.)


4.1.1  Bootstrapping trust anchors using a priming key


   To install the trust anchors for a particular security apex an
   administrator of a validating resolver will need to:
   o  query for the DNSKEY RRset of the zone at the security apex;
   o  verify the self signatures of all DNSKEYs in the RRset;
   o  verify the signature of the RRSIG made with a priming key --
      verification using one of the public priming keys that is valid at
      that moment is sufficient;





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



   o  create the trust anchors by extracting the DNSKEY RRs with the SEP
      flag set.
   The SEP keys with algorithms unknown to the validating resolver
   SHOULD be ignored during the creation of the trust anchors.


4.1.2  Distribution of priming keys


   The public parts of the priming keys SHOULD be distributed
   exclusively through out-of-DNS mechanisms.  The requirements for a
   distribution mechanism are:
   o  it can carry the "validity" period for the priming keys;
   o  it can carry the self-signature of the priming keys;
   o  and it allows for verification using trust relations outside the
      DNS.
   A distribution mechanism would benefit from:
   o  the availability of revocation lists;
   o  the ability of carrying zone owners policy information such as
      recommended values for "M" and "N" and a rollover frequency;
   o  and the technology on which is based is readily available.

































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



5.  The Threshold Rollover Mechanism vs Priming


   There is overlap between the threshold-based trust updater and the
   Priming method.  One could exclusively use the Priming method for
   maintaining the trust anchors.  However the priming method probably
   relies on "non-DNS' technology and may therefore not be available for
   all devices that have a resolver.