draft-ietf-dnsop-dnssec-operational-practices-04.txt

bind 源码 最新实现 linux/unix/windows平台

DNSOP                                                         O. Kolkman
Internet-Draft                                                  RIPE NCC
Expires: September 2, 2005                                     R. Gieben
                                                              NLnet Labs
                                                              March 2005


                      DNSSEC Operational Practices
          draft-ietf-dnsop-dnssec-operational-practices-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 September 2, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a set of practices for operating the DNS with
   security extensions (DNSSEC).  The target audience is zone
   administrators deploying DNSSEC.

   The document discusses operational aspects of using keys and
   signatures in the DNS.  It discusses issues as key generation, key
   storage, signature generation, key rollover and related policies.



Kolkman & Gieben        Expires September 2, 2005               [Page 1]

Internet-Draft        DNSSEC Operational Practices            March 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1   The Use of the Term 'key'  . . . . . . . . . . . . . . . .  4
     1.2   Time Definitions . . . . . . . . . . . . . . . . . . . . .  5
   2.  Keeping the Chain of Trust Intact  . . . . . . . . . . . . . .  5
   3.  Keys Generation and Storage  . . . . . . . . . . . . . . . . .  6
     3.1   Zone and Key Signing Keys  . . . . . . . . . . . . . . . .  6
       3.1.1   Motivations for the KSK and ZSK Separation . . . . . .  6
       3.1.2   KSKs for high level zones  . . . . . . . . . . . . . .  7
     3.2   Randomness . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.3   Key Effectivity Period . . . . . . . . . . . . . . . . . .  8
     3.4   Key Algorithm  . . . . . . . . . . . . . . . . . . . . . .  9
     3.5   Key Sizes  . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.6   Private Key Storage  . . . . . . . . . . . . . . . . . . . 10
   4.  Signature generation, Key Rollover and Related Policies  . . . 11
     4.1   Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 11
       4.1.1   Time Considerations  . . . . . . . . . . . . . . . . . 11
     4.2   Key Rollovers  . . . . . . . . . . . . . . . . . . . . . . 13
       4.2.1   Zone-signing Key Rollovers . . . . . . . . . . . . . . 13
       4.2.2   Key-signing Key Rollovers  . . . . . . . . . . . . . . 17
       4.2.3   Difference Between ZSK and KSK Rollovers . . . . . . . 18
       4.2.4   Automated Key Rollovers  . . . . . . . . . . . . . . . 19
     4.3   Planning for Emergency Key Rollover  . . . . . . . . . . . 19
       4.3.1   KSK Compromise . . . . . . . . . . . . . . . . . . . . 20
       4.3.2   ZSK Compromise . . . . . . . . . . . . . . . . . . . . 20
       4.3.3   Compromises of Keys Anchored in Resolvers  . . . . . . 20
     4.4   Parental Policies  . . . . . . . . . . . . . . . . . . . . 21
       4.4.1   Initial Key Exchanges and Parental Policies
               Considerations . . . . . . . . . . . . . . . . . . . . 21
       4.4.2   Storing Keys or Hashes?  . . . . . . . . . . . . . . . 21
       4.4.3   Security Lameness  . . . . . . . . . . . . . . . . . . 22
       4.4.4   DS Signature Validity Period . . . . . . . . . . . . . 22
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     7.1   Normative References . . . . . . . . . . . . . . . . . . . 24
     7.2   Informative References . . . . . . . . . . . . . . . . . . 24
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
   A.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . 25
   B.  Zone-signing Key Rollover Howto  . . . . . . . . . . . . . . . 26
   C.  Typographic Conventions  . . . . . . . . . . . . . . . . . . . 26
   D.  Document Details and Changes . . . . . . . . . . . . . . . . . 29
     D.1   draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 29
     D.2   draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 29
     D.3   draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 29
     D.4   draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 29
     D.5   draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 30



Kolkman & Gieben        Expires September 2, 2005               [Page 2]

Internet-Draft        DNSSEC Operational Practices            March 2005


       Intellectual Property and Copyright Statements . . . . . . . . 31


















































Kolkman & Gieben        Expires September 2, 2005               [Page 3]

Internet-Draft        DNSSEC Operational Practices            March 2005


