DNSOP Working Group Olaf M. Kolkman INTERNET-DRAFT RIPE NCC Miek Gieben NLnet Labs Roy Arends Nominum June 2001 Rollover of statically configured resolver keys. Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Comments should be sent to the authors or to the dnsop WG mailing list dnsop@cafax.se. Copyright Notice Copyright (C) The Internet Society (2001). All rights reserved. Kolkman et al. Expires December 2001 [Page 1] INTERNET-DRAFT draft-ietf-dnsop-resolver-rollover-00.txt June 2001 Abstract Key rollovers will be needed for secure deployment of the DNS secu- rity extensions (DNSSEC). From an end-user perspective these rollovers should be transparent i.e. at any point in time an end-user should be able to verify the chain of trust from a statically config- ured secure entry point. When a zone is being used as the secure entry point for one or more end-users then a rollover of the keys from that zone will need to result in a reconfiguration of the keys at the end-user resolvers. We propose a simple polling mechanism that can be used for auto- reconfiguration of statically configured keys in end-user resolvers. Table of content 1. Scope and Rationale . . . . . . . . . . . . . . . . . . . . . . . 3 2. General Description of KEY Rollover. . . . . . . . . . . . . . 4 3. Periodic Polling by resolvers. . . . . . . . . . . . . . . . . . 5 4. Zone administration considerations. . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Authors' Addresses: . . . . . . . . . . . . . . . . . . . . . . 8 8. Appendix: Notation . . . . . . . . . . . . . . . . . . . . . . . 9 Kolkman et al. Expires December 2001 [Page 2] INTERNET-DRAFT draft-ietf-dnsop-resolver-rollover-00.txt June 2001 11.. SSccooppee aanndd RRaattiioonnaallee "The Domain Name Security Extensions" (DNSSEC) [RFC2535] is a means to provide data integrity and authentication to the DNS. Using signa- tures over DK RRsets [IDdkey] end users can build chains of trust from from statically configured roots of secure island [RFC3090] to the data in the DNS that needs to be verified. In the remainder of this document we will refer to 'statically configured roots of secure islands' as secure entry points. [Author's note: This draft assumes the DK record is used for delegat- ing authority from parent to child but does not rely this particular way of parent-child authority delegation] Key rollover is the process where a ZONE key [RFC3090 section 2,2a] is replaced by another ZONE key. Since Public/Private keys have a limited life time, key rollovers need to happen at regular intervals [RFC2541]. These rollovers are normally referred to as scheduled key rollovers. Emergency key rollovers, where a key needs to be replaced by another key because a private key has been compromised, are not the subject of this document. During DNSSEC operations an end-user(*) follows a chain of trust from one of their statically configured security entry points to the data that needs to be verified. The secure entry point keys are obtained by an initial key exchange. Initial key exchanges are outside the scope of this document. For the end-users it is important that existing chains of trust from the secure entry point to the data somewhere in the DNS remains intact when a zone in the the chain of trust perform a key rollover. The rollover of keys for zones that are configured as secure entry points may happen frequently. As long as the root is not secure, mul- tiple TLD and GTLDs will act as secure entry points, the 'default' zone will in general also be configured as secure entry point so that one does not rely on connectivity to it's parent. Zone administrators will not have a-priory knowledge about which ----------- * In the context of this document an end-user is an entity that does the verification of the chain of trust. This could be a stub resolver but also a caching forwarder. Kolkman et al. Expires December 2001 [Page 3] INTERNET-DRAFT draft-ietf-dnsop-resolver-rollover-00.txt June 2001 resolvers have their zones configured as secure entry points so it will be impossible for a zone administrator to contact all end-user resolvers when a key exchange is to commence commence. 22.. GGeenneerraall DDeessccrriippttiioonn ooff KKEEYY RRoolllloovveerr.. From an end-user's point of view there are two types of rollover. Parent Child rollovers (PC-rollovers), where the zone that rolls over is part of a chain of trust and has authority delegated from a parent zone, and Secure Entry rollovers (SE-rollovers) where the end-user resolver is configured with the key of the zone that rolls over itself. In other words the zone is a secure entry point for the end-user. For zone administrators it is clear they are involved in a PC- rollover; They will have to get get their parent to create a new DK record. For some zones it may not be obvious that their KEYs are con- figured statically at end-user hosts, they will need to enable a SE- rollover. Key rollovers of the root will always be of SE-rollovers. Key rollovers of GTLDs and TLDs are likely to be SE-rollovers. The requirements and policies for a PC-rollovers are somewhat differ- ent from those of a SE-rollovers. In both cases the zone administra- tor decides to rollover it's key and in both cases another party has to take specific action. During a PC-rollover the old an the new key have to coexist in the zone and the zone must be signed with both the old and new key so that end-users can follow the chain of trust from a secure entry point parent downward. This is needed because the DK record change needs some time to propagate through the DNS and during this time there will be DK records in the DNS that point to the old key and DK records that point to the new key. Once the parent's new DK record has been distributed to all the authoritative servers and one is sure the old parent data should have timed out from caches the old key can be removed from the zone. If authority has not been delegated from a parent i.e. the zone Kolkman et al. Expires December 2001 [Page 4] INTERNET-DRAFT draft-ietf-dnsop-resolver-rollover-00.txt June 2001 administrator is sure that the rollover is only relevant to resolvers. then the old key may immediately be replaced by a new KEY, the key set containing the new key MUST then be signed with both the old and new key so that resolvers can verify the new KEY against the statically configured old KEY. 33.. PPeerriiooddiicc PPoolllliinngg bbyy rreessoollvveerrss.. To notice an ongoing key rollover the resolver will need to periodi- cally query for the KEY RRset for the zone it has configured as a secure entry point, if the ZONE KEYS published in the apex of the zone have changed with respect to the statically configured keys a rollover is ongoing. To detect new Zone KEY in the apex of a zone, the resolver uses the same mechanism as slave nameservers use for detecting changes to a primary zone ( section 4.3.5 of [RFC1035] ); The resolver should check the SOA RR by polling the authoritative server periodically. As soon as the SOA serial has been increased, a query for the KEY RRset must be made. The resolver then proceeds by verifying the KEY RRset against one of the existing statically configured keys. The KEY RRset is also verified against the self signatures made with the ZONE keys from the KEY RRset. If both the verifications are successful, the ZONE Keys from the KEY RRset are compared against the existing statically configured keys, if these two sets of keys differ a rollover is taking place and the statically configured KEYs are to be replaced by the ZONE keys from the d KEY RRset. The application MAY send a notification to the resolver administrator who might want to audit the rollover using an off-band mechanism. If one of the verifications fail the application SHOULD send a warning to the resolver administrator. 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. 44.. ZZoonnee aaddmmiinniissttrraattiioonn ccoonnssiiddeerraattiioonnss.. If zones are configured as secure entry points then a SE-rollover Kolkman et al. Expires December 2001 [Page 5] INTERNET-DRAFT draft-ietf-dnsop-resolver-rollover-00.txt June 2001 takes place. Zone administrators have to take the following into account for successful auto-configuration of end-users resolvers. Since resolvers may not be able to poll the KEY RRset for extended times, the period resolvers have access to the new key should be made as long as possible. The time during which the parent zone changes the delegation of authority from the old key to the new key can be relatively short (phase 2 in figure 1). The length of this time interval is determined by the TTL of the parents signature and the REFRESH interval in the parents SOA; all authoritative slave servers must have had the change to load the new DK record and the old DK record must have expired from caches. During this interval the child zone needs to publish two KEYs and signatures made with both the keys. A zone administrator may decide to sign their zone with the old key for an extended period of time (phase 3). During this time resolvers that use the zone as a secure entry point be able to verify the zone with the old key and will still be able to grab the new key. Resolvers that do not have the zone configured as a secure entry point will use the new key when walking the secure tree from the secure entry point via the parent to the zone. Since the intention of a key rollover is to stop using the key there will be a phase 4 where the zone is signed with the new key only. If resolvers that have the zone configured as a secure entry point have not changed the statically configured key the zone and the it's sub zones will become "BAD". Note that during a SE-rollover, i.e. a rollover for zones that are not part of a chain of trust, phase 2 may be skipped. The root would be an example of such a zone. For these zones a resolver that can dynamically update itself, should always have the same statically configured ZONE KEYs as the ZONE KEYs published in the zone itself. Kolkman et al. Expires December 2001 [Page 6] INTERNET-DRAFT draft-ietf-dnsop-resolver-rollover-00.txt June 2001 ------------------------------------------------------------------- phase 1 phase 2 phase 3 phase 4 Before Rollover. parent resolver after Rollover rollover rollover SOA 1 SOA 2 SOA 3 SOA 4 S++1(SOA 1) S++1(SOA 2) S++1(SOA 3) S++2(SOA 4) S++2(SOA 2) S++2(SOA 3) K++1 K++1 K++2 K++2 S++1(K++1) K++2 S++1(K++2) S++2(K++2) S++1(K++1,K++2) S++2(K++2) S++2(K++1,K++2) Figure 1:Zone status during rollover Key and signature notation is explained in the appendix. The number behind the SOA indicates it's serial number. ------------------------------------------------------------------- 55.. SSeeccuurriittyy CCoonnssiiddeerraattiioonnss The key rollover described are based on the verification of new key material against an existing chain of trust. This existing chain of trust can be broken; this could be the case when there was an unno- ticed attack during the initial key exchange or when one of the keys against which is verified has been compromised. Resolver administra- tors should regularly audit statically configured keys against their origin using data that is not published via the DNS. If a key that is statically configured has been compromised, a rollover of statically configured keys of a resolver may be performed by the attacker. To be successful the attacker has to spoof the name- server or pollute a caching forwarder that the end-user uses to obtain the new keys. To limit damage of a compromised key, the mech- anism described here MAY still be used to distribute a new key during an emergency key rollover. Resolvers that are able to get the key from the original nameserver or from an unpolluted cache will not be Kolkman et al. Expires December 2001 [Page 7] INTERNET-DRAFT draft-ietf-dnsop-resolver-rollover-00.txt June 2001 vulnerable to an attack with compromised keys after the rollover. 66.. RReeffeerreenncceess [IDdkey] "Delegation Signer Record in Parent", draft-ietf-dnsext-dele- gation-signer-00.txt, O. Gudmundsson May 30 2001. [RFC1035] "Domain Names - Implementation and Specification", P. Mock- apetris. November 1987. [RFC2535] "Domain Name System Security Extensions", D. Eastlake. March 1999. [RFC2541] "DNS Security Operational Considerations", D. Eastlake. March 1999. [RFC3090] "DNS Security Extensions Clarification on Zone Status", E. Lewis. March 2001. 77.. AAuutthhoorrss'' AAddddrreesssseess:: Olaf M. Kolkman Miek Gieben Roy Arends RIPE NCC Stichting NLnet Labs Nominum OKolkman@ripe.net Miek@nlnetlabs.nl Roy.Arends@nominum.com http://www.ripe.net http://www.nlnetlabs.nl http://www.nominum.com Kolkman et al. Expires December 2001 [Page 8] INTERNET-DRAFT draft-ietf-dnsop-resolver-rollover-00.txt June 2001 88.. AAppppeennddiixx:: NNoottaattiioonn In this draft we use the following notation: A Key is identified by K++. The owner, pro- tocol and keytag are optional if their value is clear from the con- text or when their value is of no importance. So Kfoo.example+3+1 is the DSA Key with keytag 1 belonging to label foo.example. K++1 and K++2 are two keys from the same zone and algorithm, both not relevant or clear from the context, with different keytags. A Signature is identified as S++(). So Sfoo.example+2+1(www.foo.example A) is the signature made with the foo.example algorithm 2 (DSA) key with keytag 1, over the www.foo.example A record. Kolkman et al. Expires December 2001 [Page 9]