draft-ietf-dnsop-dnssec-operational-practices-04.txt

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


Internet-Draft        DNSSEC Operational Practices            March 2005


   after: DNSKEY1 has been removed.

   The scenario above puts the responsibility for maintaining a valid
   chain of trust with the child.  It also is based on the premises that
   the parent only has one DS RR (per algorithm) per zone.  An
   alternative mechanism has been considered.  Using an established
   trust relation, the interaction can be performed in-band, and the
   removal of the keys by the child can possibly be signaled by the
   parent.  In this mechanism there are periods where there are two DS
   RRs at the parent.  Since at the moment of writing the protocol for
   this interaction has not been developed further discussion is out of
   scope for this document.

4.2.3  Difference Between ZSK and KSK Rollovers

   Note that KSK rollovers and ZSK rollovers are different.  A zone-key
   rollover can be handled in two different ways: pre-publish (Section
   Section 4.2.1.1) and double signature (Section Section 4.2.1.2).

   As the KSK is used to validate the key set and because the KSK is not
   changed during a ZSK rollover, a cache is able to validate the new
   key set of the zone.  The pre-publish method would work for a KSK
   rollover.  The record that are to be pre-published are the parental
   DS RRs.

   The pre-publish method has some drawbacks.  We first describe the
   rollover scheme and then indicate these drawbacks.

     normal          pre-roll         roll            after
   Parent:
     SOA0            SOA1             SOA2            SOA3
     RRSIGpar(SOA0)  RRSIGpar(SOA1)   RRSIGpar(SOA2)  RRSIGpar(SOA3)
     DS1             DS1              DS1             DS2
                     DS2              DS2
     RRSIGpar(DS)    RRSIGpar(DS)     RRSIGpar(DS)    RRSIGpar(DS)



   Child:
     SOA0            SOA0             SOA1            SOA1
     RRSIG10(SOA0)   RRSIG10(SOA0)    RRSIG10(SOA1)   RRSIG10(SOA1)

     DNSKEY1         DNSKEY1          DNSKEY2         DNSKEY2

     DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY10
     RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG2(DNSKEY)  RRSIG2 (DNSKEY)
     RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG10(DNSKEY) RRSIG10(DNSKEY)




Kolkman & Gieben        Expires September 2, 2005              [Page 18]

Internet-Draft        DNSSEC Operational Practices            March 2005


   When the child zone wants to roll it notifies the parent during the
   pre-roll phase and submits the new key to the parent.  The parent
   publishes DS1 and DS2, pointing to DNSKEY1 and DNSKEY2 respectively.
   During the rollover, which can take place as soon as the new DS set
   propagated through the DNS, the child replaces DNSKEY1 with DNSKEY2.
   Immediately after that it can notify the parent that the old DS
   record can be deleted.

   The drawbacks of these scheme are that during the pre-roll phase the
   parent cannot verify the match between the DS RR and DNSKEY2 using
   the DNS.  Besides, we introduce a "security lame" DS record
   Section 4.4.3.  Finally the child-parent interaction consists of two
   steps.  The "double signature" method only needs one interaction.

4.2.4  Automated Key Rollovers

   As keys must be renewed periodically, there is some motivation to
   automate the rollover process.  Consider that:

   o  ZSK rollovers are easy to automate as only the local zone is
      involved.
   o  A KSK rollover needs interaction between the parent and child.
      Data exchange is needed to provide the new keys to the parent,
      consequently, this data must be authenticated and integrity must
      be guaranteed in order to avoid attacks on the rollover.
   o  All time and TTL considerations presented in Section 4.2 apply to
      an automated rollover.

4.3  Planning for Emergency Key Rollover

   This section deals with preparation for a possible key compromise.
   Our advice is to have a documented procedure ready for when a key
   compromise is suspected or confirmed.

   When the private material of one of your keys is compromised it can
   be used for as long as a valid authentication chain exists.  An
   authentication chain remains intact for:
   o  as long as a signature over the compromised key in the
      authentication chain is valid,
   o  as long as a parental DS RR (and signature) points to the
      compromised key,
   o  as long as the key is anchored in a resolver and is used as a
      starting point for validation.  (This is generally the hardest to
      update.)

   While an authentication chain to your compromised key exists, your
   name-space is vulnerable to abuse by anyone who has obtained
   illegitimate possession of the key.Zone operators have to make a



