path: root/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt

DNSOP                                                          G. Guette
Internet-Draft                                             IRISA / INRIA
Expires: July 19, 2005                                        O. Courtay
                                                             Thomson R&D
                                                        January 18, 2005

           Requirements for Automated Key Rollover in DNSSEC
           draft-ietf-dnsop-key-rollover-requirements-02.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable 
   patent or other IPR claims of which I am aware have been disclosed, 
   and any of which I become aware will be disclosed, in accordance with 
   RFC 3668.  

   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.

   This Internet-Draft will expire on July 19, 2005.

Copyright Notice

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

Abstract

   This document describes problems that appear during an automated
   rollover and gives the requirements for the design of communication
   between parent zone and child zone during an automated rollover
   process.  This document is essentially about in-band key rollover.




Guette & Courtay         Expires July 19, 2005                  [Page 1]
Internet-Draft      Automated Rollover Requirements         January 2005

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.   The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
   3.   Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
   4.   Messages authentication and information exchanged  . . . . . . 5
   5.   Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
   6.   Security consideration . . . . . . . . . . . . . . . . . . . . 6
   7.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 6
   8.   Normative References . . . . . . . . . . . . . . . . . . . . . 6
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
   A.   Documents details and changes  . . . . . . . . . . . . . . . . 7
        Intellectual Property and Copyright Statements . . . . . . . . 8



















Guette & Courtay         Expires July 19, 2005                  [Page 2]
Internet-Draft      Automated Rollover Requirements         January 2005

1.  Introduction

   The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key
   cryptography and digital signatures.  It stores the public part of
   keys in DNSKEY Resource Records (RRs).  Because old keys and
   frequently used keys are vulnerable, they must be renewed
   periodically.  In DNSSEC, this is the case for Zone Signing Keys
   (ZSKs) and Key Signing Keys (KSKs) [1][2].  Automation of key
   exchanges between parents and children is necessary for large zones
   because there are too many changes to handle.

   Let us consider for example a zone with 100000 secure delegations.
   If the child zones change their keys once a year on average, that
   implies 300 changes per day for the parent zone.  This amount of
   changes is hard to manage manually.

   Automated rollover is optional and resulting from an agreement
   between the administrator of the parent zone and the administrator of
   the child zone.  Of course, key rollover can also be done manually by
   administrators.

   This document describes the requirements for a protocol to perform
   the automated key rollover process and focusses on interaction
   between parent and child zone.

2.  The Key Rollover Process

   Key rollover consists of renewing the DNSSEC keys used to sign
   resource records in a given DNS zone file.  There are two types of
   rollover, ZSK rollovers and KSK rollovers.

   During a ZSK rollover, all changes are local to the zone that renews
   its key: there is no need to contact other zones administrators to
   propagate the performed changes because a ZSK has no associated DS
   record in the parent zone.

   During a KSK rollover, new DS RR(s) must be created and stored in the
   parent zone.  In consequence, data must be exchanged between child
   and parent zones.

   The key rollover is built from two parts of different nature:
   o  An algorithm that generates new keys and signs the zone file.  It
      can be local to the zone,
   o  the interaction between parent and child zones.

   One example of manual key rollover [3] is:
   o  The child zone creates a new KSK,


Guette & Courtay         Expires July 19, 2005                  [Page 3]
Internet-Draft      Automated Rollover Requirements         January 2005

   o  the child zone waits for the creation of the DS RR in its parent
      zone,
   o  the child zone deletes the old key,
   o  the parent zone deletes the old DS RR.

   This document concentrates on defining interactions between entities
   present in key rollover process.

3.  Basic Requirements

   This section provides the requirements for automated key rollover in
   case of normal use.  Exceptional case like emergency rollover is
   specifically described later in this document.

   The main condition during a key rollover is that the chain of trust
   must be preserved to every validating DNS client.  No matter if this
   client retrieves some of the RRs from recursive caching name server
   or from the authoritative servers for the zone involved in the
   rollover.

   Automated key rollover solution may be interrupted by a manual
   intervention.  This manual intervention should not compromise the
   security state of the chain of trust.  If the chain is safe before
   the manual intervention, the chain of trust must remain safe during
   and after the manual intervention

   Two entities act during a KSK rollover: the child zone and its parent
   zone.  These zones are generally managed by different administrators.
   These administrators should agree on some parameters like
   availability of automated rollover, the maximum delay between
   notification of changes in the child zone and the resigning of the
   parent zone.  The child zone needs to know this delay to schedule its
   changes and/or to verify that the changes had been taken into account
   in the parent zone.  Hence, the child zone can also avoid some
   critical cases where all child key are changed prior to the DS RR
   creation.

   By keeping some resource records during a given time, the recursive
   cache servers can act on the automated rollover.  The existence of
   recursive cache servers must be taken into account by automated
   rollover solution.

   Indeed, during an automated key rollover a name server could have to
   retrieve some DNSSEC data.  An automated key rollover solution must
   ensure that these data are not old DNSSEC material retrieved from a
   recursive name server.



Guette & Courtay         Expires July 19, 2005                  [Page 4]
Internet-Draft      Automated Rollover Requirements         January 2005

