DNSOP G. Guette
Internet-Draft IRISA / INRIA
Expires: July 19, 2005 O. Courtay
Thomson R&D
January 18, 2005
Requirements for Automated Key Rollover in DNSSEC
draft-ietf-dnsop-key-rollover-requirements-02.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 19, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document describes problems that appear during an automated
rollover and gives the requirements for the design of communication
between parent zone and child zone during an automated rollover
process. This document is essentially about in-band key rollover.
Guette & Courtay Expires July 19, 2005 [Page 1]
Internet-Draft Automated Rollover Requirements January 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
4. Messages authentication and information exchanged . . . . . . 5
5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
6. Security consideration . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
A. Documents details and changes . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
Guette & Courtay Expires July 19, 2005 [Page 2]
Internet-Draft Automated Rollover Requirements January 2005
1. Introduction
The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key
cryptography and digital signatures. It stores the public part of
keys in DNSKEY Resource Records (RRs). Because old keys and
frequently used keys are vulnerable, they must be renewed
periodically. In DNSSEC, this is the case for Zone Signing Keys
(ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key
exchanges between parents and children is necessary for large zones
because there are too many changes to handle.
Let us consider for example a zone with 100000 secure delegations.
If the child zones change their keys once a year on average, that
implies 300 changes per day for the parent zone. This amount of
changes is hard to manage manually.
Automated rollover is optional and resulting from an agreement
between the administrator of the parent zone and the administrator of
the child zone. Of course, key rollover can also be done manually by
administrators.
This document describes the requirements for a protocol to perform
the automated key rollover process and focusses on interaction
between parent and child zone.
2. The Key Rollover Process
Key rollover consists of renewing the DNSSEC keys used to sign
resource records in a given DNS zone file. There are two types of
rollover, ZSK rollovers and KSK rollovers.
During a ZSK rollover, all changes are local to the zone that renews
its key: there is no need to contact other zones administrators to
propagate the performed changes because a ZSK has no associated DS
record in the parent zone.
During a KSK rollover, new DS RR(s) must be created and stored in the
parent zone. In consequence, data must be exchanged between child
and parent zones.
The key rollover is built from two parts of different nature:
o An algorithm that generates new keys and signs the zone file. It
can be local to the zone,
o the interaction between parent and child zones.
One example of manual key rollover [3] is:
o The child zone creates a new KSK,
Guette & Courtay Expires July 19, 2005 [Page 3]
Internet-Draft Automated Rollover Requirements January 2005
o the child zone waits for the creation of the DS RR in its parent
zone,
o the child zone deletes the old key,
o the parent zone deletes the old DS RR.
This document concentrates on defining interactions between entities
present in key rollover process.
3. Basic Requirements
This section provides the requirements for automated key rollover in
case of normal use. Exceptional case like emergency rollover is
specifically described later in this document.
The main condition during a key rollover is that the chain of trust
must be preserved to every validating DNS client. No matter if this
client retrieves some of the RRs from recursive caching name server
or from the authoritative servers for the zone involved in the
rollover.
Automated key rollover solution may be interrupted by a manual
intervention. This manual intervention should not compromise the
security state of the chain of trust. If the chain is safe before
the manual intervention, the chain of trust must remain safe during
and after the manual intervention
Two entities act during a KSK rollover: the child zone and its parent
zone. These zones are generally managed by different administrators.
These administrators should agree on some parameters like
availability of automated rollover, the maximum delay between
notification of changes in the child zone and the resigning of the
parent zone. The child zone needs to know this delay to schedule its
changes and/or to verify that the changes had been taken into account
in the parent zone. Hence, the child zone can also avoid some
critical cases where all child key are changed prior to the DS RR
creation.
By keeping some resource records during a given time, the recursive
cache servers can act on the automated rollover. The existence of
recursive cache servers must be taken into account by automated
rollover solution.
Indeed, during an automated key rollover a name server could have to
retrieve some DNSSEC data. An automated key rollover solution must
ensure that these data are not old DNSSEC material retrieved from a
recursive name server.
Guette & Courtay Expires July 19, 2005 [Page 4]
Internet-Draft Automated Rollover Requirements January 2005
4. Messages authentication and information exchanged
This section addresses in-band rollover, security of out-of-band
mechanisms is out of scope of this document.
The security provided by DNSSEC must not be compromised by the key
rollover, thus every exchanged message must be authenticated to avoid
fake rollover messages from malicious parties.
Once the changes related to a KSK are made in a child zone, there are
two ways for the parent zone to take this changes into account:
o the child zone notify directly or not directly its parent zone in
order to create the new DS RR and store this DS RR in parent zone
file,
o or the parent zone poll the child zone.
In both cases, the parent zone must receive all the child keys that
need the creation of associated DS RRs in the parent zone.
Because errors could occur during the transmission of keys between
child and parent, the key exchange protocol must be fault tolerant.
Should an error occured during the automated key rollover, an
automated key rollover solution must be able to keep the zone files
in a consistent state.
5. Emergency Rollover
Emergency key rollover is a special case of rollover decided by the
zone administrator generally for security reasons. In consequence,
emergency key rollover can break some of the requirement described
above.
A zone key might be compromised and an attacker can use the
compromised key to create and sign fake records. To avoid this, the
zone administrator may change the compromised key or all its keys as
soon as possible, without waiting for the creation of new DS RRs in
its parent zone.
Fast changes may break the chain of trust. The part of DNS tree
having this zone as apex can become unverifiable, but the break of
the chain of trust is necessary if the administrator wants to prevent
the compromised key from being used (to spoof DNS data).
Parent and child zones sharing an automated rollover mechanism,
should have an out-of-band way to re-establish a consistent state at
the delegation point (DS and DNSKEY RRs). This allows to avoid that
a malicious party uses the compromised key to roll the zone keys.
Guette & Courtay Expires July 19, 2005 [Page 5]
Internet-Draft Automated Rollover Requirements January 2005
6. Security consideration
The automated key rollover process in DNSSEC allows automated renewal
of any kind of DNS key (ZSK or KSK). It is essential that parent
side and child side can do mutual authentication. Moreover,
integrity of the material exchanged between the parent and child zone
must be provided to ensure the right DS are created.
As in any application using public key cryptography, in DNSSEC a key
may be compromised. What to do in such a case can be describe in the
zone local policy and can violate some requirements described in this
draft. The emergency rollover can break the chain of trust in order
to protect the zone against the use of the compromised key.
7. Acknowledgments
The authors want to thank members of IDsA project for their
contribution to this document.
8 Normative References
[1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
RFC 3658, December 2003.
[2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
(DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
RFC 3757, May 2004.
[3] Kolkman, O., "DNSSEC Operational Practices",
draft-ietf-dnsop-dnssec-operational-practice-01 (work in
progress), May 2004.
[4] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[5] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"Resource Records for the DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-11 (work in progress), October
2004.
[6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
2004.
[7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October
Guette & Courtay Expires July 19, 2005 [Page 6]
Internet-Draft Automated Rollover Requirements January 2005
2004.
Authors' Addresses
Gilles Guette
IRISA / INRIA
Campus de Beaulieu
35042 Rennes CEDEX
FR
EMail: gilles.guette@irisa.fr
URI: http://www.irisa.fr
Olivier Courtay
Thomson R&D
1, avenue Belle Fontaine
35510 Cesson S?vign? CEDEX
FR
EMail: olivier.courtay@thomson.net
Appendix A. Documents details and changes
This section is to be removed by the RFC editor if and when the
document is published.
Section about NS RR rollover has been removed
Remarks from Samuel Weiler and Rip Loomis added
Clarification about in-band rollover and in emergency section
Section 3, details about recursive cache servers added
Guette & Courtay Expires July 19, 2005 [Page 7]
Internet-Draft Automated Rollover Requirements January 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights.
Information on the IETF's procedures with respect to rights in
IETF Documents can be found in BCP 78 and 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights which may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr.org.
Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Guette & Courtay Expires July 19, 2005 [Page 8]