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

Versions: 00 01 02 03 04 05 06 07 08 RFC 4641

DNSOP                                                         O. Kolkman
Internet-Draft                                                  RIPE NCC
Expires: April 11, 2005                                        R. Gieben
                                                              NLnet Labs
                                                        October 11, 2004


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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 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 April 11, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document describes a set of practices for operating a DNSSEC
   aware environment.  The target audience is zone administrators
   deploying DNSSEC that need a guide to help them chose appropriate
   values for DNSSEC parameters.  It also discusses operational matters
   such as key rollovers, KSK and ZSK considerations and related
   matters.



Kolkman & Gieben         Expires April 11, 2005                 [Page 1]

Internet-Draft        DNSSEC Operational Practices          October 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   The Use of the Term 'key'  . . . . . . . . . . . . . . . .  3
     1.2   Keeping the Chain of Trust Intact  . . . . . . . . . . . .  3
   2.  Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1   Time Definitions . . . . . . . . . . . . . . . . . . . . .  4
     2.2   Time Considerations  . . . . . . . . . . . . . . . . . . .  5
   3.  Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1   Motivations for the KSK and ZSK Separation . . . . . . . .  7
     3.2   Key Security Considerations  . . . . . . . . . . . . . . .  8
       3.2.1   Key Validity Period  . . . . . . . . . . . . . . . . .  8
       3.2.2   Key Algorithm  . . . . . . . . . . . . . . . . . . . .  8
       3.2.3   Key Sizes  . . . . . . . . . . . . . . . . . . . . . .  9
     3.3   Key Rollovers  . . . . . . . . . . . . . . . . . . . . . .  9
       3.3.1   Difference Between ZSK and KSK Rollovers . . . . . . . 10
       3.3.2   Zone-signing Key Rollovers . . . . . . . . . . . . . . 10
       3.3.3   Key-signing Key Rollovers  . . . . . . . . . . . . . . 14
       3.3.4   Automated Key Rollovers  . . . . . . . . . . . . . . . 15
   4.  Planning for Emergency Key Rollover  . . . . . . . . . . . . . 15
     4.1   KSK Compromise . . . . . . . . . . . . . . . . . . . . . . 16
     4.2   ZSK Compromise . . . . . . . . . . . . . . . . . . . . . . 16
     4.3   Compromises of Keys Anchored in Resolvers  . . . . . . . . 16
   5.  Parental Policies  . . . . . . . . . . . . . . . . . . . . . . 17
     5.1   Initial Key Exchanges and Parental Policies
           Considerations . . . . . . . . . . . . . . . . . . . . . . 17
     5.2   Storing Keys So Hashes Can Be Regenerated  . . . . . . . . 17
     5.3   Security Lameness Checks . . . . . . . . . . . . . . . . . 18
     5.4   DS Signature Validity Period . . . . . . . . . . . . . . . 18
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 19
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 19
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
   A.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . 20
   B.  Zone-signing Key Rollover Howto  . . . . . . . . . . . . . . . 21
   C.  Typographic Conventions  . . . . . . . . . . . . . . . . . . . 22
   D.  Document Details and Changes . . . . . . . . . . . . . . . . . 23
     D.1   draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 23
     D.2   draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 23
       Intellectual Property and Copyright Statements . . . . . . . . 25









Kolkman & Gieben         Expires April 11, 2005                 [Page 2]

Internet-Draft        DNSSEC Operational Practices          October 2004


1.  Introduction

   During workshops and early operational deployment tests, operators
   and system administrators gained experience about operating DNSSEC
   aware DNS services.  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: It begins with
   discussing some of the considerations with respect to timing
   parameters of DNS in relation to DNSSEC (Section 2).  Aspects of key
   management such as key rollover schemes are described in Section 3.
   Emergency rollover considerations are addressed in Section 4.  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 [7] language does not apply.

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.

1.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, 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,



Kolkman & Gieben         Expires April 11, 2005                 [Page 3]

Internet-Draft        DNSSEC Operational Practices          October 2004


   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, during which
   period clients may be fetching data from caching non-authoritative
   servers.

   For the verifying clients it is important that data from secured
   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.

   The zone administrator 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.

2.  Time in DNSSEC

   Without DNSSEC all times in DNS are relative.  The SOA's refresh,
   retry and expiration timers are counters that are used to determine
   the time elapsed after a slave server synchronized (or tried to
   synchronize) with a master server.  The Time to Live (TTL) value and
   the SOA minimum TTL parameter [8] are used to determine how long a
   forwarder should cache data after it has been fetched from an
   authoritative server.  By using a signature validity period, DNSSEC
   introduces the notion of an absolute time in the DNS.  Signatures in
   DNSSEC have an expiration date after which the signature is marked as
   invalid and the signed data is to be considered bogus.

2.1  Time Definitions

   In this document we will be using a number of time related terms.
   The following definitions apply:
   o  "Signature validity period"





Kolkman & Gieben         Expires April 11, 2005                 [Page 4]

Internet-Draft        DNSSEC Operational Practices          October 2004


         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.
         If all signatures are refreshed at zone (re)signing then the
         signature publication period is equal to the signature validity
         period.
   o  "Maximum/Minimum Zone TTL"
         The maximum or minimum value of the TTLs from the complete set
         of RRs in a zone.

