rfc3757.txt

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


RFC 3757                   DNSKEY RR SEP Flag                 April 2004


   When signing a zone, it is intended that the key(s) with the SEP bit
   set (if such keys exist) are used to sign the KEY RR set of the zone.
   The same key can be used to sign the rest of the zone data too.  It
   is conceivable that not all keys with a SEP bit set will sign the
   DNSKEY RR set, such keys might be pending retirement or not yet in
   use.

   When verifying a RR set, the SEP bit is not intended to play a role.
   How the key is used by the verifier is not intended to be a
   consideration at key creation time.

   Although the SEP flag provides a hint on which public key is to be
   used as trusted root, administrators can choose to ignore the fact
   that a DNSKEY has its SEP bit set or not when configuring a trusted
   root for their resolvers.

   Using the SEP flag a key roll over can be automated.  The parent can
   use an existing trust relation to verify DNSKEY RR sets in which a
   new DNSKEY RR with the SEP flag appears.

5.  Security Considerations

   As stated in Section 3 the flag is not to be used in the resolution
   protocol or to determine the security status of a key.  The flag is
   to be used for administrative purposes only.

   No trust in a key should be inferred from this flag - trust MUST be
   inferred from an existing chain of trust or an out-of-band exchange.

   Since this flag might be used for automating public key exchanges, we
   think the following consideration is in place.

   Automated mechanisms for roll over of the DS RR might be vulnerable
   to a class of replay attacks.  This might happen after a public key
   exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
   SEP flag set, is sent to the parent.  The parent verifies the DNSKEY
   RR set with the existing trust relation and creates the new DS RR
   from the DNSKEY RR that the current DS RR is not pointing to.  This
   key exchange might be replayed.  Parents are encouraged to implement
   a replay defense.  A simple defense can be based on a registry of
   keys that have been used to generate DS RRs during the most recent
   roll over.  These same considerations apply to entities that
   configure keys in resolvers.








Kolkman, et al.              Standard Track                     [Page 5]

RFC 3757                   DNSKEY RR SEP Flag                 April 2004


6.  IANA Considerations

   IANA has assigned the 15th bit in the DNSKEY Flags Registry (see
   Section 4.3 of [4]) as the Secure Entry Point (SEP) bit.

7.  Internationalization Considerations

   Although SEP is a popular acronym in many different languages, there
   are no internationalization considerations.

8.  Acknowledgments

   The ideas documented in this document are inspired by communications
   we had with numerous people and ideas published by other folk.  Among
   others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
   Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
   have contributed ideas and provided feedback.

   This document saw the light during a workshop on DNSSEC operations
   hosted by USC/ISI in August 2002.

9.  References

9.1.  Normative References

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

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

   [3]  Lewis, E., "DNS Security Extension Clarification on Zone
        Status", RFC 3090, March 2001.

   [4]  Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
        (DS)", RFC 3755, April 2004.

9.2.  Informative References

   [5]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
        RFC 3658, December 2003.

   [6]  Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
        Story", ISBN 0151002177 (50th anniversary edition), April 1996.







Kolkman, et al.              Standard Track                     [Page 6]

RFC 3757                   DNSKEY RR SEP Flag                 April 2004


10.  Authors' Addresses

   Olaf M. Kolkman
   RIPE NCC
   Singel 256
   Amsterdam  1016 AB
   NL

   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.ripe.net/


   Jakob Schlyter
   NIC-SE
   Box 5774
   SE-114 87 Stockholm
   Sweden

   EMail: [e-mail]
   URI:   http://www.nic.se/


   Edward P. Lewis
   ARIN
   3635 Concorde Parkway Suite 200
   Chantilly, VA  20151
   US

   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.arin.net/



















Kolkman, et al.              Standard Track                     [Page 7]

RFC 3757                   DNSKEY RR SEP Flag                 April 2004


11.  Full Copyright Statement

   Copyright (C) The Internet Society (2004).  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.

   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.

Intellectual Property

   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].

Acknowledgement

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









Kolkman, et al.              Standard Track                     [Page 8]