390 lines
15 KiB
Plaintext
390 lines
15 KiB
Plaintext
|
|
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]
|