2.2  Time Considerations

   Because of the expiration of signatures, one should consider the
   following.
   o  We suggest the Maximum Zone TTL of your zone data to be a fraction
      of your signature validity period.
         If the TTL would be of similar order as the signature validity
         period, then all RRsets fetched during the validity period
         would be cached until the signature expiration time.  Section
         7.1 [5] suggests that "the resolver may use the time remaining
         before expiration of the signature validity period of a signed
         RRset as an upper bound for the TTL".  As a result query load
         on authoritative servers would peak at signature expiration
         time, as this is also the time at which records simultaneously
         expire from caches.
         To avoid query load peaks we suggest the TTL on all the RRs in
         your zone to be at least a few times smaller than your
         signature validity period.
   o  We suggest the signature publication period to be at least one
      maximum TTL smaller than the signature validity period.
         Resigning a zone shortly before the end of the signature
         validity period may cause simultaneous expiration of data from
         caches.  This in turn may lead to peaks in the load on
         authoritative servers.
   o  We suggest the minimum zone TTL to be long enough to both fetch
      and verify all the RRs in the authentication chain.  A low TTL can
      cause two problems:
         1.  During validation, some data may expire before the
         validation is complete.  The validator should be able to keep
         all data, until is completed.  This applies to all RRs needed
         to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the
         final answers i.e.  the RR set that is returned for the initial



Kolkman & Gieben         Expires April 11, 2005                 [Page 5]

Internet-Draft        DNSSEC Operational Practices          October 2004


         query.
         2.  Frequent verification causes load on recursive nameservers.
         Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from
         caching.  The TTL on those should be relatively long.
   o  Slave servers will need to be able to fetch newly signed zones
      well before the RRSIGs in the zone server by the slave server pass
      their signature expiration time.
         When a slave server is out of sync with its master and data in
         a zone is signed by expired signatures it may be better for the
         slave server not to give out any answer.
         Normally a slave server that is not able to contact a master
         server for an extended period will expire a zone.  When that
         happens the zone will not respond on queries.  The time of
         expiration is set in the SOA record and is relative to the last
         successful refresh between the master and the slave server.
         There exists no coupling between the signature expiration of
         RRSIGs in the zone and the expire parameter in the SOA.
         If the server serves a DNSSEC zone than it may well happen that
         the signatures expire well before the SOA expiration timer
         counts down to zero.  It is not possible to completely prevent
         this from happening by tweaking the SOA parameters.
         However, the effects can be minimized where the SOA expiration
         time is equal or smaller than the signature validity period.
         The consequence of an authoritative server not being able to
         update a zone, whilst that zone includes expired signatures, is
         that non-secure resolvers will continue to be able to resolve
         data served by the particular slave servers while security
         aware resolvers will experience problems because of answers
         being marked as bogus.
         We suggest the SOA expiration timer being approximately one
         third or one fourth of the signature validity period.  It will
         allow problems with transfers from the master server to be
         noticed before the actual signature time out.
         We also suggest that operators of nameservers with slave zones
         develop 'watch dogs' to spot upcoming signature expirations in
         slave zones, and take appropriate action.
         When determining the value for the expiration parameter one has
         to take the following into account: What are the chances that
         all my secondary zones expire; How quickly can I reach an
         administrator and load a valid zone? All these arguments are
         not DNSSEC specific but may influence the choice of your
         signature validity intervals.

3.  Keys

   The DNSSEC validation protocol does not distinguish between DNSKEYs.
   All DNSKEYs can be used during the validation.  In practice operators
   use Key Singing and Zone Signing Keys and use the so called SEP flag



Kolkman & Gieben         Expires April 11, 2005                 [Page 6]

Internet-Draft        DNSSEC Operational Practices          October 2004


   to distinguish between them during operations.  The dynamics and
   considerations are discussed below.

   To make zone re-signing and key rollovers 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
   referred to as Zone Signing Keys (ZSK).  In this document we assume
   that KSKs are the subset of keys that are used for key exchanges with
   the parent and potentially for configuration as trusted anchors - the
   so called Secure Entry Point keys (SEP).  In this document we assume
   a one-to-one mapping between KSK and SEP keys and we assume the SEP
   flag [4] to be set on KSKs.

3.1  Motivations for the KSK and ZSK Separation

   Differentiating between the KSK to ZSK functions has several
   advantages:

   o  The KSK can be made stronger (i.e.  using more bits in the key
      material).  This has little operational impact since it is only
      used to sign a small fraction of the zone data.
   o  As the KSK is only used to sign a key set, which is most probably
      updated less frequently than other data in the zone, it can be
      stored separately from and in a safer location than the ZSK.
   o  A KSK can be used for longer periods.
   o  No parent/child interaction is required when ZSKs are updated.

   The KSK is used less than ZSK, once a key set is signed with the KSK
   all the keys in the key set can be used as ZSK.  If a ZSK is
   compromised, it can be simply dropped from the key set.  The new key
   set is then resigned with the KSK.

   Given the assumption that for KSKs the SEP flag is set, the KSK can
   be distinguished from a ZSK by examining the flag field in the DNSKEY
   RR.  If the flag field is an odd number it is a KSK if it is an even
   number it is a ZSK.

   The zone-signing key can be used to sign all the data in a zone on a
   regular basis.  When a zone-signing key is to be rolled, no
   interaction with the parent is needed.  This allows for "Signature
   Validity Periods" in the order of days.

   The key-signing key is only to be used to sign the DNSKEY RRs in a
   zone.  If a key-signing key is to be rolled over, there will be
   interactions with parties other than the zone administrator.  These
   can include the registry of the parent zone or administrators of
   verifying resolvers that have the particular key configured as



