draft-ietf-dnsext-parent-stores-zone-keys-01.txt

bind-3.2.

INTERNET-DRAFT                                              R. Gieben 
DNSEXT Working Group                                        NLnet Labs  
Expires September 2001                                      T. Lindgreen
                                                            NLnet Labs

                     Parent stores the child's zone KEYs

                draft-ietf-dnsext-parent-stores-zone-keys-01.txt
 
 
Status of This Document
 
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.  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/ietf/1id-abstracts.txt.  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 the DNSEXT WG mailing
   list [e-mail].

   This document updates RFC 2535. 


Copyright Notice

   Copyright (C) The Internet Society (2001).  All rights reserved.


Abstract

   When dealing with large amounts of keys the procedures to update a
   zone and to sign a zone need to be clearly defined and practically
   possible.  The current idea is to have the zone KEY RR and the
   parent's SIG to reside in the child's zone and perhaps also in the
   parent's zone. Operational experiences have prompted us to develop an
   alternative scheme in which the parent zone stores the parent's
   signature over the child's key and also the child's key itself. 

   The advantage of this scheme is that all signatures signed by a key
   are in the same zone file as the producing key. This allows for a



Gieben & Lindgreen       Expires November 2001                [Page  2]

Internet Draft          Parent Stores Zone KEYS               May    2001

   simple key rollover and resigning mechanism. For large TLDs this is
   extremely important. 

   Besides the operational advantages, this also obsoletes the NULL key,
   as the absence of child's zone KEY, which is securely verified by the
   absence of the KEY-bit in the corresponding NXT RR, now unambiguously
   indicates that the child is not secured by this parent.

   We further discuss the impact on a secure aware resolver/forwarder
   and the impact on the authority of KEYs and the NXT record.


Table of Contents
 
      Status of This Document....................................
      Abstract...................................................
 
      Table of Contents..........................................
      1 Introduction.............................................
      2 Proposal.................................................
      2.1. TTL of the KEY and SIG at the parent..................
      2.2. No NULL KEY...........................................
      3 Impact on a secure aware resolver/forwarder..............
      3.1 Impact of key rollovers on resolver/forwarder..........
      4 Scheduled key rollover...................................
      5 Unscheduled key rollover.................................
      6 Zone resigning...........................................
      7. Consequences for KEY and NXT records....................
      7.1. KEY bit in NXT records................................
      7.2. Authority of KEY records..............................
      7.3. Selecting KEY sets....................................
      8. The zone-KEY and local KEY records......................
      9. Security Considerations.................................

      Authors' Addresses.........................................
      References.................................................
      Full Copyright Statement...................................


1. Introduction
   Within a CENTR working group NLnet Labs is researching the impact of
   DNSSEC on the ccTLDs and gTLDs.

   In this document we are considering a secure zone, somewhere under a
   secure entry point and on-tree [RFC 3090] validation between the
   secure entry point and the zone in question.  The resolver we are
   considering is security aware and is preconfigured with the KEY of
   the secure entry point.  We also make a distinction between a
   scheduled and a unscheduled key rollover.  A scheduled rollover is
   announced before hand.  An unscheduled key rollover is needed when a
   private key is compromised.



Gieben & Lindgreen       Expires November 2001                [Page  3]

Internet Draft          Parent Stores Zone KEYS               May    2001


   RFC 2535 states that a zone KEY must be present in the apex of a
   zone.  This can be in the at the delegation point in the parent's
   zonefile, or in the child's zonefile, or in both.  This key is only
   valid if it is signed by the parent, so there is also the question
   where this signature and this zone KEY are located. 

   The original idea was to have the zone KEY RR and the parent's SIG to
   reside in the child's zone and perhaps also in the parent's zone.
   There is a draft proposal [RFC 2535], that describes how a
   keyrollover can be handled. 

   At NLnet Labs we found that storing the parent's signature over the
   child's zone KEY in the child's zone: 
       - makes resigning a KEY by the parent difficult
       - makes a scheduled keyrollover very complicated
       - makes an unscheduled keyrollover virtually impossible

   We propose an alternative scheme in which the parent's signature over
   the child's zone KEY and the child's zone KEY itself are only stored
   in the parent's zone, i.e. where the signing key resides. This would
   solve the above problems and also obsoletes the NULL KEY.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.


