DNSOP WG D. Massey, UCLA INTERNET DRAFT T. Lehman, ISI Category: I-D E. Lewis, NAI Labs October 20, 1999 DNSSEC Implementation in the CAIRN Testbed. 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 April 20, 2000. Copyright Notice Copyright (C) The Internet Society (1999). All rights reserved. Abstract This draft describes the operational and administrative considerations encountered as part of the migration from a traditional Domain Name Service (DNS) infrastructure to one based on DNS Security (DNSSEC). The information presented in this draft is based on the implementation of DNSSEC in the Collaborative Advanced Inter-agency Research Network (CAIRN) testbed. CAIRN is a DARPA funded testbed used by Government, University, and Commercial researchers to conduct Internet Protocol (IP) network based research. Additional information on the CAIRN testbed is available at http://www.cairn.net. Details on the DNSSEC implementation in CAIRN can be found at http://www.cairn.net/DNSSEC. It is envisioned that the information presented in this draft can be used as a starting reference for sites interested in deploying DNSSEC. It is also hoped that reporting on the experience of CAIRN DNSSEC implementation will provide a forum for general discussions regarding DNSSEC implementation. Expires April 20, 2000 [Page 1] Internet Draft October 20, 1999 TABLE OF CONTENTS 1. INTRODUCTION.............................................2 1.1 Misc. Notes..........................................3 2. ARCHITECTURE AND IMPLEMENTATION OBJECTIFIES..............3 2.1 Architecture.........................................3 2.2 Implementation Objectives............................4 3. KEY GENERATION AND MANAGEMENT............................5 4. ZONE FILE SIGNING........................................7 4.1 Zone File Signing Security Considerations................8 5. SUB-ZONE ADMINISTRATION..................................8 5.1 Administration of Unsecure Sub-Zones.................9 5.2 Administration of Secure Sub-Zones..................10 5.3 Incremental Deployment Policies.....................11 5.3.1 Signatures for cairn.net Keys...................11 5.3.2 Secure Sub-Zones with Unsecure Parent Zones.....12 5.4 Trusted Keys and Key Chaining.......................12 6. OPERATIONAL SCENARIOS...................................13 6.1 Operations in an Unbroken Tree......................13 6.2 Operations in an Broken Tree (Unsecured Parent).....14 6.3 A Key Forgery Attempt...............................15 6.4 Operations in a Mixed Key Algorithm Tree............17 7. IMPLEMENTATION IN THE GENERAL INTERNET..................18 8. SUMMARY AND FUTURE EXPERIMENTATION AREAS................20 1 INTRODUCTION The DNS Security Extensions (RFC 2535) provide a mechanism for authenticating DNS responses. Authentication is accomplished by including digital signatures in the response sent by DNSSEC aware name servers. RFC 2535 describes the DNSSEC extensions in detail. Deploying DNSSEC requires new operational duties related to key generation, zone file signing, and key management. This draft describes the operational and administrative changes encountered when migrating from traditional DNS to DNSSEC. Section 2 describes the DNSSEC architecture of CAIRN as well as the objectives for the DNSSEC implementation. Section 3 describes the procedures and issues associated with key generation. Section 4 describes the procedures and issues associated with zone file signing. Section 5 describes the procedures and issues associated for submitting keys to a parent zone for signature and creating a secure sub-zone. Section 6 presents some operational scenarios. Section 7 concludes with a discussion of incremental deployment and mechanisms to facilitate implementation in the general Internet. Section 8 discusses open issues and areas of interest for future testing within CAIRN. The operational changes described in this draft are based on experience gained by deploying DNSSEC in the CAIRN network. It is expected that the operational procedures described here will change as the DNSSEC specification evolves and more operational experience is gained. Expires April 20, 2000 [Page 2] Internet Draft October 20, 1999 Feedback from other sites who have deployed (or are planning to deploy) DNSSEC is strongly encouraged. 1.1 Misc. Notes The deployment described here does not address the use of dynamic updates. This draft includes the use NXT records for purely pragmatic reasons. The use of NXT records is still being debated and some feel strongly that NXT records should not be included in DNSSEC. NXT records are used here since the current DNSSEC specification uses NXT records and the DNSSEC tools distributed with BIND generate NXT records. This draft will focus on the operational and implementation considerations associated with the DNSSEC implementation in CAIRN. It will not attempt to include detailed background on DNSSEC, except for that necessary to discuss the issues contained in this draft. The reader is referred to other RFCs and Internet Drafts for more detailed treatment of DNSSEC in general. These include but are not limited to: Domain Name System Security Extensions (RFC 2535) Handling of DNS zone signing keys DNS Security Operational Considerations (RFC 2541) 2 ARCHITECTURE AND IMPLEMENTATION OBJECTIVES 2.1 Architecture The CAIRN testbed has administrative control via delegation from the root name servers for the following zones: cairn.net, 173.140.addr.arpa, and a.1.e.f.f.3.IP6.INT. The root servers delegate the cairn.net zone to the following name servers: lila.east.isi.edu, ns.isi.edu, and flag.ep.net. The master name server is lila.east.isi.edu. The other two name servers are slaves. At this time only the cairn.net zone and other sub-zones within that hierarchy are implemented as secure zones. There are approximately 30 delegated sub-zones within cairn.net. Some of these delegations are implemented as secure sub-zones, others are not secure. There are also numerous secondary name servers for the cairn.net zone. Since this is a research network the the configuration of the delegated sub-zones and their secure status changes depending on current network activity. For this reason a detailed description of the current CAIRN DNS architecture is not presented here. However, the interested reader is encouraged visit http://www.cairn.net/DNSSEC for the latest configuration and implementation status. The DNSSEC implementation in CAIRN is based on the versions of BIND available via Internet Software Consortium (ISC). Expires April 20, 2000 [Page 3] Internet Draft October 20, 1999 2.2 Implementation Objectives Detailed descriptions of the administrative tasks associated with creating and maintaining a secure zone are presented in subsequent sections of this draft. These tasks are organized as shown below. i) generation of "zone keys" (described in Section 3) ii) signing of the zone file (described in Section 4) iii) signing zone keys and administering delegations (described in Section 5) The main administrative burden is expected to be the activities associated with item iii above. Upon generation of zone keys, a secure zone must have its public key signed by an appropriate authority. The appropriate authority is usually the parent or delegation point for the zone. This requirement will impose burdens on both the zone which is configuring itself for DNSSEC, as well as the parent for that zone. The implementation objectives for DNSSEC in CAIRN are as follows: I) Minimize the impact on a "parent" zone file in terms of modifications required due to a change in the secure status or configuration of a sub-zone. The desire is that a "parent" zone file should not have to be modified if a delegation point changes its secure status, generates new keys, or makes any other changes to its configuration which would not require a parent zone file modification in the traditional DNS implementations. It is felt that the interaction between a parent and child should be constrained to off-line signature of the child's keys by the parent. Changes in child's keys should not require a resigning of the parent's zone file. In order to accomplish this, the parent zone file will contain the same information it does today regarding delegation points. This limits the information contained in the parent zone file to the sub-zone name and the name servers which serve that zone. Key information for sub-zones would not be included in the parent zone file under this scenario. II) Provide mechanisms which allow for non-contiguous secure zone space. It is expected that initial implementations of DNSSEC will result in a DNS hierarchy which has a mix of secure and non secure zones. In addition, it is further anticipated that within the DNS tree, the secure zone space will be be non-contiguous. It is desired that there be mechanisms that allow an "island" of secure DNS hierarchy to exist and still be able to provide secure name resolution for those name servers and application resolvers which are adequately configured. It is envisioned that the "parent" signing hierarchy Expires April 20, 2000 [Page 4] Internet Draft October 20, 1999 must be allowed to deviate from the general DNS hierarchy to accommodate this. The approach taken for the CAIRN DNSSEC implementation to accomplish these two objectives is presented in subsequent sections of this draft. Specific example scenarios are presented in section 6. 3 KEY GENERATION AND MANAGEMENT Prior to DNSSEC, there were no DNS keys to manage. DNSSEC adds new requirements for creating and managing zone keys. DNSSEC authentication is based on the use of public/private zone keys. A zone creates public/private key pairs. The private key is known only by the zone and is used to sign the zone records. The public key is made widely available by placing it in a KEY record. Resolvers who trust the public key can verify signatures and authenticate records received from the zone. Generating new keys is a simple process that can be done with standard tools such as the dnskeygen tool included with BIND distribution. Keys may be generated for several different algorithms. In CAIRN, a DSA key is mandatory and must be created and an RSA key is optional. A zone decides which algorithms it will support and generates the corresponding key pairs. A crucial task for a DNSSEC zone is keeping private keys private and insuring that key pairs expire in a reasonable time. An attacker can forge DNSSEC data if he either gains access to a private key or reconstructs a private key via cryptoanalysis techniques. To provide reasonable security, each public/private key pair should periodically expire and be replaced. The recommended lifetime for key pair is dependent on both the key size and the algorithm. The key pair should be immediately discarded if the private key is believed to have been compromised. Once a site has chosen its algorithms and generated its zone key pairs, the public version of each key is placed in a KEY record. The set of KEY records must be signed and then placed in the zone's master file. Note that common tools such as dnskeygen automatically create the KEY record. CAIRN generates the following keys for the cairn.net zone: cairn.net master DSA key - this key is expected to remain unchanged for an extended period of time. It will be generated using the DSA algorithm. Its operational purpose is to sign other keys. The public portion of this key is what will be distributed to all other name servers as the top level key. This key represents the key that in a true "production" environment would require the most strict security measures to ensure it was not compromised. cairn.net master RSA key - similar to the master DSA key. cairn.net zone signing key 1 - this key will be changed more frequently than the master key. It will be generated using the Expires April 20, 2000 [Page 5] Internet Draft October 20, 1999 DSA algorithm. Its operational purpose is to sign the cairn.net zone file. cairn.net zone signing key 2 - this key will be changed more frequently than the master key. It will be generated using the RSA algorithm. Its operational purpose is to sign the cairn.net zone file. The CAIRN testbed uses the dnskeygen program which is included with the BIND distribution. The following examples shows how a DNSSEC key is generated for the cairn.net zone: dnskeygen -D 768 -z -c -n cairn.net -D defines the key algorithm to be DSA -z indicates a zone key is being generated -c indicates the key cannot be used for encryption -n sets the keys name The output of this program would be two files which contain the public and private parts of the key. The file names will be of the form: Kcairn.net.+X+Y.key -public portion of key Kcairn.net.+X+Y.private -private portion of key where X indicates the algorithm type and Y is the footprint of the key. Once the keys are generated, the public portion of the zone keys are included in the zone file in the form of a KEY record. A single file is created for this purpose which combines the contents of all the Kcairn.net.+X+Y.key files into a single file named cairn.net.keys. Its contents will be of the following form: cairn.net. TTL IN KEY flags algorithm protocol key_value cairn.net. TTL IN KEY flags algorithm protocol key_value cairn.net. TTL IN KEY flags algorithm protocol key_value Creating the key file is currently a manual process, but a script to automatically assemble a key file is being investigated. The key generation and management procedures and decisions for sub-zones are expected to differ from those described above for the cairn.net zone. The CAIRN administrative philosophy is that sub-zones are should be free to determine the key algorithms, numbers, and lifetimes as required to meet their operational and administrative needs. However, due to implementation issues described in section 5, CAIRN currently allows only RSA and DSA keys. Now that once the zone keys are generated, administrative activities can continue with signing of the zone file. Expires April 20, 2000 [Page 6] Internet Draft October 20, 1999 4 ZONE FILE SIGNING Prior to DNSSEC, a change in the local DNS data required an administrator to edit resource records in the master file, update the SOA entry, and refresh the zone. DNSSEC adds two new operations: resigning the zone file and updating the NXT records. After editing the resource records and updating the SOA, an administrator must sign the changed (or new) records with the zone keys and update the appropriate NXT records. Signing the changed records with the zone keys will produce the SIG records. A signed zone file should include one SIG record per zone key. The SIG record contains the digital signature and related information which can be used to authenticate the data. The NXT records are also stored in the zone file. The NXT records in a zone create a chain of all of the literal owner names in that zone and provide a mechanism to indicate which the data is not present in the zone file. NXT records require that the records in a zone file be placed in a canonical order. A NXT record specifies that there are no records between two ordered records in the zone file. The dnssigner tool provided with the BIND distribution automatically orders the zone file and generate the NXT records. In order to create a signed zone file, a typical zone file is created. A portion of a cairn.net zone file may be as shown below: _______ $ORIGIN cairn.net. @ 86400 IN SOA lila.east.isi.edu. root.lila.east.isi.edu. ( 1999101801 ;serial number 3600 ;refresh time (60 min) 300 ;retry time (5 min) 604800 ;expire time (1 week) 86400 ) ;minimum time (1 day) @ 86400 NS lila.east.isi.edu. @ NS ns.isi.edu. @ NS flag.ep.net. $INCLUDE /etc/named/keys/cairn.net.keys localhost 86400 A 127.0.0.1 loghost CNAME localhost.cairn.net. loopback CNAME localhost.cairn.net. ;misc addresses www A 38.245.76.15 loon A 38.245.76.29 . . . ______ Expires April 20, 2000 [Page 7] Internet Draft October 20, 1999 The only unique item at this point is the inclusion of the cairn.net zone KEY records via use of the INCLUDE statement. The CAIRN testbed uses the dnssigner program which is included with the BIND distribution to sign this zone file as shown below: dnssigner -ess -zi cairn.net -zo s_cairn.net -ks cairn.net 001 footprint cairn.net 003 footprint -ess tells dnssigner to have each private key sign the other public keys. The objective here is to have the cairn.net master key sign the cairn.net zone signing key 1 and key 2. -zi identifies the unsigned input zone file -zo specifies the name of the output file which will contain the SIG and NXT records -ks indicates that there are multiple keys to sign the zone with. The actual keys are specified following this command line switch by identifying the algorithm and footprint. The files containing these keys must be present in the same location from which the dnssigner program is being run. The output of the above command will be a zone file with SIG and NXT records. For the CAIRN configuration all records in the original unsigned zone file will be signed by the cairn.net zone signing key 1 and the cairn.net zone signing key 2. In addition the cairn.net zone signing key 1 and the cairn.net zone signing key 2 will be signed by the cairn.net master keys. 4.1 Zone File Signing Security Considerations Signing the zone requires simultaneous access to both the private keys and the modified zone file. The zone file resides on the primary name server. However, keeping the private keys on the primary name server is not recommended. In an ideal scenario, the private keys are kept off-line. This adds the additional administrative burden of transferring the zone file to location of the private keys and then transferring the signed file back to the primary server. Care must also be taken to insure that the signatures are given the proper expiration dates. A signature expiration date should be no later then the anticipated expiration date for the corresponding public key. It is expected that different keys will have different lifetimes. 5 SUB-DOMAIN ADMINISTRATION Prior to DNSSEC, a zone only stored the name servers associated Expires April 20, 2000 [Page 8] Internet Draft October 20, 1999 with its sub-zones. Interaction between a zone and a sub-zone was required only if the sub-zone changed name server locations. DNSSEC requires a much higher degree of coordination between a zone and its sub-zones. The increased coordination is a result of key exchanges and key signing that must occur between a zone and its sub-zones. Keys change frequently, at least once a quarter in CAIRN, and key exchanges between a zone and is sub-zones must be done in secure fashion. This secure key exchanges requires a new style of interaction between a zone and its sub-zone. The CAIRN administrative philosophy is to minimize the interaction between zones and sub-zones as much as possible and to allow for the incremental deployment of DNSSEC. To accomplish this, a CAIRN zone stores only its own KEY records. A zone does not store any keys which belong to any of its sub-zones and does not generate any keys on behalf of any sub-zones. These rules insure that any change in a sub-zone never require a corresponding change in the parent's zone file. RFC 2535 requires one exception to this policy with respect to NULL keys for a unsecure sub-zone. Section 5.1 describes the CAIRN policy for unsecure sub-zones and the exception. Section 5.2 describes the policy for secure sub-zones. Incremental deployment issues and key chaining across an are discussed in sections 5.3 and 5.4, respectively. 5.1 Administration of Unsecure Sub-zones. The CAIRN policy is that a zone is responsible for only its own KEY records. A zone is not responsible for holding or generating KEY records on behalf of any other zone. However to comply with RFC 2535, one exception must be made in this policy. If a sub-zone is completely unsecure, then the parent zone must generate a NULL DSA KEY and a NULL RSA KEY for its unsecure sub-zone. These NULL keys are stored in the parent zone. No communication with the sub-zone is required. The NULL KEYS should have no expiration dates and require no further administration by the parent (other than periodic signing which should automatically occur whenever other records in the parent's zone file are signed). A sub-zone can switch to secure status by notifying its parent. Once a sub-zone notifies it parent, the parent removes the NULL keys and the parent assumes no further responsibility for the security status of the sub-zone. The CAIRN policy of not generating or storing KEYs for the sub-zone comes back into effect. A sub-zone can switch back to unsecure status by generating and storing its own NULL KEYs. By generating its own NULL KEYs, a sub-zone can change its own security status without requiring a change at the parent zone. If a domain switches to unsecure and has no plans to return to secure status, then the sub-domain may request the parent resume generating and storing NULL KEYs on behalf of the sub-domain, but this results in changes to the parent's zone file is discouraged. As part of our experimentation we will be considering the best way to generate and store NULL keys. However, based on our activities to date there are concerns that requiring a parent to maintain null keys Expires April 20, 2000 [Page 9] Internet Draft October 20, 1999 and assume a degree of responsibility for a child domain for which it does not administer is not recommended. It is felt that this will impose too great a burden on a parent domain and will hinder an incremental implementation of DNSSEC in the Internet. We request further clarification on the NULL KEY in the DNSSEC specification and seek advice for handling the following three problem scenarios. First, consider the problem of a secure sub-domain which later becomes unsecure. After some time, a secure sub-domain fails to send any KEY records to the parent for signing. The sub-domain has only KEY records with expired SIGs from the parent or the sub-domain has simply stopped using DNSSEC and has no KEYs or SIGs. Given the experimental research nature of CAIRN, this scenario will occur. Is it the responsibility of the parent to declare the sub-domain unsecure and generate new NULL keys on behalf of the sub-domain? What responsibilities does a parent have in insuring a secure sub-domain really is secure? If the parent has no responsibility, is a NULL key at the parent still a meaningful concept? Second, consider a conflicting view of a sub-domain's security status. Zone sec.nosec.cairn.net is secure, but nosec.cairn.net had not implemented DNSSEC. To overcome this, the domain sec.nosec.cairn.net has its KEY set signed by cairn.net. However, later nosec.cairn.net implements DNSSEC and mistakenly assumes its sub-domains are unsecure. There are now valid keys for sec.nosec.cairn.net which are signed by cairn.net. There are also NULL keys for sec.nosec.cairn.net which are signed by its parent domain, nosec.cairn.net. How should resolvers treat the domain sec.nosec.cairn.net? If both a parent and sub-domain get decide whether the sub-domain is secure, who is right if they disagree? Third, given the multiple key types available, which NULL keys must be generated by a parent? Suppose domain.cairn.net defines a local algorithm type of 253. Zone sub.domain.cairn.net also defined a DIFFERENT local algorithm type of 253. Should domain.cairn.net generate a NULL key for its child? If so, what does this NULL key mean given that the child does have a KEY for a type 253 algorithm? If the parent does not generate a NULL KEY for type 253, doesn't this incorrectly imply the sub-domain understands the parent's algorithm 253? How are NULL KEYs applied to local algorithms? 5.2 Administration of Secure Sub-Zones A domain declares itself secure by notifying its parent and sending keys to the parent for signing. A domain is responsible for insuring that its KEY set is signed by its parent at the appropriate times. The domain should send new KEY sets whenever the SIG records from the parent expire or whenever the domain generates new KEY records. The parent may impose limitations on the frequency of KEY set signing and the domain must provide an emergency contact who can be reached if a key set is believed to be compromised. Key signing is currently accomplished by an off-line exchange of keys. A sub-domain sends a set of fully specified KEY records to Expires April 20, 2000 [Page 10] Internet Draft October 20, 1999 the parent domain. The parent domain signs the KEY set, exactly as reported by the sub-domain. The sub-domain must insure that the KEY set has the appropriate TTL values and contains any NULL KEY records if desired. The parent domain simply signs whatever records its receives. The parent is strictly forbidden from making any modification to the KEY record set. The resulting SIG records are returned to the sub-domain. Once the SIG records are returned, the parent should discard the KEY set and SIG records. No changes are made to the parent's zone file. After receiving the SIG records from its parent, a sub-domain must check each SIG record before adding the SIG record to the zone file. A sub-domain must discard a SIG record if the signature does not match the original KEY set or if the sub-domain does not implement the algorithm used to create the SIG. After the off-line KEY exchange and SIG verification is complete, the sub-domain stores its KEY record set and the accepted SIGs in its zone file. Administrative issues related to NULL keys and multiple key algorithms are addressed by administrative policies. By administrative fiat, secure CAIRN domains are required to generate DSA zone keys. This insures that every sub-domain will receive at least one signature which it understands and can verify. CAIRN zones may also optionally chose to generate RSA zone keys. A zone which chooses not to generate an RSA key must generate a NULL KEY for the RSA algorithm. This implies that the KEY set sent to a parent must consist of either DSA and RSA key records or DSA key records and a NULL RSA KEY record. Until further clarifications in the DNSSEC specification are made, additional algorithms are not allowed (see section 6.4 for an example of the problem). CAIRN eventually hopes to allow any algorithm type, including locally defined algorithms. 5.3 Incremental Deployment Policies Additional administrative problems are expected to arise during the incremental deployment phase of DNSSEC. In both CAIRN and the general Internet, not all domains can be expected to deploy DNSSEC simultaneously. Some domains will find their parent does not support DNSSEC and is unable to sign the KEY record set. Currently the net. domain is unable to sign the cairn.net. KEY set. Within CAIRN, a domain such as sec.nosec.cairn.net may deploy DNSSEC, but its parent domain nosec.cairn.net may choose not to deploy DNSSEC. CAIRN has adopted the administrative polices described below in order to handle these scenarios. 5.3.1 Signatures for cairn.net Keys CAIRN maintains a master key and suggests that all CAIRN domains include this master key in their trusted key list. This universally trusted master key is used to sign the cairn.net zone keys. It is expected that master key will be kept highly secure and will change infrequently. The cairn.net zone keys expire on a quarterly basis. Secure resolvers should agree to trust any cairn.net KEY Expires April 20, 2000 [Page 11] Internet Draft October 20, 1999 records that are covered by a valid SIG from the master key. Any change in the master key would require reconfiguring the trusted key list of all CAIRN domains. This policy is based on the DNSSEC approach of configuring a master root key for the DNS tree. In the proposed fully deployed DNSSEC tree, a master key would be trusted by all domains and used to sign the DNS root keys. The CAIRN master key is designed to imitate the actions of this proposed master root key. The proper use of a master key is still a subject of debate within CAIRN. 5.3.2 Secure Sub-Zones with Unsecure Parent Zones It is also expected that a CAIRN domain such as sec.nosec.cairn.net may deploy DNSSEC, but the parent nosec.cairn.net may be unsecure. If a sub-domain is unable to obtain KEY set signatures from its parent, the sub-domain may send its KEY set to cairn.net for signing. Secure resolvers should adopt a corresponding policy and agree to trust any zone which is signed by either a parent key or a cairn.net key. This policy is designed to insure that key chaining can succeed between any two secure domains in CAIRN. The proper approach to handling unsecure parent domains and the overall approach to the DNS key hierarchy is still a subject of debate within CAIRN. 5.4 Trusted Keys and Key Chaining The CAIRN key signing policies are designed to insure that key chaining will work within the CAIRN portion of the DNS. To obtain a secure DNS record from CAIRN, a resolver should adopt the following policy for learning zone keys: 1) statically configure the CAIRN master key as a trusted key 2) trust any cairn.net KEY with a valid SIG from the CAIRN master 3) trust any domain.cairn.net KEY with a valid SIG from a trusted cairn.net KEY 4) trust any sub.domain.cairn.net KEY with either a valid SIG from a trusted domain.cairn.net key or a valid SIG from a trusted cairn.net key Section 6.3 describes a potential forged KEY attack that can occur if the guidelines are not followed. CAIRN is interested in inter-operation and key chaining with other portions of the DNS tree. If all sites deployed DNSSEC, one approach could be to trust any root key signed by the DNS master and trust any zone key which is signed by its parent. However, it is unlikely that universal deployment of DNSSEC will be achieved quickly. The current CAIRN key chaining policy attempts to overcome problems due to incremental deployment. This approach clearly does not scale and is presented as starting point for further discussion. CAIRN is currently investigating key chaining between CAIRN and other portions of the DNS tree. Expires April 20, 2000 [Page 12] Internet Draft October 20, 1999 6 Operational Scenarios This section provides examples scenarios for DNSSEC operations within the CAIRN domain. All the examples assume a resolver requests the A record set for the host hostx.secure.isie.cairn.net. It is assumed the resolver knows how to obtain the proper A records, KEY records, and SIG records. The scenarios describe how these records are used to authenticate the result. In the first scenario, an unbroken tree of DSA and RSA is assumed. In the second scenario, the tree is broken by a domain which does not implement DNSSEC. The third scenario considers a forged key attack and describes why a resolver must be aware of the CAIRN signing policy. The fourth scenario considers an example where some domains do not implement the RSA algorithm. The fourth scenario is currently unworkable, addressing this problem appears to introduce either security holes or scaling problems related to key signing and resolver rules. 6.1 Operations in an Unbroken Tree. In the simplest operational scenario, each zone has a KEY set with both an RSA and DSA. Each KEY set is signed by both the RSA and DSA key from the zone's parent. The top level zone KEY set, cairn.net, is signed by the both the RSA and DSA master key. The DSA and RSA master keys are trusted by a resolver. --------------------- --------------------- |cairn.net | | resolver | | DSA KEY | | implements DSA | | RSA KEY | | implements RSA | | SIG by DSA master | | trusts RSA master | | SIG by RSA master | | trusts DSA master | --------------------- --------------------- | query for A records of ------------------------ hostx.secure.isie.cairn.net |isie.cairn.net | | DSA KEY | | RSA KEY | | SIG by DSA cairn.net | | SIG by RSA cairn.net | ------------------------ | ------------------------------- |secure.isie.cairn.net | | DSA KEY | | RSA KEY | | SIG by DSA isie.cairn.net | | SIG by RSA isie.cairn.net | ------------------------------- We assume the resolver has obtained the A record set for hostx.secure.isie.cairn.net and also received the two SIG records, one SIG generated by the DSA key from secure.isie.cairn.net and Expires April 20, 2000 [Page 13] Internet Draft October 20, 1999 one SIG generated by the RSA key from secure.isie.cairn.net. After obtaining the necessary KEY records and corresponding SIGs, the resolver can return either an DSA authenticated answer or an RSA authenticated answer. If the resolver knew the trusted DSA for secure.isie.cairn.net, the resolver could verify the DSA SIG which covers the A records. The resolver must learn the RSA key for secure.isie.cairn.net. The resolver obtains the KEY set for secure.isie.cairn.net and its corresponding SIGS. The DSA SIG covering this KEY set indicates that it was generated by the isie.cairn.net DSA KEY. Under CAIRN policies, isie.cairn.net has authority to sign KEY sets for the domain secure.isie.cairn.net. The resolver must now learn the DSA for isie.cairn.net. The resolver obtains the KEY set for isie.cairn.net and its corresponding SIGS. The DSA SIG covering this KEY set indicates that it was generated by the cairn.net DSA KEY. Under CAIRN policies, cairn.net has authority to sign KEY sets for the domain isie.cairn.net. The resolver must now learn the DSA for cairn.net. The resolver obtains the KEY set for cairn.net and its corresponding SIGS. The DSA SIG covering this KEY set indicates that it was generated by the cairn.net master DSA KEY. Under CAIRN policies, the cairn.net master has authority to sign KEY sets for the domain cairn.net. The resolver is configured to trust the master for key for cairn.net and can no begin checking SIGs. The resolver uses the trusted master DSA key for cairn.net and checks the DSA SIG record covering the KEY set for cairn.net. Once the KEY set for secure.isie.cairn.net has be authenticated, the resolver can trust the DSA key for cairn.net and use this DSA key to verify the KEY set for isie.cairn.net. The DSA SIG record authenticates the isie.cairn.net KEY set and the trusted DSA KEY for isie.cairn.net is obtained. The isie.cairn.net DSA KEY checks the DSA SIG record covering the secure.isie.cairn.net KEY set and the secure.isie.cairn.net DSA key is obtained. Finally, the secure.isie.cairn.net DSA key is used to verify the DSA SIG covering the A records for hostx.secure.isie.cairn.net. A similar process allows the resolver to authenticate the A records set using RSA keys and RSA SIG records. 6.2 Operations in an Broken Tree (Unsecured Parent Zone). In this operational scenario, the cairn.net and secure.isie.cairn.net zones have KEY sets with both an RSA and DSA keys. The isie.cairn.net zone has not deployed DNSSEC and there no KEY records associated with isie.cairn.net. The secure.isie.cairn.net domain will follow the CAIRN guidelines and have its KEY set signed by cairn.net. The DSA and RSA master keys are again trusted by a resolver. Expires April 20, 2000 [Page 14] Internet Draft October 20, 1999 --------------------- --------------------- |cairn.net | | resolver | | DSA KEY | | implements DSA | | RSA KEY | | implements RSA | | SIG by DSA master | | trusts RSA master | | SIG by RSA master | | trusts DSA master | --------------------- --------------------- | query for A records of ------------------------ hostx.secure.isie.cairn.net |isie.cairn.net | | no DNSSEC | ------------------------ | ------------------------------- |secure.isie.cairn.net | | DSA KEY | | RSA KEY | | SIG by DSA cairn.net | | SIG by RSA cairn.net | ------------------------------- We assume the resolver has obtained the A record set for hostx.secure.isie.cairn.net and also received the two SIG records, one SIG generated by the DSA key from secure.isie.cairn.net and one SIG generated by the RSA key from secure.isie.cairn.net. After obtaining the necessary KEY records and corresponding SIGs, the resolver can return either an DSA authenticated answer or an RSA authenticated answer. If the resolver knew the trusted DSA for secure.isie.cairn.net, the resolver could verify the DSA SIG which covers the A records. Again the resolver must learn the RSA key for secure.isie.cairn.net. The resolver obtains the KEY set for secure.isie.cairn.net and its corresponding SIGS. The DSA SIG covering the KEY set indicates that it was generated by the cairn.net DSA KEY. Under CAIRN policies, this is acceptable. The cairn.net domain is authorized to sign any of its lower domains. The resolver obtains the cairn.net DSA in the same manner described in example 6.1. Once the resolver trusts the DSA key for cairn.net, the KEY set for secure.isie.cairn.net can be verified using the DSA SIG record generated by cairn.net. Once the KEY set for secure.isie.cairn.net has be authenticated, the resolver can trust the DSA key for secure.isie.cairn.net and use this DSA key to verify the SIG record covering the A records. 6.3 A Key Forgery Attempt In this example, the domain faulty.cairn.net has been comprised. The attacker creates false KEY set for secure.isie.cairn.net and signs this false KEY set using the compromised private keys Expires April 20, 2000 [Page 15] Internet Draft October 20, 1999 from faulty.cairn.net. The resolver must rely on the CAIRN administrative signing policies to prevent this attack. --------------------- --------------------- |cairn.net | | resolver | | DSA KEY | | implements DSA | | RSA KEY | | implements RSA | | SIG by DSA master | | trusts RSA master | | SIG by RSA master | | trusts DSA master | --------------------- --------------------- | query for A records of ------------------------ hostx.secure.isie.cairn.net |faulty.cairn.net | | DSA KEY (compromised)| | RSA KEY (compromised)| | SIG by DSA cairn.net | | SIG by RSA cairn.net | ------------------------ ??? -------------------------------- |secure.isie.cairn.net (forged)| | DSA KEY (forged) | | RSA KEY (forged) | | SIG by DSA faulty.cairn.net | | SIG by RSA faulty.cairn.net | ------------------------------- The resolver obtains a false A record set for hostx.secure.isie.cairn.net and also received the two SIG records which cover the A record set. One SIG is generated by the forged DSA key from secure.isie.cairn.net and one SIG generated by the forged RSA key from secure.isie.cairn.net. The resolver requests the KEY set for secure.isie.cairn.net and receives the forged KEY set from the attacker. The forged KEY set is covered by both a DSA SIG and RSA SIG from the compromised faulty.cairn.net keys. The faulty.cairn.net keys are signed by cairn.net who is in turn signed by the master. Simply following the chain trust will lead the resolver to accept the forged secure.isie.cairn.net keys. The only protection against this attack is CAIRN key signing rules. In CAIRN, a domain's keys can only be signed either the domain's parent or the cairn.net key. According to the CAIRN policy, the domain faulty.cairn.net is not authorized to sign the KEY set for secure.isie.cairn.net. Note if the attacker has compromised either the cairn.net key or the isie.cairn.net keys, then the CAIRN policy offers not defense and the attacker can forge data from secure.isie.cairn.net. This scenario need not be limited to compromised keys. For example, it is reasonable for a zone such as netjava.cairn.net Expires April 20, 2000 [Page 16] Internet Draft October 20, 1999 to demand that its competitor, pcjava.cairn.net, is not authorized to sign (and thus forge) its KEY set. Note that java and pcjava are a purely fictional domains and any relationship to any existing malicious companies is purely coincidental. 6.4 Operations in an Mixed Key Algorithm Tree. In this operational scenario, cairn.net and secure.isie.cairn.net have KEY sets with DSA and RSA keys. However, isie.cairn.net has chosen not to use an RSA key and instead generates a NULL RSA KEY. Since there is no RSA KEY at isie.cairn.net, only a DSA SIG record covers the secure.isie.cairn.net KEY set. The DSA and RSA master keys are again trusted by a resolver. --------------------- --------------------- |cairn.net | | resolver | | DSA KEY | | implements DSA | | RSA KEY | | implements RSA | | SIG by DSA master | | trusts RSA master | | SIG by RSA master | | trusts DSA master | --------------------- --------------------- | query for A records of ------------------------ hostx.secure.isie.cairn.net |isie.cairn.net | | DSA KEY | | SIG by DSA cairn.net | | SIG by RSA cairn.net | ------------------------ | ------------------------------- |secure.isie.cairn.net | | DSA KEY | | RSA KEY | | SIG by DSA isie.cairn.net | ------------------------------- We assume the resolver has obtained the A record set for hostx.secure.isie.cairn.net and also received the two SIG records, one SIG generated by the DSA key from secure.isie.cairn.net and one SIG generated by the RSA key from secure.isie.cairn.net. After obtaining the necessary KEY records and corresponding SIGs, the resolver can return either an DSA authenticated answer as described in example scenario 6.1. Depending on how algorithm inter-operation is defined, the resolver may or may not be able to to use the RSA SIG from secure.isie.cairn.net. If the resolver knew the trusted RSA for secure.isie.cairn.net, the resolver could use the RSA SIG record to authenticate the A record set. Again the resolver must learn the RSA key for secure.isie.cairn.net, but this time the resolver has no RSA SIG record which covers the secure.isie.cairn.net KEY set. The resolver could use the DSA SIG record to authenticate the KEY set and learn the RSA KEY for secure.isie.cairn.net, but this approach can Expires April 20, 2000 [Page 17] Internet Draft October 20, 1999 be problematic. It may be that an attacker has exploited some vulnerability in the DSA algorithm. The attacker then uses this vulnerability to forge a false RSA key for secure.isie.cairn.net. The "RSA authenticated" result returned the resolver could have been compromised by a vulnerability in the DSA algorithm. Reporting this result as authenticated by RSA would be misleading at best. The resolver could instead report that there is no RSA SIG covering the secure.isie.cairn.net KEY set and thus no RSA authenticated answer is available. Before doing this, the resolver should first authenticate the fact that no RSA SIG exist for secure.isie.cairn.net. However, this means the secure.isie.cairn.net domain received better security when its parent was unsecure. In scenario 6.2, the isie.cairn.net was unsecure and the KEY set for secure.isie.cairn.net was signed by both the RSA and DSA keys from cairn.net. This approach argues for per algorithm DNS key hierarchies, further complicating KEY set signing and resolver rules for which KEYs to trust. 7 IMPLEMENTATION IN THE GENERAL INTERNET There seem to be several main areas that need to be addressed to facilitate the implementation of DNSSEC on a wider scale: i) Administrative and configuration activities associated with key distribution and signing ii) Compatibility with older versions of BIND, especially those which are acting as secondary servers to a master server which may be processing DNSSEC related resource records. (Some older version of BIND may have trouble when receiving SIG and KEY records) iii) Definition of how application resolvers should interact with the secure name servers in order to determine the security status of DNS records. Options include extending application resolvers to perform authentication processing, utilizing transaction signatures or IPSec between application resolvers and secure name servers, or relying on site security and inspection of query response flags to determine security status. Item i above, seems to be the most difficult issue when contemplating the transition from non-secure to secure DNS operations. The DNSSEC operational concept includes the following ideas relating to key distribution and signing: -There is a public master key at the root level for which all name servers have knowledge of and configure as a trusted key in their configuration files. -Every DNS zone administrator generates their own keys and signs their zone files. In addition, a DNS zone administrator must send its keys to its parent zone so that the parent can sign the sub-zones keys. The result is that every zone has in its zone file a copy of its keys along with a signature of its Expires April 20, 2000 [Page 18] Internet Draft October 20, 1999 keys by its parent keys. In this manner, if there are no breaks in the parent-child signing process going up the DNS hierarchy, it will be possible for any name server to get and verify any key that might need to verify a DNS resource record. The following problems can be readily identified relative to the transition to secure DNS operations. 1.The root servers will probably not be the first name servers ready to take on the task of generating keys, signing zone files, and signing children zone keys. 2.The procedures for the parent-child key signing exchange are not well understood, especially for a parent node which has a lot of delegation points. Automation techniques need to be developed. 3.It must be anticipated that there will be gaps in the parent-signing key signing operations as one moves up from different spots in the DNS hierarchy. This will prevent successful authentication in some cases. The following mechanism is being investigated as a vehicle to allow organizations to immediately begin using DNSSEC. The basic approach is to allow secure sub-zone to be placed anywhere in the current DNS hierarchy by allowing the parent-child key signing hierarchy to deviate from the general DNS hierarchy. This would allow secure sub-zones to authenticate data from any other secure sub-zone which also participates in this program. As a vehicle to test this concept, the CAIRN TOC is planning to provide top level key signing services for other secure sub-zones whose natural parent are not doing so. In this manner all secure sub-zones which had their keys signed by the CAIRN master keys, would only need to configure the public portion of the CAIRN master key in their name server configuration in order to have the ability to use key chaining to authenticate each others records. It is envisioned that this would provide an infrastructure for the DNSSEC community to work on some of the operational, automation, and administrative issues. The ability of the CAIRN TOC to provide these services would be dependent on the number of participants as well as the general workload required for these activities. The steps for an organization to create a secure sub-zone would be as follows: 1.Identify the zone which will be secure. 2.Install DNSSEC capable BIND, configure with the CAIRN master key as the trusted key. 3.Generate keys and sign zone files. 4.Provide CAIRN TOC with the keys have been generated. 5.CAIRN will act as the top level key signing authority, and will sign the keys, and send back copies of the SIG records. Expires April 20, 2000 [Page 19] Internet Draft October 20, 1999 This concept is currently under test with the following secure sub-zone: secure.cs.ucla.edu 8 SUMMARY AND FUTURE EXPERIMENTATION AREAS DNSSEC implementation and experimentation activities in CAIRN are expected to continue. A key concern and area of interest for this activity is further satisfaction of the implementation objectives stated in Section 2.2 of this draft. In summary they are: - Minimize the administrative burden imposed on a parent zone resulting from a child zone changing their configuration. It is desired that the zone file requirements delegating a zone under DNSSEC be the same as it is for current DNS operations. That is the delegation point only needs to specify the delegated sub-zone and the name servers which serve that sub-zone. In this manner, child sub-zones will not cause a parent zone to have to modify and resign its zone file when the sub-zone changes its secure status, generates new keys, or makes other changes to its configuration which would not require a parent zone file modification under traditional DNS implementations. The signature of the child zone keys by the parent keys is expected to be an off-line activity, which will only impact the zone file for the child zone requesting the signature services. Minimization of the impact to the parent zone file is considered very important, especially for zones with many delegation points. -Provide mechanisms which allow for non-contiguous secure zones space. In order to allow for non-contiguous secure zones space, the CAIRN implementation will allow the key signing hierarchy to deviate from the general DNS zone hierarchy. That is, if a secure sub-zone has a parent sub-zone which is unsecure, then that sub-zone can submit its keys to the cairn.net zone administrators for signature. The intent is that all name servers which have the cairn.net master key configured as a trusted key will then be able to authenticate records from other zones which do the same. This requires an administrative policy which states that the cairn.net master key is "authorized" to sign records from other zones, which are not directly delegated from the cairn.net zone. This concept of associating a trusted key with a list of zones it is authorized to sign for it not part of the current DNSSEC operational considerations. Discussion of the need (and mechanisms) to create associations between trusted keys and authorization for zone signing is desired. Expires April 20, 2000 [Page 20] Internet Draft October 20, 1999 It is felt by the authors of this draft, that initial implementation in the general Internet DNS hierarchy will require that pockets of secure DNS zones be able to exist. There must be a mechanism which allows name servers and application resolvers which are adequately configured to obtain and authenticate DNS records. Other DNSSEC areas interest for which CAIRN research and experimentation is anticipated includes: -automation of the key generation and zone file signing. -automation of the submission of a key to a parent for signature -mechanisms to allow a non-secure application resolver to use a secure name server to obtain authenticated DNS records. Evaluation of the use of IP Security (IPsec) vs Transaction Signatures is needed. Providing mechanisms for applications to inspect DNS response flags and record contents to make intelligent decision about data security is also needed. 9 IANA CONSIDERATIONS This document does not place any requirements on the assigned numbers authority. 10 SECURITY CONSIDERATIONS This entire document is a note on security considerations. 11 AUTHOR'S ADDRESS Daniel Massey Computer Science Department UCLA Los Angeles, CA 90095 +1 (703) 599-7318 Tom Lehman 4350 North Fairfax Drive Suite 770 Arlington, VA 22203 +1 (703) 812-3736 Edward Lewis 3060 Washington Rd. (Rte 97) Glenwood, MD 21738 +1 (443) 259-2352 12 REFERENCES This section will be more formally defined as the document progresses. Expires April 20, 2000 [Page 21] Internet Draft October 20, 1999 11 FULL COPYRIGHT STATEMENT Copyright (C) The Internet Society (1999). 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." Expires April 20, 2000 [Page 22]