DNSOP WG Edward Lewis INTERNET DRAFT NAI Labs Category: I-D November 24,2000 Handling of DNS Zone Signing Keys Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Comments should be sent to the authors or the DNSOP WG mailing list dnsop@cafax.se. This draft expires on May 24, 2001. Copyright Notice Copyright (C) The Internet Society (1999,2000). All rights reserved. Abstract DNS Security Extensions require a greater interaction between zone administrations sharing a zone cut. The center of the interaction is the handling of the zone keys of the child and the signature applied by the parent. DNSSEC does not include a protocol for this, but the means of this interaction need definition to maintain the security of DNS. 1 Introduction DNS Security Extensions require a greater interaction between zone administrations sharing a zone cut. The center of the interaction is the handling of the zone keys of the child and the signature applied by the parent. DNSSEC does not include a protocol for this, but the means of this interaction need definition to maintain the security of DNS. The abstract having been repeated, the following caveats should be stated. This document is a work in progress. The draft is revised in response to lessons learned at various workshops held throughout the past two years. The workshops have been based on ISC's BIND versions 8 and 9. Section 2 of the document discusses the issues surrounding keys as they progress from generation to disposal. Section 3 discusses the interactions between a parent and child zone. Section 4 lists requirements for a protocol to carry out the steps described in Section 3. Note: I appologize for not being able to include most of the recent workshop results. Job duties have derailed me, but I am not able to return my attention to this effort. I will have a more extensively updated draft submitted after the San Diego meetings. 1.1 On-tree Validation "On-tree validation" refers to the signing of a child zone's (apex) KEY RR set by the parent zone's private key. The child zone would then publish the KEY RR set and the SIG (KEY) RR as generated by the parent. (See note in section 1.1.1.) This makes possible building a chain of trust by a resolver that is verifying an answer it received. The term "on-tree" refers to following the DNS domain hierarchy to reach a trusted key, presumably the root key if no other key is available. The term "validation" refers to the digital signature by the parent to prove the integrity, authentication and authorization of the child' key to sign the child's zone data. The term "off-tree validation" refers to the use of some domain name other than the parent zone to sign a child's KEY RR set. This ability has been suggested to be a desirable feature from time to time. However, securely accomodating off-tree validation is a hard problem. So, for this document, on-tree validation is assumed to be the only recognized model. More liberal validation models require more study. Starting with a more conservative model makes transitioning to more liberal models easier, the vice versa is not easy. 1.1.1 Where Are Keys Published? (only really new material in -03) During the development of DNSSEC, it has often been assumed that, given a secured parent and child zone, the child would publish it's keys and the parent would have the option to do so also. Later documents discouraged the parent zone from publishing the child's keys becuase of the chance of a conflict. Recent work at NLnet Labs (I hope this is the correct atribution) has suggested that perhaps the child shouldn't publish the keys and that the parent should. The reason for this suggestion was the observation of the sequence of events when a parent changes it's keys, resulting in a need to revalidate all child keys. If the parent is publishing the child's (public) keys, then the revalidation can happen smoothly, without the child having to be involved. However, the issue of the parent's liability in holding the child's key is raised. What if the child needs to change their keys suddenly, but the parent is not able to change what is published, resulting in a loss of service to the client? 2 Life Cycle of a Key Pair A key pair's lifetime begins with its generation and after a period of time the pair is disposed of. The reason for time-limiting keys is that, given enough time, any secret can become exposed, guessed or otherwise "broken." The challenge is to use a key pair for less time than is needed to "break" or "discover" its private component. There are three primary factors which determine the span of time a key pair is useable. One is the quality of the generation process. Truly random number generation and hard to derive numbers increase the useful life of a key pair. Another factor is the safety of the secret. The less is it used or placed in a vulnerable position, the longer it will be useful. Yet another factor in the so-called strength of the key pair is length, generally, the longer or bigger a key, the longer it takes to break or guess it. 2.1 Key Generation Generating a key is a simple operation with a proper tool, and DNSSEC tools are available for this. At this time, a key pair is requested that meets the definition of signing zone key pair. Issues for an administraitor at this this stage are the cryptographic algorithm and length of the keys. DNSSEC has four kinds of algorithms. One is mandatory-to-implement, which means that all DNSSEC compliant software (servers, resolvers) will be able to process the signature. (DSA is in this category.) Another category is standard, which means that there is a definition for the algorithm's use in DNSSEC, but for some reason there may be software that is unable to implement it. (RSA is in this category.) Oddly, the most efficient algorithm for DNSSEC is in the latter category. The other two categories are not options at this point. One is shared secret (HMAC-MD5) and the other category includes undefined algorithms. The meaning of the length of a key varies by algorithm. In general, the longer the key, the safer the pair is. However, as safety increases, speed of signing and verification drops. An administratot should weigh more frequent key generations and deletions against slower name resolutions when choosing a key length. 2.2 Public Key Validation Before a zone key pair can be useful, it must be validated by the parent zone. To be validated, the public key must be converted into a KEY RR, complete with a fully qualified owner name, time to live value and other settings. The new KEY RR has to be combined with any other KEY RR's comprising the key set owned by the zone's apex. Individual keys are not validated in DNSSEC, entire key sets are validated. To be validated, all of the keys to be held at the zone's apex are collected and send to the parent. The information sent is specificied in section 4, for now, consider the information to be equivalent to what would be in the on-the-wire format as send in response to a query. Until the response is received from the parent, the private key of the pair may be put into use, but any signatures resulting from the use will not be useful in DNSSEC validation. (They will be considered to be extra-DNSSEC or immaterial.) 2.3 Signing With Private Key A private key can be used to sign a zone after generation in parallel with getting the public key validated. But the signatures won't be of use until there is a validating signature over the KEY RR holding the public key. There are potentially three ways in which a zone private key can be put to use. One is to use the key in a non-server, or off-line, signer application. Another is to place the key in a dynamic update enabled server. Yet another, less common use, is in a trusted dynamic update client that an administrator trusts to properly sign data. 2.3.1 Non-Server Signing A non-server, signer application is a software process that accepts a zone master file and signs the data in it with one or more private keys, and produces a signed master file. In past DNSSEC documents, the connectivity of a machine running the process is significant. If the signer machine is not accessible to the network on which the data is served, the machine is said to be "off-line." The purpose for this is enhanced security of the private key. A break-in compromising the server holding the key is less likely if there is no way to remotely send even just IP traffic to it. Off-line signing is not a requirement for DNSSEC. An on-line signer is permitted, but then host security must be tightly maintained as the a compromise of crytptographic data is often hard to recover. As opposed to the destruction of some files that could be recovered from backups, exposed cryptographic data could, in the case of DNS, put the zone's data, and all delegated zone's data, at risk of being hijacked. Note that if off-line signing is practiced, the generation of keys should also be done on this machine, or another off-line machine. 2.3.2 Dynamic Update Signing A private key is needed in dynamic update to sign, at the least, new SOA records and NXT records. Updated (changed) data sets must be signed too. Dynamic update servers should be careful to keep the private key secret, including locking it into memory and practice good host security measures. The key must not be left in an exposed configuration file on disk unless the file is properly encrypted. The same comments apply to any dynamic update client entrusted to supply signed data. A wise system administrator will rarely make use of this feature. 2.4 Loading A New Zone Assuming the intent of putting a zone key into use is to make the zone secure to the world, the validated set of KEY RRs holding all the public keys belonging to the zone's apex must be included in the zone file. If a validating SIG (KEY) RR is not available, then the key set, and all sets signed in the zone will be considered unsecured to all but zones with preconfigured keys. 2.5 Removing a Key From Use Removing a key from use is as simple as removing the KEY RR pertaining to the public key from DNS. This renders all SIG RR's generated by the private key meaningless. There are a few considerations when it comes to removing the KEY RR though. Unless the removal of the KEY RR is in response to a security emergency (such as a suspected loss of secrecy of the private key), the private key's use should be terminated first. Cache's may hold SIG RR's up to the TTL, so usually, the KEY RR won't be pulled until the TTL time after the private key is pulled and ideally replaced. One other consideration is the impact that the removing the KEY RR is the impact on any delegated zones. If the KEY RR is used to validate child zone's keys, then as soon as the KEY RR is removed, the lower zones are no longer properly secured. 2.6 Steps in Performing a Key Rollover <> 3 Parent-Child Interactions As stated in the Introduction, on-tree validation is assumed, so all zone key validation will happen between parent and child. 3.1 New Delegation At the inception of a new zone, besides the traditional data exchange, the child should request validation for an initial set of zone keys. This action would be identical to that described in the next section, except that there may not be an initial NXT to modify. Since this is the first set of keys used by the child, the parent needs to be sure that the child is truly who they claim to be. There must be some out of band means used to authenticate the new zone administrator. Successive key sets can be installed using the first set's signature, so this authentication is a one-time but crucial step. The zone administrations should also make plans to handle "stolen" child keys. If a child zone's private key is exposed or stolen, the zone must be able to install new keys and have the parent sign them. The parent must authorize the child again to prevent zone jacking. <> 3.2 Child Initiated Validation The most efficient way to accomplish the validation of a zone is to require the child zone to make a request to the parent. This could be in response to the child's decision to change keys, to replace a broken key, or a notification from the parent that the parent has changed its keys. The child first has to assemble the entire set of KEY RR's that needs validation. The set must be fully specified, meaning that all fields in the RR must be supplied. In particular, the TTL's must be set, this has proven to be a problem in workshops. The child needs to decide the span of time over which the set is to be validated. A child need not wait until a set of keys is needed "now" to make a request. Consider the following example. A child zone decides to have a different zone key for each month of the upcoming year. The child also decides to publish just three of the keys at any one time - the key for the previous month (to validate data still being tossed around), the current key, and the key for the next month (in case the KEY set is cached somewhere beyond the end of the month). The child would then assemble 12 KEY RR sets, consisting of three of the keys at a time, and submit them for validation, one set per month. The child should also request the parent sign the keys using a set of particular algorithms. If the parent does not recognize any member of the set, that algorithm cannot be supplied. The parent should not return a key of an algorithm that is not requested. The request is then sent to the parent for validation. The security of this transfer is crucial to the safety of the keys and the entire DNSSEC process. The child must ensure that the request arrives with source integrity. The parent must be able to authenticate the request, that the request is from an authorized source. Non-reputability may be a desired feature. The parent's processing of the validation must not alter the set of keys submitted by the child. The parent must not add a NULL key if there is no zone key present. If a child submits a key set that has not zone signing KEY in it, then the child zone will remain unsecured. It is not the job of the parent to notice this, this is left to the resolvers. The parent should not sign any key sets belonging to any member of a child zone other than the apex. Other than the apex key set, the parent should not sign any data in the child zone. It is not the job of the parent to provide security for members of the child zone. After the SIG (KEY) RR for each KEY RR set to be validated is generated, the result is returned to the child. It is important that the child verify the signatures returned by the parent. If the signatures don't verify the appropriate key set, DNSSEC verification of the zone data will not succeed. 3.3 Parent Initiated Validation A parent can initiate a validation of a child as a by product of the parent's changing or revoking of its own keys. When a parent removes a key, all children that relied upon the key should be notified that they need to resubmit keys for validation, as decribed in the previous section. The means a parent uses to inform children is not specified here. Also, whether a parent notifies all children or just children impacted by the change in keys is not specified. The latter issue poses an interesting design decision. If a parent chooses to notify just the children impacted by the removal of a key, then the parent must retain the knowledge of which key is used to sign which child. As this sounds like an onerous burden, consider that the alternative is to notify all children when any key is removed, and suffer a mass revalidation. 3.4 Removal Of Delegation When a delegation is ended, data is removed from the parent. But one more step is needed, the keys signing the child zone may have to be removed also. This stops the child data from being authenticated, if the child zone servers are not stopped from answering queries. This is a consideraton only in a non-cooperative removal of a zone. If keys validating a delegation are removed, a "Parent Initiated Validation" will likely ensue. 3.5 Expiration Of A Validation When a SIG (KEY) RR generated by the parent for a child's key set expires, there is no requirement that either side act. The child may simply wish to revert to an unsecured state. A parent is under no obligation to make sure that the child zone's are properly operated. 3.6 Other Adjustments There is a scenario in which a child may want to have the parent indicate that the child does not have a set of validated keys. A child may discover a problem with the key set, such as the loss of the private keys (rm -f *) or the exposure of the keys to an untrusted party. In this case, the parent should have some means for the child to request a change in state. Note that the reverse transition is not necessarily desirable. A child should not be given the ability to claim that it has validated keys without the parent doing the signing. This draft assumes that on-tree validation is the only permitted model, and this is what drives the comment. Off-tree validation needs much further development before it can be accomodated in a secure manner. When such a model is used, then it might make sense for a child to request being identified as secured without submitting keys for validation. 4 Requirements on the Validation Process This section has not been complete yet. 4.1 Child Request For Validation 4.2 Parent Response to Child 4.3 Parent Notification Of Key Removal 4.4 Parent Data Retention 5 IANA Considerations This document does not place any requirements on the assigned numbers authority. 6 Security Considerations This entire document is a note on security considerations. If the zone key is mishandled, in a way that compromises its security, then the security of its zone is compromised. 7 References 8 Author's Address Edward Lewis 3060 Washington Rd (Rte 97) Glenwood, MD 21738 +1(443)259-2352 9 Acknowledgements The following individuals and groups have made significant input into the content of this document: the attendees of the NIC-SE work shop on DNSSEC, May 18 and 19, 1999, also Olafur Gudmundsson, and Brian Wellington. A second workshop held by the CAIRN research network September 29 and 30th also provided input to this document. Dan Massey has provided input based upon this workshop and experience with DNSSEC in CAIRN. More workshops are to be acknowledged... 10 Full Copyright Statement Copyright (C) The Internet Society (1999,2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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."