Kolkman & Gieben         Expires April 11, 2005                 [Page 7]

Internet-Draft        DNSSEC Operational Practices          October 2004


   trusted entry points.  Hence, the "Key Usage Time" of these keys can
   and should be made much longer.  Although, given a long enough key,
   the "Key Usage Time" can be on the order of years we suggest to plan
   for a "Key Usage Time" of the order of a few months so that a key
   rollover remains an operational routine.

3.2  Key Security Considerations

   Keys in DNSSEC have a number of parameters which should all be chosen
   with care, the most important once are: size, algorithm and the key
   validity period (its lifetime).

3.2.1  Key Validity Period

   RFC2541 [2] describes a number of considerations with respect to the
   security of keys.  The document deals with the generation, lifetime,
   size and storage of private keys.

   In Section 3 of RFC2541 [2] there are some suggestions for a key
   validity period: 13 months for long-lived keys and 36 days for
   transaction keys but suggestions for key sizes are not made.

   If we say long-lived keys are key-signing keys and transactions keys
   are zone-signing keys, these recommendations will lead to rollovers
   occurring frequently enough to become part of 'operational habits';
   the procedure does not have to be reinvented every time a key is
   replaced.

3.2.2  Key Algorithm

   There are currently three different types of algorithms that can be
   used in DNSSEC: RSA, DSA and elliptic curve cryptography.  The latter
   is fairly new and still needs to be standardized for usage in DNSSEC.

   RSA has been developed in an open and transparent manner.  As the
   patent on RSA expired in 2000, its use is now also free.

   DSA has been developed by NIST.  The creation of signatures creation
   is roughly the same speed as with RSA, but is 10 to 40 times as slow
   for verification [11].

   We suggest the use of RSA/SHA-1 as the preferred algorithm for the
   key.  The current known attacks on RSA can be defeated by making your
   key longer.  As the MD5 hashing algorithm is showing (theoretical)
   cracks, we recommend the usage of SHA1.






Kolkman & Gieben         Expires April 11, 2005                 [Page 8]

Internet-Draft        DNSSEC Operational Practices          October 2004


3.2.3  Key Sizes

   When choosing key sizes, zone administrators will need to take into
   account how long a key will be used and how much data will be signed
   during the key publication period.  It is hard to give precise
   recommendations but Lenstra and Verheul [10] supplied the following
   table with lower bound estimates for cryptographic key sizes.  Their
   recommendations are based on a set of explicitly formulated parameter
   settings, combined with existing data points about cryptographic
   systems.  For details we refer to the original paper.


       Year    RSA Key Sizes       Year    RSA Key Sizes

       2000        952             2015        1613
       2001        990             2016        1664
       2002        1028            2017        1717
       2003        1068            2018        1771
       2004        1108            2019        1825


       2005        1149            2020        1881
       2006        1191            2021        1937
       2007        1235            2022        1995
       2008        1279            2023        2054
       2009        1323            2024        2113


       2026        2236            2025        2174
       2010        1369            2027        2299
       2011        1416            2028        2362
       2012        1464            2029        2427
       2013        1513
       2014     1562

   For example, should you wish your key to last three years from 2003,
   check the RSA key size values for 2006 in this table.  In this case
   1191.

3.3  Key Rollovers

   A DNSSEC key cannot be used forever (see RFC2541 [2] and Section
   3.2).  So key rollovers are a fact of life when using DNSSEC.  Zone
   administrators who are in the process of rolling their keys have to
   take into account that data published in previous versions of their
   zone still lives in caches.  When deploying DNSSEC, this becomes an
   important consideration; ignoring data that may be in caches may lead
   to loss of service for clients.



Kolkman & Gieben         Expires April 11, 2005                 [Page 9]

Internet-Draft        DNSSEC Operational Practices          October 2004


   The most pressing example of this is when zone material signed with
   an old key is being validated by a resolver which does not have the
   old zone key cached.  If the old key is no longer present in the
   current zone, this validation fails, marking the data bogus.
   Alternatively, an attempt could be made to validate data which is
   signed with a new key against an old key that lives in a local cache,
   also resulting in data being marked bogus.

3.3.1  Difference Between ZSK and KSK Rollovers

   Note that KSK rollovers and ZSK rollovers are different.  A zone-key
   rollover can be handled in two different ways: pre-publish (Section
   Section 3.3.2.1) and double signature (Section Section 3.3.2.2).

   As the KSK is used to validate the key set and because the KSK is not
   changed during a ZSK rollover, a cache is able to validate the new
   key set of the zone.  The pre-publish method does not work for a KSK
   rollover.  The following example demonstrates that, here rollover the
   KSK from DNSKEY1 to DNSKEY2 using the NONE working pre-publish
   method.

     normal          pre-roll         roll            after

     SOA0            SOA1             SOA2            SOA3
     RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)

     DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY2
     DNSKEY10        DNSKEY2          DNSKEY2         DNSKEY10
                     DNSKEY10         DNSKEY10
     RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG2(DNSKEY)  RRSIG2 (DNSKEY)
     RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG10(DNSKEY) RRSIG10(DNSKEY)

    A cache that queries the zone during the "normal" step gets back
   DNSKEY1.  The DS RR and the key set are cached.  If the TTL of the DS
   RR is large enough, the DS RR remains in the cache until the "after"
   step.  If in this case, the key set TTL expires, and the cache
   queries for the zone again, it will get back the new key set signed
   by DNSKEY2.  It will then try to validate the key set with DNSKEY1
   and will fail.

