[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

DNSOP Working Group                                     Olaf M. Kolkman
INTERNET-DRAFT                                          RIPE NCC
                                                        Miek Gieben
                                                        NLnet Labs
                                                        Roy Arends

                                                        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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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


   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-

   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)

   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

[RFC2541] "DNS Security Operational Considerations", D. Eastlake. March

[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<owner>+<protocol>+<keytag>. 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<ownername>+<protocol>+<keytag>(<RR
   identifier>). 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]

Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/