idnits 2.17.1 draft-guette-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 2 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 78: '... the right DS RR MUST be created and s...' RFC 2119 keyword, line 79: '...o the child zone MUST contact its pare...' RFC 2119 keyword, line 105: '... chain of trust MUST be preserved. Ev...' RFC 2119 keyword, line 106: '... during rollover MUST be authenticated...' RFC 2119 keyword, line 107: '...d data integrity MUST be guaranteed ev...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Secret keys are generally stored in a secure off-line area [7]. The name server has no on-line access to these keys. The key rollover solution SHOULD not assume that the server has on-line access to these keys. We have distinguished three entities concerned by the local key rollover process inside a zone: the name server, the zone file manager and the secret key manager. -- 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 (October 20, 2003) is 7466 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) ** 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. -------------------------------------------------------------------------------- 2 Individual G. Guette 3 Internet-Draft IRISA/INRIA Rennes 4 Expires: April 20, 2004 O. Courtay 5 ENST-Bretagne 6 October 20, 2003 8 Requirements for Automated Key Rollover in DNSsec 9 draft-guette-dnsop-key-rollover-requirements-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 30, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This internet-draft describes problems that appear during an 41 automated rollover and gives the requirements for the design of 42 automated solutions rollover process. It essentially concerned key 43 rollover, but rollover of other Resource Records present at 44 delegation point (NS RR) is also discussed. 46 1. Introduction 48 The DNS security extensions (DNSsec) [1] uses public-key cryptography 49 and digital signatures. It stores needed keys in KEY Resource Records 50 (RRs). Because old keys and frequently used keys are vulnerable, they 51 must be changed periodically. In DNSsec this is the case for Zone 52 Signing Keys (ZSKs) and Key Signing Keys (KSKs) [2] [4]. Automation 53 of key rollover process is necessary for large zones because inside a 54 large zone, there are too many changes to handle for a single 55 administrator. 57 Let us consider for example a zone with one million child zones among 58 which only 10% of secured child zones (that is, 100,000 child zones). 59 If the child zones change their keys once a year on average, that 60 implies 300 changes per day for the parent zone. All these changes 61 are hard to manage manually. 63 Automated rollover is optional and resulting from an agreement 64 between parent zone administrators and child zone administrators. 65 Of course, key rollover can also be done manually by administrators. 67 This document describes the requirements for the design of automated 68 solutions for 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) 77 to propagate the performed changes. 78 In KSK rollover, the right DS RR MUST be created and stored in the 79 parent zone, so the child zone MUST contact its parent zone and 80 notify it about the KSK changes. 82 Manual key rollover exists and works [3] but in this draft we 83 describe a way to automate the key rollover process. 85 The key rollover is built from two parts of different nature: 86 - An algorithm that changes keys 87 - Communication between parent and child zone 89 One example of manual key rollover is: 90 Child zone creates a new KSK, waiting for a certain time, DS is 91 created in parent zone, child zone deletes old key. 93 In manual rollover, communications are managed by administrators and 94 security of these communications is out of scope of DNSsec. 96 Automatic key rollover should define a secure communication between 97 parent and child zone. In this draft we concentrate our efforts on 98 defining interactions between entities present in key rollover 99 process that are not explicitly defined in manual key rollover 100 method. 102 3. Basic Requirements 104 The main constraint to respect during a key rollover is that the 105 chain of trust MUST be preserved. Every RR MUST be verifiable at any 106 time, every message exchanged during rollover MUST be authenticated 107 and data integrity MUST be guaranteed even if some RRs are retrieved 108 from recursive name server (cache). 110 Two entities are present during a KSK rollover: child zone and 111 parent zone. These zones are generally managed by different 112 administrators. These administrators MUST agree on some parameters 113 like doing automatic rollover, maximum delay between notification of 114 changes into child zone and resigning of the parent zone, etc. 116 4. Messages authentication 118 Every exchanged message MUST be authenticated and the authentication 119 tool MUST be a DNSsec tool such as TSIG [5], SIG(0) [6] or DNSsec 120 request with verifiable SIG records. 122 Some errors could occur during transmission between child zone and 123 parent zone. Key rollover solution MUST be fault tolerant, i.e. at 124 any time the rollover MUST be in a consistent state and all RRs must 125 be verifiable, even if an error occurs. 127 5. Transmission method and information exchanged 129 Once the changes related to a KSK are made in a child zone, this zone 130 MUST notify its parent zone in order to create the new DS RR and 131 store this DS RR in parent zone file. 132 Whatever the transmission methods used, the parent zone MUST receive 133 the child KSKs for which the child wants that associated DS RRs exist 134 in the parent zone. 136 6. Local separation entities 138 Secret keys are generally stored in a secure off-line area [7]. The 139 name server has no on-line access to these keys. The key rollover 140 solution SHOULD not assume that the server has on-line access to 141 these keys. We have distinguished three entities concerned by the 142 local key rollover process inside a zone: the name server, the zone 143 file manager and the secret key manager. 145 Any automatic rollover solution MUST take into account the possible 146 separation of these three entities and must support partial 147 administrator intervention as manipulation of private key. 149 For example, we can imagine that all entities are handled by 150 automated process but signing action with the private keys is done by 151 human administrator (he retrieves zone file from a repository and put 152 back the signed zone file on well-known location). 154 7. Emergency Rollover 156 Inside a zone, a key might be compromised and this key MUST be 157 changed as fast as possible. The fast changes could break the chain of 158 trust. The part of DNS tree having this zone as apex can become 159 unverifiable, but the break of the chain of trust is necessary if we 160 want that no one can use the compromised key to spoof DNS data. 162 Parent zone behavior after an emergency rollover in one of its child 163 zone is an open discussion. 164 Must we define: 166 - an EMERGENCY flag, when a child zone does an emergency KSK change, 167 it uses the EMERGENCY flag to notify its parents that the chain of 168 trust is broken and will stay broken until right DS creation and a 169 parent zone resigning. 171 - a maximum time delay after next parent zone resigning, we ensure 172 that after this delay the parent zone is resigned and the right DS 173 is created. 175 - or no pre-defined behavior 177 8. Other Resource Record concerned by automatic rollover 179 NS records are also present at delegation point, so when the child 180 zone changes some NS records, the corresponding records at 181 delegation point in parent zone MUST be updated. NS record are 182 concerned by rollover and this rollover could be automated too. In 183 this case, when the child zone notifies its parent zone that some NS 184 records have been changed, the parent zone MUST verify that NS 185 records are present in child zone file before doing any changes in 186 its own zone file. Otherwise the DNS child name server could not be 187 reached. 189 9. Security consideration 191 This document describes requirements to design an automated key 192 rollover in DNSsec based on DNSsec security. In the same way the, as 193 plain DNSsec, the automatic key rollover contains no mechanism 194 protecting against denial of service (DoS) resistant. The security 195 level obtain after an automatic key rollover, is the security level 196 provided by DNSsec. 198 10. Acknowledgments 199 The authors want to acknowledge Mohsen Souissi, Bernard Cousin, 200 Bertrand Leonard and members of IDsA project for their contribution 201 to this document. 203 Normative references 205 [1] Eastlake, D., "Domain Name System Security Extensions", RFC 206 2535, March 1999. 208 [2] Gudmundsson, O., "Delegation Signer Resource Record", 209 draft-ietf-dnsext-delegation-signer-15 (work in progress), 210 June 2003. 212 [3] Kolkman, O. and Gieben, R., "DNSSEC key operations", 213 draft-ietf-dnsext-operational-practices (work in progress), 214 June 2003. 216 [4] Kolkman, O. and Schlyter, J., "KEY RR Secure Entry Point Flag" 217 draft-ietf-dnsext-keyrr-key-signing-flag-10 (work in progress), 218 September 2003. 220 [5] Vixie, P., Gudmundsson, O., Eastlake, D., and Wellington, B., 221 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 222 2845, May 2000. 224 [6] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s)", 225 RFC 2931, September 2000. 227 [7] Eastlake, D.,"DNS Security Operational Considerations", RFC 228 2541, March 1999. 230 Author's Addresses 232 Gilles Guette 233 IRISA/INRIA Rennes 234 Campus Universitaire de Beaulieu 235 35042 Rennes France 236 Phone : (33) 02 99 84 71 32 237 Fax : (33) 02 99 84 25 29 238 E-mail : gguette@irisa.fr 240 Olivier Courtay 241 ENST-Bretagne 242 2, rue de la ch�taigneraie 243 35512 Cesson C�vign� CEDEX France 244 Phone : (33) 02 99 84 71 31 245 Fax : (33) 02 99 84 25 29 246 olivier.courtay@enst-bretagne.fr 248 Intellectual Property Statement 250 The IETF takes no position regarding the validity or scope of any 251 intellectual property or other rights that might be claimed to 252 pertain to the implementation or use of the technology described in 253 this document or the extent to which any license under such rights 254 might or might not be available; neither does it represent that it 255 has made any effort to identify any such rights. Information on the 256 IETF's procedures with respect to rights in standards-track and 257 standards-related documentation can be found in BCP-11. Copies of 258 claims of rights made available for publication and any assurances of 259 licenses to be made available, or the result of an attempt made to 260 obtain a general license or permission for the use of such 261 proprietary rights by implementors or users of this specification can 262 be obtained from the IETF Secretariat. 264 The IETF invites any interested party to bring to its attention any 265 copyrights, patents or patent applications, or other proprietary 266 rights which may cover technology that may be required to practice 267 this standard. Please address the information to the IETF Executive 268 Director. 270 Full Copyright Statement 272 Copyright (C) The Internet Society (2003). All Rights Reserved. 274 This document and translations of it may be copied and furnished to 275 others, and derivative works that comment on or otherwise explain it 276 or assist in its implementation may be prepared, copied, published 277 and distributed, in whole or in part, without restriction of any 278 kind, provided that the above copyright notice and this paragraph are 279 included on all such copies and derivative works. However, this 280 document itself may not be modified in any way, such as by removing 281 the copyright notice or references to the Internet Society or other 282 Internet organizations, except as needed for the purpose of 283 developing Internet standards in which case the procedures for 284 copyrights defined in the Internet Standards process must be 285 followed, or as required to translate it into languages other than 286 English. 288 The limited permissions granted above are perpetual and will not be 289 revoked by the Internet Society or its successors or assignees. 291 This document and the information contained herein is provided on an 292 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 293 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 294 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 295 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 296 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.