3.3.2  Zone-signing Key Rollovers

   For zone-signing key rollovers there are two ways to make sure that
   during the rollover data still cached can be verified with the new
   key sets or newly generated signatures can be verified with the keys
   still in caches.  One schema uses double signatures, it is described
   in Section 3.3.2.2, the other uses key pre-publication (Section
   3.3.2.1).  The pros, cons and recommendations are described in



Kolkman & Gieben         Expires April 11, 2005                [Page 10]

Internet-Draft        DNSSEC Operational Practices          October 2004


   Section 3.3.2.3.

3.3.2.1  Pre-publish key set Rollover

   This section shows how to perform a ZSK rollover without the need to
   sign all the data in a zone twice - the so called "pre-publish
   rollover".This method has advantages in the case of a key compromise.
   If the old key is compromised, the new key has already been
   distributed in the DNS.  The zone administrator is then able to
   quickly switch to the new key and remove the compromised key from the
   zone.  Another major advantage is that the zone size does not double,
   as is the case with the double signature ZSK rollover.  A small
   "HOWTO" for this kind of rollover can be found in Appendix B.

    normal          pre-roll         roll            after

    SOA0            SOA1             SOA2            SOA3
    RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)

    DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY1
    DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY11
                    DNSKEY11         DNSKEY11
    RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG1(DNSKEY)  RRSIG1 (DNSKEY)
    RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG11(DNSKEY) RRSIG11(DNSKEY)


   normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.
      DNSKEY 10 is used to sign all the data of the zone, the
      zone-signing key.
   pre-roll: DNSKEY 11 is introduced into the key set.  Note that no
      signatures are generated with this key yet, but this does not
      secure against brute force attacks on the public key.  The minimum
      duration of this pre-roll phase is the time it takes for the data
      to propagate to the authoritative servers plus TTL value of the
      key set.  This equates to two times the Maximum Zone TTL.
   roll: At the rollover stage (SOA serial 1) DNSKEY 11 is used to sign
      the data in the zone exclusively  (i.e.  all the signatures from
      DNSKEY 10 are removed from the zone).  DNSKEY 10 remains published
      in the key set.  This way data that was loaded into caches from
      version 1 of the zone can still be verified with key sets fetched
      from version 2 of the zone.
      The minimum time that the key set including DNSKEY 10 is to be
      published is the time that it takes for zone data from the
      previous version of the zone to expire from old caches i.e.  the
      time it takes for this zone to propagate to all authoritative
      servers plus the Maximum Zone TTL value of any of the data in the
      previous version of the zone.




Kolkman & Gieben         Expires April 11, 2005                [Page 11]

Internet-Draft        DNSSEC Operational Practices          October 2004


   after: DNSKEY 10 is removed from the zone.  The key set, now only
      containing DNSKEY 11 is resigned with the DNSKEY 1.

   The above scheme can be simplified by always publishing the "future"
   key immediately after the rollover.  The scheme would look as follows
   (we show two rollovers); the future key is introduced in "after" as
   DNSKEY 12 and again a newer one, numbered 13, in "2nd after":


       normal              roll                after

       SOA0                SOA2                SOA3
       RRSIG10(SOA0)       RRSIG11(SOA2)       RRSIG11(SOA3)

       DNSKEY1             DNSKEY1             DNSKEY1
       DNSKEY10            DNSKEY10            DNSKEY11
       DNSKEY11            DNSKEY11            DNSKEY12
       RRSIG1(DNSKEY)      RRSIG1 (DNSKEY)     RRSIG1(DNSKEY)
       RRSIG10(DNSKEY)     RRSIG11(DNSKEY)     RRSIG11(DNSKEY)


       2nd roll            2nd after

       SOA4                SOA5
       RRSIG12(SOA4)       RRSIG12(SOA5)

       DNSKEY1             DNSKEY1
       DNSKEY11            DNSKEY12
       DNSKEY12            DNSKEY13
       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)
       RRSIG12(DNSKEY)     RRSIG12(DNSKEY)


   Note that the key introduced after the rollover is not used for
   production yet; the private key can thus be stored in a physically
   secure manner and does not need to be 'fetched' every time a zone
   needs to be signed.

3.3.2.2  Double Signature Zone-signing Key Rollover

   This section shows how to perform a ZSK key rollover using the double
   zone data signature scheme, aptly named "double sig rollover".

   During the rollover stage the new version of the zone file will need
   to propagate to all authoritative servers and the data that exists in
   (distant) caches will need to expire, this will take at least the
   maximum Zone TTL .




Kolkman & Gieben         Expires April 11, 2005                [Page 12]

