📄 draft-ietf-dnsext-trustupdate-timers-01.txt
字号:
Network Working Group M. StJohnsInternet-Draft Nominum, Inc.Expires: February 16, 2006 August 15, 2005 Automated Updates of DNSSEC Trust Anchors draft-ietf-dnsext-trustupdate-timers-01Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 16, 2006.Copyright Notice Copyright (C) The Internet Society (2005).Abstract This document describes a means for automated, authenticated and authorized updating of DNSSEC "trust anchors". The method provides protection against single key compromise of a key in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor. This mechanism, if adopted, will require changes to resolver management behavior (but not resolver resolution behavior), and theStJohns Expires February 16, 2006 [Page 1] Internet-Draft trustanchor-update August 2005 addition of a single flag bit to the DNSKEY record.Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5 2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6 2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8 5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9 5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10 6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10 6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12StJohns Expires February 16, 2006 [Page 2] Internet-Draft trustanchor-update August 20051. Introduction As part of the reality of fielding DNSSEC (Domain Name System Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the community has come to the realization that there will not be one signed name space, but rather islands of signed name space each originating from specific points (i.e. 'trust points') in the DNS tree. Each of those islands will be identified by the trust point name, and validated by at least one associated public key. For the purpose of this document we'll call the association of that name and a particular key a 'trust anchor'. A particular trust point can have more than one key designated as a trust anchor. For a DNSSEC-aware resolver to validate information in a DNSSEC protected branch of the hierarchy, it must have knowledge of a trust anchor applicable to that branch. It may also have more than one trust anchor for any given trust point. Under current rules, a chain of trust for DNSSEC-protected data that chains its way back to ANY known trust anchor is considered 'secure'. Because of the probable balkanization of the DNSSEC tree due to signing voids at key locations, a resolver may need to know literally thousands of trust anchors to perform its duties. (e.g. Consider an unsigned ".COM".) Requiring the owner of the resolver to manually manage this many relationships is problematic. It's even more problematic when considering the eventual requirement for key replacement/update for a given trust anchor. The mechanism described herein won't help with the initial configuration of the trust anchors in the resolvers, but should make trust point key replacement/ rollover more viable. As mentioned above, this document describes a mechanism whereby a resolver can update the trust anchors for a given trust point, mainly without human intervention at the resolver. There are some corner cases discussed (e.g. multiple key compromise) that may require manual intervention, but they should be few and far between. This document DOES NOT discuss the general problem of the initial configuration of trust anchors for the resolver.1.1 Compliance Nomenclature The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119].1.2 Changes since -00 Added the concept of timer triggered resolver queries to refresh theStJohns Expires February 16, 2006 [Page 3] Internet-Draft trustanchor-update August 2005 resolvers view of the trust anchor key RRSet. Re-submitted expired draft as -01. Updated DNSSEC RFC References.2. Theory of Operation The general concept of this mechanism is that existing trust anchors can be used to authenticate new trust anchors at the same point in the DNS hierarchy. When a new SEP key is added to a trust point DNSKEY RRSet, and when that RRSet is validated by an existing trust anchor, then the new key can be added to the set of trust anchors. There are some issues with this approach which need to be mitigated. For example, a compromise of one of the existing keys could allow an attacker to add their own 'valid' data. This implies a need for a method to revoke an existing key regardless of whether or not that key is compromised. As another example assuming a single key compromise, an attacker could add a new key and revoke all the other old keys.2.1 Revocation Assume two trust anchor keys A and B. Assume that B has been compromised. Without a specific revocation bit, B could invalidate A simply by sending out a signed trust point key set which didn't contain A. To fix this, we add a mechanism which requires knowledge of the private key of a DNSKEY to revoke that DNSKEY. A key is considered revoked when the resolver sees the key in a self- signed RRSet and the key has the REVOKE bit set to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this key as a trust anchor or for any other purposes except validating the RRSIG over the DNSKEY RRSet specifically for the purpose of validating the revocation. Unlike the 'Add' operation below, revocation is immediate and permanent upon receipt of a valid revocation at the resolver. N.B. A DNSKEY with the REVOKE bit set has a different fingerprint than one without the bit set. This affects the matching of a DNSKEY to DS records in the parent, or the fingerprint stored at a resolver used to configure a trust point. [msj3] In the given example, the attacker could revoke B because it has knowledge of B's private key, but could not revoke A.2.2 Add Hold-Down Assume two trust point keys A and B. Assume that B has beenStJohns Expires February 16, 2006 [Page 4] Internet-Draft trustanchor-update August 2005 compromised. An attacker could generate and add a new trust anchor key - C (by adding C to the DNSKEY RRSet and signing it with B), and then invalidate the compromised key. This would result in the both the attacker and owner being able to sign data in the zone and have it accepted as valid by resolvers. To mitigate, but not completely solve, this problem, we add a hold- down time to the addition of the trust anchor. When the resolver sees a new SEP key in a validated trust point DNSKEY RRSet, the resolver starts an acceptance timer, and remembers all the keys that validated the RRSet. If the resolver ever sees the DNSKEY RRSet without the new key but validly signed, it stops the acceptance process and resets the acceptance timer. If all of the keys which were originally used to validate this key are revoked prior to the timer expiring, the resolver stops the acceptance process and resets the timer. Once the timer expires, the new key will be added as a trust anchor the next time the validated RRSet with the new key is seen at the resolver. The resolver MUST NOT treat the new key as a trust anchor until the hold down time expires AND it has retrieved and validated a DNSKEY RRSet after the hold down time which contains the new key. N.B.: Once the resolver has accepted a key as a trust anchor, the key MUST be considered a valid trust anchor by that resolver until explictly revoked as described above. In the given example, the zone owner can recover from a compromise by revoking B and adding a new key D and signing the DNSKEY RRSet with both A and B. The reason this does not completely solve the problem has to do with the distributed nature of DNS. The resolver only knows what it sees. A determined attacker who holds one compromised key could keep a single resolver from realizing that key had been compromised by intercepting 'real' data from the originating zone and substituting their own (e.g. using the example, signed only by B). This is no worse than the current situation assuming a compromised key.2.3 Remove Hold-down A new key which has been seen by the resolver, but hasn't reached it's add hold-down time, MAY be removed from the DNSKEY RRSet by the zone owner. If the resolver sees a validated DNSKEY RRSet without this key, it waits for the remove hold-down time and then, if the key hasn't reappeared, SHOULD discard any information about the key.StJohns Expires February 16, 2006 [Page 5] Internet-Draft trustanchor-update August 20052.4 Active Refresh A resolver which has been configured for automatic update of keys from a particular trust point MUST query that trust point (e.g. do a lookup for the DNSKEY RRSet and related RRSIG records) no less often than the lesser of 15 days or half the original TTL for the DNSKEY RRSet or half the RRSIG expiration interval. The expiration interval is the amount of time from when the RRSIG was last retrieved until the expiration time in the RRSIG. If the query fails, the resolver MUST repeat the query until satisfied no more often than once an hour and no less often than the lesser of 1 day or 10% of the original TTL or 10% of the original expiration interval.2.5 Resolver Parameters2.5.1 Add Hold-Down Time The add hold-down time is 30 days or the expiration time of the TTL of the first trust point DNSKEY RRSet which contained the key, whichever is greater. This ensures that at least two validated DNSKEY RRSets which contain the new key MUST be seen by the resolver prior to the key's acceptance.2.5.2 Remove Hold-Down Time The remove hold-down time is 30 days.2.5.3 Minimum Trust Anchors per Trust Point A compliant resolver MUST be able to manage at least five SEP keys per trust point.3. Changes to DNSKEY RDATA Wire Format Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE' flag. If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY) signed by the associated key, then the resolver MUST consider this key permanently invalid for all purposes except for validing the revocation.4. State Table The most important thing to understand is the resolver's view of any key at a trust point. The following state table describes that view at various points in the key's lifetime. The table is a normative part of this specification. The initial state of the key is 'Start'.StJohns Expires February 16, 2006 [Page 6] Internet-Draft trustanchor-update August 2005 The resolver's view of the state of the key changes as various events occur. [msj1] This is the state of a trust point key as seen from the resolver. The column on the left indicates the current state. The header at the top shows the next state. The intersection of the two shows the event that will cause the state to transition from the current state to the next. NEXT STATE -------------------------------------------------- FROM |Start |AddPend |Valid |Missing|Revoked|Removed| ---------------------------------------------------------- Start | |NewKey | | | | | ---------------------------------------------------------- AddPend |KeyRem | |AddTime| | | ---------------------------------------------------------- Valid | | | |KeyRem |Revbit | | ---------------------------------------------------------- Missing | | |KeyPres| |Revbit | | ---------------------------------------------------------- Revoked | | | | | |RemTime| ---------------------------------------------------------- Removed | | | | | | | ----------------------------------------------------------⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -