draft-ietf-dnsext-keyrr-key-signing-flag-12.txt

bind 9.3结合mysql数据库

   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.

6. IANA Considerations

   The flag bits  in the DNSKEY RR are assigned by IETF consensus and
   registered in the DNSKEY Flags registry (created by [4]). This
   document assigns the 15th bit in the DNSKEY RR 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.




Kolkman, et al.          Expires June 17, 2004                  [Page 6]

Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003


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

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", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
        in progress), October 2003.

Informative References

   [5]  Gudmundsson, O., "Delegation Signer Resource Record",
        draft-ietf-dnsext-delegation-signer-15 (work in progress), June
        2003.

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


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
   Karl Gustavsgatan 15
   Goteborg  SE-411 25
   Sweden

   EMail: [e-mail]




Kolkman, et al.          Expires June 17, 2004                  [Page 7]

Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003


   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.          Expires June 17, 2004                  [Page 8]

Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Kolkman, et al.          Expires June 17, 2004                  [Page 9]

Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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











































Kolkman, et al.          Expires June 17, 2004                 [Page 10]