Internet Engineering Task Force S. Morris Internet-Draft Nominet Intended status: Informational J. Ihren Expires: July 23, 2009 Autonomica J. Dickinson January 19, 2009 DNSSEC Key Management draft-morris-dnsop-dnssec-key-management-00.txt 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 July 23, 2009. Abstract RFC 4641 gives a detailed overview of the operational considerations involved in running a DNSSEC-secured zone, including key rollovers. This document expands on the previous work, and discusses timing considerations in greater depth. It explicitly identifies the relationships between the various time parameters, and gives a suggested algorithm for key rollover in a DNSSEC-secured zone. Morris, et al. Expires July 23, 2009 [Page 1] Internet-Draft DNSSEC Key Management January 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Zone-Signing Keys . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Key Timeline . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Introduction of Zone-Signing Keys in to a Zone . . . . . . 6 2.3. Emergency Zone-Signing Keys . . . . . . . . . . . . . . . 7 2.3.1. Emergency Key Replacement . . . . . . . . . . . . . . 7 2.3.2. Emergency Key Use . . . . . . . . . . . . . . . . . . 8 2.4. Key Rollover Logic . . . . . . . . . . . . . . . . . . . . 9 2.4.1. Actual and Estimated Times . . . . . . . . . . . . . . 10 2.4.2. ZSK Management Procedure . . . . . . . . . . . . . . . 10 3. Key-Signing Keys . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Key Timeline . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Introduction of Key-Signing Keys in to a Zone . . . . . . 15 3.3. Emergency Key-Signing Keys . . . . . . . . . . . . . . . . 15 3.4. Key Rollover . . . . . . . . . . . . . . . . . . . . . . . 15 3.5. Key Rollover Logic . . . . . . . . . . . . . . . . . . . . 15 3.5.1. Actual and Estimated Times . . . . . . . . . . . . . . 15 3.5.2. KSK Management Procedure . . . . . . . . . . . . . . . 16 4. Running the Key Management Procedures . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Morris, et al. Expires July 23, 2009 [Page 2] Internet-Draft DNSSEC Key Management January 2009 1. Introduction When a zone is secured with DNSSEC, [RFC4641] recommends that the keys used to sign the zone are periodically replaced (or "rolled over"). In order to implement this recommendation, the keys need to be managed in order to allow them to be introduced into and removed from the zone at the appropriate times. Considerations that must be taken into account are: o Key and signature records are not only held at the authoritative nameserver; they are also cached at client resolvers. The data on these can be interlinked, e.g. a validator may try to validate a signature retrieved from a cache with a key obtained separately. o To allow for emergency re-signing, additional keys (over and above those used to sign the zone) need to be present. o A query for the key RRset returns all DNSKEY records in the zone. As there is limited space in the UDP packet (even with EDNS0 support), stale key records must be periodically removed. (For the same reason, the number of emergency keys in the zone should be restricted to the minimum required to support the key management policy.) o Zone "boot-strapping" events, where a zone is signed for the first time, can be common in configurations where a large number of zones are being served. Procedures should be able to cope with the introduction of keys into the zone for the first time as well as "steady-state", where the records are being replaced as part of normal zone maintenance. Management policy, e.g. how long a key is used for, also needs to be taken into account. However, the point of key management logic is not to ensure that a "rollover" is completed at a certain time but rather to ensure that no changes are made to the state of keys published in the zone until it is "safe" to do so. In other words, although key management logic enforces policy, it may not enforce it strictly. 1.1. Terminology The terminology used in this document is as defined in [RFC4033] and [RFC4641]. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Morris, et al. Expires July 23, 2009 [Page 3] Internet-Draft DNSSEC Key Management January 2009 document are to be interpreted as described in [RFC2119]. 2. Zone-Signing Keys 2.1. Key Timeline The following diagram shows the time line of a particular ZSK (zone- signing key) and its replacement by its successor. Time increases to the horizontal scale from left to right and the vertical lines indicate events in the life of the key. The events are numbered: significant times and time intervals are marked. |1| |2| |3| |4| |5| |6| |7| |8| |9| | | | | | | | | | Key N | |<-Ip->|<-->|<--------Lz-------->|<--It-->|<--->| | | | | | | | | | Key N+1 | | | | |<--Ip-->|<--->|<----Lz------- - - - | | | | | | | | | Tg Tp Tr Ta Tps Tt Td Tm ---- Time ----> Timeline for a ZSK rollover. Figure 1 Event 1: key N is generated at the generate time (Tg). Although there is no reason why the key cannot be generated immediately prior to publication in the zone (Event 2), some implementations may find it convenient to create a pool of keys in one operation and draw from that pool as required. For this reason, it is shown as a separate event. Keys that are generated but not published are said to be in the generate state. Event 2: key N's DNSKEY record is put into the zone, i.e. it is added to the DNSKEY RRset which is then re-signed with the current key- signing key. Note that it is not used to sign records yet. This time is the key's publication time (Tp), and the key is now in the published state. Event 3: before it can be used, the key must stay in the published state for long enough to guarantee that any resolver that has key records from the zone in its cache will have a copy of this key record. The interval is the publication interval (Ip) and is given Morris, et al. Expires July 23, 2009 [Page 4] Internet-Draft DNSSEC Key Management January 2009 by: Ip = max(TTLk, Nc) + Pd Here, TTLk is the time-to-live (TTL) for the DNSKEY records in the zone and Nc is the negative cache time from the zone's SOA record (calculated as the minimum of the TTL of the SOA record itself (TTLsoa), and the "minimum" field in the record's parameters (Isoamin) [RFC2308]), i.e. Nc = min(TTLsoa, Isoamin) To guarantee validity at all resolvers, the record must exist for at least max(TTLk, Nc) at all servers. But a zone change can take up to Pd (the propagation delay) to replicate to all slave servers, this delay depending on the depth of the master-slave hierarchy. The sum of the two terms (Ip) is the minimum interval after the introduction of a key into the master server at which it can be said that any resolver that has key records from the zone has a copy of that key. At this point, the key is in the ready state and can be used to sign records. The time at which this event occurs is the key's ready time (Tr), which is given by: Tr = Tp + Ip Event 4: at some later time, the key is used to sign the zone. This point is the activation time (Ta) and after this, the key is said to be in the active state. Event 5: while this key is active, thought must be given to its successor. As with the introduction of the present key into the zone, the successor key will need to be published at least Ip before it is used. Denoting the publication time of the successor key by Tps, then: Tps <= Ta + Lz - Ip Here, Lz is the length of time for which a ZSK will be used, known as the ZSK lifetime. It should be noted that unlike the publication interval, Lz is not determined by timing logic, but by key management policy. Lz will be set by the operator according to their assessment of the risks posed by continuing to use a key and the risks associated with key rollover. However, operational considerations may mean a key lives for slightly more or less than Lz. Event 6: while the present ZSK is still active, its successor moves into the ready state. From this time onwards, it could be used to sign the zone. Morris, et al. Expires July 23, 2009 [Page 5] Internet-Draft DNSSEC Key Management January 2009 Event 7: at some point the decision is made to start signing the zone using the successor key. This will be when the current key has been in use for an interval equal to the ZSK lifetime, hence: Tt = Ta + Lz This point in time is the retire time (Tt) of key N; after this the key is said to be retired. (This time is also the point at which the successor key becomes active.) Event 8: the retired key needs to be retained in the zone whilst any resolvers still have RRSIG records in their cache that were created using the key. (It is possible that a resolver could have an unexpired RRSIG record and an expired DNSKEY RRset in the cache when it is asked to provide both to a client. In this case the DNSKEY RRset would need to be looked up again.) This means that once the key is no longer used to sign records, it should be retained in the zone for at least the retire interval (It) given by: It = TTLs + Pd (where TTLs is the TTL of the RRSIG records, and the propagation delay (Pd) is included in the above equation for the same reasons as described for Event 3.) Once this time has passed, the key's dead time (Td) is reached and the key is said to be dead, hence: Td = Tt + It Event 9: at any time after the key becomes dead, it can be removed from the zone and the DNSKEY RRset re-signed with the current key- signing key. This is known as the removal time (Tm), given by: Tm >= Td 2.2. Introduction of Zone-Signing Keys in to a Zone The timeline for the introduction of the first key into the zone, i.e. when the zone is signed for the first time is slightly different from that of a subsequent key. In particular, there is no publication interval. This interval is present in the general case to ensure that should a validator have a cached DNSKEY RRset when it retrieves an RRSIG, that RRset will contain the key used to create the signature. In the case of the first key in the zone, there is no existing DNSKEY RRset and no reason for a validator to have checked for a DNSKEY RRset (as the zone is not signed). Therefore the key can be used to sign the zone immediately. The start of the first key's timeline therefore looks like: Morris, et al. Expires July 23, 2009 [Page 6] Internet-Draft DNSSEC Key Management January 2009 |1| |2| | | Key 1 | |<--------Lz----- - - - | | Tg Tp Tr Ta ---- Time ----> Timeline for introduction of the first ZSK into a zone. Figure 2 Event 1: key 1 is generated at the generate time (Tg). Event 2: key 1's DNSKEY record is put into the zone, i.e. it is added to the DNSKEY RRset which is re-signed with the current key-signing key. It is also used to sign the zone. In this case, and in this case only: Tp = Tr = Ta 2.3. Emergency Zone-Signing Keys Although ZSKs will usually be generated according to some regular schedule, there may be occasions when an emergency ZSK rollover is required, e.g. if a key is suspected of being compromised. The aim of the emergency key rollover is to allow the zone to be re- signed with the new key as soon as possible. As a key must be in the ready state to sign the zone, it may be advisable to have at least one spare ZSK in that state at all times. 2.3.1. Emergency Key Replacement One way to handle this is to regard successor keys as emergency keys, and to introduce them in the zone as early as possible. A modification of Figure 1 illustrates this: Morris, et al. Expires July 23, 2009 [Page 7] Internet-Draft DNSSEC Key Management January 2009 |1| |2| |3| |4| | | | | Key N - - - -- Lz --------->| | | | | | Key N+1 - ----------------->|<--------Lz--------->| | | | | Key N+2 |<--Ip-->|<------------------------>|<--Lz-- - - | | | | ---- Time ----> Timeline showing emergency key replacement. Figure 3 In this figure, it is assumed that key N is initially in the active state and that key N+1 is in the ready state. Key N+1 is the successor to key N but is regarded as the emergency key until the time comes to use it to sign the zone. Event 1: At least Ip (publication interval) before key N's retire time, key N+2 is published in the zone. Event 2: key N+2 moves into the ready state. Event 3: key N is retired and key N+1 becomes active. Key N+2 is now regarded as the emergency key. Event 4: key N+1 is retired and key N+2 becomes the current key. (By this time, key N+3 will have been published and be in the ready state.) The above illustrates one way of handling emergency keys. An equally valid alternative would be to have a permanent emergency key. In this scheme, a key is published in the zone as an emergency key: unless it needs to be used in an emergency, it is never used to sign the zone. Instead, active keys are replaced by their successors as shown in Figure 1. 2.3.2. Emergency Key Use An emergency key rollover could be required at any time. Referring back to Figure 3, should an emergency rollover be required between events 2 and 3, the sequence would happen as previously described: there is a already key (key N+2) ready to take over as the emergency key when the current emergency key becomes active. In the worst case though, it may be required that the system run without an emergency Morris, et al. Expires July 23, 2009 [Page 8] Internet-Draft DNSSEC Key Management January 2009 key for a while. For example, if a key rollover was required between events 3 and 4 in Figure 3, the timeline would look like: |3a| |3b| | | Key N+1 - --- Lz --->| | | | Key N+2 - ---------->|<----------Lz----- - - | | Key N+3 |<--Ip-->|<-------- - - | | ---- Time ----> Timeline showing emergency key rollover. Figure 4 In the above figure, the interval shown lies between events 3 and 4 in Figure 3, the events being labelled 3a and 3b to highlight this. Here it is assumed that key N+1 is initially in the active state and that the single emergency key (N+2) is in the ready state. It is well before the active key's retire time, so there are only these two ZSKs in the zone. The events are: Event 3a: an emergency ZSK rollover is required. Key N+1 is retired and key N+2 becomes active. At this time, key N+3 (which will ultimately become the new emergency key) is published in the zone. Event 3b: key N+3 moves into the ready state, after which it can be used to replace key N+1 should the need arise. Between events 3a and 3b however, only the active key (key N+2) can be used to sign the zone. If a second emergency arises in this interval, the active key cannot be replaced: key rollover must wait until the new emergency key (N+3) becomes ready. Of course, this can be mitigated by having a number of emergency keys available, but how many is a matter of policy; there is a need to weigh the likelihood of a security breach against the number of keys required. 2.4. Key Rollover Logic Morris, et al. Expires July 23, 2009 [Page 9] Internet-Draft DNSSEC Key Management January 2009 2.4.1. Actual and Estimated Times In the above discussions, mention has been made of a number of significant times in the life of a key, e.g. publication time, activation time etc. At any particular time, the key is in one and only one state. The time at which it entered that state (and the time at which it entered all past states) are actual times. All future times are estimated times. For example, although the retire time of an active key is "activation time + key lifetime", until the key actually makes the transition into the retired state (by no longer being used to sign the zone), the retire time is only an estimated time: it may change depending on events. 2.4.2. ZSK Management Procedure The following section describes the procedure for maintaining ZSKs. It handles key rollover - both scheduled and emergency - as well as flagging which keys should be published in preparation for use in signing the zone. The following is assumed: 1. Information about keys is held in some data store. The information includes the state of each key and the times associated with each state change for each key. 2. There is only one active ZSK at any one time. 3. The procedure is run on a frequent basis that depends on the interval between events in the timeline in Figure 1. (This is discussed further below.) In the following discussion, "now()" is the time at which the procedure is run. Also defined is Nze as the number of emergency ZKSs required to be able to immediately roll at any time for emergency reasons. A likely value is: Nze = 1 1. For all keys in the data store, calculate the estimated time of entering the next stage using the relationships described above. 2. If this procedure is being run as part of an emergency rollover, set the estimated retirement time for the active key(s) as now(). (In this way, an emergency key rollover requires no special processing: it is merely the early retirement of the active key.) Morris, et al. Expires July 23, 2009 [Page 10] Internet-Draft DNSSEC Key Management January 2009 3. For each retired key, if now() >= Td, mark the key as dead. (Or remove it from the data store. Either way, this key is no longer of use and will never be used again.) 4. For each published key, if now() >= Tr, mark the key as ready. 5. If now() is within (Ip + Ri) of the estimated retire time of the active key (where Ri is the interval between runs of the procedure) AND the number of keys in the publish and ready states combined is less than (1 + Nze), move a number of keys equal to the difference between these two values from the generate state into the publish state. (This step ensures that when the active key is retired, there is a key to replace it as well as the desired number of emergency keys in the ready state.) The term Ri appears here because to avoid a policy violation (i.e. a delay in retiring the active key) this action must occur at least Ip before the estimated retire time of the key. As the procedure is run at intervals, the only way to guarantee this is to add a margin equal to the run interval. 6. If now() is earlier than the retire time of the active key, exit. (Note "earlier"; if an emergency rollover is taking place, the retirement time of the active key(s) will be equal to now() due to the processing of step 2.) 7. Check whether there are keys in the ready state. If not, the currently active key cannot be retired and the procedure will have to wait until one or more keys becomes ready. In this case, exit the procedure. 8. Set the retire time of the active key to now(). 9. Mark one of the ready keys as active. After this procedure, all keys in the publish, ready, active and retire states should be published in the zone. The active key should be used to sign the zone. 3. Key-Signing Keys 3.1. Key Timeline There are three significant differences between key-signing keys (KSKs) and ZSKs: Morris, et al. Expires July 23, 2009 [Page 11] Internet-Draft DNSSEC Key Management January 2009 1. KSKs only sign the DNSKEY RRset. This means that, unlike ZSKs, it is feasible to use multiple KSKs to sign the zone without generating a excessive amount of signature data. 2. They have to involve the parent zone in the addition and removal of DS records. 3. KSKs may be configured as so-called "trust anchors" in validating resolvers. Whether or not a KSK is used as a trust anchor and how to transport the KSK to the validator in a secure way is outside the scope of this document. The first difference has led to the preferred method for handling KSK rollover [RFC4641] being that of double-signature: the DNSKEY RRset is signed by both the new key and the old key and the associated DS records for both published in the parent zone. After a suitable interval, the records for the old key are removed. This is the scheme adopted in the timeline below. The second difference means that timings are not wholly within the control of the zone manager, in that the time take to publish the DS records depends on the policies and procedures of the parent zone. A further ramification is that the independence of the parent DS and child DNSKEY records means that downstream validators might have inconsistent data, i.e. the DS record without the DNSKEY record or vice-versa. Although this is valid state according to [RFC4035], the information cannot be used for validation until the validator has both components. |1| |2| |3| |4| |5| |6| |7| |8| | | | | | | | | Key N | |<-Ip->|<-->|<--------Lk-------->|<------>| | | | | | | | | Key N+1 | | | | |<--Ip-->|<--->|<----Lk--- - - - | | | | | | | | Tg Tp Tr Ta Tps Tt Tm ---- Time ----> Timeline for a KSK rollover. Figure 5 Event 1: key N is generated at time Tg and enters the generate state. As before, although there is no reason why the key cannot be Morris, et al. Expires July 23, 2009 [Page 12] Internet-Draft DNSSEC Key Management January 2009 generated immediately prior to publication, some implementations may find its convenient to create a central pool of keys and draw from it. For this reason, it is again shown as a separate event. Event 2: the key is added to and used for signing the DNSKEY RRset and is thereby published in the zone. At the same time, the corresponding DS record is also submitted to the parent zone for publication. This time is the publish time (Tp) and the KSK is said to be in the published state. Event 3: after some time (the publication interval, Ip), any validator that has copies of the DNSKEY and/or DS RRsets in its cache will have a copy of the data for key N. This point is the ready time and is given by: Tr = Tp + Ip In the case of the KSK, the publication interval depends on the publication interval of both the DNSKEY record and the DS record. These are independent of one another, so a suitable expression for Ip is: Ip = max(Ipc, Ipp) ... where Ipc is the publication interval in the child zone and Ipp that of the parent. The child term comprises two parts - the time taken for the introduction of the DNSKEY record to be registered on the downstream slave servers (= Pdc, the child propagation delay) and the time taken for information about the DNSKEY RRset to expire from the validator cache, i.e. Ipc = max(TTLkc, Ncc) + Pdc (TTLkc is the TTL for a DNSKEY record in the child zone and Ncc the negative cache time in that zone.) The parent term is similar, but also includes the time taken for the DS record to be included in the parent zone after the request has been made. In other words: Ipp = Rt + max(TTLdp, Ncp) + Pdp (TTLdp is the TTL for a DS record in the parent zone, Ncp the negative cache time in that zone, Pdp the propagation delay. Rt is the registration time, which is the time taken between the submission of the DS record to the parent zone and its publication in the zone.) Morris, et al. Expires July 23, 2009 [Page 13] Internet-Draft DNSSEC Key Management January 2009 As the key has already been used to sign the DNSKEY RRset, the key is also active, in that all other KSKs could be withdrawn from the zone at this point and the zone would still be valid. However, while a predecessor key is active, it is convenient to regard the successor key as merely being ready. Event 4: at some later time, the predecessor key is withdrawn from the zone and, in the absence of any emergency keys, key N becomes the only KSK for the zone. The key is said to be active, and this time is the active time (Ta) Event 5: as with the ZSK, at some point we need to give thought to key replacement. The successor key must be introduced into the zone at a time such that when the current key is withdrawn, any validator that has key information (DNSKEY and/or DS records) in its cache will have data about the successor key. As before, this interval is the publication interval, Ip. Denoting the publication time of the successor key as Tps, we get: Tps <= Ta + Lk - Ip Event 6: the successor key (key N+1) enters the ready state. Event 7: at some time a decision will be made to retire the current key (key N). This will be when the current key has been active for its lifetime (Lk). At this point, the retire time, the key is said to be retired: Tt <= Ta + Lk At the same time, the successor key becomes active. Event 8: at some later time, the DNSKEY record can be removed from the child zone and a request made to remove the DS record from the parent zone. This is the removal time Tm and is given by: Tm >= Tt (Note that there is no "dead" state. A ZSK is dead when it has stopped being used to sign the zone (although the key is still published) and when all downstream validators have removed from their caches any signatures created using it. In the case of a KSK, it is used to sign the DNSKEY RRset right up to the point at which it is removed from the zone.) Morris, et al. Expires July 23, 2009 [Page 14] Internet-Draft DNSSEC Key Management January 2009 3.2. Introduction of Key-Signing Keys in to a Zone There is no special requirement on the introduction of key-signing keys into a zone. Until a downstream validator is in possession of both a valid DNSKEY record and its corresponding DS record, the key cannot be used for validation of the zone and the zone will be treated as unsigned [RFC4035] (section 5.1). Therefore the only consideration is how long the DNSKEY and DS take to propagate through the DNS infrastructure before the all validators regard the zone as signed. 3.3. Emergency Key-Signing Keys In the same way that additional ZSKs are kept in a ready state in the zone to act as emergency keys, additional KSKs need to be available in the ready state for the same reason. The number of emergency keys kept available is a matter of key management policy, and the logic for the introduction of emergency keys into the zone is the same as that given in Section 2.3.1. 3.4. Key Rollover KSK rollovers can not be fully automatic. The reason is that by definition, they have to involve the parent zone. If (as is the usual case) the parent zone is managed by a different entity then some of the steps in the KSK rollover operation have to wait for confirmation from the parent before proceeding to the next step. This has been represented above by the DS request time, Rt. It is important to note however, that this does not preclude the development of key rollover logic similar to that described in Section 2.4.2 for the ZSKs. In accordance with the goal of the rollover logic being able to determine when a state change is "safe", the only effect of being dependent on the parent is that there may be a period waiting for the parent to respond, in addition to any interval the key rollover logic requires. Although this introduces additional delays, even with a parent that is less than ideally responsive the only effect will be a slowdown in the rollover state transitions. This may cause a policy violation, but will not cause any operational problems. 3.5. Key Rollover Logic 3.5.1. Actual and Estimated Times Time stamps for KSK rollovers exhibit the same behaviour as for ZSK rollovers in that all times are estimates until after the event to Morris, et al. Expires July 23, 2009 [Page 15] Internet-Draft DNSSEC Key Management January 2009 which they refer has occurred. 3.5.2. KSK Management Procedure The following section describes the procedure for maintaining KSKs in a zone. It handles key rollover - both scheduled and emergency - as well as flagging which keys should be published in preparation for use in signing the zone. As before, it is assumed that data about keys is held in some key management store, that the procedure is run on a regular basis and that "now()" is the time at which the procedure is run. Also defined is Nke as the number of emergency KSKs required to be able to immediately roll at any time for emergency reasons. A likely value is: Nke = 1 1. For all keys in the data store, calculate the estimated time of entering the next stage using the relationships described above. 2. If this procedure is being run as part of an emergency rollover, set the estimated retirement time for the active key(s) as now(). (In this way, an emergency key rollover requires no special processing: it is merely the early retirement of the active key.) 3. For each published key, if now() >= Tr, mark the key as ready. 4. If now() is within (Ip + Ri) of the estimated retire time of the active key (where Ri is the interval between runs of the procedure) AND the number of keys in the publish and ready states combined is less than (1 + Nke), move a number of keys equal to the difference between these two values from the generate state into the publish state. (This step ensures that when the active key is retired, there are keys available to take over from it.) The term Ri appears here because to avoid a policy violation (i.e. a delay in retiring the active key) this action must occur at least Ip before the estimated retire time of the key. As the procedure is run at intervals, the only way to guarantee this is to add a margin equal to the run interval. 5. If now() < Tt of the current key, exit the procedure. 6. If now() >= Tt of the current key AND there are no keys in the ready state, exit the procedure. Morris, et al. Expires July 23, 2009 [Page 16] Internet-Draft DNSSEC Key Management January 2009 7. Check that the DS record of the successor key is available from the parent zone. The check may be made in a variety of ways, including querying the server furthest down the chain of parent nameservers or querying one of or all of the parent nameservers. The key that will replace the active key is in the ready state. However, the entry to the ready state is based on the assumption that the DS record has been published after a time Rt. But that is only an assumption, and relies on the behaviour of the parent zone operator. To be safe, a check is made that the DS record has propagated through the parent's server network. If it hasn't, there may have been some breakdown in communication with the parent zone. 8. Mark the successor key as active, and remove all retired keys from the zone. After this procedure, all keys in the publish, ready, active and retire states should be published in the zone. The active key should be used to sign the DNSKEY RRset. 4. Running the Key Management Procedures The preceding sections outlined procedures to be used to manage KSKs and ZSKs. One way to use these procedures is to run them only when a significant event occurs. In other words, when a procedure completes, calculate the time at which the next event will occur and run it again at that time. In practice though, it will be easier to run them on a regular basis. This has two implications: 1. Depending on the frequency of running the procedure, in many cases the result will be a no-op; the set of keys to be published in the zone will be unchanged from the last time it is run. 2. Policy will not be enforced exactly, e.g. the a key may remain active longer that the key lifetime because the procedure is not run until some time after the retire time is reached. Neither of these objections is fatal. In the first case, it will be easy to detect that a key set is unchanged and so prevent a needless update. The latter case is dealt with by reducing the run interval to the point at which the maximum delay in making a transition between the states of keys is acceptable. Morris, et al. Expires July 23, 2009 [Page 17] Internet-Draft DNSSEC Key Management January 2009 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations This document does not introduce any new security issues beyond those already discussed in [RFC4033], [RFC4034] and [RFC4035]. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [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. [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006. Authors' Addresses Stephen Morris Nominet Minerva House, Edmund Halley Road Oxford, OX4 4DQ UK Phone: +44 1865 332211 Email: stephen.morris@nominet.org.uk Morris, et al. Expires July 23, 2009 [Page 18] Internet-Draft DNSSEC Key Management January 2009 Johan Ihren Autonomica Bellmansgatan 30 Stockholm, SE-118 47 Sweden Phone: +46 8615 8573 Email: johani@autonomica.se John Dickinson 6 Nelson Close Wallingford, OX10 0LG UK Phone: Email: jad@jadickinson.co.uk Morris, et al. Expires July 23, 2009 [Page 19] Internet-Draft DNSSEC Key Management January 2009 Full Copyright Statement Copyright (C) The IETF Trust (2009). 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. Morris, et al. Expires July 23, 2009 [Page 20]