Network Working Group G. Guette Internet-Draft IRISA / INRIA Expires: February 5, 2005 D. Fort B. Cousin IRISA August 7, 2004 A generalization of Delegation Signer Resource Record (DS RR) use draft-guette-ds-generalization-00.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 January 7, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines a generalization of the DS RR use in order to reduce the number of secure entry points in a resolver and in order to create a secure link between islands of security. This allows to simulate a secure spanning tree among all secure zones and reduce the number of non secure name resolutions. Guette, et al. Expires February 5, 2005 [Page 1] Internet-Draft DS Generalization August 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The three ways to add a secure zone in the DNS tree . . . . . 3 2.1 The new secure zone is a leaf of an island of security . . 3 2.2 The new secure zone is the new apex of an island of security . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3 The new secure zone is a new island of security . . . . . 3 3. Influence of the three previous topologies on the name resolution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 The new secure zone is a leaf of an island of security . . 4 3.2 The new secure zone is the new apex of an island of security . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3 The new secure zone is a new island of security . . . . . 4 4. The DS resource record . . . . . . . . . . . . . . . . . . . . 4 4.1 DS RR wire format and its new use . . . . . . . . . . . . 4 5. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Authentication of a new secure zone and key rollover problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1 The key rollover problem . . . . . . . . . . . . . . . . . 5 7. Changes on the resolver's resolution algorithm . . . . . . . . 6 8. Security considerations . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 8 Guette, et al. Expires February 5, 2005 [Page 2] Internet-Draft DS Generalization August 2004 1. Introduction The DNS security extensions (DNSSEC) [5][2][1][3] uses public-key cryptography and digital signatures. It stores the public part of keys in DNSKEY Resource Records (RRs) and signatures in RRSIG RRs. In order to validate a resource record, a chain of trust is built from a secure entry point [4] to the RR queried. To allows the build of a chain of trust, a delegation signer (DS) RR [6] is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. Section 2 and 3 describe the different topologies induce by adding a new secure zone and their consequences. Section 4, 5 and 6 describe the new use of DS RRs and the algorithm to update/create these DS RRs. 2. The three ways to add a secure zone in the DNS tree When a DNS zone deploys DNSSEC, three cases can arise: o This zone becomes a new leaf of an existing island of security. o This zone becomes a new apex of at least one existing island of security. o This zone becomes a new island of security. 2.1 The new secure zone is a leaf of an island of security When a DNS zone deploys DNSSEC and becomes a leaf of an existing island of security, its parent zone must create and deploy the DS RR for this new secure delegation. 2.2 The new secure zone is the new apex of an island of security When a DNS zone deploys DNSSEC and becomes the new apex of an island of security (i.e., the new zone owns any delegation for an existing apex of an island of security), the new secure zone must create and store DS RR for all its secure delegated zones. 2.3 The new secure zone is a new island of security This topology appears when the new secure zone has no secure parent and no secure child zone. DS RR for this zone can not be created because the parent zone is not secure and the new secure zone does not create DS RR because it does not own any secure delegation. 3. Influence of the three previous topologies on the name resolution Guette, et al. Expires February 5, 2005 [Page 3] Internet-Draft DS Generalization August 2004 3.1 The new secure zone is a leaf of an island of security In this case, the new secure zone does not impact on the name resolution. Either resolvers have already a trust anchor for the apex of the island of security and the resolver can perform secure name resolution, or resolvers do not have a trust anchor for the apex of the island of security and they can not perform a secure name resolution. 3.2 The new secure zone is the new apex of an island of security In this case, the apex of the island of security changes and a resolver that wants to perform secure name resolution about the new secure zone must have a trust anchor for this new secure zone. Thus, the new secure zone should publish its public key on various media in order to notify administrators of resolvers that a new secure zone exists. A diffusion is needed. 3.3 The new secure zone is a new island of security The new secure zone is nor a leaf neither an apex of an island of security, this case is the creation of a new island of security. The new secure zone has no secure parent and no secure child. This zone becomes a new apex of an island of security and the diffusion of its public key is needed. 4. The DS resource record 4.1 DS RR wire format and its new use All information about the DS wire format can be found in the RFC 3658 [6], the DS RR stores in the parent zone some information allowing to identify a key of its secure child zone. In this document, we generalized the use of the DS RR, allowing a zone that has unsecure delegation(s) to store a DS RR that identifies a key of the apex of the next island of security in the subdomain of the unsecure delegation. Storing DS RR that identifies the apex of the next island of security, allows to simulate a complete DNSSEC tree containing all the existing secure DNSSEC zone. As a consequence, the number of trusted anchors in a resolver is reduced to the upper island(s) of security keys. 5. Algorithm In this section, we assume that the generalization of the DS RR is effective on all islands of security. The problem of authentication Guette, et al. Expires February 5, 2005 [Page 4] Internet-Draft DS Generalization August 2004 of the new secure zone is discussed in the next section. When a zone deploys DNSSEC, it firstly creates keys and signs its zone file and must contact its closest secure ancestor (CSA) in order to create DS RRs. Then, the CSA creates DS RR for this new secure zone and must transmit to the new secure zone all the DS RRs identifying keys of zones contained in the subdomain of the new secure zone, it owns. The new secure zone takes the transmitted DS RR and signs them to create secure delegations. If some of these delegations are already present in the new secure zone, this means that the new secure zone has become an apex of another island of security. A secure zone 'X' can store DS RR identifying a key of a non directly delegated zone 'Y' only if it does not exist a secure zone on the path between 'X' and 'Y'. 6. Authentication of a new secure zone and key rollover problem Authentication of a new secure zone is reduced to a DNSSEC bootstrap problem. When a zone becomes secure with DNSSEC there is no in-band way to authentify the key of this new zone. Authentication of the new secure zone, keys of the new secure zone and owner of the new secure zone must be done by the parent zone administrator with another method (X.509 certificates, phone call, meeting, etc.). The generalization of the DS RR use implies the generalization of this authentication. In all cases, the new secure zone must contact its CSA and the authentication of the new secure zone must be done by the CSA. Once the authentication is complete, the CSA can create DS RR(s) for the new secure zone. 6.1 The key rollover problem At the present time, when a zone creates a new KSK and has a secure parent zone, the parent zone must create appropriated DS RR(s). If its parent zone is not secured, no DS is needed. The generalization of DS RR use implies that a secure link exists between islands of security and their closest secure ancestor. Thus, when a zone creates a new KSK, this zone must notify its closest secure ancestor. If the zone is inside an island of security (not the apex), the CSA is its parent zone. If a secure zone has no CSA, no DS can be created for this secure zone and no action is needed. This is the case for the root zone. Guette, et al. Expires February 5, 2005 [Page 5] Internet-Draft DS Generalization August 2004 7. Changes on the resolver's resolution algorithm Currently, a resolver begins a name resolution from a secure entry point and follows the delegations to the resource queried. If there is an unsecured delegation on the path the name resolution is unsecured. With the generalization of DS RR use, this case does not exit anymore. A resolver follows the delegations, if a delegation is unsecure the resolver continues until the next secure zone is found. Then, the resolver asks for a DS RR for this zone, the DS RR is stored in the CSA, the resolver validates the key with this DS and continues the name resolution until to find the RR queried. 8. Security considerations This document describes a generalization of the DS RR use. This generalization ensures that all signatures of resource records contained in a secure zone can be verified if the resolver trusts only the apex of the highest island of security. If the root zone is secured, only the root zone key is needed. 9 Normative References [1] Arends, R., "Resource Records for the DNS Security Extensions", July 2004. [2] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, "DNS Security Introduction and Requirements", July 2004. [3] Arends, R., "Protocol Modifications for the DNS Security Extensions", July 2004. [4] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, May 2004. [5] Eastlake, D., "Domain Name System Security Extensions", March 1999. [6] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", December 2003. Guette, et al. Expires February 5, 2005 [Page 6] Internet-Draft DS Generalization August 2004 Authors' Addresses Gilles Guette IRISA / INRIA Campus de Beaulieu 35042 Rennes CEDEX FR EMail: gilles.guette@irisa.fr URI: http://www.irisa.fr David Fort IRISA Campus de Beaulieu 35042 Rennes CEDEX FR EMail: david.fort@irisa.fr URI: http://www.irisa.fr Bernard Cousin IRISA Campus de Beaulieu 35042 RENNES CEDEX FR EMail: bernard.cousin@irisa.fr URI: http://www.irisa.fr Guette, et al. Expires February 5, 2005 [Page 7] Internet-Draft DS Generalization August 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. Guette, et al. Expires February 5, 2005 [Page 8] Internet-Draft DS Generalization August 2004 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, et al. Expires February 5, 2005 [Page 9]