1.  Introduction

   During workshops and early operational deployment tests, operators
   and system administrators gained experience about operating the DNS
   with security extensions (DNSSEC).  This document translates these
   experiences into a set of practices for zone administrators.  At the
   time of writing, there exists very little experience with DNSSEC in
   production environments; this document should therefore explicitly
   not be seen as representing 'Best Current Practices'.

   The procedures herein are focused on the maintenance of signed zones
   (i.e. signing and publishing zones on authoritative servers).  It is
   intended that maintenance of zones such as resigning or key rollovers
   be transparent to any verifying clients on the Internet.

   The structure of this document is as follows.  In Section 2 we
   discuss the importance of keeping the "chain of trust" intact.
   Aspects of key generation and storage of private keys are discussed
   in Section 3; the focus in this section is mainly on the private part
   of the key(s).  Section 4 describes considerations concerning the
   public part of the keys.  Since these public keys appear in the DNS
   one has to take into account all kinds of timing issues, which are
   discussed in Section 4.1.  Section 4.2 and Section 4.3 deal with the
   rollover, or which, of keys.  Finally Section 4.4 discusses
   considerations on how parents deal with their children's public keys
   in order to maintain chains of trust.

   The typographic conventions used in this document are explained in
   Appendix C.

   Since this is a document with operational suggestions and there are
   no protocol specifications, the RFC2119 [4] language does not apply.

   This document obsoletes RFC2541 [7]

1.1  The Use of the Term 'key'

   It is assumed that the reader is familiar with the concept of
   asymmetric keys on which DNSSEC is based (Public Key Cryptography
   [11]).  Therefore, this document will use the term 'key' rather
   loosely.  Where it is written that 'a key is used to sign data' it is
   assumed that the reader understands that it is the private part of
   the key-pair that is used for signing.  It is also assumed that the
   reader understands that the public part of the key-pair is published
   in the DNSKEY resource record and that it is the public part that is
   used in key-exchanges.





Kolkman & Gieben        Expires September 2, 2005               [Page 4]

Internet-Draft        DNSSEC Operational Practices            March 2005


1.2  Time Definitions

   In this document we will be using a number of time related terms.
   The following definitions apply:
   o  "Signature validity period"
         The period that a signature is valid.  It starts at the time
         specified in the signature inception field of the RRSIG RR and
         ends at the time specified in the expiration field of the RRSIG
         RR.
   o  "Signature publication period"
         Time after which a signature (made with a specific key) is
         replaced with a new signature (made with the same key).  This
         replacement takes place by publishing the relevant RRSIG in the
         master zone file.
         After one stopped publishing an RRSIG in a zone it may take a
         while before the RRSIG has expired from caches and has actually
         been removed from the DNS.
   o  "Key effectivity period"
         The period which a key pair is expected to be effective.  This
         period is defined as the time between the first inception time
         stamp and the last expiration date of any signature made with
         this key.
         The key effectivity period can span multiple signature validity
         periods.
   o  "Maximum/Minimum Zone TTL"
         The maximum or minimum value of the TTLs from the complete set
         of RRs in a zone.

2.  Keeping the Chain of Trust Intact

   Maintaining a valid chain of trust is important because broken chains
   of trust will result in data being marked as Bogus (as defined in [2]
   section 5), which may cause entire (sub)domains to become invisible
   to verifying clients.  The administrators of secured zones have to
   realize that their zone is, to their clients, part of a chain of
   trust.

   As mentioned in the introduction, the procedures herein are intended
   to ensure maintenance of zones, such as resigning or key rollovers,
   will be transparent to the verifying clients on the Internet.

   Administrators of secured zones will have to keep in mind that data
   published on an authoritative primary server will not be immediately
   seen by verifying clients; it may take some time for the data to be
   transfered to other secondary authoritative nameservers and clients
   may be fetching data from caching non-authoritative servers.

   For the verifying clients it is important that data from secured



Kolkman & Gieben        Expires September 2, 2005               [Page 5]

Internet-Draft        DNSSEC Operational Practices            March 2005


   zones can be used to build chains of trust regardless of whether the
   data came directly from an authoritative server, a caching nameserver
   or some middle box.  Only by carefully using the available timing
   parameters can a zone administrator assure that the data necessary
   for verification can be obtained.

   The responsibility for maintaining the chain of trust is shared by
   administrators of secured zones in the chain of trust.  This is most
   obvious in the case of a 'key compromise' when a trade off between
   maintaining a valid chain of trust and replacing the compromised keys
   as soon as possible must be made.  Then zone administrators will have
   to make a trade off, between keeping the chain of trust intact -
   thereby allowing for attacks with the compromised key - or to
   deliberately break the chain of trust and making secured sub domains
   invisible to security aware resolvers.  Also see Section 4.3.

3.  Keys Generation and Storage

   This section describes a number of considerations with respect to the
   security of keys.  It deals with the generation, effectivity period,
   size and storage of private keys.

3.1  Zone and Key Signing Keys

   The DNSSEC validation protocol does not distinguish between DNSKEYs.
   All DNSKEYs can be used during the validation.  In practice operators
   use Key Signing and Zone Signing Keys and use the so-called (Secure
   Entry Point) SEP flag to distinguish between them during operations.
   The dynamics and considerations are discussed below.

   To make zone resigning and key rollover procedures easier to
   implement, it is possible to use one or more keys as Key Signing Keys
   (KSK).  These keys will only sign the apex DNSKEY RR set in a zone.
   Other keys can be used to sign all the RRsets in a zone and are