Internet-Draft        DNSSEC Operational Practices          October 2004


       normal              roll               after

       SOA0                SOA1               SOA2
       RRSIG10(SOA0)       RRSIG10(SOA1)      RRSIG11(SOA2)
                           RRSIG11(SOA1)

       DNSKEY1             DNSKEY1            DNSKEY1
       DNSKEY10            DNSKEY10           DNSKEY11
                           DNSKEY11
       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)     RRSIG1(DNSKEY)
       RRSIG10(DNSKEY)     RRSIG10(DNSKEY)    RRSIG11(DNSKEY)
                           RRSIG11(DNSKEY)

   normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.
      DNSKEY 10 is used to sign all the data of the zone, the
      zone-signing key.
   roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced
      into the key set and all the data in the zone is signed with
      DNSKEY 10 and DNSKEY 11.  The rollover period will need to exist
      until all data from version 0 of the zone has expired from remote
      caches.  This will take at least the maximum Zone TTL of version 0
      of the zone.
   after: DNSKEY 10 is removed from the zone.  All the signatures from
      DNSKEY 10 are removed from the zone.  The key set, now only
      containing DNSKEY 11, is resigned with DNSKEY 1.

   At every instance the data from the previous version of the zone can
   be verified with the key from the current version and the other way
   around.  The data from the current version can be verified with the
   data from the previous version of the zone.  The duration of the
   rollover phase and the period between rollovers should be at least
   the "Maximum Zone TTL".

   Making sure that the rollover phase lasts until the signature
   expiration time of the data in version 0 of the zone is recommended.
   This way all caches are cleared of the old signatures.  However, this
   date could be considerably longer than the Maximum Zone TTL, making
   the rollover a lengthy procedure.

   Note that in this example we assumed that the zone was not modified
   during the rollover.  New data can be introduced in the zone as long
   as it is signed with both keys.

3.3.2.3  Pros and Cons of the Schemes







Kolkman & Gieben         Expires April 11, 2005                [Page 13]

Internet-Draft        DNSSEC Operational Practices          October 2004


   Pre-publish-key set rollover: This rollover does not involve signing
      the zone data twice.  Instead, just before the actual rollover,
      the new key is published in the key set and thus available for
      cryptanalysis attacks.  A small disadvantage is that this process
      requires four steps.  Also the pre-publish scheme will not work
      for KSKs as explained in Section 3.3.
   Double signature rollover: The drawback of this signing scheme is
      that during the rollover the number of signatures in your zone
      doubles, this may be prohibitive if you have very big zones.  An
      advantage is that it only requires three steps.

3.3.3  Key-signing Key Rollovers

   For the rollover of a key-signing key the same considerations as for
   the rollover of a zone-signing key apply.  However we can use a
   double signature scheme to guarantee that old data (only the apex key
   set) in caches can be verified with a new key set and vice versa.

   Since only the key set is signed with a KSK, zone size considerations
   do not apply.


       normal          roll            after

       SOA0            SOA1            SOA2
       RRSIG10(SOA0)   RRSIG10(SOA1)   RRSIG10(SOA2)

       DNSKEY1         DNSKEY1         DNSKEY2
                       DNSKEY2
       DNSKEY10        DNSKEY10        DNSKEY10
       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY)
                       RRSIG2 (DNSKEY)
       RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY)

   normal: Version 0 of the zone.  The parental DS points to DNSKEY1.
      Before the rollover starts the child will have to verify what the
      TTL is of the DS RR that points to DNSKEY1 - it is needed during
      the rollover and we refer to the value as TTL_DS.
   roll: During the rollover phase the zone administrator generates a
      second KSK, DNSKEY2.  The key is provided to the parent and the
      child will have to wait until a new DS RR has been generated that
      points to DNSKEY2.  After that DS RR has been published on all
      servers authoritative for the parents zone, the zone administrator
      has to wait at least TTL_DS to make sure that the old DS RR has
      expired from caches.






Kolkman & Gieben         Expires April 11, 2005                [Page 14]

Internet-Draft        DNSSEC Operational Practices          October 2004


   after: DNSKEY1 has been removed.

   The scenario above puts the responsibility for maintaining a valid
   chain of trust with the child.  It also is based on the premises hat
   the parent only has one DS RR (per algorithm) per zone.  An
   alternative mechanism has been considered.  Using an established
   trust relation, the interaction can be performed in-band, and where
   removal of the keys by the child can be signaled by the parent.  In
   this mechanism there are periods where there are two DS RRs at the
   parent.  Since at the moment of writing the protocol for this
   interaction has not been developed further discussion is out of scope
   for this document.

3.3.4  Automated Key Rollovers

   As keys must be renewed periodically, there are some motivation to
   automate the rollover process (also see [12])

   o  ZSK rollovers are easy to automate as only the local zone is
      involved.
   o  A KSK rollover needs interaction between the parent and child.
      Data exchange is needed to provide the new keys to the parent,
      consequently, this data must be authenticated and integrity must
      be guaranteed in order to avoid attacks on the rollover.
   o  All time and TTL considerations presented in Section 3.3 apply to
      an automated rollover.

4.  Planning for Emergency Key Rollover

   This section deals with preparation for a possible key compromise.
   Our advice is to have a documented procedure ready for when a key
   compromise is suspected or confirmed.

   When the private material of one of your keys is compromised it can
   be used for as long as a valid authentication chain exists.  An
   authentication chain remains intact for:
   o  as long as a signature over the compromised key in the
      authentication chain is valid,
   o  as long as a parental DS RR (and signature) points to the
      compromised key,
   o  as long as the key is anchored in a resolver and is used as a
      starting point for validation.  (This is the hardest to update.)

   While an authentication chain to your compromised key exists, your
   name-space is vulnerable to abuse by the malicious key holder (i.e.
   the owner of the compromised key).  Zone operators have to make a
   trade off if the abuse of the compromised key is worse than having
   data in caches that cannot be validated.  If the zone operator



