draft-ietf-dnsext-trustupdate-timers-02.txt
来自「非常好的dns解析软件」· 文本 代码 · 共 731 行 · 第 1/2 页
TXT
731 行
---------------------------------------------------------- Revoked | | | | | |RemTime| ---------------------------------------------------------- Removed | | | | | | | ----------------------------------------------------------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.StJohns Expires July 14, 2006 [Page 7] Internet-Draft trustanchor-update January 20064.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. 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.4.3. Trust Point Deletion A trust point which has all of its trust anchors revoked is considered deleted and is treated as if the trust point was never configured. If there are no superior trust points, data at and below the deleted trust point are considered insecure. If there there ARE superior trust points, data at and below the deleted trust point are evaluated with respect to the superior trust point.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.StJohns Expires July 14, 2006 [Page 8] Internet-Draft trustanchor-update January 2006 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. 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.StJohns Expires July 14, 2006 [Page 9] Internet-Draft trustanchor-update January 20065.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.6. IANA Considerations The IANA will need to assign a bit in the DNSKEY flags field (see section 4.3 of [RFC3755]) for the REVOKE bit. There are no other IANA actions required.7. Security Considerations7.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.7.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.StJohns Expires July 14, 2006 [Page 10] Internet-Draft trustanchor-update January 20067.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.8. 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. [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 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.StJohns Expires July 14, 2006 [Page 11] Internet-Draft trustanchor-update January 2006Author's Address Michael StJohns Nominum, Inc. 2385 Bay Road Redwood City, CA 94063 USA Phone: +1-301-528-4729 Email: Mike.StJohns@nominum.com URI: www.nominum.comStJohns Expires July 14, 2006 [Page 12] Internet-Draft trustanchor-update January 2006Intellectual 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 ietf-ipr@ietf.org.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 (2006). 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.Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.StJohns Expires July 14, 2006 [Page 13] ⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?