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

bind-3.2.

   from the child, who has suffered a key compromise, and has decided to
   prefer being unsecured over either dropping of the Internet or being
   exposed to have verifiable secure info added by the key-compromiser
   to their zone information.


4. Scheduled key rollover
   When the signatures, produced by the key to be rolled over, are all
   in one zone file, there are two parties involved.  Let us look at an
   possible example where a TLD rolls over its zone KEY. The new key
   needs to be signed with the root's key before it can be used to sign
   the TLD zone and the zone KEYs of the TLD's children. The steps that
   need to be taken by TLD and root are: 
      - the TLD adds the new key to its KEY set in its zonefile. This
	zone and KEY set are signed with the old zone KEY
      - then the TLD signals the parent



Gieben & Lindgreen       Expires November 2001                [Page  6]

Internet Draft          Parent Stores Zone KEYS               May    2001

      - the root copies the new KEY set, consisting of the both new and
	the old key, in its zonefile, resigns it and signals the TLD
      - the TLD removes the old key from its KEY set, resigns its zone
	with the new KEY, and signals the the root
      - the root copies the new KEY set, now consisting of the new key
	only, and resigns it 

   Note that this procedure is immune to fake signals and spoofing
   attacks (as long as there is no key compromise):
      - on a fake signal either way the action becomes a null-action as
	the new KEY set is identical to the existing one.
      - a spoofed new KEY set will not validate with the existing KEY
	that the parent holds.