Kolkman & Gieben         Expires April 11, 2005                [Page 15]

Internet-Draft        DNSSEC Operational Practices          October 2004


   chooses to break the authentication chain to the compromised key,
   data in caches signed with this key cannot be validated.  However, if
   the zone administrator chooses to take the path of a regular
   roll-over, the malicious key holder can spoof data so that it appears
   to be valid.  Note that this kind of attack is more likely to occur
   in a localized part of the network topology i.e.  downstream from
   where the spoof takes place.


4.1  KSK Compromise

   When the KSK has been compromised the parent must be notified as soon
   as possible using secure means.  The key set of the zone should be
   resigned as soon as possible.  Care must be taken to not break the
   authentication chain.  The local zone can only be resigned with the
   new KSK after the parent's zone has created and reloaded its zone
   with the DS created from the new KSK.  Before this update takes place
   it would be best to drop the security status of a zone all together:
   the parent removes the DS of the child at the next zone update.
   After that the child can be made secure again.

   An additional danger of a key compromise is that the compromised key
   can be used to facilitate a legitimate DNSKEY/DS and/or nameserver
   rollover at the parent.  When that happens the domain can be in
   dispute.  An out of band and secure notify mechanism to contact a
   parent is needed in this case.

4.2  ZSK Compromise

   Primarily because there is no parental interaction required when a
   ZSK is compromised, the situation is less severe than with with a KSK
   compromise.  The zone must still be resigned with a new ZSK as soon
   as possible.  As this is a local operation and requires no
   communication between the parent and child this can be achieved
   fairly quickly.  However, one has to take into account that just as
   with a normal rollover the immediate disappearance from the old
   compromised key may lead to verification problems.  The
   pre-publication scheme as discussed above minimizes such problems.

4.3  Compromises of Keys Anchored in Resolvers

   A key can also be pre-configured in resolvers.  For instance, if
   DNSSEC is successfully deployed the root key will be pre-configured
   in most security aware resolvers.

   If trust-anchor keys are compromised, the resolvers using these keys
   should be notified of this fact.  Zone administrators may consider
   setting up a mailing list to communicate the fact that a SEP key is



Kolkman & Gieben         Expires April 11, 2005                [Page 16]

Internet-Draft        DNSSEC Operational Practices          October 2004


   about to be rolled over.  This communication will of course need to
   be authenticated e.g.  by using digital signatures.

   End-user faced with the task of updating anchored key should always
   validate the new key.  New keys should be authenticated out of the
   DNS, for example, looking them up on an x.509 secured announcement
   website.

5.  Parental Policies

5.1  Initial Key Exchanges and Parental Policies Considerations

   The initial key exchange is always subject to the policies set by the
   parent (or its registry).  When designing a key exchange policy one
   should take into account that the authentication and authorization
   mechanisms used during a key exchange should be as strong as the
   authentication and authorization mechanisms used for the exchange of
   delegation information between parent and child.  I.e.  there is no
   implicit need in DNSSEC to make the authentication process stronger
   than it was in DNS.

   Using the DNS itself as the source for the actual DNSKEY material,
   with an off-band check on the validity of the DNSKEY, has the benefit
   that it reduces the chances of user error.  A parental DNSKEY
   download tool can make use of the SEP bit [4] to select the proper
   key from a DNSSEC key set; thereby reducing the chance that the wrong
   DNSKEY is sent.  It can validate the self-signature over a key;
   thereby verifying the ownership of the private key material.
   Fetching the DNSKEY from the DNS ensures that the child will not
   become bogus once the parent publishes the DS RR indicating the child
   is secure.

   Note: the off-band verification is still needed when the key-material
   is fetched via the DNS.  The parent can never be sure whether the
   DNSKEY RRs have been spoofed or not.

5.2  Storing Keys So Hashes Can Be Regenerated

   When designing a registry system one should consider if the DNSKEYs
   and/or the corresponding DSs are stored.  Storing DNSKEYs will help
   during troubleshooting while the overhead of calculating DS records
   from them is minimal.

   Having an out-of-band mechanism, such as a Whois database, to find
   out which keys are used to generate DS Resource Records for specific
   owners and/or zones may also help with troubleshooting.





Kolkman & Gieben         Expires April 11, 2005                [Page 17]

Internet-Draft        DNSSEC Operational Practices          October 2004


5.3  Security Lameness Checks

   Security Lameness is defined as what happens when a parent has a DS
   RR pointing to a non-existing DNSKEY RR.  During key exchange a
   parent should make sure that the child's key is actually configured
   in the DNS before publishing a DS RR in its zone.  Failure to do so
   would render the child's zone being marked as bogus.

   Child zones should be very careful removing DNSKEY material,
   specifically SEP keys, for which a DS RR exists.

   Once a zone is "security lame" a fix (e.g.  by removing a DS RR) will
   take time to propagate through the DNS.

