draft-ietf-dnsext-trustupdate-timers-01.txt

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

4.1  Events
   NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
      That key will become a new trust anchor for the named trust point
      after its been present in the RRSet for at least 'add time'.
   KeyPres The key has returned to the valid DNSKEY RRSet.
   KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
      this key.
   AddTime The key has been in every valid DNSKEY RRSet seen for at
      least the 'add time'.
   RemTime A revoked key has been missing from the trust point DNSKEY
      RRSet for sufficient time to be removed from the trust set.
   RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
      "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
      signed by this key.

4.2  States
   Start The key doesn't yet exist as a trust anchor at the resolver.
      It may or may not exist at the zone server, but hasn't yet been
      seen at the resolver.





StJohns                 Expires February 16, 2006               [Page 7]

Internet-Draft             trustanchor-update                August 2005


   AddPend The key has been seen at the resolver, has its 'SEP' bit set,
      and has been included in a validated DNSKEY RRSet.  There is a
      hold-down time for the key before it can be used as a trust
      anchor.
   Valid The key has been seen at the resolver and has been included in
      all validated DNSKEY RRSets from the time it was first seen up
      through the hold-down time.  It is now valid for verifying RRSets
      that arrive after the hold down time.  Clarification:  The DNSKEY
      RRSet does not need to be continuously present at the resolver
      (e.g. its TTL might expire).  If the RRSet is seen, and is
      validated (i.e. verifies against an existing trust anchor), this
      key MUST be in the RRSet otherwise  a 'KeyRem' event is triggered.
   Missing This is an abnormal state.  The key remains as a valid trust
      point key, but was not seen at the resolver in the last validated
      DNSKEY RRSet.  This is an abnormal state because the zone operator
      should be using the REVOKE bit prior to removal.  [Discussion
      item:  Should a missing key be considered revoked after some
      period of time?]
   Revoked This is the state a key moves to once the resolver sees an
      RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
      this key with its REVOKE bit set to '1'.  Once in this state, this
      key MUST permanently be considered invalid as a trust anchor.
   Removed After a fairly long hold-down time, information about this
      key may be purged from the resolver.  A key in the removed state
      MUST NOT be considered a valid trust anchor.

5.  Scenarios

   The suggested model for operation is to have one active key and one
   stand-by key at each trust point.  The active key will be used to
   sign the DNSKEY RRSet.  The stand-by key will not normally sign this
   RRSet, but the resolver will accept it as a trust anchor if/when it
   sees the signature on the trust point DNSKEY RRSet.

   Since the stand-by key is not in active signing use, the associated
   private key may (and SHOULD) be provided with additional protections
   not normally available to a key that must be used frequently.  E.g.
   locked in a safe, split among many parties, etc.  Notionally, the
   stand-by key should be less subject to compromise than an active key,
   but that will be dependent on operational concerns not addressed
   here.

5.1  Adding A Trust Anchor

   Assume an existing trust anchor key 'A'.
   1.  Generate a new key pair.





StJohns                 Expires February 16, 2006               [Page 8]

Internet-Draft             trustanchor-update                August 2005


   2.  Create a DNSKEY record from the key pair and set the SEP and Zone
       Key  bits.
   3.  Add the DNSKEY to the RRSet.
   4.  Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
       'A'.
   5.  Wait a while.

5.2  Deleting a Trust Anchor

   Assume existing trust anchors 'A' and 'B' and that you want to revoke
   and delete 'A'.
   1.  Set the revolcation bit on key 'A'.
   2.  Sign the DNSKEY RRSet with both 'A' and 'B'.
   'A' is now revoked.  The operator SHOULD include the revoked 'A' in
   the RRSet for at least the remove hold-down time, but then may remove
   it from the DNSKEY RRSet.

