idnits 2.17.1 draft-ietf-dnsop-resolver-rollover-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 a Security Considerations section. ** 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.) ** The document seems to lack an Authors' Addresses Section. ** There are 12 instances of too long lines in the document, the longest one being 37 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC1035], [RFC3090], [RFC2535], [RFC2541], [IDdkey]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 155: '...ning the new key MUST then be signed w...' RFC 2119 keyword, line 181: '... The application MAY send a notificati...' RFC 2119 keyword, line 184: '... SHOULD send a warning to the resolv...' RFC 2119 keyword, line 187: '...PIRE interval it MUST not discard exis...' RFC 2119 keyword, line 188: '... the application SHOULD send a warning...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 107 has weird spacing: '... of the chain...' == Line 293 has weird spacing: '...ipe.net http:...' == 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 'MUST not' in this paragraph: If the resolver finds it impossible to perform the serial check for the EXPIRE interval it MUST not discard existing statically config-ured keys, the application SHOULD send a warning to the resolver administrator who might wish to unconfigure the key. -- 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 (June 2001) is 8349 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) -- Missing reference section? 'RFC2535' on line 279 looks like a reference -- Missing reference section? 'IDdkey' on line 273 looks like a reference -- Missing reference section? 'RFC3090' on line 285 looks like a reference -- Missing reference section? 'RFC2541' on line 282 looks like a reference -- Missing reference section? 'RFC1035' on line 276 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSOP Working Group Olaf M. Kolkman 2 INTERNET-DRAFT RIPE NCC 3 Miek Gieben 4 NLnet Labs 5 Roy Arends 6 Nominum 8 June 2001 10 Rollover of statically configured resolver keys. 11 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 10 of RFC2026. Internet-Drafts are working documents of 17 the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 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/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Comments should be sent to the authors or to the dnsop WG mailing 35 list dnsop@cafax.se. 37 Copyright Notice 39 Copyright (C) The Internet Society (2001). All rights reserved. 41 Abstract 43 Key rollovers will be needed for secure deployment of the DNS secu- 44 rity extensions (DNSSEC). From an end-user perspective these 45 rollovers should be transparent i.e. at any point in time an end-user 46 should be able to verify the chain of trust from a statically config- 47 ured secure entry point. 49 When a zone is being used as the secure entry point for one or more 50 end-users then a rollover of the keys from that zone will need to 51 result in a reconfiguration of the keys at the end-user resolvers. 53 We propose a simple polling mechanism that can be used for auto- 54 reconfiguration of statically configured keys in end-user resolvers. 56 Table of content 58 1. Scope and Rationale . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. General Description of KEY Rollover. . . . . . . . . . . . . . 4 60 3. Periodic Polling by resolvers. . . . . . . . . . . . . . . . . . 5 61 4. Zone administration considerations. . . . . . . . . . . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. Authors' Addresses: . . . . . . . . . . . . . . . . . . . . . . 8 65 8. Appendix: Notation . . . . . . . . . . . . . . . . . . . . . . . 9 67 11.. SSccooppee aanndd RRaattiioonnaallee 69 "The Domain Name Security Extensions" (DNSSEC) [RFC2535] is a means 70 to provide data integrity and authentication to the DNS. Using signa- 71 tures over DK RRsets [IDdkey] end users can build chains of trust 72 from from statically configured roots of secure island [RFC3090] to 73 the data in the DNS that needs to be verified. In the remainder of 74 this document we will refer to 'statically configured roots of secure 75 islands' as secure entry points. 77 [Author's note: This draft assumes the DK record is used for delegat- 78 ing authority from parent to child but does not rely this particular 79 way of parent-child authority delegation] 81 Key rollover is the process where a ZONE key [RFC3090 section 2,2a] 82 is replaced by another ZONE key. Since Public/Private keys have a 83 limited life time, key rollovers need to happen at regular intervals 84 [RFC2541]. These rollovers are normally referred to as scheduled key 85 rollovers. Emergency key rollovers, where a key needs to be replaced 86 by another key because a private key has been compromised, are not 87 the subject of this document. 89 During DNSSEC operations an end-user(*) follows a chain of trust from 90 one of their statically configured security entry points to the data 91 that needs to be verified. The secure entry point keys are obtained 92 by an initial key exchange. Initial key exchanges are outside the 93 scope of this document. For the end-users it is important that 94 existing chains of trust from the secure entry point to the data 95 somewhere in the DNS remains intact when a zone in the the chain of 96 trust perform a key rollover. 98 The rollover of keys for zones that are configured as secure entry 99 points may happen frequently. As long as the root is not secure, mul- 100 tiple TLD and GTLDs will act as secure entry points, the 'default' 101 zone will in general also be configured as secure entry point so that 102 one does not rely on connectivity to it's parent. 104 Zone administrators will not have a-priory knowledge about which 105 ----------- 106 * In the context of this document an end-user is 107 an entity that does the verification of the chain 108 of trust. This could be a stub resolver but also a 109 caching forwarder. 111 resolvers have their zones configured as secure entry points so it 112 will be impossible for a zone administrator to contact all end-user 113 resolvers when a key exchange is to commence commence. 115 22.. GGeenneerraall DDeessccrriippttiioonn ooff KKEEYY RRoolllloovveerr.. 117 From an end-user's point of view there are two types of rollover. 119 Parent Child rollovers (PC-rollovers), where the zone that rolls over 120 is part of a chain of trust and has authority delegated from a parent 121 zone, and 123 Secure Entry rollovers (SE-rollovers) where the end-user resolver is 124 configured with the key of the zone that rolls over itself. In other 125 words the zone is a secure entry point for the end-user. 127 For zone administrators it is clear they are involved in a PC- 128 rollover; They will have to get get their parent to create a new DK 129 record. For some zones it may not be obvious that their KEYs are con- 130 figured statically at end-user hosts, they will need to enable a SE- 131 rollover. 133 Key rollovers of the root will always be of SE-rollovers. Key 134 rollovers of GTLDs and TLDs are likely to be SE-rollovers. 136 The requirements and policies for a PC-rollovers are somewhat differ- 137 ent from those of a SE-rollovers. In both cases the zone administra- 138 tor decides to rollover it's key and in both cases another party has 139 to take specific action. 141 During a PC-rollover the old an the new key have to coexist in the 142 zone and the zone must be signed with both the old and new key so 143 that end-users can follow the chain of trust from a secure entry 144 point parent downward. This is needed because the DK record change 145 needs some time to propagate through the DNS and during this time 146 there will be DK records in the DNS that point to the old key and DK 147 records that point to the new key. Once the parent's new DK record 148 has been distributed to all the authoritative servers and one is sure 149 the old parent data should have timed out from caches the old key can 150 be removed from the zone. 152 If authority has not been delegated from a parent i.e. the zone 153 administrator is sure that the rollover is only relevant to 154 resolvers. then the old key may immediately be replaced by a new 155 KEY, the key set containing the new key MUST then be signed with both 156 the old and new key so that resolvers can verify the new KEY against 157 the statically configured old KEY. 159 33.. PPeerriiooddiicc PPoolllliinngg bbyy rreessoollvveerrss.. 161 To notice an ongoing key rollover the resolver will need to periodi- 162 cally query for the KEY RRset for the zone it has configured as a 163 secure entry point, if the ZONE KEYS published in the apex of the 164 zone have changed with respect to the statically configured keys a 165 rollover is ongoing. 167 To detect new Zone KEY in the apex of a zone, the resolver uses the 168 same mechanism as slave nameservers use for detecting changes to a 169 primary zone ( section 4.3.5 of [RFC1035] ); The resolver should 170 check the SOA RR by polling the authoritative server periodically. As 171 soon as the SOA serial has been increased, a query for the KEY RRset 172 must be made. The resolver then proceeds by verifying the KEY RRset 173 against one of the existing statically configured keys. The KEY RRset 174 is also verified against the self signatures made with the ZONE keys 175 from the KEY RRset. 177 If both the verifications are successful, the ZONE Keys from the KEY 178 RRset are compared against the existing statically configured keys, 179 if these two sets of keys differ a rollover is taking place and the 180 statically configured KEYs are to be replaced by the ZONE keys from 181 the d KEY RRset. The application MAY send a notification to the 182 resolver administrator who might want to audit the rollover using an 183 off-band mechanism. If one of the verifications fail the application 184 SHOULD send a warning to the resolver administrator. 186 If the resolver finds it impossible to perform the serial check for 187 the EXPIRE interval it MUST not discard existing statically config- 188 ured keys, the application SHOULD send a warning to the resolver 189 administrator who might wish to unconfigure the key. 191 44.. ZZoonnee aaddmmiinniissttrraattiioonn ccoonnssiiddeerraattiioonnss.. 193 If zones are configured as secure entry points then a SE-rollover 194 takes place. Zone administrators have to take the following into 195 account for successful auto-configuration of end-users resolvers. 197 Since resolvers may not be able to poll the KEY RRset for extended 198 times, the period resolvers have access to the new key should be made 199 as long as possible. 201 The time during which the parent zone changes the delegation of 202 authority from the old key to the new key can be relatively short 203 (phase 2 in figure 1). The length of this time interval is determined 204 by the TTL of the parents signature and the REFRESH interval in the 205 parents SOA; all authoritative slave servers must have had the change 206 to load the new DK record and the old DK record must have expired 207 from caches. During this interval the child zone needs to publish 208 two KEYs and signatures made with both the keys. 210 A zone administrator may decide to sign their zone with the old key 211 for an extended period of time (phase 3). During this time resolvers 212 that use the zone as a secure entry point be able to verify the zone 213 with the old key and will still be able to grab the new key. 214 Resolvers that do not have the zone configured as a secure entry 215 point will use the new key when walking the secure tree from the 216 secure entry point via the parent to the zone. 218 Since the intention of a key rollover is to stop using the key there 219 will be a phase 4 where the zone is signed with the new key only. If 220 resolvers that have the zone configured as a secure entry point have 221 not changed the statically configured key the zone and the it's sub 222 zones will become "BAD". 224 Note that during a SE-rollover, i.e. a rollover for zones that are 225 not part of a chain of trust, phase 2 may be skipped. The root would 226 be an example of such a zone. For these zones a resolver that can 227 dynamically update itself, should always have the same statically 228 configured ZONE KEYs as the ZONE KEYs published in the zone itself. 230 ------------------------------------------------------------------- 231 phase 1 phase 2 phase 3 phase 4 233 Before Rollover. parent resolver after Rollover 234 rollover rollover 236 SOA 1 SOA 2 SOA 3 SOA 4 S++1(SOA 237 1) S++1(SOA 2) S++1(SOA 3) S++2(SOA 4) 238 S++2(SOA 2) S++2(SOA 3) 240 K++1 K++1 K++2 K++2 241 S++1(K++1) K++2 S++1(K++2) S++2(K++2) 242 S++1(K++1,K++2) S++2(K++2) 243 S++2(K++1,K++2) 245 Figure 1:Zone status during rollover 247 Key and signature notation is explained in the appendix. The number 248 behind the SOA indicates it's serial number. 249 ------------------------------------------------------------------- 251 55.. SSeeccuurriittyy CCoonnssiiddeerraattiioonnss 253 The key rollover described are based on the verification of new key 254 material against an existing chain of trust. This existing chain of 255 trust can be broken; this could be the case when there was an unno- 256 ticed attack during the initial key exchange or when one of the keys 257 against which is verified has been compromised. Resolver administra- 258 tors should regularly audit statically configured keys against their 259 origin using data that is not published via the DNS. 261 If a key that is statically configured has been compromised, a 262 rollover of statically configured keys of a resolver may be performed 263 by the attacker. To be successful the attacker has to spoof the name- 264 server or pollute a caching forwarder that the end-user uses to 265 obtain the new keys. To limit damage of a compromised key, the mech- 266 anism described here MAY still be used to distribute a new key during 267 an emergency key rollover. Resolvers that are able to get the key 268 from the original nameserver or from an unpolluted cache will not be 269 vulnerable to an attack with compromised keys after the rollover. 271 66.. RReeffeerreenncceess 273 [IDdkey] "Delegation Signer Record in Parent", draft-ietf-dnsext-dele- 274 gation-signer-00.txt, O. Gudmundsson May 30 2001. 276 [RFC1035] "Domain Names - Implementation and Specification", P. Mock- 277 apetris. November 1987. 279 [RFC2535] "Domain Name System Security Extensions", D. Eastlake. March 280 1999. 282 [RFC2541] "DNS Security Operational Considerations", D. Eastlake. March 283 1999. 285 [RFC3090] "DNS Security Extensions Clarification on Zone Status", E. 286 Lewis. March 2001. 288 77.. AAuutthhoorrss'' AAddddrreesssseess:: 290 Olaf M. Kolkman Miek Gieben Roy Arends 291 RIPE NCC Stichting NLnet Labs Nominum 292 OKolkman@ripe.net Miek@nlnetlabs.nl Roy.Arends@nominum.com 293 http://www.ripe.net http://www.nlnetlabs.nl http://www.nominum.com 294 88.. AAppppeennddiixx:: NNoottaattiioonn 296 In this draft we use the following notation: 298 A Key is identified by K++. The owner, pro- 299 tocol and keytag are optional if their value is clear from the con- 300 text or when their value is of no importance. So Kfoo.example+3+1 is 301 the DSA Key with keytag 1 belonging to label foo.example. K++1 and 302 K++2 are two keys from the same zone and algorithm, both not relevant 303 or clear from the context, with different keytags. 305 A Signature is identified as S++(). So Sfoo.example+2+1(www.foo.example A) is the signature 307 made with the foo.example algorithm 2 (DSA) key with keytag 1, over 308 the www.foo.example A record.