[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                           J. Ihren
Internet-Draft                                             Autonimica AB
Expires: January 7, 2005                                      O. Kolkman
                                                                RIPE NCC
                                                              B. Manning
                                                                  EP.net
                                                            July 9, 2004


   An In-Band Rollover Algorithm and a Out-Of-Band Priming Method for
                           DNS Trust Anchors.
            draft-kolkman-dnsext-dnssec-in-band-rollover-00

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 January 7, 2005.

Copyright Notice

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

Abstract

   The DNS Security Extensions (DNSSEC) works by validating so called
   chains of authority.  The start of these chains of authority are
   usually public keys that are anchored in the DNS clients, the so
   called trust anchors.




Ihren, et al.           Expires January 7, 2005                 [Page 1]


Internet-Draft      DNSSEC Key Rollover and Priming            July 2004


   This memo describes a method how these client trust anchors can be
   replaced using the DNS validation and querying mechanisms (in-band)
   if the key pairs used for signing by zone owner are rolled.

   This memo also describes a method to establish the validity of trust
   anchors for initial configuration, or priming, using out of band
   mechanisms.

Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Key Signing Keys, Zone Signing Keys and Secure Entry
           Points.  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction and Background  . . . . . . . . . . . . . . . . .  4
   3.  M-N Trust Anchor Rollover. . . . . . . . . . . . . . . . . . .  5
     3.1   The Rollover . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2   The Algorithm. . . . . . . . . . . . . . . . . . . . . . .  6
     3.3   Implementation notes . . . . . . . . . . . . . . . . . . .  7
     3.4   Possible transactions. . . . . . . . . . . . . . . . . . .  7
       3.4.1   Single DNSKEY replaced.  . . . . . . . . . . . . . . .  7
       3.4.2   Addition of a new DNSKEY (no removal)  . . . . . . . .  8
       3.4.3   Removal of old DNSKEY (no addition). . . . . . . . . .  8
       3.4.4   Multiple DNSKEYs replaced. . . . . . . . . . . . . . .  8
       3.4.5   Only some RRSIGs validate over an unchanged DNSKEY
               set. . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.5   No need for resolver-side overlap of old and new keys. . .  8
   4.  Bootstrapping automatic rollovers. . . . . . . . . . . . . . .  8
     4.1   Priming Keys.  . . . . . . . . . . . . . . . . . . . . . .  9
       4.1.1   Bootstrapping trust-anchors using a priming key. . . .  9
       4.1.2   Distribution of priming keys.  . . . . . . . . . . . .  9
   5.  M-N algorithm vs Priming . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 10
     6.1   M-N Algorithm Security Considerations  . . . . . . . . . . 10
     6.2   Priming Key Security Considerations  . . . . . . . . . . . 11
   7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 11
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 11
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   B.  Document History . . . . . . . . . . . . . . . . . . . . . . . 12
     B.1   version 00 . . . . . . . . . . . . . . . . . . . . . . . . 13
       Intellectual Property and Copyright Statements . . . . . . . . 14








Ihren, et al.           Expires January 7, 2005                 [Page 2]


Internet-Draft      DNSSEC Key Rollover and Priming            July 2004


1.  Terminology

   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
   and "MAY" in this document are to be interpreted as described in
   RFC2119 [1].

   The term "zone" refers to the unit of administrative control in the
   Domain Name System.  In this document "name server" denotes a DNS
   name server that is authoritative (i.e.  knows all there is to know)
   for a DNS zone.  A "zone owner" is the entity responsible for signing
   and publishing a zone on a name server.  The terms "authentication
   chain", "bogus", "trust anchors" and "Island of Security" are defined
   in [4].  Throughout this document we use the term "resolver" to mean
   "Validating Stub Resolvers" as defined in [4].

   We use the term "security apex" as the zone for which a trust anchor
   has been configured and which is therefore, by definition, at the
   root of an island of security.  The configuration of trust anchors is
   a client side issue therefore a zone owner may not always know if
   their zone has become a security apex.

   A "stale anchor" is a trust anchor (a public key) that relates to a
   key that is not used for signing.  Since trust anchors indicate that
   a zone is supposed to be secure a validator will mark the all data in
   an island of security as bogus when all trust anchors become stale.

   It is assumed that the reader is familiar with public key
   cryptography concepts [REF: Schneier Applied Cryptography] and is
   able to distinguish between the private and public parts of a key
   based on the context in which we use the term "key", if there is a
   possible ambiguity we will explicitly mention if a private or a
   public part of a key is used.

   The term "administrator" is used loosely throughout the text.  In
   some cases an administrator is meant to be a person, in other cases
   the administrator may be a process that has been delegated certain
   responsibilities.

1.1  Key Signing Keys, Zone Signing Keys and Secure Entry Points.

   Although the DNSSEC protocol does not make a distinction between
   different keys the operational practice is that a distinction is made
   between zone signing keys and key signing keys.  A key signing key is
   used to exclusively sign the DNSKEY Resource Record (RR) set at the
   apex of a zone and the zone signing keys sign all the data in the
   zone (including the DNSKEY RR set at the apex).

   Keys that are intended to be used as the start of the authentication



Ihren, et al.           Expires January 7, 2005                 [Page 3]


Internet-Draft      DNSSEC Key Rollover and Priming            July 2004


   chain for a particular zone, either because they are pointed to by a
   parental DS RR or because they are configured as a trust anchor, are
   called Secure Entry Point (SEP) keys.  In practice these SEP keys
   will be key signing keys.

   In order for the mechanism described herein to work the keys that are
   intended to be used as secure entry points MUST have the SEP [2] flag
   set.  In the examples it is assumed that keys with the SEP flag set
   are used as key signing keys and thus exclusively sign the DNSKEY RR
   set published at the apex of the zone.

2.  Introduction and Background

   When DNSSEC signatures are validated the resolver constructs a chain
   of authority from a pre-configured trust anchor to the DNSKEY
   Resource Record (RR), which contains the public key that validates
   the signature stored in a RRSIG RR.  DNSSEC is designed so that the
   administrator of a resolver can create multiple islands of security
   by configuring multiple trust anchors.

   It is expected that resolvers will have more than one trust-anchor
   configured.  Although there is no deployment experience it is not
   unreasonable to expect resolvers to be configured with a number of
   trust anchors that varies between order 1 and order 1000.  Because
   zone owners are expected to roll their keys, trust-anchors will have
   to be maintained in order not to become stale.

   Since there is no global key maintenance policy for zone owners and
   there are no mechanisms in the DNS to signal the key maintenance
   policy it may be very hard for resolvers administrators to keep their
   set of trust anchors up to date.  For instance, if there is only one
   trust anchor configured and the key maintenance policy is clearly
   published, through some out of band trusted channel, than a resolver
   administrator can probably keep track of key rollovers and update the
   trust anchor annually.  With more than 100 different policies all
   published through different channels this soon becomes an
   unmanageable problem.

   In Section 3 this memo sets out a lightweight, in-DNS, mechanism to
   track key rollovers and modify the trust-anchor's accordingly.  The
   algorithm is stateless and does not need protocol extensions.

   In Section 4 we describe a method [Editors note: for now only the
   frame work and a set of requirements] to install trust anchors.  This
   method can be used at first configuration or when the trust anchors
   became out of sync with the keys published by a zone owner.

   The choice for which domains trust anchors are to be configured is a



Ihren, et al.           Expires January 7, 2005                 [Page 4]


Internet-Draft      DNSSEC Key Rollover and Priming            July 2004


   local policy issue.  So is the choice which trust anchors has
   prevalence if there are multiple chains of trust to a given piece of
   DNS data (e.g.  when a domain and its sub-domain both have a trust
   anchor configured).  Both issues are out of the scope of this
   document.

3.  M-N Trust Anchor Rollover.

3.1  The Rollover

   When a key pair is replaced all signatures (in DNSSEC these are the
   RRSIG records) created with the old key will be replaced by new
   signatures created by the new key.  Access to the new public key is
   needed to verify these signatures.

   Since a zone signing keys are in "the middle" of a chain of authority
   the can be verified using the signature made by a key signing key.
   Rollover is therefore transparent to validators.  But if a key
   signing key is rolled a resolver can determine its authenticity by
   either following the authorization chain from the parents DS RR, an
   out-of-DNS authentication or by relying on other trust anchors known
   for the zone in which the key is rolled.  The M-N trust anchor
   rollover mechanism, described below, is based on using existing trust
   anchors to verify a subset of the available signatures.

   Our example pseudo zone below contains a number of key signing keys
   numbered 1 through Y and two zone signing keys A and B.  During a key
   rollover key 2 is replaced by key Y+1.  The zone content changes
   from:

          example.com.  DNSKEY key1
          example.com.  DNSKEY key2
          example.com.  DNSKEY key3
          ...
          example.com.  DNSKEY keyN

          example.com.  DNSKEY keyA
          example.com.  DNSKEY keyB

          example.com.  RRSIG DNSKEY ... (key1)
          example.com.  RRSIG DNSKEY ... (key2)
          example.com.  RRSIG DNSKEY ... (key3)
          ...
          example.com.  RRSIG DNSKEY ... (keyY)
          example.com.  RRSIG DNSKEY ... (keyA)
          example.com.  RRSIG DNSKEY ... (keyB)

    to:



Ihren, et al.           Expires January 7, 2005                 [Page 5]


Internet-Draft      DNSSEC Key Rollover and Priming            July 2004


          example.com.  DNSKEY key1
          example.com.  DNSKEY key3
          ...
          example.com.  DNSKEY keyY
          example.com.  DNSKEY keyY+1

          example.com.  RRSIG DNSKEY ... (key1)
          example.com.  RRSIG DNSKEY ... (key3)
          ...
          example.com.  RRSIG DNSKEY ... (keyY)
          example.com.  RRSIG DNSKEY ... (keyY+1)

   When the rollover becomes visible to the verifying stub resolver it
   will be able to verify the RRSIGs associated with key1, key3 ...
   keyY.  There will be no RRSIG by key2 and the RRSIG by keyY+1 will
   not be used for validation, since that key is previously unknown and
   thereby not trusted.

   Note that this example is simplified.  Because of operational
   considerations described in [5] having a period where the two key
   signing keys are available is actually a good idea.

3.2  The Algorithm.

   The M-N trust anchor rollover algorithm applies as follows.  If for a
   particular zone
   o  at least M public keys from the trust anchors directly verify the
      related RRSIGs over the DNSKEY RRset.  (the M criterion)
   and if
   o  the number of element in the set difference between 'the set of
      keys from the DNSKEY RRset with the SEP bit set' and 'the set of
      keys configured as trust anchors' is smaller or equal than N.
      (the N criterion)
   then all the trust-anchors for the particular zone replaced by the
   keys from the zones DNSKEY RR set that have the SEP flag set

   The choices for the rollover acceptance policy parameters M and N are
   left to the administrator of the resolver.  To be certain that a
   rollover is picked up by resolvers running this algorithm zone owners
   should only roll 1 SEP key at a time.  That way they comply to the
   most strict rollover acceptance policy of N=1.  The value of M is
   limited by the amount of SEP keys a zone owner publishes.  If the
   policy of the zone owner is to use Y SEP keys than the value of M
   should be M<=Y-N.

   If the rollover acceptance policy is M=1 then the result for the
   rollover in our example above should be that the local database of
   trusted keys is updated by removing key "key2" and adding key



Ihren, et al.           Expires January 7, 2005                 [Page 6]


Internet-Draft      DNSSEC Key Rollover and Priming            July 2004


   "keyN+1" to the key store.

3.3  Implementation notes

   The DNSSEC protocol ordains that all DNSKEYs should be self-signed.
   The implementation should check this.  In order to be resilient
   against failures the implementation should collect the DNSKEY RRsets
   from (other) authoritative servers if verification of the self
   signatures fails.

   The algorithm SHOULD only be applied to algorithms, as represented in
   the algorithm field in the DNSKEY/RRSIG [3], that the resolver is
   aware of.  In other words the SEP keys of unknown algorithms should
   not be used when calculating the set difference for the N parameter
   and the SEP keys of unknown algorithm should not be entered as trust
   anchors.

   If a the M criterion is not met then the set of trust-anchors is out
   of sync with the SEP keys in the DNSKEY RRset and some or all of the
   trust-anchors are stale.  This condition should be flagged.  The most
   appropriate action is human audit possibly followed by re-priming
   (Section 4) the keyset.

   An implementation should regularly probe the the authoritative
   nameservers for new keys.  Since there is no mechanism to publish
   rollover frequencies this document RECOMMENDS zone owners not to roll
   their key signing keys more often than once per month and resolver
   administrators to probe for key rolls (and apply the M-N algorithm)
   not less often than once per month.  If the rollover frequency is
   higher than the probing frequency than trust anchors may become
   stale.  The exact relation between the frequencies depends on the
   amount of SEP keys rolled by the zone owner and the value M
   configured by the resolver administrator.

   In all the cases below a transaction where M-N algorithm does not
   validate should be considered bad (i.e.  possibly spoofed or
   otherwise corrupted data).  The most appropriate action is human
   audit.

3.4  Possible transactions.

3.4.1  Single DNSKEY replaced.

   This is probably the most typical transaction on the zone owners
   part.  The result should be that if the M-N algorithm validates then
   the key store is updated by removal of the old key and addition of
   the new key.  Note that if the DNSKEY RRset contains exactly M keys
   replacement of keys is not possible.



Ihren, et al.           Expires January 7, 2005                 [Page 7]


Internet-Draft      DNSSEC Key Rollover and Priming            July 2004


3.4.2  Addition of a new DNSKEY (no removal)

   If M-N algorithm validates then the new key is added to the key
   store.  Not more than N keys can be added at once.

3.4.3  Removal of old DNSKEY (no addition).

   If the M-N algorithm validates then the old key is removed from the
   key store.  Note that it is not possible to reduce the keyset to a
   size smaller than M.

3.4.4  Multiple DNSKEYs replaced.

   Not more than N keys can be replace at one time.  Since M keys need
   to validate the total number of SEP keys in the DNSKEY RRset is M+N.

   Since the value of N is set by the resolvers local policy zone owners
   should assume N==1 in order to prevent a subset of the resolvers to
   become stale because they did not pick up the change.

3.4.5  Only some RRSIGs validate over an unchanged DNSKEY set.

   This is a case where the M criterion may not be met, see Section 3.3.

3.5  No need for resolver-side overlap of old and new keys.

   It is worth pointing out that there is no need for the resolver to
   keep state about old keys versus new keys.  From the resolver point
   of view there are only trusted and not trusted keys.  The reason is
   that the zone owner needs to do proper maintenance of RRSIGs
   regardless of the resolver rollover mechanism and hence must ensure
   that a key is not rolled out out the DNSKEY set until there cannot be
   any RRSIGs created by this key still legally cached.

   Hence the rollover mechanism is stateless: as soon as the resolver
   (or in this case the rollover tracking utility) detects a change in
   the DNSKEY set with a sufficient number of matching RRSIGs the
   trusted key definition is immediately updated.

4.  Bootstrapping automatic rollovers.

   It is expected that with the ability to automatically roll trust
   anchors at trust points will follow a diminished unwillingness to
   roll these keys, since the risks associated with stale keys are
   minimized.

   The problem of "priming" the trust anchors, or bringing them into
   sync (which could happen if a resolver is off line for a long period



Ihren, et al.           Expires January 7, 2005                 [Page 8]


Internet-Draft      DNSSEC Key Rollover and Priming            July 2004


   in which a set of SEP keys in a zone 'evolve' away from its trust
   anchor configuration) remains.

   For (re)priming we can rely on out of band technology and we propose
   the following framework.

4.1  Priming Keys.

   If all the trust anchors roll somewhat frequently (on the order of
   months or at most about a year) then it will not be possible to
   design a device, or a software distribution that includes trust
   anchors, that after being manufactured is put on a shelf for several
   key rollover periods before being brought into use (since no trust
   anchors that were known at the time of manufacture remain active).

   To alleviate this we propose the concept of "priming keys".  Priming
   keys are ordinary DNSSEC Key Signing Keys with the characteristic
   that
   o  The private part of a priming key signs the DNSKEY RRset at the
      security apex, i.e.  at least one RRSIG DNSKEY is created by a
      priming key rather than by an "ordinary" trust anchor
   o  the public parts of priming keys are not included in the DNSKEY
      RRset.  Instead the public parts of priming keys are only
      available out-of-band.
   o  The public parts of the priming keys have a validity period.
      Within this period they can be used to obtain trust anchors.
   o  The priming key pairs are long lived (relative to the key rollover
      period.)

4.1.1  Bootstrapping trust-anchors using a priming key.

   To install the trust-anchor for a particular security apex an
   administrator of a validating resolver will need to:
   o  query for the DNSKEY RR set of the zone at the security apex;
   o  verify the self signatures of all DNSKEYs in the RRset;
   o  verify the signature of the RRSIG made with a priming key --
      verification using one of the public priming keys that is valid at
      that moment is sufficient;
   o  create the trust anchors by extracting the DNSKEY RRs with the SEP
      flag set.
   The SEP keys with algorithms unknown to the validating resolver
   SHOULD be ignored during the creation of the trust anchors.

4.1.2  Distribution of priming keys.

   The public parts of the priming keys SHOULD be distributed
   exclusively through out-of-DNS mechanisms.  The requirements for a
   distribution mechanism are:



Ihren, et al.           Expires January 7, 2005                 [Page 9]


Internet-Draft      DNSSEC Key Rollover and Priming            July 2004


   o  it can carry the "validity" period for the priming keys;
   o  it can carry the self-signature of the priming keys;
   o  and it allows for verification  using trust relations outside the
      DNS.
   A distribution mechanism would benefit from:
   o  the availability of revocation lists;
   o  the ability of carrying zone owners policy information such as
      recommended values for "M" and "N" and a rollover frequency;
   o  and the technology on which is based is readily available.

   [Editors Note:

   X.509 technology is a logical candidate for the distribution of
   priming keys.  The exact details need further research.

   What we probably need a convention on the use id-ce-keyUsage, the
   id-ce-extKeyUsage (assignment of a KeyPurposeId) and other relevant
   field [6].  Is there a possibility to store the keyroll policy
   information? PKIX specialist are invited to give their input.

   End of Editors note]

5.  M-N algorithm vs Priming

   There is overlap in the M-N algorithm and the Priming method.  One
   could exclusively use the Priming method for maintaining the trust
   anchors.  However the priming method probably relies on "non-DNS'
   technology and may therefore not be available for all devices that
   have a resolver.

6.  Security Considerations.

6.1  M-N Algorithm Security Considerations

   A clear issue for resolvers will be how to ensure that they track all
   rollover events for the zones they have configure trust anchors for.
   Because of temporary outages validating resolvers may have missed a
   rollover of a KSK.  The parameters that determine the robustness
   against failures are: a long period between rollovers during which
   the KSK set is stable and validating resolvers can actually notice
   the change; the number of KSKs and the value of M.

   With a large number of KSKs and a small value of M this operation
   becomes more robust since losing one key, for whatever reason, will
   not be crucial.  Unfortunately the choice for the number of KSKs is a
   local policy issue for the zone owner while the choice for the
   parameter M is a local policy issue  resolvers administrator.




Ihren, et al.           Expires January 7, 2005                [Page 10]


Internet-Draft      DNSSEC Key Rollover and Priming            July 2004


   Higher values of M increase the resilience against attacks somewhat;
   more signatures need to verify before a rollover is approved.

   The M-N algorithm does not provide a revocation mechanism.  In the
   case that the private keys of a zone owner are compromised the
   culprit may use these private keys to roll the trust anchors of (a
   subset of) the  resolvers.

6.2  Priming Key Security Considerations

   Since priming keys are not included in the DNSKEY RR set they are
   less sensitive to packet size constraints and can be chosen
   relatively large.  The private parts are only needed to sign the
   DNSKEY RR set during the validity period of the particular priming
   key pair.  Note that the private part of the priming key is used each
   time when a DNSKEY RRset has to be resigned in practice there shall
   little difference between the usage pattern of the private part of
   key signing keys and priming keys.

7.  IANA Considerations.

   NONE.

8.  References

8.1  Normative References

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

   [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]  Arends, R., "Resource Records for DNS Security Extensions",
        draft-ietf-dnsext-dnssec-records-04 (work in progress),
        September 2003.

8.2  Informative References

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

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




Ihren, et al.           Expires January 7, 2005                [Page 11]


Internet-Draft      DNSSEC Key Rollover and Priming            July 2004


   [6]  Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
        Public Key Infrastructure Certificate and CRL Profile", RFC
        2459, January 1999.


Authors' Addresses

   Johan Ihren
   Autonimica AB
   Bellmansgaten 30
   Stockholm  SE-118 47
   Sweden

   EMail: johani@autonomica.se


   Olaf M. Kolkman
   RIPE NCC
   Singel 256
   Amsterdam  1016 AB
   NL

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


   Bill Manning
   EP.net
   Marina del Rey, CA  90295
   USA

Appendix A.  Acknowledgments

   The present design for in-band automatic rollovers of DNSSEC trust
   anchors is the result of many conversations and it is no longer
   possible to remember exactly who contributed what.

   In addition we've also had appreciated help from (in no particular
   order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt
   Larson and Mark Kosters.

Appendix B.  Document History

   This appendix will be removed if and when the document is submitted
   to the RFC editor.

   The version you are reading is tagged as $Revision: 1.5 $.



Ihren, et al.           Expires January 7, 2005                [Page 12]


Internet-Draft      DNSSEC Key Rollover and Priming            July 2004


   Text between square brackets, other than references, are editorial
   comments and will be removed.

B.1  version 00

   Kolkman documented the ideas provided by Ihren and Manning.  In the
   process of documenting (and prototyping) Kolkman changed some of the
   details of the M-N algorithms working.  Ihren did not have a change
   to review the draft before Kolkman posted;

   Kolkman takes responsibilities for omissions, fuzzy definitions and
   mistakes.







































Ihren, et al.           Expires January 7, 2005                [Page 13]


Internet-Draft      DNSSEC Key Rollover and Priming            July 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.




Ihren, et al.           Expires January 7, 2005                [Page 14]