5.3  Key Roll-Over

   Assume existing keys A and B. 'A' is actively in use (i.e. has been
   signing the DNSKEY RRSet.)  'B' was the stand-by key. (i.e. has been
   in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
   used to sign the RRSet.)
   1.  Generate a new key pair 'C'.
   2.  Add 'C' to the DNSKEY RRSet.
   3.  Set the revocation bit on key 'A'.
   4.  Sign the RRSet with 'A' and 'B'.
   'A' is now revoked, 'B' is now the active key, and 'C' will be  the
   stand-by key once the hold-down expires.  The operator SHOULD include
   the revoked 'A' in the RRSet for at least the remove hold-down time,
   but may then remove it from the DNSKEY RRSet.

5.4  Active Key Compromised

   This is the same as the mechanism for Key Roll-Over (Section 5.3)
   above assuming 'A' is the active key.

5.5  Stand-by Key Compromised

   Using the same assumptions and naming conventions as Key Roll-Over
   (Section 5.3) above:
   1.  Generate a new key pair 'C'.
   2.  Add 'C' to the DNSKEY RRSet.
   3.  Set the revocation bit on key 'B'.
   4.  Sign the RRSet with 'A' and 'B'.
   'B' is now revoked, 'A' remains the active key, and 'C' will be the
   stand-by key once the hold-down expires.  'B' SHOULD continue to be
   included in the RRSet for the remove hold-down time.



StJohns                 Expires February 16, 2006               [Page 9]

Internet-Draft             trustanchor-update                August 2005


6.  Security Considerations

6.1  Key Ownership vs Acceptance Policy

   The reader should note that, while the zone owner is responsible
   creating and distributing keys, it's wholly the decision of the
   resolver owner as to whether to accept such keys for the
   authentication of the zone information.  This implies the decision
   update trust anchor keys based on trust for a current trust anchor
   key is also the resolver owner's decision.

   The resolver owner (and resolver implementers) MAY choose to permit
   or prevent key status updates based on this mechanism for specific
   trust points.  If they choose to prevent the automated updates, they
   will need to establish a mechanism for manual or other out-of-band
   updates outside the scope of this document.

6.2  Multiple Key Compromise

   This scheme permits recovery as long as at least one valid trust
   anchor key remains uncompromised.  E.g. if there are three keys, you
   can recover if two of them are compromised.  The zone owner should
   determine their own level of comfort with respect to the number of
   active valid trust anchors in a zone and should be prepared to
   implement recovery procedures once they detect a compromise.  A
   manual or other out-of-band update of all resolvers will be required
   if all trust anchor keys at a trust point are compromised.

6.3  Dynamic Updates

   Allowing a resolver to update its trust anchor set based in-band key
   information is potentially less secure than a manual process.
   However, given the nature of the DNS, the number of resolvers that
   would require update if a trust anchor key were compromised, and the
   lack of a standard management framework for DNS, this approach is no
   worse than the existing situation.

7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.



StJohns                 Expires February 16, 2006              [Page 10]

Internet-Draft             trustanchor-update                August 2005


   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

Editorial Comments

   [msj1]  msj: N.B. This table is preliminary and will be revised to
           match implementation experience.  For example, should there
           be a state for "Add hold-down expired, but haven't seen the
           new RRSet"?

   [msj2]  msj: To be assigned.

   [msj3]  msj: For discussion: What's the implementation guidance for
           resolvers currently with respect to the non-assigned flag
           bits?  If they consider the flag bit when doing key matching
           at the trust anchor, they won't be able to match.


Author's Address

   Michael StJohns
   Nominum, Inc.
   2385 Bay Road
   Redwood City, CA  94063
   USA

   Phone: [phone]
   Email: [e-mail]
   URI:   www.nominum.com

















StJohns                 Expires February 16, 2006              [Page 11]

Internet-Draft             trustanchor-update                August 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.





StJohns                 Expires February 16, 2006              [Page 12]

Internet-Draft             trustanchor-update                August 2005


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.















































StJohns                 Expires February 16, 2006              [Page 13]