4.  Messages authentication and information exchanged

   This section addresses in-band rollover, security of out-of-band
   mechanisms is out of scope of this document.

   The security provided by DNSSEC must not be compromised by the key
   rollover, thus every exchanged message must be authenticated to avoid
   fake rollover messages from malicious parties.

   Once the changes related to a KSK are made in a child zone, there are
   two ways for the parent zone to take this changes into account:
   o  the child zone notify directly or not directly its parent zone in
      order to create the new DS RR and store this DS RR in parent zone
      file,
   o  or the parent zone poll the child zone.

   In both cases, the parent zone must receive all the child keys that
   need the creation of associated DS RRs in the parent zone.

   Because errors could occur during the transmission of keys between
   child and parent, the key exchange protocol must be fault tolerant.
   Should an error occured during the automated key rollover, an
   automated key rollover solution must be able to keep the zone files
   in a consistent state.

5.  Emergency Rollover

   Emergency key rollover is a special case of rollover decided by the
   zone administrator generally for security reasons.  In consequence,
   emergency key rollover can break some of the requirement described
   above.

   A zone key might be compromised and an attacker can use the
   compromised key to create and sign fake records.  To avoid this, the
   zone administrator may change the compromised key or all its keys as
   soon as possible, without waiting for the creation of new DS RRs in
   its parent zone.

   Fast changes may break the chain of trust.  The part of DNS tree
   having this zone as apex can become unverifiable, but the break of
   the chain of trust is necessary if the administrator wants to prevent
   the compromised key from being used (to spoof DNS data).

   Parent and child zones sharing an automated rollover mechanism,
   should have an out-of-band way to re-establish a consistent state at
   the delegation point (DS and DNSKEY RRs).  This allows to avoid that
   a malicious party uses the compromised key to roll the zone keys.


Guette & Courtay         Expires July 19, 2005                  [Page 5]
Internet-Draft      Automated Rollover Requirements         January 2005

6.  Security consideration

   The automated key rollover process in DNSSEC allows automated renewal
   of any kind of DNS key (ZSK or KSK).  It is essential that parent
   side and child side can do mutual authentication.  Moreover,
   integrity of the material exchanged between the parent and child zone
   must be provided to ensure the right DS are created.

   As in any application using public key cryptography, in DNSSEC a key
   may be compromised.  What to do in such a case can be describe in the
   zone local policy and can violate some requirements described in this
   draft.  The emergency rollover can break the chain of trust in order
   to protect the zone against the use of the compromised key.

7.  Acknowledgments

   The authors want to thank members of IDsA project for their
   contribution to this document.

8  Normative References

   [1]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
        RFC 3658, December 2003.

   [2]  Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
        RFC 3757, May 2004.

   [3]  Kolkman, O., "DNSSEC Operational Practices",
        draft-ietf-dnsop-dnssec-operational-practice-01 (work in
        progress), May 2004.

   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
        2535, March 1999.

   [5]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
        "Resource Records for the DNS Security Extensions",
        draft-ietf-dnsext-dnssec-records-11 (work in progress), October
        2004.

   [6]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
        "DNS Security Introduction and Requirements",
        draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
        2004.

   [7]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
        "Protocol Modifications for the DNS Security Extensions",
        draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October


Guette & Courtay         Expires July 19, 2005                  [Page 6]
Internet-Draft      Automated Rollover Requirements         January 2005

        2004.

Authors' Addresses

   Gilles Guette
   IRISA / INRIA
   Campus de Beaulieu
   35042  Rennes CEDEX
   FR

   EMail: gilles.guette@irisa.fr
   URI:   http://www.irisa.fr

   Olivier Courtay
   Thomson R&D
   1, avenue Belle Fontaine
   35510  Cesson S?vign? CEDEX
   FR

   EMail: olivier.courtay@thomson.net

Appendix A.  Documents details and changes

   This section is to be removed by the RFC editor if and when the
   document is published.

   Section about NS RR rollover has been removed

   Remarks from Samuel Weiler and Rip Loomis added

   Clarification about in-band rollover and in emergency section

   Section 3, details about recursive cache servers added








Guette & Courtay         Expires July 19, 2005                  [Page 7]
Internet-Draft      Automated Rollover Requirements         January 2005

Intellectual Property Statement

     The IETF takes no position regarding the validity or scope of any 
     intellectual property or other rights that might be claimed to 
     pertain to the implementation or use of the technology described 
     in this document or the extent to which any license under such 
     rights might or might not be available; neither does it represent 
     that it has made any effort to identify any such rights. 
     Information on the IETF's procedures with respect to rights in 
     IETF Documents can be found in BCP 78 and 79.   
          
     Copies of IPR disclosures made to the IETF Secretariat and any 
     assurances of licenses to be made available, or the result of an 
     attempt made to obtain a general license or permission for the use 
     of such proprietary rights by implementers or users of this 
     specification can be obtained from the IETF on-line IPR repository 
     at http://www.ietf.org/ipr. 
      
     The IETF invites any interested party to bring to its attention 
     any copyrights, patents or patent applications, or other 
     proprietary rights which may cover technology that may be required 
     to implement this standard. Please address the information to the 
     IETF at ietf-ipr.org. 
      
    
 Full Copyright Statement 
    
   Copyright (C) The Internet Society (2005).  This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 
    
   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM 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.

 Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.


         


Guette & Courtay         Expires July 19, 2005                  [Page 8]