5.4  DS Signature Validity Period

   Since the DS can be replayed as long as it has a valid signature a
   short signature validity period over the DS minimizes the time a
   child is vulnerable in the case of a compromise of the child's
   KSK(s).  A signature validity period that is too short introduces the
   possibility that a zone is marked bogus in case of a configuration
   error in the signer.  There may not be enough time to fix the
   problems before signatures expire.  Something as mundane as operator
   unavailability during weekends shows the need for DS signature
   lifetimes longer than 2 days.  We recommend the minimum for a DS
   signature validity period to be a few days.

   The maximum signature lifetime of the DS record depends on how long
   child zones are willing to be vulnerable after a key compromise.
   Other considerations, such as how often the zone is (re)signed can
   also be taken into account.

   We consider a signature validity period of around one week to be a
   good compromise between the operational constraints of the parent and
   minimizing damage for the child.

6.  Security Considerations

   DNSSEC adds data integrity to the DNS.  This document tries to assess
   considerations to operate a stable and secure DNSSEC service.  Not
   taking into account the 'data propagation' properties in the DNS will
   cause validation failures and may make secured zones unavailable to
   security aware resolvers.

7.  Acknowledgments

   We, the folk mentioned as authors, only acted as editors.  Most of
   the ideas in this draft were the result of collective efforts during



Kolkman & Gieben         Expires April 11, 2005                [Page 18]

Internet-Draft        DNSSEC Operational Practices          October 2004


   workshops, discussions and try outs.

   At the risk of forgetting individuals who where the original
   contributors of the ideas we would like to acknowledge people who
   where actively involved in the compilation of this document.  In
   random order: Olafur Gudmundsson, Wesley Griffin, Michael Richardson,
   Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette and Olivier
   Courtay, Sam Weiler, Jelte Jansen.

   Mike StJohns designed the key exchange between parent and child
   mentioned in the last paragraph of  Section 3.3.3

   Section 3.3.4 was supplied by G.  Guette and O.  Courtay.

   Emma Bretherick and Adrian Bedford corrected many of the spelling and
   style issues.

   Kolkman and Gieben take the blame for introducing all miscakes(SIC).

8.  References

8.1  Normative References

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

   [2]  Eastlake, D., "DNS Security Operational Considerations", RFC
        2541, March 1999.

   [3]  Lewis, E., "DNS Security Extension Clarification on Zone
        Status", RFC 3090, March 2001.

   [4]  Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key
        (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work
        in progress), February 2003.

   [5]  Arends, R., "DNS Security Introduction and Requirements",
        draft-ietf-dnsext-dnssec-intro-11 (work in progress), March
        2003.

   [6]  Arends, R., "Protocol Modifications for the DNS Security
        Extensions", draft-ietf-dnsext-dnssec-protocol-07 (work in
        progress), March 2003.

8.2  Informative References

   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.



Kolkman & Gieben         Expires April 11, 2005                [Page 19]

Internet-Draft        DNSSEC Operational Practices          October 2004


   [8]   Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
         RFC 2308, March 1998.

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

   [10]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
         Sizes", The Journal of Cryptology 14 (255-293), 2001.

   [11]  Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
         Source Code in C", 1996.

   [12]  Guette, G., "Requirements for Automated Key Rollover in
         DNSsec", draft-ietf-dnsop-key-rollover-requirements-01 (work in
         progress), August 2004.


Authors' Addresses

   Olaf M. Kolkman
   RIPE NCC
   Singel 256
   Amsterdam  1016 AB
   The Netherlands

   Phone: +31 20 535 4444
   EMail: olaf@ripe.net
   URI:   http://www.ripe.net/


   Miek Gieben
   NLnet Labs
   Kruislaan 419
   Amsterdam  1098 VA
   The Netherlands

   EMail: miek@nlnetlabs.nl
   URI:   http://www.nlnetlabs.nl

Appendix A.  Terminology

   In this document there is some jargon used that is defined in other
   documents.  In most cases we have not copied the text from the
   documents defining the terms but given a more elaborate explanation
   of the meaning.  Note that these explanations should not be seen as
   authoritative.





Kolkman & Gieben         Expires April 11, 2005                [Page 20]

Internet-Draft        DNSSEC Operational Practices          October 2004


   Private and Public Keys: DNSSEC secures the DNS through the use of
      public key cryptography.  Public key cryptography is based on the
      existence of two keys, a public key and a private key.  The public
      keys are published in the DNS by use of the DNSKEY Resource Record
      (DNSKEY RR).  Private keys should remain private.
   Signer: The system that has access to the private key material and
      signs the Resource Record sets in a zone.  A signer may be
      configured to sign only parts of the zone e.g.  only those RRsets
      for which existing signatures are about to expire.
   KSK: A Key-Signing Key (KSK) is a key that is used exclusively for
      signing the apex key set.  The fact that a key is a KSK is only
      relevant to the signing tool.
   ZSK: A Zone Signing Key (ZSK) is a key that is used for signing all
      data in a zone.  The fact that a key is a ZSK is only relevant to
      the signing tool.
   SEP Key: A KSK that has a parental DS record pointing to it.  Note:
      this is not enforced in the protocol.  A SEP Key with no parental
      DS is security lame.
   Anchored Key: A DNSKEY configured in resolvers around the globe.
      This key is hard to update, hence the term anchored.
   Bogus: Also see Section 5 of [5].  An RRset in DNSSEC is marked
      "Bogus" when a signature of a RRset does not validate against a
      DNSKEY.
   Singing the Zone File: The term used for the event where an
      administrator joyfully signs its zone file while producing melodic
      sound patterns.
   Zone Administrator: The 'role' that is responsible for signing a zone
      and publishing it on the primary authoritative server.

