idnits 2.17.1 draft-ietf-dnsop-key-rollover-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 5 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 79: '...er, new DS RR(s) MUST be created and s...' RFC 2119 keyword, line 80: '..., the child zone MUST contact its pare...' RFC 2119 keyword, line 99: '...ted key rollover MUST use a secure com...' RFC 2119 keyword, line 108: '... chain of trust MUST be preserved. Ev...' RFC 2119 keyword, line 109: '...server. Every RR MUST be verifiable at...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 8, 2004) is 7381 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '7' is defined on line 222, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (ref. '1') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- No information found for draft-ietf-dnsext-operational-practices - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-12) exists of draft-ietf-dnsext-keyrr-key-signing-flag-10 ** Obsolete normative reference: RFC 2845 (ref. '5') (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 2541 (ref. '7') (Obsoleted by RFC 4641) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSOP G. Guette 2 Internet-Draft IRISA/INRIA Rennes 3 Expires: August 8, 2004 O. Courtay 4 ENST-Bretagne 5 February 8, 2004 7 Requirements for Automated Key Rollover in DNSsec 8 draft-ietf-dnsop-key-rollover-requirements-00 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 8, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document describes problems that appear during an automated 40 rollover and gives the requirements for the design of communication 41 between parent zone and child zone in an automated rollover process. 42 This document is essentially about key rollover, the rollover of 43 one other Resource Record present at delegation point (NS RR) is 44 also discussed. 46 1. Introduction 48 The DNS security extensions (DNSsec) [1] uses public-key cryptography 49 and digital signatures. It stores the public keys in KEY Resource 50 Records (RRs). Because old keys and frequently used keys are 51 vulnerable, they must be changed periodically. In DNSsec this is the 52 case for Zone Signing Keys (ZSKs) and Key Signing Keys (KSKs) [2, 4]. 53 Automation of key rollover process is necessary for large zones 54 because inside a large zone, there are too many changes to handle for 55 a single administrator. 57 Let us consider for example a zone with one million child zones among 58 which only 10% of secured child zones. If the child zones change their 59 keys once a year on average, that implies 300 changes per day for the 60 parent zone. All these changes are hard to manage manually. 62 Automated rollover is optional and resulting from an agreement 63 between the administrator of the parent zone and the administrator of 64 the child zone. Of course, key rollover can also be done manually by 65 administrators. 67 This document describes the requirements for the design of messages 68 of automated key rollover process. 70 2. The Key Rollover Process 72 Key rollover consists in replacing the DNSsec keys used to sign 73 resource records in a given DNS zone file. There are two types of 74 rollover, ZSK rollover and KSK rollover. 75 In ZSK rollover, all changes are local to the zone that changes its 76 key: there is no need to contact other zones (e.g. parent zone) to 77 propagate the performed changes because this type of key have no 78 associated DS records in the parent zone. 79 In KSK rollover, new DS RR(s) MUST be created and stored in the 80 parent zone. In consequence, the child zone MUST contact its parent 81 zone and notify it about the KSK change(s). 83 Manual key rollover exists and works [3]. The key rollover is built 84 from two parts of different nature: 85 - An algorithm that generates new keys. It could be local to the 86 zone 87 - The interaction between parent and child zone 89 In this document we focus on the interaction between parent and 90 child zone servers. 91 One example of manual key rollover is: 92 Child zone creates a new KSK, waiting for the creation of the DS 93 record in its parent zone and then child zone deletes old key. 95 In manual rollover, communications are managed by the zone 96 administrators and the security of these communications is out of 97 scope of DNSsec. 99 Automated key rollover MUST use a secure communication between parent 100 and child zone. In this document we concentrate our efforts on 101 defining interactions between entities present in key rollover 102 process that are not explicitly defined in manual key rollover 103 method. 105 3. Basic Requirements 107 The main constraint to respect during a key rollover is that the 108 chain of trust MUST be preserved. Even if a resolver retrieve some RRs 109 from recursive name server. Every RR MUST be verifiable at any time, 110 every message exchanged during rollover MUST be authenticated and 111 data integrity MUST be guaranteed. 113 Two entities are present during a KSK rollover: the child zone and 114 its parent zone. These zones are generally managed by different 115 administrators. These administrators MUST agree on some parameters 116 like availability of automated rollover, the maximum delay between 117 notification of changes in the child zone and the resigning of the 118 parent zone. The child zone needs to know this delay to schedule its 119 changes. 121 During an automated rollover process, data are transmitted between 122 the primary name server of the parent and the the primary name server 123 of the child zone. 124 The reason is that the IP address of the primary name server is easy 125 to obtain. 126 Other solutions based on machine dedicated to the rollover are not 127 suitable solutions because of the difficulty to obtain the IP 128 addresses of the dedicated machine in an automated manner. 130 4. Messages authentication and information exchanged 132 Every exchanged message MUST be authenticated and the authentication 133 tool MUST be a DNSsec tool such as TSIG [5], SIG(0) [6] or DNSsec 134 request with verifiable SIG records. 136 Once the changes related to a KSK are made in a child zone, this zone 137 MUST notify its parent zone in order to create the new DS RR and 138 store this DS RR in parent zone file. 140 The parent zone MUST receive all the child Keys that needs the 141 creation of an associated DS RRs in the parent zone. 143 Some errors could occur during transmission between child zone and 144 parent zone. Key rollover solution MUST be fault tolerant, i.e. at 145 any time the rollover MUST be in a consistent state and all RRs MUST 146 be verifiable, even if an error occurs. That is to say that it MUST 147 remains a valid chain of trust. 149 5. Emergency Rollover 151 A key of a zone might be compromised and this key MUST be changed as 152 soon as possible. Fast changes could break the chain of trust. The 153 part of DNS tree having this zone as apex can become unverifiable, 154 but the break of the chain of trust is necessary if we want to no one 155 can use the compromised key to spoof DNS data. 157 Parent zone behavior after an emergency rollover in one of its child 158 zone is an open discussion. 159 Should we define: 161 - an EMERGENCY flag. When a child zone does an emergency KSK change, 162 it uses the EMERGENCY flag to notify its parents that the chain of 163 trust is broken and will stay broken until right DS creation and a 164 parent zone resigning. 166 - a maximum time delay after next parent zone resigning, we ensure 167 that after this delay the parent zone is resigned and the right DS 168 is created. 170 - that no pre-defined behavior for the parent zone is needed 172 6. Other Resource Record concerned by automatic rollover 174 NS records are also present at delegation point, so when the child 175 zone changes some NS records, the corresponding records at 176 delegation point in parent zone MUST be updated. NS records are 177 concerned by rollover and this rollover could be automated too. In 178 this case, when the child zone notifies its parent zone that some NS 179 records have been changed, the parent zone MUST verify that these NS 180 records are present in child zone before doing any changes in its own 181 zone file. This allow to avoid inconsistency between NS records at 182 delegation point and NS records present in the child zone. 184 7. Security consideration 186 This document describes requirements to design an automated key 187 rollover in DNSsec based on DNSsec security. In the same way the, as 188 plain DNSsec, the automatic key rollover contains no mechanism 189 protecting against denial of service (DoS) resistant. The security 190 level obtain after an automatic key rollover, is the security level 191 provided by DNSsec. 193 8. Acknowledgments 194 The authors want to acknowledge Mohsen Souissi, Bernard Cousin, 195 Bertrand Leonard and members of IDsA project for their contribution 196 to this document. 198 Normative references 200 [1] Eastlake, D., "Domain Name System Security Extensions", RFC 201 2535, March 1999. 203 [2] Gudmundsson, O., "Delegation Signer Resource Record", 204 draft-ietf-dnsext-delegation-signer-15 (work in progress), 205 June 2003. 207 [3] Kolkman, O. and Gieben, R., "DNSSEC key operations", 208 draft-ietf-dnsext-operational-practices (work in progress), 209 June 2003. 211 [4] Kolkman, O. and Schlyter, J., "KEY RR Secure Entry Point Flag" 212 draft-ietf-dnsext-keyrr-key-signing-flag-10 (work in progress), 213 September 2003. 215 [5] Vixie, P., Gudmundsson, O., Eastlake, D., and Wellington, B., 216 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 217 2845, May 2000. 219 [6] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s)", 220 RFC 2931, September 2000. 222 [7] Eastlake, D.,"DNS Security Operational Considerations", RFC 223 2541, March 1999. 225 Author's Addresses 227 Gilles Guette 228 IRISA/INRIA Rennes 229 Campus Universitaire de Beaulieu 230 35042 Rennes France 231 Phone : (33) 02 99 84 71 32 232 Fax : (33) 02 99 84 25 29 233 E-mail : gguette@irisa.fr 235 Olivier Courtay 236 ENST-Bretagne 237 2, rue de la ch�taigneraie 238 35512 Cesson C�vign� CEDEX France 239 Phone : (33) 02 99 84 71 31 240 Fax : (33) 02 99 84 25 29 241 olivier.courtay@enst-bretagne.fr 243 Intellectual Property Statement 245 The IETF takes no position regarding the validity or scope of any 246 intellectual property or other rights that might be claimed to 247 pertain to the implementation or use of the technology described in 248 this document or the extent to which any license under such rights 249 might or might not be available; neither does it represent that it 250 has made any effort to identify any such rights. Information on the 251 IETF's procedures with respect to rights in standards-track and 252 standards-related documentation can be found in BCP-11. Copies of 253 claims of rights made available for publication and any assurances of 254 licenses to be made available, or the result of an attempt made to 255 obtain a general license or permission for the use of such 256 proprietary rights by implementors or users of this specification can 257 be obtained from the IETF Secretariat. 259 The IETF invites any interested party to bring to its attention any 260 copyrights, patents or patent applications, or other proprietary 261 rights which may cover technology that may be required to practice 262 this standard. Please address the information to the IETF Executive 263 Director. 265 Full Copyright Statement 267 Copyright (C) The Internet Society (2003). All Rights Reserved. 269 This document and translations of it may be copied and furnished to 270 others, and derivative works that comment on or otherwise explain it 271 or assist in its implementation may be prepared, copied, published 272 and distributed, in whole or in part, without restriction of any 273 kind, provided that the above copyright notice and this paragraph are 274 included on all such copies and derivative works. However, this 275 document itself may not be modified in any way, such as by removing 276 the copyright notice or references to the Internet Society or other 277 Internet organizations, except as needed for the purpose of 278 developing Internet standards in which case the procedures for 279 copyrights defined in the Internet Standards process must be 280 followed, or as required to translate it into languages other than 281 English. 283 The limited permissions granted above are perpetual and will not be 284 revoked by the Internet Society or its successors or assignees. 286 This document and the information contained herein is provided on an 287 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 288 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 289 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 290 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 291 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.