5. Unscheduled key rollover
   Although nobody hopes that this will ever happen, we must be able to
   cope with possible key compromises. When such an event occurs, an
   immediate keyrollover is needed and must be completed in the shortest
   possible time.  With two parties involved, it will still be awkward,
   but not impossible to update two zonefiles overnight. "Out-of-band"
   communication between the two parties will be necessary, since the
   compromised old key can not be trusted.  We think that between two
   parties this is doable, but this complicated procedure is beyond the
   scope of this document. 

   An alternative to an emergency key-rollover is becoming unsecured as
   an emergency measure. This has already been mentioned above in
   section 3.1. This only involves an emergency change in the parents
   zonefile (deleting the child's zone KEY), and allows the child and
   its underlying zones time to clean up before becoming secured again,
   without dropping from the Internet or being exposed to having secured
   but false zone information.


6. Zone resigning
   Resigning a TLD is necessary before the current signatures expire.
   When all SIGs (produced by the TLD's zone KEY) and the child KEY
   records, are kept in the TLD's zonefile, such a resign session is
   trivial, as only one party (the TLD) and one zonefile are involved. 


7. Consequences for KEY and NXT records
   There are two reasons to have of the child's zone KEY not only at the
   parent but also in the child's own zonefile: 
	1. to facilitate a key-rollover  
	2. to prevent local lookups for local information to suffer 
           from possible loss of access to its outside parent

   To cope with 1, secure aware resolvers MUST be aware that during a
   key-rollover there may be a conflict, and that in that case the



Gieben & Lindgreen       Expires November 2001                [Page  7]

Internet Draft          Parent Stores Zone KEYS               May    2001

   parent always holds the active KEY set.  To cope with 2, the local
   resolver/caching forwarder should be preconfigured with the zone-KEY
   and thus looks at its own zone as were it a secure entry-point.  For
   both things to work, the zone-KEY set must be selfsigned in the child
   zonefile.

7.1. KEY bit in NXT records
   RFC 2535, section 5.2 states:

   " The NXT RR type bit map format currently defined is one bit per RR
   type present for the owner name.  A one bit indicates that at least
   one RR of that type is present for the owner name.  A zero indicates
   that no such RR is present. [....] "

   As the zone KEY is present in a child zone, and signed by the zone
   KEY (thus selfsigned), the definition of NXT RR type bit states in
   RFC 2535, section 5.2 that the KEY bit must be set. We do not see a
   compelling reason to change this default behavior.

7.2. Authority of KEY records
   The parent of a zone generates the signature for the key belonging to
   that zone. By making that signature available the parent publicly
   states that the child zone is trustworthy: when it comes to security
   in DNSSEC the parent is more authoritative than the child. 

   From this we conclude that a parent zone MUST set the authority bit
   to 1 and child zones MUST set this bit to 0 when dealing with KEYs
   from that child zone.This also causes resolvers to pick up and cache
   the right KEY set, in case it finds conflicting KEY sets during a
   key-rollover.

   Some zones have no parent to make it authoritatively secure, for
   instance, the root. To be secure anyway it must be defined a secure
   entry point. If a resolver knows that a secure entry point is a
   secure entry point it must have its key preconfigured.  There is no
   need for a parent in this scenario, because the resolver itself can
   check the security of that zone. A interesting consequence of this is
   that nobody is authoritative for a key belonging to a secure entry
   point. This authority must established via some out of band
   mechanism, like publishing it in a newspaper.

7.3. Selecting KEY sets
   As the zone KEY set is present in two places, there is a possibility
   of two conflicting KEY sets, this will happen during a key-rollover
   and may happen at other times.

   With one exception, a resolver MUST always select the KEY set from
   the parent in case of a conflict, as this is the active KEY set. For
   this reason, the parent sets the AA-bit on requests, while the child
   does not.




Gieben & Lindgreen       Expires November 2001                [Page  8]

Internet Draft          Parent Stores Zone KEYS               May    2001

   The one exception is when a resolver regards the child's zone as a
   secure-entry point, in which case it has the zone KEY preconfigured.
   In other words: a preconfigured KEY has even more authority then what
   a parent says.  Specifying a zone as a secure entry-point makes sense
   for a local resolver in its own local zone.


8. The zone KEY and local KEY records.
   It must be recognized that the zone KEY RR, which is signed by a
   non-local organization, is something special. The external signature
   over the public part of the key provides the local zone-administrator
   with the authority to use the corresponding private part to sign
   everything local, and thus to make his/her own zone secure. Please
   also note that the external signer, and NOT the local zone is
   authoritative for the zone KEY RRset.

   Part of the RRs that the zone-administrator may wish to sign are KEY
   RRs for local use, for instance for IPSEC.

   To make sure, that the local zone is authoritative for its own local
   KEY RRs, and that they get not exported and signed externally, these
   local KEY records SHOULD not be part of the zone KEY RRset.
   Therefore, they could be placed under a label in the zonefile, f.i.
   keys.child.parent, or for these kind of keys a new RR type could be
   defined (e.g. PUBKEY).

   Besides being kept clear of local KEY records, the zone KEY RRset
   SHOULD also be kept clear of any other obsolete or otherwise not
   strictly needed KEY records, because this increases the number of
   possible key compromise attacks and also increases the size of the
   parents zone file unnecessarily.

   In other words: the KEY RRset with the toplevel label of a zone
   SHOULD only contain its active zone KEY, unless a key-rollover is in
   progress. During a keyrollover a new KEY RR must be added to this
   RRset.  Once the new KEY becomes the active zone KEY, the old KEY
   becomes obsolete and SHOULD be removed as soon as practically
   possible. Information stored in caches SHOULD NOT be an issue on when
   to remove the old zone KEY.


9. Security Considerations
   This document addresses the operational difficulties that arise when
   DNSSEC is deployed. By putting the child's zone KEY at the parent we
   solve at lot of problems by minimizing the amount of communication
   between the two.  There is one security issue: the parent must not
   ever create a valid parental SIG over a KEY RR, from which the
   private part is (also) known to someone else than the legitimate
   administrator of the child zone. This can happen in two ways:
      1. The private KEY at the child has been compromised.
      2. The parent has been fooled and thus insufficiently checked



Gieben & Lindgreen       Expires November 2001                [Page  9]

Internet Draft          Parent Stores Zone KEYS               May    2001

         whether the KEY RR is really from the child.

   For the security it doesn't matter if the SIG and the KEY are located
   at the child or at the parent, but if they are located at the parent
   it is much easier to replace the SIG. And by keeping the parental SIG
   lifetime short, the parent helps to protect the child against
   possible key compromises.  The selfsigned zone KEY stored in the
   child's zone can have a long SIG expiration lifetime, this has no
   impact on the child's security.

   All security considerations from RFC 2535 apply.


Authors' Addresses

   R. Gieben					  T. Lindgreen
   Stichting NLnet Labs				  Stichting NLnet Labs
   Kruislaan 419				  Kruislaan 419
   1098 VA Amsterdam				  1098 VA Amsterdam
   [e-mail]				  [e-mail]


References

   [RFC 3090] Lewis, E. "DNS Security Extension Clarification on Zone 
       Status", RFC 3090
       www.ietf.org/rfc/rfc3090.txt
   [RFC 2119] Bradner, S. "Key words for use in RFCs to Indicate Requirement
          Levels", RFC 2119
       www.ietf.org/rfc/rfc2119.txt
   [RFC 2535] Eastlake, D. "DNS Security Extensions", RFC 2535
       www.ietf.org/rfc/rfc2535.txt


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished
   to others, and derivative works that comment on or otherwise explain
   it or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.



Gieben & Lindgreen       Expires November 2001                [Page 10]

Internet Draft          Parent Stores Zone KEYS               May    2001


   The limited permissions granted above are perpetual and will not
   be revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on
   an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.