3 Internet-Draft IRISA / INRIA
4 Expires: July 19, 2005 O. Courtay
8 Requirements for Automated Key Rollover in DNSSEC
9 draft-ietf-dnsop-key-rollover-requirements-02.txt
13 By submitting this Internet-Draft, I certify that any applicable
14 patent or other IPR claims of which I am aware have been disclosed,
15 and any of which I become aware will be disclosed, in accordance with
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on July 19, 2005.
38 Copyright (C) The Internet Society (2005). All Rights Reserved.
42 This document describes problems that appear during an automated
43 rollover and gives the requirements for the design of communication
44 between parent zone and child zone during an automated rollover
45 process. This document is essentially about in-band key rollover.
50 Guette & Courtay Expires July 19, 2005 [Page 1]
51 Internet-Draft Automated Rollover Requirements January 2005
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
56 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
57 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
58 4. Messages authentication and information exchanged . . . . . . 5
59 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
60 6. Security consideration . . . . . . . . . . . . . . . . . . . . 6
61 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
62 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6
63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
64 A. Documents details and changes . . . . . . . . . . . . . . . . 7
65 Intellectual Property and Copyright Statements . . . . . . . . 8
85 Guette & Courtay Expires July 19, 2005 [Page 2]
86 Internet-Draft Automated Rollover Requirements January 2005
90 The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key
91 cryptography and digital signatures. It stores the public part of
92 keys in DNSKEY Resource Records (RRs). Because old keys and
93 frequently used keys are vulnerable, they must be renewed
94 periodically. In DNSSEC, this is the case for Zone Signing Keys
95 (ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key
96 exchanges between parents and children is necessary for large zones
97 because there are too many changes to handle.
99 Let us consider for example a zone with 100000 secure delegations.
100 If the child zones change their keys once a year on average, that
101 implies 300 changes per day for the parent zone. This amount of
102 changes is hard to manage manually.
104 Automated rollover is optional and resulting from an agreement
105 between the administrator of the parent zone and the administrator of
106 the child zone. Of course, key rollover can also be done manually by
109 This document describes the requirements for a protocol to perform
110 the automated key rollover process and focusses on interaction
111 between parent and child zone.
113 2. The Key Rollover Process
115 Key rollover consists of renewing the DNSSEC keys used to sign
116 resource records in a given DNS zone file. There are two types of
117 rollover, ZSK rollovers and KSK rollovers.
119 During a ZSK rollover, all changes are local to the zone that renews
120 its key: there is no need to contact other zones administrators to
121 propagate the performed changes because a ZSK has no associated DS
122 record in the parent zone.
124 During a KSK rollover, new DS RR(s) must be created and stored in the
125 parent zone. In consequence, data must be exchanged between child
128 The key rollover is built from two parts of different nature:
129 o An algorithm that generates new keys and signs the zone file. It
130 can be local to the zone,
131 o the interaction between parent and child zones.
133 One example of manual key rollover [3] is:
134 o The child zone creates a new KSK,
137 Guette & Courtay Expires July 19, 2005 [Page 3]
138 Internet-Draft Automated Rollover Requirements January 2005
140 o the child zone waits for the creation of the DS RR in its parent
142 o the child zone deletes the old key,
143 o the parent zone deletes the old DS RR.
145 This document concentrates on defining interactions between entities
146 present in key rollover process.
148 3. Basic Requirements
150 This section provides the requirements for automated key rollover in
151 case of normal use. Exceptional case like emergency rollover is
152 specifically described later in this document.
154 The main condition during a key rollover is that the chain of trust
155 must be preserved to every validating DNS client. No matter if this
156 client retrieves some of the RRs from recursive caching name server
157 or from the authoritative servers for the zone involved in the
160 Automated key rollover solution may be interrupted by a manual
161 intervention. This manual intervention should not compromise the
162 security state of the chain of trust. If the chain is safe before
163 the manual intervention, the chain of trust must remain safe during
164 and after the manual intervention
166 Two entities act during a KSK rollover: the child zone and its parent
167 zone. These zones are generally managed by different administrators.
168 These administrators should agree on some parameters like
169 availability of automated rollover, the maximum delay between
170 notification of changes in the child zone and the resigning of the
171 parent zone. The child zone needs to know this delay to schedule its
172 changes and/or to verify that the changes had been taken into account
173 in the parent zone. Hence, the child zone can also avoid some
174 critical cases where all child key are changed prior to the DS RR
177 By keeping some resource records during a given time, the recursive
178 cache servers can act on the automated rollover. The existence of
179 recursive cache servers must be taken into account by automated
182 Indeed, during an automated key rollover a name server could have to
183 retrieve some DNSSEC data. An automated key rollover solution must
184 ensure that these data are not old DNSSEC material retrieved from a
185 recursive name server.
189 Guette & Courtay Expires July 19, 2005 [Page 4]
190 Internet-Draft Automated Rollover Requirements January 2005
192 4. Messages authentication and information exchanged
194 This section addresses in-band rollover, security of out-of-band
195 mechanisms is out of scope of this document.
197 The security provided by DNSSEC must not be compromised by the key
198 rollover, thus every exchanged message must be authenticated to avoid
199 fake rollover messages from malicious parties.
201 Once the changes related to a KSK are made in a child zone, there are
202 two ways for the parent zone to take this changes into account:
203 o the child zone notify directly or not directly its parent zone in
204 order to create the new DS RR and store this DS RR in parent zone
206 o or the parent zone poll the child zone.
208 In both cases, the parent zone must receive all the child keys that
209 need the creation of associated DS RRs in the parent zone.
211 Because errors could occur during the transmission of keys between
212 child and parent, the key exchange protocol must be fault tolerant.
213 Should an error occured during the automated key rollover, an
214 automated key rollover solution must be able to keep the zone files
215 in a consistent state.
217 5. Emergency Rollover
219 Emergency key rollover is a special case of rollover decided by the
220 zone administrator generally for security reasons. In consequence,
221 emergency key rollover can break some of the requirement described
224 A zone key might be compromised and an attacker can use the
225 compromised key to create and sign fake records. To avoid this, the
226 zone administrator may change the compromised key or all its keys as
227 soon as possible, without waiting for the creation of new DS RRs in
230 Fast changes may break the chain of trust. The part of DNS tree
231 having this zone as apex can become unverifiable, but the break of
232 the chain of trust is necessary if the administrator wants to prevent
233 the compromised key from being used (to spoof DNS data).
235 Parent and child zones sharing an automated rollover mechanism,
236 should have an out-of-band way to re-establish a consistent state at
237 the delegation point (DS and DNSKEY RRs). This allows to avoid that
238 a malicious party uses the compromised key to roll the zone keys.
241 Guette & Courtay Expires July 19, 2005 [Page 5]
242 Internet-Draft Automated Rollover Requirements January 2005
244 6. Security consideration
246 The automated key rollover process in DNSSEC allows automated renewal
247 of any kind of DNS key (ZSK or KSK). It is essential that parent
248 side and child side can do mutual authentication. Moreover,
249 integrity of the material exchanged between the parent and child zone
250 must be provided to ensure the right DS are created.
252 As in any application using public key cryptography, in DNSSEC a key
253 may be compromised. What to do in such a case can be describe in the
254 zone local policy and can violate some requirements described in this
255 draft. The emergency rollover can break the chain of trust in order
256 to protect the zone against the use of the compromised key.
260 The authors want to thank members of IDsA project for their
261 contribution to this document.
263 8 Normative References
265 [1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
266 RFC 3658, December 2003.
268 [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
269 (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
272 [3] Kolkman, O., "DNSSEC Operational Practices",
273 draft-ietf-dnsop-dnssec-operational-practice-01 (work in
276 [4] Eastlake, D., "Domain Name System Security Extensions", RFC
279 [5] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
280 "Resource Records for the DNS Security Extensions",
281 draft-ietf-dnsext-dnssec-records-11 (work in progress), October
284 [6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
285 "DNS Security Introduction and Requirements",
286 draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
289 [7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
290 "Protocol Modifications for the DNS Security Extensions",
291 draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October
294 Guette & Courtay Expires July 19, 2005 [Page 6]
295 Internet-Draft Automated Rollover Requirements January 2005
307 EMail: gilles.guette@irisa.fr
308 URI: http://www.irisa.fr
312 1, avenue Belle Fontaine
313 35510 Cesson S?vign? CEDEX
316 EMail: olivier.courtay@thomson.net
318 Appendix A. Documents details and changes
320 This section is to be removed by the RFC editor if and when the
321 document is published.
323 Section about NS RR rollover has been removed
325 Remarks from Samuel Weiler and Rip Loomis added
327 Clarification about in-band rollover and in emergency section
329 Section 3, details about recursive cache servers added
338 Guette & Courtay Expires July 19, 2005 [Page 7]
339 Internet-Draft Automated Rollover Requirements January 2005
341 Intellectual Property Statement
343 The IETF takes no position regarding the validity or scope of any
344 intellectual property or other rights that might be claimed to
345 pertain to the implementation or use of the technology described
346 in this document or the extent to which any license under such
347 rights might or might not be available; neither does it represent
348 that it has made any effort to identify any such rights.
349 Information on the IETF's procedures with respect to rights in
350 IETF Documents can be found in BCP 78 and 79.
352 Copies of IPR disclosures made to the IETF Secretariat and any
353 assurances of licenses to be made available, or the result of an
354 attempt made to obtain a general license or permission for the use
355 of such proprietary rights by implementers or users of this
356 specification can be obtained from the IETF on-line IPR repository
357 at http://www.ietf.org/ipr.
359 The IETF invites any interested party to bring to its attention
360 any copyrights, patents or patent applications, or other
361 proprietary rights which may cover technology that may be required
362 to implement this standard. Please address the information to the
363 IETF at ietf-ipr.org.
366 Full Copyright Statement
368 Copyright (C) The Internet Society (2005). This document is subject
369 to the rights, licenses and restrictions contained in BCP 78, and
370 except as set forth therein, the authors retain all their rights.
372 This document and the information contained herein are provided on an
373 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
374 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
375 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
376 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
377 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
378 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
382 Funding for the RFC Editor function is currently provided by the
389 Guette & Courtay Expires July 19, 2005 [Page 8]