Appendix B.  Zone-signing Key Rollover Howto

   Using the pre-published signature scheme and the most conservative
   method to assure oneself that data does not live in caches here
   follows the "HOWTO".
   Key notation:
   Step 0: The preparation: Create two keys and publish both in your key
      set.  Mark one of the keys as "active" and the other as
      "published".  Use the "active" key for signing your zone data.
      Store the private part of the "published" key, preferably
      off-line.
   Step 1: Determine expiration: At the beginning of the rollover make a
      note of the highest expiration time of signatures in your zone
      file created with the current key marked as "active".
      Wait until the expiration time marked in Step 1 has passed
   Step 2: Then start using the key that was marked as "published" to
      sign your data i.e.  mark it as "active".  Stop using the key that
      was marked as "active", mark it as "rolled".




Kolkman & Gieben         Expires April 11, 2005                [Page 21]

Internet-Draft        DNSSEC Operational Practices          October 2004


   Step 3: It is safe to engage in a new rollover (Step 1) after at
      least one "signature validity period".

Appendix C.  Typographic Conventions

   The following typographic conventions are used in this document:
   Key notation: A key is denoted by KEYx, where x is a number, x could
      be thought of as the key id.
   RRset notations: RRs are only denoted by the type.  All other
      information - owner, class, rdata and TTL - is left out.  Thus:
      "example.com 3600 IN A 192.168.1.1" is reduced to "A".  RRsets are
      a list of RRs.  A example of this would be: "A1,A2", specifying
      the RRset containing two "A" records.  This could again be
      abbreviated to just "A".
   Signature notation: Signatures are denoted as RRSIGx(RRset), which
      means that RRset is signed with DNSKEYx.
   Zone representation: Using the above notation we have simplified the
      representation of a signed zone by leaving out all unnecessary
      details such as the names and by representing all data by "SOAx"
   SOA representation: SOA's are represented as SOAx, where x is the
      serial number.
   Using this notation the following zone:


   example.net.     600     IN SOA  ns.example.net. bert.example.net. (
                            10         ; serial
                            450        ; refresh (7 minutes 30 seconds)
                            600        ; retry (10 minutes)
                            345600     ; expire (4 days)
                            300        ; minimum (5 minutes)
                             )
                     600     RRSIG   SOA 5 2 600 20130522213204 (
                                     20130422213204 14 example.net.
                                     cmL62SI6iAX46xGNQAdQ... )
                     600     NS      a.iana-servers.net.
                     600     NS      b.iana-servers.net.
                     600     RRSIG   NS 5 2 600 20130507213204 (
                                     20130407213204 14 example.net.
                                     SO5epiJei19AjXoUpFnQ ... )
                     3600    DNSKEY  256 3 5 (
                                     EtRB9MP5/AvOuVO0I8XDxy0...
                                     ) ; key id = 14
                     3600    DNSKEY  256 3 5 (
                                     gsPW/Yy19GzYIY+Gnr8HABU...
                                     ) ; key id = 15
                     3600    RRSIG   DNSKEY 5 2 3600 20130522213204 (
                                     20130422213204 14 example.net.
                                     J4zCe8QX4tXVGjV4e1r9... )



Kolkman & Gieben         Expires April 11, 2005                [Page 22]

Internet-Draft        DNSSEC Operational Practices          October 2004


                     3600    RRSIG   DNSKEY 5 2 3600 20130522213204 (
                                     20130422213204 15 example.net.
                                     keVDCOpsSeDReyV6O... )
                     600     RRSIG   NSEC 5 2 600 20130507213204 (
                                     20130407213204 14 example.net.
                                     obj3HEp1GjnmhRjX... )
   a.example.net.    600     IN TXT  "A label"
                     600     RRSIG   TXT 5 3 600 20130507213204 (
                                     20130407213204 14 example.net.
                                     IkDMlRdYLmXH7QJnuF3v... )
                     600     NSEC    b.example.com. TXT RRSIG NSEC
                     600     RRSIG   NSEC 5 3 600 20130507213204 (
                                     20130407213204 14 example.net.
                                     bZMjoZ3bHjnEz0nIsPMM... )

                     ...


    is reduced to the following representation:

       SOA10
       RRSIG14(SOA10)

       DNSKEY14
       DNSKEY15

       RRSIG14(KEY)
       RRSIG15(KEY)

    The rest of the zone data has the same signature as the SOA record,
   i.e a RRSIG created with DNSKEY 14.

Appendix D.  Document Details and Changes

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

   $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.29 2004/
   10/11 11:27:10 dnssec Exp $

D.1  draft-ietf-dnsop-dnssec-operational-practices-00

   Submission as working group document.  This document is a modified
   and updated version of draft-kolkman-dnssec-operational-practices-00.

D.2  draft-ietf-dnsop-dnssec-operational-practices-01

   changed the definition of "Bogus" to reflect the one in the protocol



Kolkman & Gieben         Expires April 11, 2005                [Page 23]

Internet-Draft        DNSSEC Operational Practices          October 2004


   draft.

   Bad to Bogus

   Style and spelling corrections

   KSK - SEP mapping made explicit.

   Updates from Sam Weiler added










































Kolkman & Gieben         Expires April 11, 2005                [Page 24]

Internet-Draft        DNSSEC Operational Practices          October 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 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 that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2004).  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.


Acknowledgment

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




Kolkman & Gieben         Expires April 11, 2005                [Page 25]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/