2. Proposal
   The core of the new proposal is that the parent zone stores the
   parent's signature over the child's zone KEY and also the child's
   zone KEY itself, and is authoritative for both KEY and SIG.  The
   child zone may also contain its zone KEY, in which case is must be
   selfsigned. The child zone must not hold the parent's SIG, and must
   also not set the AA-bit on requests for its zone KEY.

   The main advantage of this proposal is that all signatures signed by
   a key are in the same zone file as the producing key. This allows for
   a simple key rollover and resigning mechanism. For large TLDs this is
   extremely important.  A disadvantage would be that not all the
   information concerning one zone is stored at that zone, this is
   covered in section 7.2.

   A parent running DNSSEC SHOULD NOT refuse a request from a child to
   include and sign its key, but can ask for certain conditions to be
   met. These condition could include a fee, sufficient authentication,
   signing a non liability clause, the conditions specified in section 8
   of this document, etc.

2.1. TTL of the KEY and SIG at the parent
   Each zone in DNS expresses in its SOA record the maximum and minimum



Gieben & Lindgreen       Expires November 2001                [Page  4]

Internet Draft          Parent Stores Zone KEYS               May    2001

   TTL values that they allow in the zone. Thus it is possible that the
   parent will sign with a value that is unacceptable to the child. The
   parent MUST follow the TTL request of the child as long as that is
   within the allowed range for the parent.

2.2. No NULL KEY 
   This proposal obsoletes the NULL KEY. If there is no child KEY at the
   parent, which can be securely verified by inspecting the the unset
   KEY-bit in the corresponding NXT RR, the child is not secured by this
   parent (of course, the child can then still be secured off-tree).
   This updates section 3.1.2 "The zone KEY RR Flag Field" of RFC 2535,
   it says:

   " 11: If both bits are one, the "no key" value, there is no key
        information and the RR stops after the algorithm octet.
        By the use of this "no key" value, a signed zone KEY RR can
        authenticatably assert that, for example, a zone is not
        secured.  See section 3.4 below. "

   As we don't have a NULL KEY anymore this is obsoleted. 
   Section 3.4 "Determination of Zone Secure/Unsecured Status":

   " A zone KEY RR with the "no-key" type field value (both key type
   flag bits 0 and 1 on) indicates that the zone named is unsecured
   while a zone KEY RR with a key present indicates that the zone named
   is secure.  The secured versus unsecured status of a zone may vary
   with different cryptographic algorithms.  Even for the same
   algorithm, conflicting zone KEY RRs may be present. "

   This is rewritten as:

    " A zone is considered secured by on-tree validation [RFC 3090] when
    the there is a zone KEY from that zone present at its parent. If
    there is no zone KEY present, and the resolver is also unaware of
    alternative algorithms used and/or possible off-tree validation, the
    zone is considered unsecured. "

   To further clarify this. A zone is secure, when the resolver expects
   it to be, there are two possibilities:
      1. When its parent is secure and holds a signed KEY for this child.  
      2. When zone is a secure entry point, i.e. the resolver is
         preconfigured with the KEY of this zone.

   RFC 3090 calls this globally secured.

   When a zone contains SIGs and a selfsigned KEY and this KEY is
   preconfigured in the resolvers of interest, the a zone can be
   considered locally secured (the RFC 3090 defintion).  hijacked.

   If a zone is not globally or locally it must be considered unsecure.




Gieben & Lindgreen       Expires November 2001                [Page  5]

Internet Draft          Parent Stores Zone KEYS               May    2001


3. Impact on a secure aware resolver/forwarder 
   The resolver must be aware of the fact that the parent is more
   authoritative than a child when it comes to deciding whether a zone
   is secured or not.

   Without caching and with on-tree validation, a resolver will always
   start its search at a secure entry point. In this way it can
   determine whether it must expect SIG records or not. 

   Considering caching in a secure aware resolver or forwarder. If
   information of a secure zone is cached, its validated KEY should also
   be cached.

3.1. Impact of key rollovers on resolver/forwarder
   When a zone is in the process of a key rollover, there could be a
   discrepancy between the KEY and the SIG in the apex of the zone and
   the KEY and SIG that are stored in the cache of a resolver.

   Suppose a resolver has cached the NS, KEY and SIG records of a zone.
   Next a request comes for an A record in that zone. Also the zone is
   in the process of a key rollover and already has new keys in its
   zone.  The resolver receives an answer consisting of the A record and
   a SIG over the A record.  It uses the tag field in the SIG to
   determine if it has a KEY which is suitable to validate the SIG.  If
   it does not has such a KEY the resolver must ask the parent of the
   zone for a new KEY and then try it again.  Now the resolver has 2
   keys for the zone, according to the tag field in the SIG it can use
   either one.

   If the new key also does not validate the SIG the zone is marked bad.
   If the parent indicates by having a not set KEY-bit in the NXT RR
   that there is no KEY for this zone, the child must be considered
   unsecured by this parent, despite the appearance of an (old) KEY in
   the cache.  This could for instance happen after an emergency request