--- /dev/null
+
+
+
+Intended Status: Informational O. Gudmundsson
+Network Working Group OGUD Consulting LLC
+Internet-Draft J. Ihren
+Expires: August 21, 2008 AAB
+ February 18, 2008
+
+
+ Names of States in the life of a DNSKEY
+ draft-gudmundsson-life-of-dnskey-00
+
+Status 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 August 21, 2008.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2008).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson & Ihren Expires August 21, 2008 [Page 1]
+\f
+Internet-Draft DNSSEC Key life stages. February 2008
+
+
+Abstract
+
+ This document recommends a specific terminology to use when
+ expressing the state that a DNSKEY is in at particular time. This
+ does not affect how the protocol operates in any way.
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. DNSKEY timeline . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Life stages of a DNSKEY . . . . . . . . . . . . . . . . . . . 5
+ 3.1. Generated . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2. Published . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2.1. Pre-Publication . . . . . . . . . . . . . . . . . . . 5
+ 3.2.2. Out-Of-Band Publication . . . . . . . . . . . . . . . 5
+ 3.3. Active . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.4. Retired . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.5. Removed . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.5.1. Lame . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.5.2. Stale . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.6. Revoked . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Security considerations . . . . . . . . . . . . . . . . . . . 7
+ 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
+ 6.2. Informative References . . . . . . . . . . . . . . . . . . 9
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
+ Intellectual Property and Copyright Statements . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson & Ihren Expires August 21, 2008 [Page 2]
+\f
+Internet-Draft DNSSEC Key life stages. February 2008
+
+
+1. Introduction
+
+ When the editors of this document where comparing their DNSSEC key
+ management projects they discovered that they where discussing
+ roughly the same thing but using different terminology.
+
+ This document presents a unified terminology to use when describing
+ the current state of a DNSKEY.
+
+ The DNSSEC standards documents ([1], [2] and [3]) do not address the
+ required states for the key management of a DNSSEC key. The DNSSEC
+ Operational Practices [4] document does propose that keys be
+ published before use but uses inconsistent or confusing terms. This
+ document assumes basic understanding of DNSSEC and key management.
+
+ The terms proposed in this document attempt to avoid any confusion
+ and make the states of keys to be as clear as possible. The terms
+ used in this document are intended as a operational supplement to the
+ terms defined in Section 2 of [1].
+
+ To large extent this discussion is motivated by Trust anchor keys but
+ the same terminology can be used for zone signing keys.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson & Ihren Expires August 21, 2008 [Page 3]
+\f
+Internet-Draft DNSSEC Key life stages. February 2008
+
+
+2. DNSKEY timeline
+
+ The model in this document is that keys progress through a state
+ machine along a one-way path, keys never move to an earlier states.
+
+
+
+ GENERATED----------> PUBLISHED ---> ACTIVE ---> RETIRED --> REMOVED
+ | ^ | | | ^
+ | | | | v |
+ +--> Pre-PUBLISHED--+ +--------+---------> REVOKED ---+
+
+
+ DNSKEY time line.
+
+ There are few more states that are defined below but these apply only
+ to the publisher of TA's and the consumer of TA's. Two of these are
+ sub-sets of the Published state, the other two are error states.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson & Ihren Expires August 21, 2008 [Page 4]
+\f
+Internet-Draft DNSSEC Key life stages. February 2008
+
+
+3. Life stages of a DNSKEY
+
+3.1. Generated
+
+ Once a key is generated it enters state Generated and stays there
+ until the next state. While in this state only the owner of the key
+ is aware of its existence and can prepare for its future use.
+
+3.2. Published
+
+ Once the key is added to the DNSKEY set of a zone the key is there
+ for the world to see, or published. The key needs to remain in this
+ state for some time to propagate to all validators that have cached
+ the prior version of the DNSKEY set. In the case of KSK the key
+ should remain in this state for a longer time as documented in DNSSEC
+ Timers RFC [5].
+
+3.2.1. Pre-Publication
+
+ In certain circumstances a zone owner may want to give out a new
+ Trust Anchor before exposing the actual public key. In this case the
+ zone can publish a DS record of the key. This allows others to
+ configure the trust anchor but will not be able to use the key until
+ the key is published in the DNSKEY RRset.
+
+3.2.2. Out-Of-Band Publication
+
+ In certain circumstances a domain may want to give out a new Trust
+ Anchor outside DNS to give others a long lead time to configure the
+ new key as trust anchor. The reason people may want to do this is to
+ keep the size of the DNSKEY set smaller and only add new trust anchor
+ just before the key goes into use. One likely use for this is the
+ DNS "." root key as it does not have a parent that can publish a DS
+ record for it. The publication mechanism does not matter it can be
+ any one of web-site, advertisement in Financial Times and other
+ international publication, e-mail to DNS related mailing lists, etc..
+
+3.3. Active
+
+ The key is in ACTIVE state while it is actively signing data in the
+ zone it resides in. It is one of the the keys that are signing the
+ zone or parts of the zone.
+
+3.4. Retired
+
+ When the key is no longer used for signing the zone it enters state
+ Retired. In this state there may still be signatures by the key in
+ cached data from the zone available at recursive servers, but the
+
+
+
+Gudmundsson & Ihren Expires August 21, 2008 [Page 5]
+\f
+Internet-Draft DNSSEC Key life stages. February 2008
+
+
+ authoritative servers for the zone do no longer carry any signatures
+ generated by the key.
+
+3.5. Removed
+
+ Once the key is removed from the DNSKEY RRset it enters the state
+ Removed. At this point all signatures by the key that may still be
+ temporarily valid will fail to verify once the validator refreshes
+ the DNSKEY RRset in its memory.
+
+ Therefore "removal" of a key is typically not done until all the
+ cached signatures have expired. Entering this state too early may
+ cause number of validators to end up with STALE Trust Anchors.
+
+3.5.1. Lame
+
+ A Trust Anchor is Lame if the parent continues to publish DS pointing
+ to the key after it has been removed from the DNSKEY RRset. A Trust
+ Anchor is arguably Lame if there are no signatures by a Retired KSK
+ in the zone.
+
+3.5.2. Stale
+
+ A Stale Trust Anchor is an old TA that remains in a validators list
+ of active key(s) after the key has been removed from the zone's
+ DNSKEY RRset.
+
+3.6. Revoked
+
+ There are times when a zone wants to signal that a particular key
+ should not be used at all. The mechanism to do this is to set the
+ REVOKE bit [5]. Any key in any of the while the key is the DNSSKEY
+ set can be exited to Revoked state. After some time in the Revoke
+ state the key will be Removed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson & Ihren Expires August 21, 2008 [Page 6]
+\f
+Internet-Draft DNSSEC Key life stages. February 2008
+
+
+4. Security considerations
+
+ TBD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson & Ihren Expires August 21, 2008 [Page 7]
+\f
+Internet-Draft DNSSEC Key life stages. February 2008
+
+
+5. IANA considerations
+
+ This document does not have any IANA actions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson & Ihren Expires August 21, 2008 [Page 8]
+\f
+Internet-Draft DNSSEC Key life stages. February 2008
+
+
+6. References
+
+6.1. Normative References
+
+6.2. Informative References
+
+ [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033,
+ March 2005.
+
+ [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+ [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Protocol Modifications for the DNS Security Extensions",
+ RFC 4035, March 2005.
+
+ [4] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
+ RFC 4641, September 2006.
+
+ [5] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust
+ Anchors", RFC 5011, September 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson & Ihren Expires August 21, 2008 [Page 9]
+\f
+Internet-Draft DNSSEC Key life stages. February 2008
+
+
+Authors' Addresses
+
+ Olafur Gudmundsson
+ OGUD Consulting LLC
+ 3821 Village Park Drive
+ Chevy Chase, MD 20815
+ USA
+
+ Email: ogud@ogud.com
+
+
+ Johan Ihren
+ Automatica, AB
+ Bellmansgatan 30
+ Stockholm, SE-118 47
+ Sweden
+
+ Email: johani@automatica.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson & Ihren Expires August 21, 2008 [Page 10]
+\f
+Internet-Draft DNSSEC Key life stages. February 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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, THE IETF TRUST 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
+ ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+Gudmundsson & Ihren Expires August 21, 2008 [Page 11]
+\f
git.samba.org / tridge / bind9.git / blobdiff