Kolkman & Gieben        Expires September 2, 2005              [Page 19]

Internet-Draft        DNSSEC Operational Practices            March 2005


   trade off if the abuse of the compromised key is worse than having
   data in caches that cannot be validated.  If the zone operator
   chooses to break the authentication chain to the compromised key,
   data in caches signed with this key cannot be validated.  However, if
   the zone administrator chooses to take the path of a regular roll-
   over, the malicious key holder can spoof data so that it appears to
   be valid.  Note that this kind of attack is more likely to occur in a
   localized part of the network topology i.e. downstream from where the
   spoof takes place.


4.3.1  KSK Compromise

   When the KSK has been compromised the parent must be notified as soon
   as possible using secure means.  The key set of the zone should be
   resigned as soon as possible.  Care must be taken to not break the
   authentication chain.  The local zone can only be resigned with the
   new KSK after the parent's zone has created and reloaded its zone
   with the DS created from the new KSK.  Before this update takes place
   it would be best to drop the security status of a zone all together:
   the parent removes the DS of the child at the next zone update.
   After that the child can be made secure again.

   An additional danger of a key compromise is that the compromised key
   can be used to facilitate a legitimate DNSKEY/DS and/or nameserver
   rollover at the parent.  When that happens the domain can be in
   dispute.  An authenticated out of band and secure notify mechanism to
   contact a parent is needed in this case.

4.3.2  ZSK Compromise

   Primarily because there is no parental interaction required when a
   ZSK is compromised, the situation is less severe than with with a KSK
   compromise.  The zone must still be resigned with a new ZSK as soon
   as possible.  As this is a local operation and requires no
   communication between the parent and child this can be achieved
   fairly quickly.  However, one has to take into account that just as
   with a normal rollover the immediate disappearance from the old
   compromised key may lead to verification problems.  The pre-
   publication scheme as discussed above minimizes such problems.

4.3.3  Compromises of Keys Anchored in Resolvers

   A key can also be pre-configured in resolvers.  For instance, if
   DNSSEC is successfully deployed the root key may be pre-configured in
   most security aware resolvers.

   If trust-anchor keys are compromised, the resolvers using these keys



Kolkman & Gieben        Expires September 2, 2005              [Page 20]

Internet-Draft        DNSSEC Operational Practices            March 2005


   should be notified of this fact.  Zone administrators may consider
   setting up a mailing list to communicate the fact that a SEP key is
   about to be rolled over.  This communication will of course need to
   be authenticated e.g. by using digital signatures.

   End-users faced with the task of updating an anchored key should
   always validate the new key.  New keys should be authenticated out of
   the DNS, for example, looking them up on an SSL secured announcement
   website.

4.4  Parental Policies

4.4.1  Initial Key Exchanges and Parental Policies Considerations

   The initial key exchange is always subject to the policies set by the
   parent (or its registry).  When designing a key exchange policy one
   should take into account that the authentication and authorization
   mechanisms used during a key exchange should be as strong as the
   authentication and authorization mechanisms used for the exchange of
   delegation information between parent and child.  I.e. there is no
   implicit need in DNSSEC to make the authentication process stronger
   than it was in DNS.

   Using the DNS itself as the source for the actual DNSKEY material,
   with an off-band check on the validity of the DNSKEY, has the benefit
   that it reduces the chances of user error.  A parental DNSKEY
   download tool can make use of the SEP bit [1] to select the proper
   key from a DNSSEC key set; thereby reducing the chance that the wrong
   DNSKEY is sent.  It can validate the self-signature over a key;
   thereby verifying the ownership of the private key material.
   Fetching the DNSKEY from the DNS ensures that the chain of trust
   remains intact once the parent publishes the DS RR indicating the
   child is secure.

   Note: the off-band verification is still needed when the key-material
   is fetched via the DNS.  The parent can never be sure whether the
   DNSKEY RRs have been spoofed or not.

4.4.2  Storing Keys or Hashes?

   When designing a registry system one should consider which of the
   DNSKEYs and/or the corresponding DSs to store.  Since a child zone
   might wish to have a DS published using a message digest algorithm
   not yet understood by the registry, the registry can't count on being
   able to generate the DS record from a raw DNSKEY.  Thus, we recommend
   that registry system at least support storing DS records.

   It may also be useful to store DNSKEYs, since having them may help



Kolkman & Gieben        Expires September 2, 2005              [Page 21]

Internet-Draft        DNSSEC Operational Practices            March 2005


   during troubleshooting and, so long as the child's chosen message
   digest is supported, the overhead of generating DS records from them
   is minimal.  Having an out-of-band mechanism, such as a Whois
   database, to find out which keys are used to generate DS Resource
   Records for specific owners and/or zones may also help with
   troubleshooting.

   The storage considerations also relate the design of the customer
   interface and the method by which data is transfered between
   registrant and registry; Will the child zone owner be able to upload
   DS RRs with unknown hash algorithms or does the interface only allows
   DNSKEYs?  In the registry-registrar model one can use the DNSSEC EPP
   protocol extensions [9] which allows transfer of DS RRs and
   optionally DNSKEY RRs.

4.4.3  Security Lameness

   Security Lameness is defined as what happens when a parent has a DS
   RR pointing to a non-existing DNSKEY RR.  During key exchange a
   parent should make sure that the child's key is actually configured
   in the DNS before publishing a DS RR in its zone.  Failure to do so
   could cause the child's zone being marked as Bogus.

   Child zones should be very careful removing DNSKEY material,
   specifically SEP keys, for which a DS RR exists.

   Once a zone is "security lame", a fix (e.g. removing a DS RR) will
   take time to propagate through the DNS.

4.4.4  DS Signature Validity Period

   Since the DS can be replayed as long as it has a valid signature, a
   short signature validity period over the DS minimizes the time a
   child is vulnerable in the case of a compromise of the child's
   KSK(s).  A signature validity period that is too short introduces the
   possibility that a zone is marked Bogus in case of a configuration
   error in the signer.  There may not be enough time to fix the
   problems before signatures expire.  Something as mundane as operator
   unavailability during weekends shows the need for DS signature
   validity periods longer than 2 days.  We recommend the minimum for a
   DS signature validity period of a few days.

   The maximum signature validity period of the DS record depends on how
   long child zones are willing to be vulnerable after a key compromise.
   Other considerations, such as how often the zone is (re)signed can
   also be taken into account.

   We consider a signature validity period of around one week to be a



Kolkman & Gieben        Expires September 2, 2005              [Page 22]

Internet-Draft        DNSSEC Operational Practices            March 2005


   good compromise between the operational constraints of the parent and
   minimizing damage for the child.

   In addition to the signature validity period, which sets a lower
   bound on the amount of times the zone owner will need to sign the
   zone data and which sets an upper bound to the time a child is
   vulnerable after key compromise,  there is the TTL value on the DS
   RRs.  By lowering the TTL, the authoritative servers will see more
   queries, on the other hand a low TTL increases the speed with which
   new DS RRs propagate through the DNS.  As argued in Section 4.1.1,
   the TTL should be a fraction of the signature validity period.

5.  Security Considerations

   DNSSEC adds data integrity to the DNS.  This document tries to assess
   the operational considerations to maintain a stable and secure DNSSEC
   service.  Not taking into account the 'data propagation' properties
   in the DNS will cause validation failures and may make secured zones
   unavailable to security aware resolvers.

6.  Acknowledgments

   Most of the ideas in this draft were the result of collective efforts
   during workshops, discussions and try outs.

   At the risk of forgetting individuals who were the original
   contributors of the ideas we would like to acknowledge people who
   were actively involved in the compilation of this document.  In
   random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
   Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
   Olivier Courtay, Sam Weiler, Jelte Jansen and Niall O'Reilly.

   Some material in this document has been shamelessly copied from