Received: from sol.tis.com by magellan.TIS.COM id aa01243; 14 Dec 94 9:45 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma017680; Wed Dec 14 09:47:17 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA16375; Wed, 14 Dec 94 09:44:52 EST Message-Id: <9412141444.AA16375@tis.com> Reply-To: James M Galvin To: dns-security@tis.com Subject: draft minutes of San Jose meeting Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-Id: <4020.787416310.0@tis.com> Date: Wed, 14 Dec 1994 09:45:11 -0500 From: James M Galvin ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4020.787416310.1@tis.com> Enclosed below is the draft minutes of the San Jose meeting from last week. Please submit comments and revisions to me or the mailing list by tuesday, December 20. I will revise the minutes and submit them to the Secretariat for publication on wednesday, December 21. Thanks, Jim ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4020.787416310.2@tis.com> Content-Description: DNS Security San Jose Minutes The DNS Security Working Group met on Wednesday, December 7, at the San Jose IETF. It began with a review of the differences between the Ohta-san and Eastlake/Kaufman proposals. It was noted that this version of both documents have many similarities, with most differences in the underlying details. The gross level differences identified were as follows. o The Ohta-san proposal does not include an explicit discussion of key management or distribution while Eastlake/Kaufman does. o The Ohta-san proposal does not include a revocation mechanism while Eastlake/Kaufman does. o The Ohta-san proposal specifies the creation of 8 new resource records for each algorithm supported while Eastlake/Kaufman specifies 2 new resource records --- a key RR and a signature RR --- each with an embedded algorithm identifier. With respect to the first two differences, it was pointed out that the Ohta-san proposal could be augmented to include the necessary discussion. There was detailed discussion of the operational implications of the last difference. The issues raised included: 1. Having separate resource records for each algorithm allows servers/clients to easily request exactly those signature and keys records they need. 2. Having a single resource record with an embedded algorithm identifier allows clients/servers to know immediately if a zone is secure without having to query for all possible algorithms. At the completion of the discussion the chair called for a consensus from the working group as to which proposal represented the best direction for the working group at this time. The working group chose the Eastlake/Kaufman proposal. The remainder of the time was devoted to a discussion of three technical issues. revocation choice of algorithm signing of non-authoritative data On the topic of revocation, the working group concluded that this mechanism was not need by secure DNS. Instead, the document should indicate that the expiration time of the signature should be a small multiple of the original TTL for the resource record, thus requiring that the data be re-signed on a regular schedule. The principal motivation for this was that the working group believed that any revocation mechanism conflicted with the TTL mechanism of the DNS insofar as it was attempting to clear caches of invalid data. Further, the mechanism proposed specified that revocation records be distributed on a space available basis, so there was no guarantee that in fact it would be available for processing. On the topic of algorithm choices, a brief comparison of Diffie-Hellman/ElGamal and RSA was presented. It was noted that with respect to signature verification RSA outperformed Diffie-Hellman/ElGamal by several orders of magnitude. In addition, the size of an RSA signature was at most half the size of a comparable Diffie-Hellman/ElGamal signature. There was brief mention of the problems of export and use of cryptography internationally but no conclusion was reached. The working group agreed that no change in the choice of RSA was appropriate at this time. With respect to the signing of non-authoritative data, in particular zone delegation information, Ohta-san's proposal explicitly pointed out that it was not necessary to do this as long as the key of the child zone was signed by the parent's key. The discussion noted that with Eastlake/Kaufman, if the data was signed, there would be 3 signature records in addition to the KEY, NS, and A records that were returned, which would have an unfavorably high probability of exceeding the payload maximum for a UDP packet. Eastlake/Kaufman agreed to revise their proposal to recommend that servers allow for the NS and A record signature records to not be included if they do not fit, since they are not required. ------- =_aaaaaaaaaa0--   Received: from sol.tis.com by magellan.TIS.COM id aa25142; 16 Dec 94 16:51 EST Received: from gw.home.vix.com(192.5.5.1) by relay via smap (V1.3) id sma003550; Fri Dec 16 16:52:56 1994 Received: by gw.home.vix.com id AA14455; Fri, 16 Dec 94 12:16:41 -0800 Message-Id: <9412162016.AA14455@gw.home.vix.com> X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: dns-security@tis.com Cc: Jim McCoy Subject: Jim McCoy: Searching for Kaufman/Eastlake DNS changes Date: Fri, 16 Dec 1994 12:16:40 -0800 From: Paul A Vixie someone please reply to jim? ------- Forwarded Message From: mccoy@io.com (Jim McCoy) Message-Id: <199412161914.NAA13729@pentagon.io.com> Subject: Searching for Kaufman/Eastlake DNS changes To: paul@vix.com Date: Fri, 16 Dec 1994 13:14:17 -0600 (CST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 393 Hi there. Rich Salz suggested you might be the guy to contact to see if there is a ref implementation of the Kaufman/Eastlake DNS mods for the SIG and KEY RRs. If there is I would love a pointer to it. Also, I seem to remember hearing about a list discussing DNS security in general but can't remeber the address, is there such a list and if so what is the sub address? Thanks, jim mccoy ------- End of Forwarded Message   Received: from sol.tis.com by magellan.TIS.COM id aa06876; 23 Dec 94 11:06 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma015706; Fri Dec 23 11:08:11 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA24990; Fri, 23 Dec 94 11:05:48 EST Message-Id: <9412231605.AA24990@tis.com> Reply-To: James M Galvin To: minutes@cnri.reston.va.us Cc: dns-security@tis.com Subject: DNS Security Minutes Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pem-signature"; micalg="rsa-md5"; boundary="----- =_aaaaaaaaaa1" Date: Fri, 23 Dec 1994 11:06:30 -0500 From: James M Galvin ------- =_aaaaaaaaaa1 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <21370.788198782.2@tis.com> ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21370.788198782.3@tis.com> Enclosed below are the minutes of the DNS Security Working Group meeting at the San Jose IETF. Jim ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21370.788198782.4@tis.com> Content-Description: DNS Security Minutes DNS Security WG Meeting Minutes December 1994 San Jose Recorded by Jim Galvin, Chair The DNS Security Working Group met on Wednesday, December 7, at the San Jose IETF. It began with a review of the differences between the Ohta-san and Eastlake/Kaufman proposals. It was noted that this version of both documents have many similarities, with most differences in the underlying details. The gross level differences identified were as follows. o The Ohta-san proposal does not include an explicit discussion of key management or distribution while Eastlake/Kaufman does. o The Ohta-san proposal does not include a revocation mechanism while Eastlake/Kaufman does. o The Ohta-san proposal specifies the creation of 8 new resource records for each algorithm supported while Eastlake/Kaufman specifies 2 new resource records --- a key RR and a signature RR --- each with an embedded algorithm identifier. With respect to the first two differences, it was pointed out that the Ohta-san proposal could be augmented to include the necessary discussion. There was detailed discussion of the operational implications of the last difference. The issues raised included: 1. Having separate resource records for each algorithm allows servers/clients to easily request exactly those signature and keys records they need. 2. Having a single resource record with an embedded algorithm identifier allows clients/servers to know immediately if a zone is secure without having to query for all possible algorithms. At the completion of the discussion the chair called for a consensus from the working group as to which proposal represented the best direction for the working group at this time. The working group chose the Eastlake/Kaufman proposal. The remainder of the time was devoted to a discussion of three technical issues. revocation choice of algorithm signing of non-authoritative data On the topic of revocation, the working group concluded that this mechanism was not need by secure DNS. Instead, the document should indicate that the expiration time of the signature should be a small multiple of the original TTL for the resource record, thus requiring that the data be re-signed on a regular schedule. The principal motivation for this was that the working group believed that any revocation mechanism conflicted with the TTL mechanism of the DNS insofar as it was attempting to clear caches of invalid data. Further, the mechanism proposed specified that revocation records be distributed on a space available basis, so there was no guarantee that in fact it would be available for processing. On the topic of algorithm choices, a brief comparison of Diffie-Hellman/ElGamal and RSA was presented. It was noted that with respect to signature verification RSA outperformed Diffie-Hellman/ElGamal by several orders of magnitude. In addition, the size of an RSA signature was at most half the size of a comparable Diffie-Hellman/ElGamal signature. There was brief mention of the problems of export and use of cryptography internationally but no conclusion was reached. The working group agreed that no change in the choice of RSA was appropriate at this time. With respect to the signing of non-authoritative data, in particular zone delegation information, Ohta-san's proposal explicitly pointed out that it was not necessary to do this as long as the key of the child zone was signed by the parent's key. The discussion noted that with Eastlake/Kaufman, if the data was signed, there would be 3 signature records in addition to the KEY, NS, and A records that were returned, which would have an unfavorably high probability of exceeding the payload maximum for a UDP packet. Eastlake/Kaufman agreed to revise their proposal to recommend that servers allow for the NS and A record signature records to not be included if they do not fit, since they are not required. ------- =_aaaaaaaaaa0-- ------- =_aaaaaaaaaa1 Content-Type: application/pem-signature Content-ID: <21370.788198782.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6B= ekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn0Lw8g= G67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.com MIC-Info: RSA-MD5,RSA,e2nXm/oDqkIBqZiPWLA89SxczFV7NkWmwcf1Jjmh+PyeY7/1xcN0= O945/aZGqwn8wbPOimxHzjPkN82CVS2kan/OPEJU09C5RAavEOU31ru0qBNYcHlLzBlLdob9dD= 4O ------- =_aaaaaaaaaa1--   Received: from sol.tis.com by magellan.TIS.COM id aa10421; 24 Dec 94 3:04 EST Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3) id sma026018; Sat Dec 24 03:06:02 1994 Received: from skidrow.tay.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA27182; Sat, 24 Dec 94 00:02:35 -0800 Received: by skidrow.tay.dec.com (5.65/MS-081993); id AA14806; Sat, 24 Dec 1994 03:07:20 -0500 Message-Id: <9412240807.AA14806@skidrow.tay.dec.com> To: dns-security@tis.com Cc: dee@lkg.dec.com Subject: updated draft Date: Sat, 24 Dec 94 03:07:19 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I have updated the draft based on discussions at the IETF and some later email with the implementors. Unforuntately, in a few hours, I'll be leaving on vacation and will probably be out of touch for a week. I look forward to reading your comments on my return. I'm not sending this to internet-drafts but plan to send the next version. Donald --------------------------------------------------------------------------- Donald E. Eastlake, III DTN: 226-6577(w) dee@lkg.dec.com 550 King St, LKG2-1/BB3 1-508-486-6577(w) dee@ranger.enet.dec.com Littleton, MA 01460 USA 1-508-486-7417(fax) 1-508-287-4877(h) DNS Security Working Group Donald E. Eastlake, 3rd INTERNET-DRAFT DEC Charles W. Kaufman Iris Expires: 23 Jun 1995 24 Dec 1994 Domain Name System Protocol Security Extensions ------ ---- ------ -------- -------- ---------- Status of This Document This draft, file name draft-ietf-dnssec-secext-03.txt, is intended to be become a proposed standard RFC. Distribution of this document is unlimited. Comments should be sent to the DNS Security Working Group mailing list or to the authors. This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, munnari.oz.au, or ftp.is.co.za. Eastlake, Kaufman [Page 1] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 Abstract The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support a general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to keys for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions. Acknowledgements The significant contributions of the following persons (in alphabetic order) to this draft are gratefully acknowledged: Madelyn Badger, James M. Galvin, Olafur Gudmundsson, Sandy Murphy, Masataka Ohta, Jeffrey I. Schiller. Eastlake, Kaufman [Page 2] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 Table of Contents [Table of Contents gets moved here from the end] Eastlake, Kaufman [Page 3] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 [pg 2, ToC] Eastlake, Kaufman [Page 4] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 1. Introduction This draft describes extensions of the DNS protocol to support DNS security and public key distribution. This draft assumes that the reader is familiar with the Domain Name System, particularly as described in RFCs 1034 and 1035. Eastlake, Kaufman [Page 5] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 2. Brief Overview of the Extensions The DNS protocol extensions provide three distinct services: key distribution as described in section 2.2 below, data origin authentication as described in section 2.3 below, and transaction authentication, described in section 2.4 below. 2.1 Services Not Provided It is part of the design philosophy of the DNS that the data in it is public and that the DNS gives the same answers to all inquirers. Following this philosophy, no attempt has been made to include any sort of access control lists or other means to differentiate inquirers. In addition, no effort has been made to provide for any confidentiality for queries or responses. (This service may be available via an IP network level security protocol for which there is current an IETF working group.) 2.2 Key Distribution The resource records are defined to associate keys with DNS names. This permits the DNS to be used as a general public key distribution mechanism in support of the data origin authentication and transaction authentication DNS services as well as other security services such as IP level security. The syntax of a KEY resource record is described in Section 3. It includes the name of the entity the key is associated with (frequently but not always the KEY resource record owner name), an algorithm identifier, flags indicating the type of entity the key is associated with and/or asserting that there is no key associated with that entity, and the actual public key parameters. Under conditions described in Section 3, security aware DNS servers will automatically attempt to return KEY resources as additional information, along with those actually requested, to minimize query traffic. Eastlake, Kaufman [Page 6] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 2.3 Data Origin Authentication and Integrity Security is provided by associating with resource records in the DNS cryptographically generated digital signatures. Commonly, there will be a single private key that signs for an entire zone. If a security aware resolver reliably learns the public key of the zone, it can verify that all the data read was properly authorized and is reasonably current. The expected implementation is for the zone private key to be kept off-line and used to re-sign all of the records in the zone periodically. The data origin authentication key belongs to the zone and not to the servers that store copies of the data. That means compromise of a server or even all servers for a zone will not affect the degree of assurance that a resolver has that the data is genuine. A resolver can learn the public key of a zone either by reading it from DNS or by having it staticly configured. To reliably learn the public key by reading it from DNS, the key itself must be signed. Thus, to provide a reasonable degree of security, the resolver must be configured with at least the public key of one zone. From that, it can securely read the public keys of other zones if the intervening zones in the DNS tree are secure. It is in principle more secure to have the resolver manually configured with the public keys of multiple zones, since then the compromise of a single zone would not permit the faking of information from other zones. It is also more administratively cumbersome, however, particularly when public keys change. Adding origin authentication and integrity requires no change to the "on-the-wire" DNS protocol beyond the addition of the signature resource types (and, as a practical matter, the key resource type needed for key distribution). This service can be supported by existing resolver and server implementations so long as they could support the additional resource types. If signatures are always separately retrieved and verified when retrieving the information they authenticate, there will be more trips to the server and performance will suffer. To avoid this, security aware servers mitigate that degradation by automatically sending exactly the signature(s) needed. 2.3.2 The SIG Resource Record The syntax of a SIG resource record (signature) is described in Section 4. It includes the type of the RR(s) being signed, the name of the signer, the time at which the signature was created, the time it expires (when it is no longer to be believed), its original time Eastlake, Kaufman [Page 7] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 to live (which may be longer than its current time to live but cannot be shorter), the cryptographic algorithm in use, and the actual signature. Every name in a zone supporting signed data will have associated with it at least one SIG resource record for each resource type under that name. A security aware server supporting the performance enhanced version of the DNS protocol security extensions will attempt to return, with all records retrieved, the corresponding SIGs. If a server does not support the protocol, the resolver must retrieve all the SIG records for a name and select the one or ones that sign the resource record(s) that resolver is interested in. 2.3.3 Authenticating Name Non-existence The above security mechanism provides only a way to sign existing RRs in a zone. Data origin authentication is not obviously provided for the non-existence of a domain name in a zone. This gap is filled by the NXD RR which authenticatably asserts a range of non-existent names in a zone. The owner of the NXD RR is the start of such a ranger and its RDATA is the end of the range; however, there are additional complexities due to wildcards. Section 6 below covers the NXD RR. 2.3.5 Special Problems With Time-to-Live A digital signature will fail to verify if any change has occurred to the data between the time it was originally signed and the time the signature is verified. This conflicts with our desire to have the time-to-live field tick down when resource records are cached. This could be avoided by leaving the time-to-live out of the digital signature, but that would allow unscrupulous secondaries to set arbitrarily long time to live values undetected. Instead, we include the "original" time-to-live in the signature and communicate that data in addition to the current time-to-live. Unscrupulous servers under this scheme can manipulate the time to live but a security aware resolver will bound the TTL value it uses at the original signed value. Separately, signatures include a time signed and an expiration time. A resolver that knows an absolute time can determine securely whether a signature has expired. It is not possible to rely solely on the signature expiration as a substitute for the TTL, however, singe non-security aware servers must still be supported. Eastlake, Kaufman [Page 8] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 2.3.5 Signers Other Than The Zone There are two general cases where a SIG resource record is signed by other than the zone private key. One is for future support of dynamic update where an entity is permitted to authenticate/update its own records. The public key of the entity must be present in the DNS and be appropriately signed but the other RR(s) may be signed with the entity's key. The other is for support of transaction authentication as described in Section 2.3 below. 2.3 DNS Transaction Authentication The data origin authentication service described above protects resource records but provides no protection for DNS message headers. If header bits are falsely set by a server, there is little that can be done. However, it is possible to add transaction authentication. Such authentication means that a resolver can be sure it is getting messages from the server it thinks it queried and that the response is from the query it sent and that these messages have not been diddled in transit. This is accomplished by optionally adding a special SIG resource record to end of the reply which digitally signs the concatenation of the server's response and the resolver's query. The private key used belongs to the host composing the reply, not to the zone being queried. The corresponding public key is stored in and retrieved from the DNS. Because replies are highly variable, message authentication SIGs can not be pre-calculated. Thus it will be necessary to keep the private key on-line, for example in software or in a directly connected piece of hardware. DNS level transaction authentication would be unnecessary if a lower level (i.e., IP level) end-to-end security protocol were available. However, such a protocol is not yet standardized and when it is, there will be a considerable time during which there will be systems on which it will be hard to add IPSEC but relatively easy to replace the DNS components. Eastlake, Kaufman [Page 9] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 3. The KEY Resource Record The KEY RR is used to document a key that is associated with a DNS name. It will be a public key as only public keys are stored in the DNS. This can be the public key of a zone owner, of a host or other end entity, or a user. A KEY RR is, like any other RR, authenticated by a SIG RR. Security aware DNS implementations should be designed to handle at least two simultaneously valid keys of the same type associated with a name. The type number for the KEY RR is 25. 3.1 KEY RDATA format The RDATA for a KEY RR consists of an object name, flags, the algorithm version, and the public key itself. The format is as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / +- object name +---------------+---------------+ / | flags | algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / + - public key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ The object name, and the flags octets are described in Sections 3.2 and 3.3 below respectively. The flags must be examined before any following data as they control its the format and even whether there is any following data. The algorithm and public key fields are described in Section 3.4. The format of the public key is algorithm dependent. 3.2 Object Types and DNS Names and Keys The public key in a KEY RR belongs to the object named in the object name field. Frequently this will also be the owner name of the KEY RR. But they will be different in the case of the key or keys stored under a zone's name for the zone's superzone or keys that are stored for cross certification of other zones. The DNS object name may refer to up to three different things. For Eastlake, Kaufman [Page 10] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 example, dee.lkg.dec.com could be (1) a zone, (2) a host or other end entity , and (3) the mapping into a DNS name of the user or account dee@lkg.dec.com . Thus, there are flags in the KEY RR to indicate with which of these roles the object name and public key are associated as described below. Although the same name can be used for up to all three of these contexts, such overloading of a name is discouraged. It is also possible to use the same key for different things with the same name or even different names, but this is strongly discouraged. In particular, the use of a zone key as a non-zone key will usually require that the key be kept on line and thereby become much more vulnerable. It would be desirable for the growth of DNS to be managed so that additional possible simultaneous uses for names are NOT added. New uses should be distinguished by exclusive domains. For example, all IP autonomous system numbers have been mapped into the in-as.arpa domain [draft-ietf-dnssec-as-map-*.txt] and all telephone numbers in the world have been mapped into the tpc.int domain [RFC 1530]. This is much preferable to having the same name possibly be an autonomous system number, telephone number, and/or host as well as a zone and a user. In addition to the name type bits, there are three control bits, the "no key" bit, the "experimental" bit, and the "signatory" bit, as described below. 3.3 The KEY RR Flag Octet In the "flags" field: Bit 0 is the "no key" bit. If this bit is on, there is no key information and the RR stops with the flags octet. By the use of this bit, a signed KEY RR can authenticatably assert that, for example, a zone is not secured. Bits 1 is the "experimental" bit. Keys may be associated with zones, entities, or users for experimental, trial, or optional use, in which case this bit will be one. If this bit is a zero, it means that the use or availability of security based on the key is "mandatory". Thus, if this bit is off for a zone, the zone should be assumed secured by SIG RRs and any responses indicating the zone is not secured should be considered bogus. Similarly, if this bit were off for a host key and attempts to negotiate IP-security with the host produced indications that IP-security was not supported, it should be assumed that the host has been compromised or communications with it are being spoofed. On the other hand, if this Eastlake, Kaufman [Page 11] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 bit were a one, the host might very well sometimes operate in a secure mode and at other times operate without the availability of IP-security. The experimental bit, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR. The experimental bit must be zero for safe secure operation and should only be a one for a minimal transition period. Bit 2 is the "signatory" bit. It indicates that the key can validly sign RRs of the same name. If the owner name is a wildcard, then RRs with any name which is in the wildcard's scope can be signed including NS and corresponding zone KEY RRs to carve out a subzone. This bit is meaningless for zone keys which always have authority to sign any RRs in the zone. The signatory bit, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR. Bits 3-4 are reserved and must be zero. If they are found non- zero, they should be ignored and the KEY RR used as indicated by the other flags. Bit 5 on indicates that this is a key associated with a "user" or "account" at an end entity, usually a host. The coding of the owner name is that used for the responsible individual mailbox in the SOA record: The owner name is the user name as the name of a node under the entity name. For example, "j.random_user" on host.subdomain.domain could have a public key associated through a KEY RR with name j\.random_user.host.subdomain.domain. It could be used in an IP-security protocol where authentication of a user was desired. This key would be useful in IP or other security for a user level service such a telnet, ftp, rlogin, etc. Bit 6 on indicates that this is a key associated with the non- zone entity whose name is the RR owner name. This will commonly be a host but could, in some parts of the DNS tree, be some other type of entity such as an Autonomous System [draft-ietf-dnssec-as-map-*.txt]. This is the public key used in connection with the optional DNS transaction authentication service that can be used if the owner name is a DNS server host. It could also be used in an IP-security protocol where authentication of a host was desired. Bit 7 on indicates that this is a zone key for the zone whose name is the RSA RR owner name. This is the fundamental type of DNS data origin authentication public key. 3.4 The KEY Algorithm Version and MD5/RSA Algorithm This octet is the key algorithm version parallel to the same field for the SIG resource. The MD5/RSA algorithm described in this draft Eastlake, Kaufman [Page 12] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 is number 1. Version numbers 2 through 253 are available for assignment should sufficient reason arise. However, the designation of a new version could have a major impact on interoperability and requires an IETF standards action. Version 254 is reserved for private use and will never be assigned a specific algorithm. For version 254, the public key area shown in the packet diagram above will actually begin with an Object Identifier (OID) indicating the private algorithm in use and the remainder of the combined area is whatever is required by that algorithm. Algorithm versions 0 and 255 are reserved. If the no key bit is zero and the algorithm field is 1, indicating the MD5/RSA algorithm, the public key filed is structured as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | public key exponent |modulus length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / +- modulus / | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The public key modulus field is a multiprecision unsigned integer. The "modulus length" is an unsigned octet which is the actual modulus length minus 64. This limits keys to a maximum of 255+64 or 319 octets and a minimum of 64 octets. Although moduluses of less than 512 significant bits are not permitted, due to the weak security they provide, they can be represented by using leading zeros. 3.5 KEY RRs in the Construction of Responses An explicit request for KEY RRs does not cause any special additional information processing except, of course, for the corresponding SIG RR from a security aware server. Security aware DNS servers will include KEY RRs as additional information in responses where appropriate as follows: On the retrieval of NS RRs, the zone key KEY RR(s) for the zone served by these name servers will be included. If not all additional info will fit, the KEY RR(s) have lower priority than type A glue RRs. On retrieval of type A RRs, the end entity KEY RR(s) will be included. On inclusion of A RRs as additional information, their KEY RRs will also be included but with lower priority than the relevant A Eastlake, Kaufman [Page 13] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 RRs. 3.6 File Representation of KEY RRs KEY RRs may appear as lines in a zone data file. In the RDATA portion, the object name appears first. The flag octet and algorithm version octets are then represented as unsigned integers; however, if the "no key" flag is on in the flags, nothing appears after the flag octet. If the algorithm specified is the MD5/RSA algorithm, then the exponent and modulus appear. The public key exponent is an unsigned integer from 3 to 16777215. The public key modulus can be quite large, up to 319 octets. It is the last data field and is represented in base 64 (see Appendix) and may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to obtain the full signature. These substrings can span lines using the standard parenthesis. If an algorithm from 2 through 253 is specified, the public key parameters required by that algorithm are given. If the algorithm specified is number 254, then an OID appears followed by whatever is required for the private algorithm. An implementation that does not understand a particular standard or private algorithm should attempt to parse the rest of the line as one or more base 64 substrings to be concatenated to yield the key parameters. Algorithm versions 0 and 255 are reserved. Eastlake, Kaufman [Page 14] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 4. The SIG Resource Record The SIG or "signature" resource record (RR) is the fundamental way that data is authenticated in the secure DNS. As such it is the heart of the security provided. The SIG RR unforgably authenticates other RRs of a particular type, class, and name and binds them to a time interval and the signer's fully qualified domain name. This is done using cryptographic techniques and the signer's private key. The signer is frequently the owner of the zone from which the RR originated. 4.1 SIG RDATA Format The RDATA portion of a SIG RR is as shown below. The integrity of the RDATA information is protected by the signature field. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type covered | algorithm | labels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | original TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time signed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key footprint | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / +- signature / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value of the SIG RR type is 24. The "type covered" is the type of the other RRs covered by this SIG. The algorithm version number is an octet specifying the digital signature algorithm used. The MD5/RSA algorithm described in this draft is version 1. Version numbers 2 through 253 are available for assignment should sufficient reason arise to allocate them. However, the designation of a new version could have a major impact on the interoperability of the global DNS systems and requires an IETF standards action. Version 254 is reserved for private use and will Eastlake, Kaufman [Page 15] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 never be assigned a specific algorithm. For version 254, the "signature" area shown above will actually begin with an Object Identified (OID) indicating the private algorithm in use and the remainder of the signature area is whatever is required by that algorithm. Version numbers 0 and 255 are reserved. The "labels" octet is an unsigned count of how many labels there are in the original SIG RR owner name not counting the null label for root and not counting any initial "*" for a wildcard. If, on retrieval, the RR appears to have a longer name, the resolver can tell it is the result of wildcard substitution. If the RR owner name appears to be shorter than the labels count, the SIG RR should be considered corrupt and ignored. The maximum number of labels possible in the current DNS is 127 but the entire octet is reserved and would be required should DNS names ever be expanded to 255 labels. If a secured retrieval is the result of wild card substitution, it is necessary for the resolver to use the original form of the name in verifying the digital signature. The field helps optimize the determination of the original form reducing the effort in authentication signed data. The following table give some examples. The value of "labels" is at the top, the retrieved owner name on the left, and the table entry is the name to use in signature verification except that "bad" means the RR is corrupt. labels= | 0 | 1 | 2 | 3 | 4 | --------+-----+------+--------+----------+----------+ .| . | bad | bad | bad | bad | d.| *. | d. | bad | bad | bad | c.d.| *. | *.d. | c.d. | bad | bad | b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad | a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. | The "original TTL" field is included in the RDATA portion to avoid authentication problems that caching servers would otherwise cause by decrementing the real TTL field and security problems that unscrupulous servers could otherwise cause by manipulating the real TTL field. This original TTL is protected by the signature while the current TTL field is not. NOTE: The "original TTL" must be restored into the covered RRs when the signature is verified. This implies that the RRs need to all have the same TTL to start with. The SIG is valid until the "signature expiration" time which is an unsigned number of seconds since the start of 1 January 1970. The "time signed" field is an unsigned number of seconds since the start of 1 January 1970. The "key footprint" is a 16 bit quantity that is used to help Eastlake, Kaufman [Page 16] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 efficiently select between multiple keys which may be applicable and as a quick check that a public key about to be used for the computationally expensive effort to check the signature is possibly valid. Its exact meaning is algorithm dependent. For the MD5/RSA algorithm, it is the next to the bottom two octets of the public key modulus needed to decode the signature field. That is to say, the most significant 16 of the lest significant 24 bits of this quantity in network order. The "signer's name" field is the fully qualified domain name of the signer generating the SIG RR. This is frequently the zone which contained the RR(s) being authenticated. The structured of the "signature" field depends on the algorithm chosen and is described below for the MD5/RSA algorithm. 4.1.1 Signature Format The actual signature portion of the SIG RR binds RDATA to all of the "type covered" RRs with that owner name. These covered RRs are thereby authenticated. To accomplish this, a data sequence is constructed as follows: data = RDATA | RR(s)... where | is concatenation and RR(s) are all the expanded (no name abbreviation) RR(s) of the type covered with the same owner name and class as the SIG RR in canonical order. The canonical order for RRs is to sort them in ascending order as left justified unsigned octet sequences where a missing octet sorts before a zero octet. How this data sequence is processed into the signature is algorithm dependent. For the MD5/RSA algorithm, the signature is as follows hash = MD5 ( data ) signature = ( 01 | FF* | 00 | hash ) ** e (mod n) where "|" is concatenation, "e" is the secret key exponent of the signer, and "n" is the public modulus that is the signer's public key. 01, FF, and 00 are fixed octets of the corresponding hexadecimal value. The FF octet is repeated the maximum number of times such that the value of the quantity being exponentiated is one octet shorter than the value of n. The size of n, including most and least significant bits (which will Eastlake, Kaufman [Page 17] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 be 1) SHALL be not less than 512 bits and not more than 2552 bits. n and e MUST be chosen such that the public exponent is less than 2**24 - 1 and SHOULD be chosen such that the public exponent is small. The above specifications are similar to Public Key Cryptographic Standard #1 [PKCS1]. (A public exponent of 3 minimizes the effort needed to decode a signature. Use of 3 as the public exponent may be weak for confidentiality uses since, if the same data can be collected encrypted under three different keys with an exponent of 3 then, using the Chinese Remainder Theorem, the original plain text can be easily recovered. This weakness is not significant for DNS because we seek only authentication, not confidentiality.) 4.1.2 SIG RRs Covering Type ANY The SIG RR described above protects all the RRs with a particular owner name, class, and type. Thus a server must supply them all to convince a security aware resolver. However, an unscrupulous server could claim there were no RRs of a particular type and class under an owner name while presenting signed RRs of other types. To provide a means of protection against this, one or more SIG RR is added for each owner name that covers the type ANY. It is calculated as indicated above except that all RRs for that owner name and SIG key, except the SIG RR covering type ANY itself, are included in the data string which is processed into the signature. To allow for dynamic update, the zone key signed ANY SIG RR covers only zone signed RRs. If RRs are added to a zone authenticated by an entity or user key, then an ANY SIG RR signed by that key covering the RRs signed by that key should be added. 4.1.3 Zone Transfer (AXFR) SIG The above SIG mechanisms assure the authentication of all the RRs of a particular name, class and type and all the RRs of a particular name, class and any type. However, to secure complete zone transfers, a SIG RR owned by the zone name must be created with a type covered of AXFR that covers all other zone signed RRs. It will be calculated by hashing together all other static zone RRs, including SIGs. The RRs are ordered and concatenated for hashing as described in Section 4.1.1. This SIG, other than having to be calculated last of all zone key signed SIGs in the zone, is the same as any other SIG. Eastlake, Kaufman [Page 18] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 Dynamic zone RRs which might be added by some future dynamic zone update protocol and signed by an end entity or user key rather than a zone key (see Section 3.2) are not included. They originate in the network and will not, in general, be migrated to the recommended off line zone signing procedure (see Section 8.2). Thus such dynamic RRs are not directly signed by the zone and are not generally protected against omission during zone transfers. 4.1.4 Transaction SIGs A response message from a security aware server may optionally contain a special SIG as the last item in the additional information section to authenticate the transaction. This SIG has a "type covered" field of zero, which is not a valid RR type. It is calculated by using a "data" (see section 4.1.1) of the entire preceding DNS reply message, including header, concatenated with the entire DNS query message that produced this response, including the query's header. That is data = full response (less trailing message SIG) | full query Verification of the message SIG (which is signed by the server host key, not the zone key) by the requesting resolver shows that the query and response were not tampered with in transit and that the response corresponds to the intended query. 4.2 SIG RRs in the Construction of Responses Security aware servers MUST, for every authoritative RR the query will return, attempt to send the available SIG RRs which authenticate the requested RR. If multiple such SIGs are available, there may be insufficient space in the response to include them all. In this case, SIGs whose signer is the zone containing the RR MUST be given highest priority and retained even if SIGs with other signers must be dropped. Sending SIGs to authenticate non-authoritative data (glue records and NS RRs for subzones) is optional and should be avoided if it will lead to UDP DNS response truncation. If a SIG covers any RR that would be in the answer section of the response, its automatic inclusion MUST be the answer section. If it covers an RR that would appear in the authority section, its automatic inclusion MUST be in the authority section. If it covers an RR that would appear in the additional information section it MUST Eastlake, Kaufman [Page 19] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 appear in the additional information section. Optionally, DNS transactions may be authenticated by a SIG RR at the end of the response in the additional information section (section 4.1.4). Such SIG RRs are signed by the DNS server originating the response. Although the signer field must be the name of the originating server host, the owner name, class, TTL, and original TTL, are meaningless. The class and TTL fields can be zero. To save space, the name should be root (a single zero octet). [There may be a problem with SIG and NXD RR's associated with domain names that are CNAMEs. The DNS RFCs prohibit other types of RRs appearing with a CNAME RR. This problem is being ignored until it is clear if DNS servers will really have a problem with this.] 4.3 Processing Responses with SIG RRs If SIG RRs are received in response to a query explicitly specifying the SIG type, no special processing is required but a security aware client may wish to authenticate them by checking the signature and applying consistency checks. If SIG RRs are received in any other response, a security aware client should check them using the public key of the signer. The result should then be verified against the appropriate other RRs retrieved. If the message does not pass reasonable checks or the SIG does not check against the signed RRs, the SIG RR is invalid and should be ignored. The time of receipt of the SIG RR must be in the inclusive range of the time signed and the signature expiration but the SIG can be retained and remains locally valid until the expiration time plus the authenticated TTL. If the SIG RR is the last RR in a response in the additional information section and has a type covered of zero, it is a transaction signature of the the response and the query that produced the response. It may be optionally checked and the message rejected if the checks fail. But even it the checks succeed, such a transaction authentication SIG does NOT authenticate any RRs in the message. Only proper direct or hashed RR signets signed by the zone can authenticate RRs. If a resolver does not implement transaction SIGs, it MUST at least ignore them without error. If all reasonable checks indicate that the SIG RR is valid then RRs verified by it should be considered authenticated and all other RRs in the response should be considered with suspicion. Eastlake, Kaufman [Page 20] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 4.4 File Representation of SIG RRs A SIG RR can be represented as a single logical line in a zone data file [RFC1033] but there are some special problems as described below. (It does not make sense to include a transaction authenticating SIG RR in a file as it is a transient authentication that must be calculated in real time by the DNS server.) There is no particular problem with the signer, covered type, and times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY is the year, the first MM is the month number (01-12), DD is the day of the month (01-31), HH is the hour in 24 hours notation (00-23), the second MM is the minute (00-59), and SS is the second (00-59). The original TTL and algorithm fields appears as unsigned integers. The "labels" field does not appear in the file representation as it can be calculated from the owner name. The key footprint appears as an eight digit unsigned hexadecimal number. However, the signature itself can be very long. It is the last data field and is represented in base 64 (see Appendix) and may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to obtain the full signature. These substrings can be split between lines using the standard parenthesis. Eastlake, Kaufman [Page 21] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 5. Non-existent Names The SIG RR mechanism described in section 4 above provides strong authentication of RRs that exist in a zone. But is it not immediately clear how to authenticatably deny the existence of a name in a zone. The nonexistence of a name in a zone is indicates by the NXD RR for a name interval containing the nonexistent name. An NXD RR and its SIG are returned in the additional information section, along with the error, if the resolver is security aware. NXD RRs can also be returned if an explicit query is made for the NXD type. The existence of a complete set of NXD records in a zone means that any query for any name to a security aware server serving the zone should result in an reply containing at least one signed RR. 5.1 The NXD Resource Record The NXD resource record is used to securely indicate that no RRs with an owner name in a certain name interval exist in a zone. The owner name of the NXD RR is an existing name in the zone. It's RDATA is another existing name in the zone. The presence of the NXD RR means that no name between its owner name and the name in its RDATA area exists. This implies a canonical ordering of all domain names in a zone. The ordering is to sort labels as unsigned left justified octet strings where the absence of a byte sorts before a zero byte. Names are then sorted by sorting on the highest level label and then, within those names with the same highest level label by the next lower label, etc. Since we are talking about a zone, the zone name itself always exists and all other names are the zone name with some prefix of lower level labels. Thus the zone name itself always sorts first. There is a slight problem with the last NXD in a zone as it wants to have an owner name which is the last existing name in sort order, which is easy, but it is not obvious what name to put in its RDATA to indicate the entire remainder of the name space. This is handled by treating the name space as circular and putting the zone name in the RDATA of the last NXD. There are additional complexities due to interaction with wildcards as explained below. The NXD RRs for a zone can be automatically calculated and added to Eastlake, Kaufman [Page 22] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 the zone by the same recommended off-line process that signs the zone. The NXD RR's TTL should not exceed the zone minimum TTL. The type number for the NXD RR is xxx. 5.2 NXD RDATA Format The RDATA for an NXD RR consists simply of a domain name. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next domain name / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3 Example Assume a zone has entries for big.foo.bar, medium.foo.bar. small.foo.bar. tiny.foo.bar. Then a query to a security aware server for huge.foo.bar would produce an error reply with the additional information section containing big.foo.bar. NXD medium.foo.bar. and the corresponding SIG RR. 5.4 Interaction of NXD RRs and Wildcard RRs As a wildcard RR causes all possible names in an interval to exist, there should not be an NXD record that would cover any part of this interval. Thus if *.X.ZONE exists you would expect an NXD RR that ends at X.ZONE and one that starts with the last name covered by *.X.ZONE. However, this "last name covered" is something very ugly and long like \255\255\255....X.zone. So the NXD for the interval following is simply given the owner name *.X.zone. This "*" type name is not expanded when the NXD is returned as additional information in connection with a query for a non-existent name and Eastlake, Kaufman [Page 23] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 type. If there could be any wildcard RRs in a zone and thus wildcard NXDs, care must be taken in interpreting the results of explicit NXD retrievals as the owner name may be a wildcard expansion. The existence of one or more wildcard RRs covering a name interval makes it possible for a malicious server to hide any more specificly named RRs in the internal. The server can just falsely return the wildcard match NXD instead of the more specificly named RRs. If there is a zone wide wildcard, there will be only one NXD RR whose owner name and RDATA are both the zone name. In this case a server could conceal the existence of any more specific RRs in the zone. (It would be possible to make a more complex NXD feature, taking into account the types of RRs that did not exist in a name interval, and the like, which would eliminate this possibility. But it would be more complex and would be so constraining as to make any future dynamic update feature that could create new names very difficult (see Section 3.2).) 5.5 Blocking NXD Pseudo-Zone Transfers In a secure zone, a resolver can query for the initial NXD associated with the zone name. Using the RDATA field from that RR, it can query for the next NXD RR. By repeating this, it can walk through all the NXDs in the zone. If there are no wildcards, it can use this technique to find all names in a zone. If it does type ANY queries, it can incrementally get all information in the zone and perhaps defeat attempts to administratively block zone transfers. If there are any wildcards, this NXD walking technique will not find any more specific RR names in the part of the name space the wildcard covers. By doing explicit retrievals for wildcard names, a resolver could determine what intervals are covered by wildcards but still could not, with these techniques, find any names inside such intervals except by trying every name. If it is desired to block NXD walking, the recommended method is to add a zone wide wildcard of the KEY type with the no key bit on and with no type (zone, entity, or user) bit on. This will cause there to be only one NXD RR in the zone for the zone name and leak no information about what real names exist in the zone. This protection from pseudo-zone transfers is bought at the expense of eliminating the data origin authentication of the non-existence of names that NXD RRs can provide. If an entire zone is covered by a wildcard, a malicious server can return an RR produced by matching the resulting wildcard NXD and can thus hide all the real data and delegations with more specific names in the zone. Eastlake, Kaufman [Page 24] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 6. How to Resolve Securely Retrieving or resolving authentic data from the DNS involves starting with one or more trusted public keys and, in general, progressing securely from them through the DNS zone structure to the zone of interest. Such trusted public keys would normally be configured in a manner similar to that described in section 6.1. However, as a practical matter, a security aware resolver would still gain some confidence in the results it returns even if it was not configured with any keys but trusted what it got from a local well known server as a starting point. 6.1 Boot File Format The recommended format for a boot file line to configure starting keys is as follows: pubkey name object flags algorithm [exponent modulus] for a public key. "object" is the domain name of the thing the key is associated with and "name" is the owner name if the line is translated into a KEY RR). Flags indicates the type of key and is the same as the flag byte in the KEY RR. In particular, if the "no key" bit is on in flags, then all fields after flags may be omitted. Algorithm is the algorithm in use where one is the MD5/RSA algorithm and 254 indicates a private algorithm. The material after the algorithm is algorithm dependent and, for private algorithms, starts with the algorithm's identifying OID. For the RSA algorithm, it is the public key exponent as a decimal number between 3 and 16777215, and the modulus in base 64 (see Appendix). While it might seem logical for everyone to start with the key for the root zone, this has problems. The logistics of updating every DNS resolver in the world when the root key changes would be excessive. It may be some time before there even is a root key. Furthermore, many organizations will explicitly wish their "interior" DNS implementations to completely trust only their own zone. These interior resolvers can then go through the organization's zone server to access data outsize the organization's domain. 6.2 Chaining Through Zones Starting with one trusted zone key, it is possible to retrieve signed keys for subzones which have a key. Every secure zone (except root) should also include the KEY RR for its super-zone signed by the secure zone and with the owner name of the secure zone and object Eastlake, Kaufman [Page 25] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 name of the super-zone. This makes it possible to climb the tree of zones if one starts below root. A secure sub-zone is indicated by a KEY RR appearing with the NS RRs for the sub-zone and with the same owner and object names. These make it possible to descend within the tree of zones. A resolver should keep track of the number of successive secure zones traversed from a starting point to any secure zone it can reach. In general, the lower such a distance number is, the greater the confidence in the data. Data configured via a boot file should be given a distance number of zero. Should a query encounter different data with different distance values, that with a larger value should be ignored. A security conscious resolver should completely refuse to step from a secure zone into a non-secure zone unless the non-secure zone is certified to be non-secure or only experimentally secure by the presence of an authenticated KEY RR for the non-secure zone with a no key flag or the presence of a KEY RR with the experimental bit set. Otherwise the resolver is probably getting completely bogus or spoofed data. If legitimate non-secure zones are encountered in traversing the DNS tree, then no zone can be trusted as secure that can be reached only via information from such non-secure zones. Since the non-secure zone data could have been spoofed, the "secure" zone reach via it could be counterfeit. The "distance" to data in such zones or zones reached via such zones could be set to 512 or more as this exceeds the largest possible distance through secure zones in the DNS. Nevertheless, continuing to apply secure checks within "secure" zones reached via non-secure zones will, as a practical matter, provide some increase in security. The syntax of KEY RRs, with an arbitrary object name, provides for cross-certification. Although the syntax permits the owner name of a cross-certification KEY RR to be any name, by convention and to avoid an undue concentration of such KEY RRs under any particular name, their owner name should be the zone name prefixed with the destination object name (truncated an integral number of labels from the front if necessary due to DNS name restrictions). Thus a key for isoc.org would appear in the mit.edu zone with the owner name isoc.org.mit.edu and object name isoc.org. The existence of cross certifications adds further policy questions. Assume we have a zone B.A and a zone Y.X. Many possibilities exist for a secure resolver configured with the B.A key to get to Y.X. If all the zones along the way are secure, it could climb to root and then descend the other side, a total of four hops (B.A -> A -> . -> X -> Y.X). If the B.A administrator had installed a cross certified key for Y.X in the B.A zone, using that would be a shorter and Eastlake, Kaufman [Page 26] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 presumably more secure way to find Y.X's key which would be immune to the non-security or even compromise of the servers for A or root or X. But what if some less trusted subzone of B.A, say flakey.B.A installed a cross certified key for Y.X? If there is a conflict, should this be preferred to a hierarhically derived key obtained by climbing to root and descending? Such questions are entirely a matter of local resolver policy. 6.3 Secure Time Coordinated interpretation of the time fields in SIG RRs requires that reasonably consistent time be available to the hosts implementing the DNS security extensions. A variety of time synchronization protocols exist including the Network Time Protocol (NTP, RFC1305). If such protocols are used, they should be used securely so that time can not be spoofed. Otherwise, for example, a host could get its clock turned back and might then believe old SIG and KEY RRs which were valid but no longer are. Eastlake, Kaufman [Page 27] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 7. Operational Considerations This section discusses a variety of considerations in secure operation of DNS using these proposed protocol extensions. 7.1 Key Size Considerations There are a number of factors that effect public key size choice for use in the DNS security extension. Unfortunately, these factors usually do not all point in the same direction. Choice of a key size should generally be made by the zone administrator depending on their local conditions. For most schemes, larger keys are more secure but slower. Verification (the most common operation) for the MD5/RSA algorithm will vary roughly with the square of the modulus length, signing will vary with the cube of the modulus length, and key generation (the least common operation) will vary with the fourth power of the modulus length. The current best algorithms for factoring a modulus and breaking RSA security vary roughly with the square of the modulus itself. Thus going from a 640 bit modulus to a 1280 bit modulus only increases the verification time by a factor of 4 but vastly increases the work factor of breaking the key. [RSA FAQ] However, larger keys increase size of the KEY and SIG RRs. This increases the chance of UDP packet overflow and the possible necessity for using higher overhead TCP. The recommended minimum RSA algorithm modulus size, 640 bits, is believed by the authors to be secure at this time and for some years but high level zones in the DNS tree may wish to set a higher minimum, perhaps 1000 bits, for security reasons. (Since the United States National Security Agency generally permits export of encryption systems using an RSA modulus of up to 512 bits, use of that small a modulus, i.e. n, must be considered weak.) For a key used only to secure data and not to secure other keys, 640 bits should be entirely adequate. 7.2 Key Storage It is strongly recommended that zone private keys and the zone file master copy be kept and used in off-line non-network connected physically secure machines only. Periodically an application can be run to re-sign the RRs in a zone by adding NXD and SIG RRs. Then the augmented file can be transferred, perhaps by sneaker-net, to the Eastlake, Kaufman [Page 28] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 networked zone primary server machine. The idea is to have a one way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. The master copy of the zone file should be off net and should not be updated based on an unsecured network mediated communication. Non-zone private keys, such as host or user keys, may have to be kept on line to be used for real-time purposes such a IP secure session set-up or secure mail. 7.3 Key Generation Careful key generation is a sometimes over looked but absolutely essential element in any cryptographically secure system. The strongest algorithms used with the longest keys are still of no use if an adversary can guess enough to lower the size of the likely key space so that it can be exhaustively searched. Suggestions will be found in draft-ietf-security-randomness-*.txt. It is strongly recommended that key generation also occur off-line, perhaps on the machine used to sign zones (see Section 7.2). 7.4 Key Lifetimes No key should be used forever. The longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis. No zone key should have a lifetime significantly over five years. The recommended maximum lifetime for zone keys that are kept off-line and carefully guarded is 13 months with the intent that they be replaced every year. The recommended maximum lifetime for end entity keys that are used for IP-security or the like and are kept on line is 36 days with the intent that they be replaced monthly or more often. In some cases, an entity key lifetime of a little over a day may be reasonable. Key lifetimes significantly over a year increase the risk that, when the time comes up change the key, no one at the site will remember how to do it. Eastlake, Kaufman [Page 29] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 7.5 Signature Lifetime Signature expiration times must be set far enought in the future that it is quite certain that new signatures can be generated before the old ones expire. However, setting expiration too far into the future could, if bad data or signatures were ever generated, mean a long time to flush such badness. It is recommended that signature lifetime be a small multiple of the TTL but not less than a reasonable re-signing interval. 7.6 Root It should be noted that in DNS the root is a zone unto itself. Thus the root zone key should only be see signing itself or signing RRs with names one level below root, such as .aq, .edu, or .arpa. Implementations MAY reject as bogus any purported root signature of records with a name more than one level below root. Eastlake, Kaufman [Page 30] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 8. Conformance Several levels of server and resolver conformance are defined. 8.1 Server Conformance Three levels of server conformance are defined as follows: Basic server compliance is the ability to store and retrieve (including zone transfer) SIG, KEY, and NXD RRs. Secondaries for a secure zone must be at least basicly compliant. Medium server compliance adds the following to basic compliance: (1) ability to read SIG, KEY, and NXD RRs in zone files and (2) ability, given a zone file and private key, to add appropriate SIG and NXD RRs, possibly via a separate application. Primary servers for secure zones must be at least minimally compliant. Full server compliance is ability to automatically include SIG, KEY, and NXD RRs in responses as appropriate, as well as meeting minimal compliance. 8.2 Resolver Conformance Two levels of resolver compliance are defined: A basic compliance resolver can handle SIG, KEY, and NXD RRs when they are explicitly requested. A fully compliant resolver understands KEY, SIG, and NXD RRs, maintains appropriate information in its local caches and database to indicate which RRs have been authenticated and to what extent they have been authenticated, and performs additional queries as necessary to obtain KEY, SIG, or NXD RRs from non-security aware servers. Eastlake, Kaufman [Page 31] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 9. Security Considerations This document concerns technical details of extensions to the Domain Name System (DNS) protocol to provide data integrity and data origin authentication, public key distribution, and optional transaction security. If should be noted that, at most, these extensions guarantee the validity of resource records, including KEY resource records, retrieved from the DNS. They do not magically solve other security problems. For example, using secure DNS you can have high confidence in the IP address you retrieve for a host; however, this does not stop someone for substituting an unauthorized host at that address or capturing packets sent to that address and responding with packets apparently from that address. Any reasonably complete security system will require the protection of many other facets of the Internet. References [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 3 June 1991, Version 1.4. [RFC1032] - Domain Administrators Guide, M. Stahl, November 1987 [RFC1033] - Domain Administrators Operations Guide, M. Lottor, November 1987 [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, November 1987 [RFC1035] - Domain Names - Implementation and Specifications [RFC1321] - The MD5 Message-Digest Algorithm, R. Rivest, April 16 1992. [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. Eastlake, Kaufman [Page 32] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 Authors Addresses Donald E. Eastlake, 3rd Digital Equipment Corporation 550 King Street, LKG2-1/BB3 Littleton, MA 01460 Telephone: +1 508 486 6577(w) +1 508 287 4877(h) EMail: dee@lkg.dec.com Charles W. Kaufman Iris Associates 1 Technology Park Drive Westford, MA 01886 Telephone: +1 508-392-5276 EMail: charlie_kaufman@iris.com Expiration and File Name This draft expires 23 June 1995. Its file name is draft-ietf-dnssec-secext-03.txt. Eastlake, Kaufman [Page 33] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 Appendix: Base 64 Encoding The following encoding technique is taken from RFC 1521 by Borenstein and Freed. It is reproduced here in a slightly edited form for convenience. A 65-character subset of US-ASCII is used, enabling 6 bits to be represented per printable character. (The extra 65th character, "=", is used to signify a special processing function.) The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating 3 8-bit input groups. These 24 bits are then treated as 4 concatenated 6-bit groups, each of which is translated into a single digit in the base64 alphabet. Each 6-bit group is used as an index into an array of 64 printable characters. The character referenced by the index is placed in the output string. Table 1: The Base64 Alphabet Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. A full encoding quantum is always completed at the end of a quantity. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Padding at the end of the data is performed using the '=' character. Since all base64 input is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output Eastlake, Kaufman [Page 34] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character. Eastlake, Kaufman [Page 35] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 Status of This Document....................................1 Abstract...................................................2 Acknowledgements...........................................2 Table of Contents..........................................3 1. Introduction............................................5 2. Brief Overview of the Extensions.......................6 2.1 Services Not Provided..................................6 2.2 Key Distribution.......................................6 2.3 Data Origin Authentication and Integrity...............7 2.3.2 The SIG Resource Record..............................7 2.3.3 Authenticating Name Non-existence....................8 2.3.5 Special Problems With Time-to-Live...................8 2.3.5 Signers Other Than The Zone..........................9 2.3 DNS Transaction Authentication.........................9 3. The KEY Resource Record................................10 3.1 KEY RDATA format......................................10 3.2 Object Types and DNS Names and Keys...................10 3.3 The KEY RR Flag Octet.................................11 3.4 The KEY Algorithm Version and MD5/RSA Algorithm.......12 3.5 KEY RRs in the Construction of Responses..............13 3.6 File Representation of KEY RRs........................14 4. The SIG Resource Record................................15 4.1 SIG RDATA Format......................................15 4.1.1 Signature Format....................................17 4.1.2 SIG RRs Covering Type ANY...........................18 4.1.3 Zone Transfer (AXFR) SIG............................18 4.1.4 Transaction SIGs....................................19 4.2 SIG RRs in the Construction of Responses..............19 4.3 Processing Responses with SIG RRs.....................20 4.4 File Representation of SIG RRs........................21 5. Non-existent Names.....................................22 5.1 The NXD Resource Record...............................22 5.2 NXD RDATA Format......................................23 5.3 Example...............................................23 5.4 Interaction of NXD RRs and Wildcard RRs...............23 5.5 Blocking NXD Pseudo-Zone Transfers....................24 6. How to Resolve Securely................................25 6.1 Boot File Format......................................25 6.2 Chaining Through Zones................................25 6.3 Secure Time...........................................27 7. Operational Considerations.............................28 Eastlake, Kaufman [Page 36] INTERNET-DRAFT DNS Protocol Security Extensions December 1994 7.1 Key Size Considerations...............................28 7.2 Key Storage...........................................28 7.3 Key Generation........................................29 7.4 Key Lifetimes.........................................29 7.5 Signature Lifetime....................................30 7.6 Root..................................................30 8. Conformance............................................31 8.1 Server Conformance....................................31 8.2 Resolver Conformance..................................31 9. Security Considerations................................32 References................................................32 Authors Addresses.........................................33 Expiration and File Name..................................33 Appendix: Base 64 Encoding................................34 Eastlake, Kaufman [Page 37]   Received: from sol.tis.com by magellan.TIS.COM id aa19729; 27 Dec 94 12:20 EST Received: from fnal.fnal.gov(131.225.9.1) by relay via smap (V1.3) id sma008780; Tue Dec 27 12:22:12 1994 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HL4X40B1PC00OXIT@FNAL.FNAL.GOV>; Tue, 27 Dec 1994 11:21:49 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA05487; Tue, 27 Dec 94 11:21:13 CST Date: Tue, 27 Dec 1994 11:21:12 -0600 From: Matt Crawford Subject: Comments Re: updated draft In-Reply-To: Your message of Sat, 24 Dec 94 03:07:19 EST. <9412240807.AA14806@skidrow.tay.dec.com> Sender: crawdad@munin.fnal.gov To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com Message-Id: <9412271721.AA05487@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > or even different names, but this is strongly discouraged. In > particular, the use of a zone key as a non-zone key will usually > require that the key be kept on line and thereby become much more > vulnerable. ^ private If the spec for AAAA RRs is out as an RFC before the next version of this draft goes in, I urge you to change all references to type A RRs to include type AAAA. That will save an addendum later. > > The SIG is valid until the "signature expiration" time which is an > unsigned number of seconds since the start of 1 January 1970. > > The "time signed" field is an unsigned number of seconds since the > start of 1 January 1970. Could you mention the time zone GMT or UCT or whatever its proper name is? > be 1) SHALL be not less than 512 bits and not more than 2552 bits. n > and e MUST be chosen such that the public exponent is less than 2**24 > - 1 and SHOULD be chosen such that the public exponent is small. Comparison with section 3.6 indicates that "less than or equal to" was meant here. > 4.1.4 Transaction SIGs > [...] > This SIG has a "type covered" field of zero, which is not a valid RR > type. It is calculated by using a "data" (see section 4.1.1) of the > entire preceding DNS reply message, including header, concatenated You can't possibly mean the IP header with its variable TTL field, so could you write "including DNS header" here? > 4.3 Processing Responses with SIG RRs > [...] > message. Only proper direct or hashed RR signets signed by the zone > can authenticate RRs. Is this reference to direct and hashed signets a bit of legacy terminology from earlier versions? > Full server compliance is ability to automatically include SIG, > KEY, and NXD RRs in responses as appropriate, as well as meeting > minimal compliance. Was that "minimal" supposed to be "medium"? _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab   Received: from sol.tis.com by magellan.TIS.COM id aa18895; 1 Jan 95 20:08 EST Received: from inet-gw-2.pa.dec.com(16.1.0.23) by relay via smap (V1.3) id sma009459; Sun Jan 1 20:10:57 1995 Received: from skidrow.tay.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA27731; Sun, 1 Jan 95 17:09:56 -0800 Received: by skidrow.tay.dec.com (5.65/MS-081993); id AA13977; Sun, 1 Jan 1995 20:14:43 -0500 Message-Id: <9501020114.AA13977@skidrow.tay.dec.com> To: Matt Crawford Cc: dns-security@tis.com Subject: Re: Comments Re: updated draft In-Reply-To: Your message of "Tue, 27 Dec 94 11:21:12 CST." <9412271721.AA05487@munin.fnal.gov> Date: Sun, 01 Jan 95 20:14:42 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Matt, Thanks for all your excellent suggestions. I've incorporated them along with some other comments I've gotten and will now submit this draft-ietf-dnssec-secext-03.txt to internet-drafts. From: Matt Crawford In-Reply-To: Your message of Sat, 24 Dec 94 03:07:19 EST. <9412240807.AA14806@skidrow.tay.dec.com> Sender: crawdad@munin.fnal.gov To: "Donald E. Eastlake 3rd (Beast)" Cc: dns-security@tis.com Content-Transfer-Encoding: 7BIT >> or even different names, but this is strongly discouraged. In >> particular, the use of a zone key as a non-zone key will usually >> require that the key be kept on line and thereby become much more >> vulnerable. ^ > private Good clarification. >If the spec for AAAA RRs is out as an RFC before the next version of >this draft goes in, I urge you to change all references to type A >RRs to include type AAAA. That will save an addendum later. I went ahead and made this change where I noticed it. I don't see that it is necessary to wait for AAAA RRs to be RFCified. If the AAAA RFC is not out when this draft is to be submitted as an RFC, I can alway take them out. >> >> The SIG is valid until the "signature expiration" time which is an >> unsigned number of seconds since the start of 1 January 1970. >> >> The "time signed" field is an unsigned number of seconds since the >> start of 1 January 1970. > >Could you mention the time zone GMT or UCT or whatever its proper >name is? GMT. Good point. >> be 1) SHALL be not less than 512 bits and not more than 2552 bits. n >> and e MUST be chosen such that the public exponent is less than 2**24 >> - 1 and SHOULD be chosen such that the public exponent is small. > >Comparison with section 3.6 indicates that "less than or equal to" >was meant here. Right. >> 4.1.4 Transaction SIGs >> [...] >> This SIG has a "type covered" field of zero, which is not a valid RR >> type. It is calculated by using a "data" (see section 4.1.1) of the >> entire preceding DNS reply message, including header, concatenated > >You can't possibly mean the IP header with its variable TTL field, so >could you write "including DNS header" here? I didn't consider that a "DNS reply message" had much to do with the transport envelope around it but I'll make the change you suggest for clarity. >> 4.3 Processing Responses with SIG RRs >> [...] >> message. Only proper direct or hashed RR signets signed by the zone >> can authenticate RRs. > >Is this reference to direct and hashed signets a bit of legacy >terminology from earlier versions? Right. I've changed it to just say SIG RR. >> Full server compliance is ability to automatically include SIG, >> KEY, and NXD RRs in responses as appropriate, as well as meeting >> minimal compliance. > >Was that "minimal" supposed to be "medium"? Yes, this is also and artifact of changing the names of the conformance levels. >_________________________________________________________ >Matt Crawford crawdad@fnal.gov Fermilab Thanks again, Donald   Received: from sol.tis.com by magellan.TIS.COM id aa02586; 4 Jan 95 14:27 EST Received: from kerby.ocsg.com(192.156.168.6) by relay via smap (V1.3) id sma020188; Wed Jan 4 14:29:20 1995 Received: (uucp@localhost) by kerby.ocsg.com (8.6.9/8.6.4 + 8.6.9, dpg hack 5dec94) with UUCP id LAA08875; Wed, 4 Jan 1995 11:19:34 -0800 Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93) id AA03528; Wed, 4 Jan 95 10:45:03 -0800 Date: Wed, 4 Jan 95 10:45:03 -0800 From: Dennis Glatting Message-Id: <9501041845.AA03528@war04.ocsg.com> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: bind-workers@vix.com, dns-security@tis.com Subject: Looking for a Public Domain implementation of the DNS Security Extensions Reply-To: dpg@ocsg.com Is there a public domain implementation of the DNS Security Extensions (draft-ietf-dnssec-secext-03.txt)? Where can I get hold of a copy? -dpg   Received: from sol.tis.com by magellan.TIS.COM id aa02751; 4 Jan 95 14:51 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma021017; Wed Jan 4 14:54:02 1995 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA19799; Wed, 4 Jan 95 14:51:08 EST Message-Id: <9501041951.AA19799@tis.com> Reply-To: James M Galvin To: dpg@ocsg.com Cc: bind-workers@vix.com, dns-security@tis.com Subject: Re: Looking for a Public Domain implementation of the DNS Security Extensions In-Reply-To: Dennis Glatting's message of Wed, 04 Jan 1995 10:45:03 PST. <9501041845.AA03528@war04.ocsg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <22427.789249140.1@tis.com> Date: Wed, 04 Jan 1995 14:52:21 -0500 From: James M Galvin Is there a public domain implementation of the DNS Security Extensions (draft-ietf-dnssec-secext-03.txt)? Where can I get hold of a copy? TIS is developing a version of the extensions you cite, which we expect to be openly available to the Internet community. They are not currently available. We expect to begin beta testing sometime during first quarter 95. We'll let these lists know about our progress and the availability of the software from time to time. Jim   Received: from sol.tis.com by magellan.TIS.COM id aa12931; 5 Jan 95 13:08 EST Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay via smap (V1.3) id sma015974; Thu Jan 5 13:10:15 1995 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06265; 5 Jan 95 12:45 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@magellan.TIS.COM MMDF-Warning: Parse error in original version of preceding line at magellan.TIS.COM Cc: dns-security@tis.com From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-dnssec-secext-03.txt Date: Thu, 05 Jan 95 12:45:56 -0500 Sender: cclark@cnri.reston.va.us Message-Id: <9501051245.aa06265@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Security Working Group of the IETF. Title : Domain Name System Protocol Security Extensions Author(s) : D. Eastlake, C. Kaufman Filename : draft-ietf-dnssec-secext-03.txt Pages : 35 Date : 01/04/1995 The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support a general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to keys for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950104174616.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950104174616.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from sol.tis.com by magellan.TIS.COM id ab05178; 10 Jan 95 22:35 EST Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3) id sma021894; Tue Jan 10 18:13:15 1995 Received: from skidrow.tay.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA05289; Tue, 10 Jan 95 14:21:47 -0800 Received: by skidrow.tay.dec.com (5.65/MS-081993); id AA22223; Tue, 10 Jan 1995 17:26:44 -0500 Message-Id: <9501102226.AA22223@skidrow.tay.dec.com> To: Internet Drafts MMDF-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Cc: dns-security@tis.com Subject: submission of draft-ietf-dnssec-as-map-01.txt Date: Tue, 10 Jan 95 17:26:44 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Please place the following updated draft in the internet drafts directories. Thanks, Donald --------------------------------------------------------------------------- Donald E. Eastlake, III DTN: 226-6577(w) dee@lkg.dec.com 550 King St, LKG2-1/BB3 1-508-486-6577(w) dee@ranger.enet.dec.com Littleton, MA 01460 USA 1-508-486-7417(fax) 1-508-287-4877(h) INTERNET-DRAFT Mapping A.S. Number into the DNS 12 January 1995 Expires 11 July 1995 Mapping Autonomous Systems Number into the Domain Name System ------- ---------- ------- ------ ---- --- ------ ---- ------ Donald E. Eastlake 3rd Status of This Document This draft, file name draft-ietf-dnssec-as-map-01.txt, is intended to be become a standards track RFC concerning DNS and routing security. Distribution of this document is unlimited. Comments should be sent to the DNS Security Working Group mailing list or to the author. This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, munnari.oz.au, or ftp.is.co.za. Donald E. Eastlake 3rd [Page 1] INTERNET-DRAFT Mapping A.S. Numbers into the DNS Abstract One requirement of secure routing is that independent routing entities, such as those identified by Internet Autonomous System Numbers, be able to authenticate messages to each other. Modifications currently being developed (see draft-ietf-dnssec- secext-*.txt) to the Domain Name System will enable it to be used for convenient public key distribution. This draft maps all Autonomous System numbers into DNS Domain Names so that the DNS can be used to distribute their public keys. Acknowledgements The contributions of the following persons to this draft are gratefully acknowledged: Ran Atkinson, Christian Huitema, Tony Li, Michael A. Patton. Donald E. Eastlake 3rd [Page 2] INTERNET-DRAFT Mapping A.S. Numbers into the DNS Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgements...........................................2 Table of Contents..........................................3 1. Introduction............................................4 2. Autonomous System Number Mapping........................5 3. Meaning of RRs..........................................6 4. Security Considerations.................................7 References.................................................7 Author's Address...........................................7 Expiration and File Name...................................7 Donald E. Eastlake 3rd [Page 3] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 1. Introduction There are a number of elements that will be required to secure routing in the Internet. One of these is a way that independently operated top level routing domains be able to authenticate messages to each other. Sharing a private symmetric key between each pair of such domains is impractical. The Autonomous System numbering scheme provides for 2**16 such domains which implies approximately 2**31 pairs, an impractical number of keys to securely generate, install, and periodically replace. The solution is to use public key technology whereby each domain has a private key it can use to sign messages. Other domains that know the corresponding public key can then authenticate these messages. Such authenticated messages can be used to set up and maintain efficient symmetric keys on an as needed basis. But how do the domains securely obtain the Autonomous System number to public key mapping? Extensions currently being developed for the Domain Name System will enable it to be conveniently used for authenticated public key distribution (see draft-ietf-dnssec-secext-*.txt). All that is required is a mapping of Autonomous System numbers into domain names, which is provided by this draft. It should be noted that the public keys retrieved from DNS will likely be used primarily to authenticate initial connection set up messages. Autonomous Systems that need to converse with any frequency will probably negotiate more efficient session keys. Donald E. Eastlake 3rd [Page 4] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 2. Autonomous System Number Mapping Autonomous System (A.S.) numbers are 16 bit quantities, usually written as decimal number whose maximum value would be 65,535. For example, ANS is autonomous system 690. The A.S. number is mapped into a domain name as described below. Take the thousands part of the A.S. number and the number modulo 1,000 as decimal numbers, reverse their order and put a period between them, and then append ".in-as.arpa". This mapping is analogous to the IPv4 address mapping into the in-addr.arpa DNS domain. Thus the domain name correspond to Autonomous System 690 (decimal) is 690.0.in-as.arpa. and the domain corresponding to the largest possible A.S. number is 535.65.in-as.arpa. Donald E. Eastlake 3rd [Page 5] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 3. Meaning of RRs The following guidance is given for some RR types that could be stored under the names mapped from A.S. numbers. The KEY RR is given first, then the rest in alphabetic order. KEY: This type of resource record associates a public key with the Autonomous System (A.S.) designated by its name. Such a public key can be used to authenticate communications with or between A.S.s. The existence of KEY RRs in the reason for mapping A.S. names into the DNS. Under DNS security as proposed in draft-ietf-dnssec- secext-*.txt the KEY RR can be used to store any type of digital key. A: DO NOT place type A RRs at A.S. nodes. A.S. domain names are reserved for Autonomous Systems only and should NOT be used for a host or any type of end entity other than an Autonomous System. CNAME: This type of RR is an alias pointing to another domain name. An A.S. could have a CNAME pointing to a different A.S. but this is not likely to be very useful as A.S. RRs will normally be looked up when the A.S. number is actually encountered in use. MX: There is no special use for an MX RR for an A.S. name. It could point to a host that would accept mail related to that A.S. NS: The presence of NS records under an in-as.arpa name means that it has been carved out as a subzone. This gives the A.S. complete control over the zone refresh parameters and control over the creation of inferior names. No special meaning is currently assigned to such inferior names so, although this is not advised, they could be used for hosts or whatever. PTR: The part of the forward domain tree that administratively corresponds to the A.S. should be indicated by a PTR RR. It some entity, say example.net, has several A.S.s, there would be PTRs to example.net from several names in the in-as.arpa hierarchy. RP: A Responsible Person RR SHOULD appear under each A.S. name telling you who you should contact in the case of problems with that A.S. TXT: Text RRs can be used for comments, postal address, or similar notes under an A.S. name. Donald E. Eastlake 3rd [Page 6] INTERNET-DRAFT Mapping A.S. Numbers into the DNS 4. Security Considerations The entirety of this document concerns a means to map Internet Autonomous System numbers into the Domain Name System (DNS) so that secure DNS can be used to provide secure distribution of Autonomous System's public keys. References [RFC904] - Exterior Gateway Protocol Formal Specification, D. L. Mills [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, November 1987 [RFC1035] - Domain Names - Implementation and Specifications, P. Mockapetris Author's Address Donald E. Eastlake 3rd Digital Equipment Corporation 550 King Street, LKG2-1/BB3 Littleton, MA 01460 Telephone: +1 508 486 6577(w) +1 508 287 4877(h) EMail: dee@lkg.dec.com Expiration and File Name This draft expires 11 July 1995 Its file name is draft-ietf-dnssec-as-map-01.txt. Donald E. Eastlake 3rd [Page 7]   Received: from sol.tis.com by magellan.TIS.COM id aa09017; 11 Jan 95 9:25 EST Received: from venera.isi.edu(128.9.0.32) by relay via smap (V1.3) id sma016133; Wed Jan 11 09:21:06 1995 Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 11 Jan 1995 06:26:48 -0800 From: bmanning@isi.edu Posted-Date: Wed, 11 Jan 1995 06:26:21 -0800 (PST) Message-Id: <199501111426.AA25899@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 11 Jan 1995 06:26:21 -0800 Subject: Re: submission of draft-ietf-dnssec-as-map-01.txt To: "Donald E. Eastlake 3rd" Date: Wed, 11 Jan 1995 06:26:21 -0800 (PST) Cc: internet-drafts@cnri.reston.va.us, dns-security@tis.com In-Reply-To: <9501102226.AA22223@skidrow.tay.dec.com> from "Donald E. Eastlake 3rd" at Jan 10, 95 05:26:44 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 183 You might consider removing the .arpa zone. Recent practice has been to move these sort of zones into the .INT domain. (the inaddr domains for nasps and ipv6 come to mind) --bill   Received: from sol.tis.com by magellan.TIS.COM id aa11635; 11 Jan 95 12:57 EST Received: from inet-gw-1.pa.dec.com(16.1.0.22) by relay via smap (V1.3) id sma019664; Wed Jan 11 12:53:18 1995 Received: from skidrow.tay.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA07037; Wed, 11 Jan 95 09:51:03 -0800 Received: by skidrow.tay.dec.com (5.65/MS-081993); id AA12881; Wed, 11 Jan 1995 12:56:09 -0500 Message-Id: <9501111756.AA12881@skidrow.tay.dec.com> To: bmanning@isi.edu MMDF-Warning: Unable to confirm address in preceding line at magellan.TIS.COM Cc: dns-security@tis.com Subject: Re: submission of draft-ietf-dnssec-as-map-01.txt In-Reply-To: Your message of "Wed, 11 Jan 95 06:26:21 PST." <199501111426.AA25899@zed.isi.edu> Date: Wed, 11 Jan 95 12:56:09 -0500 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp I don't really care and have gotten comments both ways. My feeling was that Autonomous Systems numbers were kind of connected with IPv4 so I'm inclined to put it under .arpa. Donald From: bmanning@isi.edu Posted-Date: Wed, 11 Jan 1995 06:26:21 -0800 (PST) To: "Donald E. Eastlake 3rd" Cc: internet-drafts@cnri.reston.va.us, dns-security@tis.com In-Reply-To: <9501102226.AA22223@skidrow.tay.dec.com> from "Donald E. Eastlake 3rd" at Jan 10, 95 05:2 6:44 pm X-Mailer: ELM [version 2.4 PL24] k> >You might consider removing the .arpa zone. Recent practice has been to move these sort of >zones into the .INT domain. (the inaddr domains for nasps and ipv6 come to mind) > >--bill   Received: from sol.tis.com by magellan.TIS.COM id aa13459; 11 Jan 95 16:58 EST Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay via smap (V1.3) id sma025631; Wed Jan 11 16:55:01 1995 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10180; 11 Jan 95 16:42 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, tis.com@magellan.TIS.COM MMDF-Warning: Parse error in original version of preceding line at magellan.TIS.COM Cc: dns-security@tis.com From: Internet-Drafts@cnri.reston.va.us Reply-To: Internet-Drafts@cnri.reston.va.us Subject: I-D ACTION:draft-ietf-dnssec-as-map-01.txt Date: Wed, 11 Jan 95 16:42:43 -0500 Sender: cclark@cnri.reston.va.us Message-Id: <9501111642.aa10180@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Security Working Group of the IETF. Title : Mapping Autonomous Systems Number into the Domain Name System Author(s) : D. Eastlake Filename : draft-ietf-dnssec-as-map-01.txt Pages : 7 Date : 01/10/1995 One requirement of secure routing is that independent routing entities, such as those identified by Internet Autonomous System Numbers, be able to authenticate messages to each other. Modifications currently being developed (see other draft-ietf-dnssec-*.txt) to the Domain Name System will enable it to be used for convenient public key distribution. This draft maps all Autonomous System numbers into DNS Domain Names so that the DNS can be used to distribute their public keys. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-as-map-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-as-map-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-as-map-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950111122236.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-as-map-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-as-map-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950111122236.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from relay.tis.com by neptune.TIS.COM id aa05870; 7 Feb 95 16:14 GMT Received: by relay.tis.com; id LAA28677; Tue, 7 Feb 1995 11:17:44 -0500 Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V1.3) id sma028659; Tue Feb 7 11:17:27 1995 Received: from magellan.TIS.COM by tis.com (4.1/SUN-5.64) id AA12776; Tue, 7 Feb 95 11:14:49 EST Received: from sol.tis.com by magellan.TIS.COM id aa03181; 7 Feb 95 11:15 EST Received: from magellan.tis.com by tis.com (4.1/SUN-5.64) id AA12756; Tue, 7 Feb 95 11:14:46 EST Reply-To: List Master To: dns-security@tis.com Subject: DNS-SECURITY Archives Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <3174.792173712.1@tis.com> Date: Tue, 07 Feb 1995 11:15:12 -0500 Message-Id: <3176.792173712@tis.com> From: List Master (agent: James M Galvin) The DNS-SECURITY archives are available via anonymous ftp from the host "ftp.tis.com" in the directory "/pub/ietf/dns-security". There you will find files called dns-security-YYMM.txt.Z, which are compressed text files containing all messages sent to the DNS-SECURITY list up through and including the month MM and the year YY. The most recent messages are in a file called "dns-security.mbox". This file is updated automatically as each message is sent to the list. No more waiting for me to update the archives! Yeah!! Enjoy, Jim List Maintainer   Received: from relay.tis.com by neptune.TIS.COM id aa20783; 5 Mar 95 19:13 EST Received: from cs.columbia.edu(128.59.16.20) by relay.tis.com via smap (V1.3) id sma004392; Sun Mar 5 19:17:07 1995 Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.10.7]) by cs.columbia.edu (8.6.10/8.6.6) with ESMTP id TAA21211 for ; Sun, 5 Mar 1995 19:17:32 -0500 Received: (from jakka@localhost) by play.cs.columbia.edu (8.6.10/8.6.6) id TAA26759 for dns-security@tis.com; Sun, 5 Mar 1995 19:17:31 -0500 Date: Sun, 5 Mar 95 19:17:31 EST From: Jakka Sairamesh To: dns-security@tis.com Subject: Subscribe Message-ID: Hello, I am very interested in extensions to DNS to suppory Dynamic Updates and secure way of doing it. I would like to know more about this. Can I subscribe to this mailing list thanks a lot ramesh Center For Telecommunications Columbia University New York, NY, 10027   Received: from relay.tis.com by neptune.TIS.COM id aa27818; 6 Mar 95 17:21 EST Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (a1.4) id sma015486; Mon Mar 6 17:15:30 1995 Message-Id: <9503062215.AA07361@tis.com> Reply-To: James M Galvin To: dns-security@tis.com Subject: non-meeting in Danvers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <27372.794528160.1@tis.com> Date: Mon, 06 Mar 1995 17:16:01 -0500 From: James M Galvin Unless someone has a strong objection, I'm not planning a meeting in Danvers. The current status is as follows. TIS has been implementing the specification. We expect to have a prototype implementation by the Danvers meeting. Eastlake/Kaufman and TIS have been interacting to resolve ambiguities and to otherwise clarify the proposal as it was last presented. The plan is for Eastlake/Kaufman to issue one more version of the specification and then to call for consensus on the mailing list to submit the document for publication as a Proposed Standard. I would expect that this working group will meet either in July or December to present a detailed status of the implementation and some relevant statistics on its operation. Comments? (Silence will be interpreted as agreement, so those who dissent should speak up.) Thanks, Jim   Received: from relay.tis.com by neptune.TIS.COM id aa28077; 6 Mar 95 18:05 EST Received: from fnal.fnal.gov(131.225.9.1) by relay.tis.com via smap (a1.4) id sma016428; Mon Mar 6 18:09:15 1995 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HNTND3YUTS00D36E@FNAL.FNAL.GOV>; Mon, 06 Mar 1995 17:09:40 -0500 (CDT) Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA14449; Mon, 6 Mar 95 17:08:38 CST Date: Mon, 06 Mar 1995 17:08:37 -0600 From: Matt Crawford Subject: Re: non-meeting in Danvers In-reply-to: Your message of Mon, 06 Mar 95 17:16:01 EST. <9503062215.AA07361@tis.com> Sender: crawdad@munin.fnal.gov To: James M Galvin Cc: dns-security@tis.com Message-id: <9503062308.AA14449@munin.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Message-Id: <9503070357.AA11046@necom830.cc.titech.ac.jp> Subject: Re: non-meeting in Danvers To: galvin@tis.com Date: Tue, 7 Mar 95 12:57:32 JST Cc: dns-security@tis.com In-Reply-To: <9503062215.AA07361@tis.com>; from "James M Galvin" at Mar 6, 95 5:16 pm X-Mailer: ELM [version 2.3 PL11] > Unless someone has a strong objection, I'm not planning a meeting in > Danvers. The current status is as follows. > > TIS has been implementing the specification. We expect to have a > prototype implementation by the Danvers meeting. I really wanted to see a promised working implementation well before the meeting. I'm afraid it's too late now, though. > Eastlake/Kaufman and TIS have been interacting to resolve ambiguities > and to otherwise clarify the proposal as it was last presented. Resolve ambiguities and clarify? As the proposal still contains several technical defects, fix them. As Doland himself havs recently said: :IETF is much more likely to implement before standardizing and that, :in some areas, IETF standards are much more successful than those :promulgated by other organizations. it's good to be able to clearly demonstrate the defects with not-working implementations. Otherwise, defects are too subtle to be understood by those who does not have a lot of experience on name server coding. Masataka Ohta   Received: from relay.tis.com by neptune.TIS.COM id aa29192; 10 Mar 95 8:53 EST Received: from mailhub.tis.com(192.33.112.100) by relay.tis.com via smap (a1.4) id sma001569; Fri Mar 10 08:57:04 1995 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA26454; Fri, 10 Mar 95 08:57:03 EST Message-Id: <9503101357.AA26454@tis.com> Reply-To: James M Galvin To: Masataka Ohta Cc: dns-security@tis.com Subject: Re: non-meeting in Danvers In-Reply-To: Masataka Ohta's message of Tue, 07 Mar 1995 12:57:32 +0200. <9503070357.AA11046@necom830.cc.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <20479.794843790.1@tis.com> Date: Fri, 10 Mar 1995 08:56:31 -0500 From: James M Galvin > Eastlake/Kaufman and TIS have been interacting to resolve ambiguities > and to otherwise clarify the proposal as it was last presented. Resolve ambiguities and clarify? As the proposal still contains several technical defects, fix them. We, TIS, are not aware of any technical defects. We've really had very little trouble implementing the specifications as written. Thanks, Jim   Received: from relay.tis.com by neptune.TIS.COM id aa15044; 12 Mar 95 21:42 EST Received: from unknown(131.112.32.132) by relay.tis.com via smap (a1.4) id sma017821; Sun Mar 12 21:45:25 1995 Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 13 Mar 95 11:44:26 +0900 From: Masataka Ohta Message-Id: <9503130244.AA10698@necom830.cc.titech.ac.jp> Subject: Re: non-meeting in Danvers To: galvin@tis.com Date: Mon, 13 Mar 95 11:44:24 JST Cc: dns-security@tis.com In-Reply-To: <9503101357.AA26454@tis.com>; from "James M Galvin" at Mar 10, 95 8:56 am X-Mailer: ELM [version 2.3 PL11] > > Eastlake/Kaufman and TIS have been interacting to resolve ambiguities > > and to otherwise clarify the proposal as it was last presented. > > Resolve ambiguities and clarify? > > As the proposal still contains several technical defects, fix > them. > > We, TIS, are not aware of any technical defects. It is not surprising that you, who can't understand why non-authoritative delegation can't be authenticated, can't detect other defects. > We've really had very > little trouble implementing the specifications as written. The defect is not in cryptographic part on which TIS people have a lot of expertise, but in DNS part. Give the large amount of delay, I suspect there yet exist no implementation with sufficient functionality on DNS protocols. Let us check your implementation. Masataka Ohta   Received: from relay.tis.com by neptune.TIS.COM id aa11942; 31 Mar 95 13:06 EST Received: from callandor.cybercash.com(204.178.186.70) by relay.tis.com via smap (a1.4) id sma010241; Fri Mar 31 13:10:52 1995 Received: by callandor.cybercash.com; id RAA18786; Thu, 30 Mar 1995 17:29:14 -0500 Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (V1.3) id sma018782; Thu Mar 30 17:28:49 1995 Received: by cybercash.com (4.1/SMI-4.1) id AA05003; Fri, 31 Mar 95 13:08:26 EST Date: Fri, 31 Mar 95 13:08:26 EST From: "Donald E. Eastlake" Message-Id: <9503311808.AA05003@cybercash.com> To: dns-security@tis.com Subject: preliminary version of next dnssec draft DNS Security Working Group Donald E. Eastlake, 3rd INTERNET-DRAFT CyberCash Charles W. Kaufman Iris Expires: 1 Oct 1995 31 Mar 1995 Domain Name System Protocol Security Extensions ------ ---- ------ -------- -------- ---------- Status of This Document This draft, file name draft-ietf-dnssec-secext-04.txt, is intended to be become a Proposed Standard RFC. Distribution of this document is unlimited. Comments should be sent to the DNS Security Working Group mailing list or to the authors. This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, munnari.oz.au, or ftp.is.co.za. Eastlake, Kaufman [Page 1] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 Abstract The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support a general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to keys for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions. Acknowledgements The significant contributions of the following persons (in alphabetic order) to this draft are gratefully acknowledged: Madelyn Badger, Matt Crawford, James M. Galvin, Olafur Gudmundsson, Sandy Murphy, Masataka Ohta, Michael A. Patton, Jeffrey I. Schiller. Eastlake, Kaufman [Page 2] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 Table of Contents Status of This Document....................................1 Abstract...................................................2 Acknowledgements...........................................2 Table of Contents..........................................3 1. Overview of Contents....................................5 2. Brief Overview of the Extensions.......................6 2.1 Services Not Provided..................................6 2.2 Key Distribution.......................................6 2.3 Data Origin Authentication and Integrity...............7 2.3.2 The SIG Resource Record..............................7 2.3.3 Authenticating Name Non-existence....................8 2.3.4 Special Problems With Time-to-Live...................8 2.3.5 Signers Other Than The Zone..........................9 2.4 DNS Transaction Authentication.........................9 3. The KEY Resource Record................................10 3.1 KEY RDATA format......................................10 3.2 Object Types and DNS Names and Keys...................10 3.3 The KEY RR Flag Octet.................................11 3.4 The KEY Algorithm Number and the MD5/RSA Algorithm....12 3.5 KEY RRs in the Construction of Responses..............13 3.6 File Representation of KEY RRs........................14 4. The SIG Resource Record................................15 4.1 SIG RDATA Format......................................15 4.1.1 Signature Format....................................17 4.1.2 SIG RRs Covering Type ANY...........................18 4.1.3 Zone Transfer (AXFR) SIG............................19 4.1.4 Transaction SIGs....................................19 4.2 SIG RRs in the Construction of Responses..............20 4.3 Processing Responses and SIG RRs......................20 4.4 Signature Expiration, TTLs, and Validity..............21 4.5 File Representation of SIG RRs........................22 5. Non-existent Names.....................................23 5.1 The NXD Resource Record...............................23 5.2 NXD RDATA Format......................................24 5.3 Example...............................................24 5.4 Interaction of NXD RRs and Wildcard RRs...............24 5.5 Blocking NXD Pseudo-Zone Transfers....................25 6. How to Resolve Securely................................27 6.1 Boot File Format......................................27 6.2 Chaining Through Zones................................28 Eastlake, Kaufman [Page 3] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 6.3 Secure Time...........................................29 6.4 Resolver Response Code................................29 7. Operational Considerations.............................31 7.1 Key Size Considerations...............................31 7.2 Key Storage...........................................31 7.3 Key Generation........................................32 7.4 Key Lifetimes.........................................32 7.5 Signature Lifetime....................................33 7.6 Root..................................................33 8. Conformance............................................34 8.1 Server Conformance....................................34 8.2 Resolver Conformance..................................34 9. Security Considerations................................35 References................................................35 Authors Addresses.........................................36 Expiration and File Name..................................36 Appendix: Base 64 Encoding................................37 Eastlake, Kaufman [Page 4] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 1. Overview of Contents This draft describes extensions of the Domain Name System (DNS) protocol to support DNS security and public key distribution. It assumes that the reader is familiar with the Domain Name System, particularly as described in RFCs 1034 and 1035. Section 2 provides an overview of the extensions and the key distribution, data origin authentication, and transaction security they provide. Section 3 discusses the KEY resource record, its structure, use in DNS responses, and file representation. These resource records represent the pubic keys of entities name in the DNS and are used for key distribution. Section 4 discusses the SIG digital signature resource record, its structure, use in DNS responses, and file representation. These resource records are used to authenticate other resource records in the DNS and optionally to authenticate DNS transactions. Section 5 discusses the NXD resource record and its use in DNS responses. The NXD RR permits authenticated denial of the existence of a name in the DNS. Section 6 discusses how a resolver can be configured with a starting key or keys and proceed to securely resolve DNS requests. New response statuscodes needed to reflect the security component of responses to security aware applications are also enumerated. Section 7 reviews a variety of operational considerations including key generation, lifetime, and storage. Section 8 defines levels of conformance for resolvers and servers. Section 9 provides a few paragraphs on overall security considerations. Eastlake, Kaufman [Page 5] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 2. Brief Overview of the Extensions The DNS protocol security extensions provide three distinct services: key distribution as described in section 2.2 below, data origin authentication as described in section 2.3 below, and transaction authentication, described in section 2.4 below. 2.1 Services Not Provided It is part of the design philosophy of the DNS that the data in it is public and that the DNS gives the same answers to all inquirers. Following this philosophy, no attempt has been made to include any sort of access control lists or other means to differentiate inquirers. In addition, no effort has been made to provide for any confidentiality for queries or responses. (This service may be available via a network level security protocol for which there is current an IETF working group.) 2.2 Key Distribution Resource records are defined to associate keys with DNS names. This permits the DNS to be used as a general public key distribution mechanism in support of the data origin authentication and transaction authentication DNS services as well as other security services such as network level security. The syntax of a KEY resource record is described in Section 3. It includes the name of the entity the key is associated with (frequently but not always the KEY resource record owner name), an algorithm identifier, flags indicating the type of entity the key is associated with and/or asserting that there is no key associated with that entity, and the actual public key parameters. Under conditions described in Section 3, security aware DNS servers will automatically attempt to return KEY resources as additional information, along with those resource records actually requested, to minimize the number of queries needed. Eastlake, Kaufman [Page 6] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 2.3 Data Origin Authentication and Integrity Security is provided by associating with resource records in the DNS cryptographically generated digital signatures. Commonly, there will be a single private key that signs for an entire zone. If a security aware resolver reliably learns the public key of the zone, it can verify, for any data read from that zone, that it was properly authorized and is reasonably current. The expected implementation is for the zone private key to be kept off-line and used to re-sign all of the records in the zone periodically. The data origin authentication key belongs to the zone and not to the servers that store copies of the data. That means compromise of a server or even all servers for a zone will not necessarily affect the degree of assurance that a resolver has that the data is genuine. A resolver can learn the public key of a zone either by reading it from DNS or by having it staticly configured. To reliably learn the public key by reading it from DNS, the key itself must be signed. Thus, to provide a reasonable degree of security, the resolver must be configured with at least the public key of one zone. From that, it can securely read the public keys of other zones if the intervening zones in the DNS tree are secure. It is in principle more secure to have the resolver manually configured with the public keys of multiple zones, since then the compromise of a single zone would not permit the faking of information from other zones. It is also more administratively cumbersome, however, particularly when public keys change. Adding origin authentication and integrity requires no change to the "on-the-wire" DNS protocol beyond the addition of the signature resource types (and, as a practical matter, the key resource type needed for key distribution). This service can be supported by existing resolver and server implementations so long as they can support the additional resource types (see Section 8). If signatures are always separately retrieved and verified when retrieving the information they authenticate, there will be more trips to the server and performance will suffer. To avoid this, security aware servers mitigate that degradation by automatically sending exactly the signature(s) needed where possible. 2.3.2 The SIG Resource Record The syntax of a SIG resource record (signature) is described in Section 4. It includes the type of the RR(s) being signed, the name of the signer, the time at which the signature was created, the time it expires (when it is no longer to be believed), its original time Eastlake, Kaufman [Page 7] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 to live (which may be longer than its current time to live but cannot be shorter), the cryptographic algorithm in use, and the actual signature. Every name in a zone supporting signed data will have associated with it at least one SIG resource record for each resource type under that name. A security aware server supporting the performance enhanced version of the DNS protocol security extensions will attempt to return, with all records retrieved, the corresponding SIGs. If a server does not support the protocol, the resolver must retrieve all the SIG records for a name and select the one or ones that sign the resource record(s) that resolver is interested in. 2.3.3 Authenticating Name Non-existence The above security mechanism provides only a way to sign existing RRs in a zone. Data origin authentication is not obviously provided for the non-existence of a domain name in a zone. This gap is filled by the NXD RR which authenticatably asserts a range of non-existent names in a zone. The owner of the NXD RR is the start of such a ranger and its RDATA is the end of the range; however, there are additional complexities due to wildcards. Section 6 below covers the NXD RR. 2.3.4 Special Problems With Time-to-Live A digital signature will fail to verify if any change has occurred to the data between the time it was originally signed and the time the signature is verified. This conflicts with our desire to have the time-to-live field tick down when resource records are cached. This could be avoided by leaving the time-to-live out of the digital signature, but that would allow unscrupulous secondaries to set arbitrarily long time to live values undetected. Instead, we include the "original" time-to-live in the signature and communicate that data in addition to the current time-to-live. Unscrupulous servers under this scheme can manipulate the time to live but a security aware resolver will bound the TTL value it uses at the original signed value. Separately, signatures include a time signed and an expiration time. A resolver that knows an absolute time can determine securely whether a signature has expired. It is not possible to rely solely on the signature expiration as a substitute for the TTL, however, since non-security aware servers must still be supported. Eastlake, Kaufman [Page 8] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 2.3.5 Signers Other Than The Zone There are two general cases where a SIG resource record is signed by other than the zone private key. One is for future support of dynamic update where an entity is permitted to authenticate/update its own records. The public key of the entity must be present in the DNS and be appropriately signed but the other RR(s) may be signed with the entity's key. The other is for support of transaction authentication as described in Section 2.4 below. 2.4 DNS Transaction Authentication The data origin authentication service described above protects resource records but provides no protection for DNS message headers. If header bits are falsely set by a server, there is little that can be done. However, it is possible to add transaction authentication. Such authentication means that a resolver can be sure it is getting messages from the server it thinks it queried and that the response is from the query it sent and that these messages have not been diddled in transit. This is accomplished by optionally adding a special SIG resource record to the end of the reply which digitally signs the concatenation of the server's response and the resolver's query. The private key used belongs to the host composing the reply, not to the zone being queried. The corresponding public key is stored in and retrieved from the DNS. Because replies are highly variable, message authentication SIGs can not be pre-calculated. Thus it will be necessary to keep the private key on-line, for example in software or in a directly connected piece of hardware. DNS level transaction authentication would be unnecessary if a lower level (i.e., IP level) end-to-end security protocol were available. However, such a protocol is not yet standardized and when it is, there will be a significant time during which there will be systems on which it will be hard to add IPSEC but relatively easy to replace the DNS components. Eastlake, Kaufman [Page 9] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 3. The KEY Resource Record The KEY RR is used to document a key that is associated with a DNS name. It will be a public key as only public keys are stored in the DNS. This can be the public key of a zone owner, of a host or other end entity, or a user. A KEY RR is, like any other RR, authenticated by a SIG RR. Security aware DNS implementations should be designed to handle at least two simultaneously valid keys of the same type associated with a name. The type number for the KEY RR is 25. 3.1 KEY RDATA format The RDATA for a KEY RR consists of an object name, flags, the algorithm number, and the public key itself. The format is as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / +- object name +---------------+---------------+ / | flags | algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / + - public key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ The object name and flags octets are described in Sections 3.2 and 3.3 below respectively. The flags must be examined before any following data as they control the format and even whether there is any following data. The algorithm and public key fields are described in Section 3.4. The format of the public key is algorithm dependent. 3.2 Object Types and DNS Names and Keys The public key in a KEY RR belongs to the object named in the object name field. Frequently this will also be the owner name of the KEY RR. But they will be different in the case of the key or keys stored under a zone's name for the zone's superzone or keys that are stored for cross certification of other zones. The object name may be compressed with standard DNS name compression when being transmitted over the network. Eastlake, Kaufman [Page 10] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 The DNS object name may refer to up to three different things. For example, dee.cybercash.com could be (1) a zone, (2) a host or other end entity , and (3) the mapping into a DNS name of the user or account dee@cybercash.com . Thus, there are flags in the KEY RR to indicate with which of these roles the object name and public key are associated as described below. Except for the case of cross certification, where the object name isn't in the zone at all, the object name and owner name of a KEY RR will be the same. The inclusion of a superzone's key in its subzone is a special case of cross certification. Although the same name can be used for up to all three of these contexts, such overloading of a name is discouraged. It is also possible to use the same key for different things with the same name or even different names, but this is strongly discouraged. In particular, the use of a zone key as a non-zone key will usually require that the private key be kept on line and thereby become much more vulnerable. It would be desirable for the growth of DNS to be managed so that additional possible simultaneous uses for names are NOT added. New uses should be distinguished by exclusive domains. For example, all IP autonomous system numbers have been mapped into the in-as.arpa domain [draft-ietf-dnssec-as-map-*.txt] and all telephone numbers in the world have been mapped into the tpc.int domain [RFC 1530]. This is much preferable to having the same name possibly be an autonomous system number, telephone number, and/or host as well as a zone and a user. In addition to the name type bits, there are additional control bits, the "no key" bit, the "experimental" bit, and the "signatory" field, as described below. 3.3 The KEY RR Flag Octet In the "flags" field: Bit 0 is the "no key" bit. If this bit is on, there is no key information and the RR stops with the flags octet. By the use of this bit, a signed KEY RR can authenticatably assert that, for example, a zone is not secured. Bit 1 is the "experimental" bit. Keys may be associated with zones, entities, or users for experimental, trial, or optional use, in which case this bit will be one. If this bit is a zero, it means that the use or availability of security based on the key is "mandatory". Thus, if this bit is off for a zone, the zone should be assumed secured by SIG RRs and any responses indicating the zone is Eastlake, Kaufman [Page 11] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 not secured should be considered bogus. If this bit is a one for a host or end entity, it might sometimes operate in a secure mode and at other times operate without security. The experimental bit, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR. The experimental bit must be zero for safe secure operation and should only be a one for a minimal transition period. Bits 2-4 are the "signatory" field. If non-zero, it indicates that the key can validly sign RRs of the same name. If the owner name is a wildcard, then RRs with any name which is in the wildcard's scope can be signed including NS and corresponding zone KEY RRs to carve out a subzone. Seven different non-zero values are possible for this field and any differences in their meaning are reserved for definition in connection with possible future DNS dynamic update or other new DNS commands. This field is meaningless for zone keys which always have authority to sign any RRs in the zone. The signatory field, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR. Bit 5 on indicates that this is a key associated with a "user" or "account" at an end entity, usually a host. The coding of the owner name is that used for the responsible individual mailbox in the SOA record: The owner name is the user name as the name of a node under the entity name. For example, "j.random_user" on host.subdomain.domain could have a public key associated through a KEY RR with name j\.random_user.host.subdomain.domain. It could be used in an security protocol where authentication of a user was desired. This key would be useful in IP or other security for a user level service such a telnet, ftp, rlogin, etc. Bit 6 on indicates that this is a key associated with the non- zone entity whose name is the RR owner name. This will commonly be a host but could, in some parts of the DNS tree, be some other type of entity such as an Autonomous System [draft-ietf-dnssec-as-map-*.txt]. This is the public key used in connection with the optional DNS transaction authentication service that can be used if the owner name is a DNS server host. It could also be used in an IP-security protocol where authentication of a host was desired. Bit 7 on indicates that this is a zone key for the zone whose name is the KEY RR owner name. This is the fundamental type of DNS data origin authentication public key. 3.4 The KEY Algorithm Number and the MD5/RSA Algorithm This octet is the key algorithm parallel to the same field for the SIG resource. The MD5/RSA algorithm described in this draft is Eastlake, Kaufman [Page 12] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 number 1. Numbers 2 through 253 are available for assignment should sufficient reason arise. However, the designation of a new algorithm could have a major impact on interoperability and requires an IETF standards action. Number 254 is reserved for private use and will never be assigned a specific algorithm. For number 254, the public key area shown in the packet diagram above will actually begin with an Object Identifier (OID) indicating the private algorithm in use and the remainder of the area is whatever is required by that algorithm. Algorithms 0 and 255 are reserved. If the no key bit is zero and the algorithm field is 1, indicating the MD5/RSA algorithm, the public key filed is structured as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | public key exponent | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | / +- modulus / | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ The public key exponent is a 24 bit unsigned integer. The public key modulus field is a multiprecision unsigned integer. The length of the modulus can be determined from the RDLENGTH and the preceding RDATA fields. Leading zero bytes are prohibited in the modulus. 3.5 KEY RRs in the Construction of Responses An explicit request for KEY RRs does not cause any special additional information processing except, of course, for the corresponding SIG RR from a security aware server. Security aware DNS servers will include KEY RRs as additional information in responses where appropriate including the following: (1) On the retrieval of NS RRs, the zone key KEY RR(s) for the zone served by these name servers will be included. If not all additional info will fit, the KEY RR(s) have lower priority than type A or AAAA glue RRs. (2) On retrieval of type A or AAAA RRs, the end entity KEY RR(s) will be included. On inclusion of A or AAAA RRs as additional information, their KEY RRs will also be included but with lower priority than the relevant A or AAAA RRs. Eastlake, Kaufman [Page 13] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 3.6 File Representation of KEY RRs KEY RRs may appear as lines in a zone data file. In the RDATA portion, the object name appears first. The flag octet and algorithm number octets are then represented as unsigned integers; however, if the "no key" flag is on in the flags, nothing appears after the flag octet. The public key is represented in base 64 (see Appendix) and may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to obtain the full signature. These substrings can span lines using the standard parenthesis. Note that the public key may have internal sub-fields but these do not appear in the master file representation. For example, with algorithm 1 there is a public exponent and then a modulus and with algorithm 254, there will be an OID followed by algorithm dependent information. Eastlake, Kaufman [Page 14] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 4. The SIG Resource Record The SIG or "signature" resource record (RR) is the fundamental way that data is authenticated in the secure DNS. As such it is the heart of the security provided. The SIG RR unforgably authenticates other RRs of a particular type, class, and name and binds them to a time interval and the signer's fully qualified domain name. This is done using cryptographic techniques and the signer's private key. The signer is frequently the owner of the zone from which the RR originated. 4.1 SIG RDATA Format The RDATA portion of a SIG RR is as shown below. The integrity of the RDATA information is protected by the signature field. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type covered | algorithm | labels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | original TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signature expiration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time signed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key footprint | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / +- signature / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value of the SIG RR type is 24. The "type covered" is the type of the other RRs covered by this SIG. The algorithm number is an octet specifying the digital signature algorithm used. The MD5/RSA algorithm described in this draft is number 1. Numbers 2 through 253 are available for assignment should sufficient reason arise to allocate them. However, the designation of a new algorithm could have a major impact on the interoperability of the global DNS systems and requires an IETF standards action. Number 254 is reserved for private use and will not be assigned a Eastlake, Kaufman [Page 15] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 specific algorithm. For number 254, the "signature" area shown above will actually begin with an Object Identified (OID) indicating the private algorithm in use and the remainder of the signature area is whatever is required by that algorithm. Numbers 0 and 255 are reserved. The "labels" octet is an unsigned count of how many labels there are in the original SIG RR owner name not counting the null label for root and not counting any initial "*" for a wildcard. If a secured retrieval is the result of wild card substitution, it is necessary for the resolver to use the original form of the name in verifying the digital signature. This field helps optimize the determination of the original form reducing the effort in authenticating signed data. If, on retrieval, the RR appears to have a longer name than indicated by "labels", the resolver can tell it is the result of wildcard substitution. If the RR owner name appears to be shorter than the labels count, the SIG RR should be considered corrupt and ignored. The maximum number of labels possible in the current DNS is 127 but the entire octet is reserved and would be required should DNS names ever be expanded to 255 labels. The following table give some examples. The value of "labels" is at the top, the retrieved owner name on the left, and the table entry is the name to use in signature verification except that "bad" means the RR is corrupt. labels= | 0 | 1 | 2 | 3 | 4 | --------+-----+------+--------+----------+----------+ .| . | bad | bad | bad | bad | d.| *. | d. | bad | bad | bad | c.d.| *. | *.d. | c.d. | bad | bad | b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad | a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. | The "original TTL" field is included in the RDATA portion to avoid (1) authentication problems that caching servers would otherwise cause by decrementing the real TTL field and (2) security problems that unscrupulous servers could otherwise cause by manipulating the real TTL field. This original TTL is protected by the signature while the current TTL field is not. NOTE: The "original TTL" must be restored into the covered RRs when the signature is verified. This implies that the RRs need to all have the same TTL to start with. The SIG is valid until the "signature expiration" time which is an unsigned number of seconds since the start of 1 January 1970, GMT, ignoring leap seconds, but see also section 4.4. The "time signed" field is an unsigned number of seconds since the Eastlake, Kaufman [Page 16] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 start of 1 January 1970, GMT, ignoring leap seconds. The "key footprint" is a 16 bit quantity that is used to help efficiently select between multiple keys which may be applicable and as a quick check that a public key about to be used for the computationally expensive effort to check the signature is possibly valid. Its exact meaning is algorithm dependent. For the MD5/RSA algorithm, it is the next to the bottom two octets of the public key modulus needed to decode the signature field. That is to say, the most significant 16 of the lest significant 24 bits of this quantity in network order. The "signer's name" field is the fully qualified domain name of the signer generating the SIG RR. This is frequently the zone which contained the RR(s) being authenticated. The signer's name may be compressed with standard DNS name compression when being transmitted over the network. The structured of the "signature" field depends on the algorithm chosen and is described below for the MD5/RSA algorithm. 4.1.1 Signature Format The actual signature portion of the SIG RR binds the other RDATA fields to all of the "type covered" RRs with that owner name. These covered RRs are thereby authenticated. To accomplish this, a data sequence is constructed as follows: data = RDATA | RR(s)... where | is concatenation, RDATA is all the RDATA fields in the SIG RR itself before the signature, and RR(s) are all the RR(s) of the type covered with the same owner name and class as the SIG RR in canonical form and order. For purposes of DNS security, the canonical form for an RR is the RR with domain names (1) fully expanded (no name compression via pointers) and (2) all domain name letters set to lower case. For purposes of DNS security, the canonical order for RRs is to sort them in ascending order as left justified unsigned octet sequences in network (transmission) order where a missing octet sorts before a zero octet. How this data sequence is processed into the signature is algorithm dependent. For the MD5/RSA algorithm, the signature is as follows Eastlake, Kaufman [Page 17] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 hash = MD5 ( data ) signature = ( 01 | FF* | 00 | hash ) ** e (mod n) where MD5 is the message digest algorithm documented in RFC 1321, "|" is concatenation, "e" is the secret key exponent of the signer, and "n" is the public modulus that is the signer's public key. 01, FF, and 00 are fixed octets of the corresponding hexadecimal value. The FF octet is repeated the maximum number of times such that the value of the quantity being exponentiated is one octet shorter than the value of n. The size of n, including most and least significant bits (which will be 1) SHALL be not less than 512 bits and not more than 2552 bits. n and e MUST be chosen such that the public exponent is less than or equal to 2**24 - 1 and SHOULD be chosen such that the public exponent is small. Leading zeros bytes are not permitted in the MD5/RSA algorithm signature. The above specifications are similar to Public Key Cryptographic Standard #1 [PKCS1]. A public exponent of 3 minimizes the effort needed to decode a signature. Use of 3 as the public exponent may be weak for confidentiality uses since, if the same data can be collected encrypted under three different keys with an exponent of 3 then, using the Chinese Remainder Theorem, the original plain text can be easily recovered. This weakness is not significant for DNS because we seek only authentication, not confidentiality. 4.1.2 SIG RRs Covering Type ANY The SIG RR described above protects all of the set of RRs with a particular owner name, class, and type. Thus a server must supply all of such RRs to convince a security aware resolver. However, an unscrupulous server could claim there were no RRs of a particular type and class under an owner name while presenting signed RRs of the same name and class but other types. To provide a means of protection against this, one or more SIG RRs that cover the type ANY are added for each owner name. They are calculated as indicated above except that all RRs for the owner name, class, and SIG key, except any SIG RRs covering type ANY itself, are included in the data string which is processed into the signature. To allow for dynamic update, the zone key signed ANY SIG RR covers only zone signed RRs. If RRs are added to a zone authenticated by an Eastlake, Kaufman [Page 18] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 entity or user key, they are not covered by an ANY SIG. 4.1.3 Zone Transfer (AXFR) SIG The above SIG mechanisms assure the authentication of all zone signed RRs of a particular name, class and type and of a particular name, class and any type. However, to secure complete zone transfers, a SIG RR owned by the zone name must be created with a type covered of AXFR that covers all other zone signed RRs. It will be calculated by hashing together all other static zone RRs, including SIGs. The RRs are ordered and concatenated for hashing as described in Section 4.1.1 except that the type ANY SIGs are placed at the end of all other types for the same owner name. The AXFR SIG must be calculated last of all zone key signed SIGs in the zone. It really belongs to the zone as a whole, not the the zone name, and is not included in the calculation of any SIG covering type ANY. The AXFR SIG is only retrieved as part of a zone transfer. Dynamic zone RRs which might be added by some future dynamic zone update protocol and signed by an end entity or user key rather than a zone key (see Section 3.2) are not included. They originate in the network and will not, in general, be migrated to the recommended off line zone signing procedure (see Section 8.2). Thus such dynamic RRs are not directly signed by the zone and are not generally protected against omission during zone transfers. 4.1.4 Transaction SIGs A response message from a security aware server may optionally contain a special SIG as the last item in the additional information section to authenticate the transaction. This SIG has a "type covered" field of zero, which is not a valid RR type. It is calculated by using a "data" (see section 4.1.1) of the entire preceding DNS reply message, including DNS header, concatenated with the entire DNS query message that produced this response, including the query's DNS header. That is data = full response (less trailing message SIG) | full query Verification of the message SIG (which is signed by the server host key, not the zone key) by the requesting resolver shows that the query and response were not tampered with in transit and that the response corresponds to the intended query. Eastlake, Kaufman [Page 19] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 4.2 SIG RRs in the Construction of Responses Security aware servers MUST, for every authoritative RR the query will return, attempt to send the available SIG RRs which authenticate the requested RR. If multiple such SIGs are available, there may be insufficient space in the response to include them all. In this case, SIGs whose signer is the zone containing the RR MUST be given highest priority and retained even if SIGs with other signers must be dropped. Sending SIGs to authenticate non-authoritative data (glue records and NS RRs for subzones) is optional and should be avoided if it would lead to UDP DNS response truncation. Note that KEYs for subzones are authoritative. If a SIG covers any RR that would be in the answer section of the response, its automatic inclusion MUST be the answer section. If it covers an RR that would appear in the authority section, its automatic inclusion MUST be in the authority section. If it covers an RR that would appear in the additional information section it MUST appear in the additional information section. Optionally, DNS transactions may be authenticated by a SIG RR at the end of the response in the additional information section (section 4.1.4). Such SIG RRs are signed by the DNS server originating the response. Although the signer field must be the name of the originating server host, the owner name, class, TTL, and original TTL, are meaningless. The class and TTL fields can be zero. To save space, the owner name should be root (a single zero octet). [There may be a problem with SIG and NXD RR's associated with domain names that are CNAMEs. The DNS RFCs prohibit other types of RRs appearing with a CNAME RR. This problem is being ignored until it is clear if DNS servers will really have a problem with this.] 4.3 Processing Responses and SIG RRs If SIG RRs are received in response to a query initiated outside the resolver explicitly specifying the SIG type, no special processing is required. A security aware client MAY, in this case, wish to authenticate them by checking the signature and applying consistency checks. If SIG RRs are received in any other response (i.e., SIGs sent spontaneously by a security aware server or requested for security purposes from a non-security aware server by a security aware resolver), a security aware resolver MUST check them using the public key of the signer. The result should then be verified against the Eastlake, Kaufman [Page 20] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 appropriate other RRs retrieved. If the message does not pass reasonable checks or the SIG does not check against the signed RRs, the SIG RR is invalid and should be ignored. If all of the SIG RR(s) purporting to authenticate a set of RRs are invalid, then the set of RR(s) is not authenticated and should generally be ignored. If the SIG RR is the last RR in a response in the additional information section and has a type covered of zero, it is a transaction signature of the response and the query that produced the response. It MAY be optionally checked and the message rejected if the checks fail. But even it the checks succeed, such a transaction authentication SIG does NOT authenticate any RRs in the message. Only a proper SIG RR signed by the zone can authenticate RRs. If a resolver does not implement transaction SIGs, it MUST at least ignore them without error. If all reasonable checks indicate that the SIG RR is valid then RRs verified by it should be considered authenticated. If a response, other than a query initiated outside the resolver explicitly specifying the SIG type which fails, is received without SIGs, the resolver should act as follows: if the zone is secure, the resolver should spontaneously initiate a query to the same resolver for the SIGs covering any retrieved RRs and hold those RRs in a neither valid nor invalid state pending the results of this query; if the zone is insecure, the RRs should be accepted but marked as not authenticated. 4.4 Signature Expiration, TTLs, and Validity Security aware servers should not consider SIG RRs to be authentic after their expiration time and not consider any RR to be valid after its signatures have expired. Within that constraint, servers should continue to follow DNS TTL aging. Thus authoritative servers should continue to follow the zone refresh and expire parameters and a non- authoritative server should count down the TTL and discard RRs when the TTL is zero. In addition, when RRs are transmitted in a query response, the TTL should be trimmed so that current time plus the TTL does not extend beyond the signature expiration time. Thus, in general, the TTL on an transmitted RR would be min(sigExpTim,max(zoneMinTTL,min(originalTTL,currentTTL))) Eastlake, Kaufman [Page 21] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 4.5 File Representation of SIG RRs A SIG RR can be represented as a single logical line in a zone data file [RFC1033] but there are some special problems as described below. (It does not make sense to include a transaction authenticating SIG RR in a file as it is a transient authentication that must be calculated in real time by the DNS server.) There is no particular problem with the signer, covered type, and times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY is the year, the first MM is the month number (01-12), DD is the day of the month (01-31), HH is the hour in 24 hours notation (00-23), the second MM is the minute (00-59), and SS is the second (00-59). The original TTL and algorithm fields appears as unsigned integers. The "labels" field does not appear in the file representation as it can be calculated from the owner name. The key footprint appears as an unsigned decimal number. However, the signature itself can be very long. It is the last data field and is represented in base 64 (see Appendix) and may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to obtain the full signature. These substrings can be split between lines using the standard parenthesis. Eastlake, Kaufman [Page 22] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 5. Non-existent Names The SIG RR mechanism described in section 4 above provides strong authentication of RRs that exist in a zone. But is it not immediately clear how to authenticatably deny the existence of a name in a zone. The nonexistence of a name in a zone is indicated by the NXD RR for a name interval containing the nonexistent name. An NXD RR and its SIG are returned in the authority section, along with the error, if the server is security aware. NXD RRs will also be returned if an explicit query is made for the NXD type. The existence of a complete set of NXD records in a zone means that any query for any name to a security aware server serving the zone should result in an reply containing at least one signed RR. NXD RRs do not appear in zone master files since they can be derived from the rest of the zone. 5.1 The NXD Resource Record The NXD resource record is used to securely indicate that no RRs with an owner name in a certain name interval exist in a zone. The owner name of the NXD RR is an existing name in the zone. It's RDATA is another existing name in the zone. The presence of the NXD RR means that no name between its owner name and the name in its RDATA area exists. This implies a canonical ordering of all domain names in a zone. The ordering is to sort labels as unsigned left justified octet strings where the absence of a byte sorts before a zero byte. Names are then sorted by sorting on the highest level label and then, within those names with the same highest level label by the next lower label, etc. Since we are talking about a zone, the zone name itself always exists and all other names are the zone name with some prefix of lower level labels. Thus the zone name itself always sorts first. There is a slight problem with the last NXD in a zone as it wants to have an owner name which is the last existing name in sort order, which is easy, but it is not obvious what name to put in its RDATA to indicate the entire remainder of the name space. This is handled by treating the name space as circular and putting the zone name in the RDATA of the last NXD. There are additional complexities due to interaction with wildcards Eastlake, Kaufman [Page 23] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 as explained below. The NXD RRs for a zone can be automatically calculated and added to the zone by the same recommended off-line process that signs the zone. The NXD RR's TTL should not exceed the zone minimum TTL. 5.2 NXD RDATA Format The RDATA for an NXD RR consists simply of a domain name. The type number for the NXD RR is 30. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next domain name / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3 Example Assume a zone has entries for big.foo.bar, medium.foo.bar. small.foo.bar. tiny.foo.bar. Then a query to a security aware server for huge.foo.bar would produce an error reply with the authority section data including big.foo.bar. NXD medium.foo.bar. and the corresponding SIG RR. 5.4 Interaction of NXD RRs and Wildcard RRs As a wildcard RR causes all possible names in an interval to exist, there should not be an NXD record that would cover any part of this interval. Thus if *.X.ZONE exists you would expect an NXD RR that ends at X.ZONE and one that starts with the last name covered by *.X.ZONE. However, this "last name covered" is something very ugly and long like \255\255\255....X.zone. So the NXD for the interval following is simply given the owner name *.X.ZONE. This "*" type name is not expanded when the NXD is returned as authority Eastlake, Kaufman [Page 24] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 information in connection with a query for a non-existent name and type. If there could be any wildcard RRs in a zone and thus wildcard NXDs, care must be taken in interpreting the results of explicit NXD retrievals as the owner name may be a wildcard expansion. The existence of one or more wildcard RRs covering a name interval makes it possible for a malicious server to hide any more specificly named RRs in the internal. The server can just falsely return the wildcard match NXD instead of the more specificly named RRs. If there is a zone wide wildcard, there will be only one NXD RR whose owner name and RDATA are both the zone name. In this case a server could conceal the existence of any more specific RRs in the zone. (It would be possible to design a more complex NXD feature, taking into account the types of RRs that did not exist in a name interval, and the like, which would eliminate this possibility. But it would be more complex and would be so constraining as to make any future dynamic update feature that could create new names very difficult (see Section 3.2).) 5.5 Blocking NXD Pseudo-Zone Transfers In a secure zone, a resolver can query for the initial NXD associated with the zone name. Using the RDATA field from that RR, it can query for the next NXD RR. By repeating this, it can walk through all the NXDs in the zone. If there are no wildcards, it can use this technique to find all names in a zone. If it does type ANY queries, it can incrementally get all information in the zone and perhaps defeat attempts to administratively block zone transfers. If there are any wildcards, this NXD walking technique will not find any more specific RR names in the part of the name space the wildcard covers. By doing explicit retrievals for wildcard names, a resolver could determine what intervals are covered by wildcards but still could not, with these techniques, find any names inside such intervals except by trying every name. If it is desired to block NXD walking, the recommended method is to add a zone wide wildcard of the KEY type with the no key bit on and with no type (zone, entity, or user) bit on. This will cause there to be only one NXD RR in the zone for the zone name and leak no information about what real names exist in the zone. This protection from pseudo-zone transfers is bought at the expense of eliminating the data origin authentication of the non-existence of names that NXD RRs can provide. If an entire zone is covered by a wildcard, a malicious server can return an RR produced by matching the resulting wildcard NXD and can thus hide all the real data and delegations with Eastlake, Kaufman [Page 25] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 more specific names in the zone. Eastlake, Kaufman [Page 26] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 6. How to Resolve Securely Retrieving or resolving authentic data from the DNS involves starting with one or more trusted public keys. With trusted keys, it is possible to progress securely through the secure DNS zone structure to the zone of interest as described in section 6.2. Such trusted public keys would normally be configured in a manner similar to that described in section 6.1. However, as a practical matter, a security aware resolver would still gain some confidence in the results it returns even if it was not configured with any keys but trusted what it got from a local well known server as a starting point. The proper validation of signatures requires a reasonably secure shared opinion of the absolute time between resolvers and servers. In getting to the data of interest to respond to a query, a secure resolver may encounter genuine non-secure zones. It may proceed through such zones but should report this as described in section 6.4. 6.1 Boot File Format The recommended format for a boot file line to configure starting keys is as follows: pubkey name object flags algorithm key-data for a public key. "object" is the domain name of the thing the key is associated with and "name" is the owner name (if the line is translated into a KEY RR). Flags indicates the type of key and is the same as the flag byte in the KEY RR. In particular, if the "no key" bit is on in flags, then all fields after flags may be omitted. Algorithm is the algorithm in use where one is the MD5/RSA algorithm and 254 indicates a private algorithm. The material after the algorithm is algorithm dependent and, for private algorithms, starts with the algorithm's identifying OID. It is encoded in base 64 (see Appendix). While it might seem logical for everyone to start with the key for the root zone, this has problems. The logistics of updating every DNS resolver in the world when the root key changes would be excessive. It may be some time before there even is a root key. Furthermore, many organizations will explicitly wish their "interior" DNS implementations to completely trust only their own zone. These interior resolvers can then go through the organization's zone server to access data outsize the organization's domain. Eastlake, Kaufman [Page 27] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 6.2 Chaining Through Zones Starting with one or more trusted keys for a zone, it is possible to retrieve signed keys for its subzones and superzone which have a key. Every secure zone (except root) should also include the KEY RR for its super-zone signed by the secure zone and with the owner name of the secure zone and object name of the super-zone. This makes it possible to climb the tree of zones if one starts below root. A secure sub-zone is indicated by a KEY RR appearing with the NS RRs for the sub-zone and with the same owner and object names. These make it possible to descend within the tree of zones. A resolver should keep track of the number of successive secure zones traversed from a starting point to any secure zone it can reach. In general, the lower such a distance number is, the greater the confidence in the data. Data configured via a boot file should be given a distance number of zero. Should a query encounter different data for the same query with different distance values, that with a larger value should be ignored. (This can happen due to cross- certification as described below.) A security conscious resolver should completely refuse to step from a secure zone into a non-secure zone unless the non-secure zone is certified to be non-secure or only experimentally secure by the presence of an authenticated KEY RR for the non-secure zone with a no key flag or the presence of a KEY RR with the experimental bit set. Otherwise the resolver is probably getting completely bogus or spoofed data. If legitimate non-secure zones are encountered in traversing the DNS tree, then no zone can be trusted as secure that can be reached only via information from such non-secure zones. Since the non-secure zone data could have been spoofed, the "secure" zone reach via it could be counterfeit. The "distance" to data in such zones or zones reached via such zones could be set to 512 or more as this exceeds the largest possible distance through secure zones in the DNS. Nevertheless, continuing to apply secure checks within "secure" zones reached via non-secure zones will, as a practical matter, provide some increase in security. The syntax of KEY RRs, with an arbitrary object name, provides for cross-certification. Although the syntax permits the owner name of a cross-certification KEY RR to be any name, by convention and to avoid an undue concentration of such KEY RRs under any particular name, their owner name should be the zone name prefixed with the destination object name (truncated an integral number of labels from the front if necessary due to DNS name restrictions). Thus a key for isoc.org would appear in the mit.edu zone with the owner name isoc.org.mit.edu and object name isoc.org. Eastlake, Kaufman [Page 28] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 The existence of cross certifications adds further policy questions. Assume we have a zone BB.AA and a zone YY.XX. Many possibilities exist for a secure resolver configured with the BB.AA key to get to YY.XX. If all the zones along the way are secure, it could climb to root and then descend the other side, a total of four hops (BB.AA -> AA -> . -> XX -> YY.XX). If the BB.AA administrator had installed a cross certified key for YY.XX in the BB.AA zone, using that would be a shorter and presumably more secure way to find YY.XX's key which would be immune to the non-security or even compromise of the servers for AA or root or XX. But what if some less trusted subzone of BB.AA, say Flakey.BB.AA installed a cross certified key for YY.XX? If there is a conflict, should this be preferred to a hierarhically derived key obtained by climbing to root and descending? Such questions are entirely a matter of local resolver policy and no universal answer can be given. 6.3 Secure Time Coordinated interpretation of the time fields in SIG RRs requires that reasonably consistent time be available to the hosts implementing the DNS security extensions. A variety of time synchronization protocols exist including the Network Time Protocol (NTP, RFC1305). If such protocols are used, they should be used securely so that time can not be spoofed. Otherwise, for example, a host could get its clock turned back and might then believe old SIG and KEY RRs which were valid but no longer are. 6.4 Resolver Response Code Without security, a DNS resolver has three basic response codes it can give: Success - with data. Transient failure - no server reachable or responding, etc. Solid failure - an authoritative answer that the data does not exist. With security, a second dimension can be added to these responses: Null - resolver is not secure. Verified - response has been securely verified. Eastlake, Kaufman [Page 29] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 Verification Not Available - queried zone is known to be insecure zone. Verification Not Possible - queried zone is secure but verification was not possible due to chaining through one or more insecure zones. Verification Failed - queried zone is secure but response signature failed to verify. In general, it is desireable for there to be local options on the treatment of various combinations of these two sets of response codes. A trusted security aware application should get both the basic and security response codes. A high security resolver might wish to refuse to supply any non-verified DNS data to applications and translate confirmed absence of security or failed verification into a solid failure indication. A low security resolver might wish to provide whatever information it can along with an indication of its security. However, under no circumstances should Verification Failed information be made available to a non-security aware application. Stub resolvers will generally not be security aware. They will partake of the security policy of the recursive resolver they make use of. Eastlake, Kaufman [Page 30] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 7. Operational Considerations This section discusses a variety of considerations in secure operation of DNS using these proposed protocol extensions. 7.1 Key Size Considerations There are a number of factors that effect public key size choice for use in the DNS security extension. Unfortunately, these factors usually do not all point in the same direction. Choice of zone key size should generally be made by the zone administrator depending on their local conditions. For most schemes, larger keys are more secure but slower. Given a small public exponent, verification (the most common operation) for the MD5/RSA algorithm will vary roughly with the square of the modulus length, signing will vary with the cube of the modulus length, and key generation (the least common operation) will vary with the fourth power of the modulus length. The current best algorithms for factoring a modulus and breaking RSA security vary roughly with the square of the modulus itself. Thus going from a 640 bit modulus to a 1280 bit modulus only increases the verification time by a factor of 4 but increases the work factor of breaking the key by over 2^3000. [RSA FAQ] An upper bound of 2552 bit has been established for the MD4/RSA DNS security algorithm for interoperability purposes. However, larger keys increase size of the KEY and SIG RRs. This increases the chance of UDP packet overflow and the possible necessity for using higher overhead TCP. The recommended minimum RSA algorithm modulus size, 640 bits, is believed by the authors to be secure at this time and for some years but high level zones in the DNS tree may wish to set a higher minimum, perhaps 1000 bits, for security reasons. (Since the United States National Security Agency generally permits export of encryption systems using an RSA modulus of up to 512 bits, use of that small a modulus, i.e. n, must be considered weak.) For a key used only to secure data and not to secure other keys, 640 bits should be entirely adequate. 7.2 Key Storage It is strongly recommended that zone private keys and the zone file master copy be kept and used in off-line non-network connected Eastlake, Kaufman [Page 31] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 physically secure machines only. Periodically an application can be run to re-sign the RRs in a zone by adding NXD and SIG RRs. Then the augmented file can be transferred, perhaps by sneaker-net, to the networked zone primary server machine. The idea is to have a one way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. For maximum security, the master copy of the zone file should be off net and should not be updated based on an unsecured network mediated communication. Non-zone private keys, such as host or user keys, may have to be kept on line to be used for real-time purposes such a IP secure session set-up or secure mail. 7.3 Key Generation Careful key generation is a sometimes over looked but absolutely essential element in any cryptographically secure system. The strongest algorithms used with the longest keys are still of no use if an adversary can guess enough to lower the size of the likely key space so that it can be exhaustively searched. Suggestions will be found in RFC 1750. It is strongly recommended that key generation also occur off-line, perhaps on the machine used to sign zones (see Section 7.2). 7.4 Key Lifetimes No key should be used forever. The longer a key is in use, the greater the probability that it will have been compromised through carelessness, accident, espionage, or cryptanalysis. Furthermore, if key rollover is a rare event, there is an increased risk that, when the time does come up change the key, no one at the site will remember how to do it or other problems will have developed in the procedures. While key lifetime is a matter of local policy, these considerations suggest that no zone key should have a lifetime significantly over four years. A reasonable maximum lifetime for zone keys that are kept off-line and carefully guarded is 13 months with the intent that they be replaced every year. A reasonable maximum lifetime for end entity keys that are used for IP-security or the like and are kept on Eastlake, Kaufman [Page 32] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 line is 36 days with the intent that they be replaced monthly or more often. In some cases, an entity key lifetime of somewhat over a day may be reasonable. 7.5 Signature Lifetime Signature expiration times must be set far enough in the future that it is quite certain that new signatures can be generated before the old ones expire. However, setting expiration too far into the future could, if bad data or signatures were ever generated, mean a long time to flush such badness. It is recommended that signature lifetime be a small multiple of the TTL but not less than a reasonable re-signing interval. 7.6 Root It should be noted that in DNS the root is a zone unto itself. Thus the root zone key should only be seen signing itself or signing RRs with names one level below root, such as .aq, .edu, or .arpa. Implementations MAY reject as bogus any purported root signature of records with a name more than one level below root. Eastlake, Kaufman [Page 33] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 8. Conformance Several levels of server and resolver conformance are defined. 8.1 Server Conformance Three levels of server conformance are defined as follows: Basic server compliance is the ability to store and retrieve (including zone transfer) SIG, KEY, and NXD RRs. Secondaries for a secure zone must be at least basicly compliant. Medium server compliance adds the following to basic compliance: (1) ability to read SIG, KEY, and NXD RRs in zone files and (2) ability, given a zone file and private key, to add appropriate SIG and NXD RRs, possibly via a separate application. Primary servers for secure zones must be at least minimally compliant. Full server compliance is ability to automatically include SIG, KEY, and NXD RRs in responses as appropriate, as well as meeting medium compliance. 8.2 Resolver Conformance Two levels of resolver compliance are defined: A basic compliance resolver can handle SIG, KEY, and NXD RRs when they are explicitly requested. A fully compliant resolver understands KEY, SIG, and NXD RRs, maintains appropriate information in its local caches and database to indicate which RRs have been authenticated and to what extent they have been authenticated, and performs additional queries as necessary to obtain KEY, SIG, or NXD RRs from non-security aware servers. Eastlake, Kaufman [Page 34] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 9. Security Considerations This document concerns technical details of extensions to the Domain Name System (DNS) protocol to provide data integrity and data origin authentication, public key distribution, and optional transaction security. If should be noted that, at most, these extensions guarantee the validity of resource records, including KEY resource records, retrieved from the DNS. They do not magically solve other security problems. For example, using secure DNS you can have high confidence in the IP address you retrieve for a host; however, this does not stop someone for substituting an unauthorized host at that address or capturing packets sent to that address and responding with packets apparently from that address. Any reasonably complete security system will require the protection of many other facets of the Internet. References [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 3 June 1991, Version 1.4. [RFC1032] - Domain Administrators Guide, M. Stahl, November 1987 [RFC1033] - Domain Administrators Operations Guide, M. Lottor, November 1987 [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, November 1987 [RFC1035] - Domain Names - Implementation and Specifications [RFC1305] - Network Time Protocol (v3), D. Mills, April 9 1992. [RFC1321] - The MD5 Message-Digest Algorithm, R. Rivest, April 16 1992. [RFC1750] - Randomness Requirements for Security, D. Eastlake, S. Crocker, J. Schiller, December 1994. [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. Eastlake, Kaufman [Page 35] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 Authors Addresses Donald E. Eastlake, 3rd CyberCash, Inc. 318 Acton Street Carlisle, MA 01741 USA Telephone: +1 508 287 4877(w/h) EMail: dee@cybercash.com Charles W. Kaufman Iris Associates 1 Technology Park Drive Westford, MA 01886 USA Telephone: +1 508-392-5276 EMail: charlie_kaufman@iris.com Expiration and File Name This draft expires 1 October 1995. Its file name is draft-ietf-dnssec-secext-04.txt. Eastlake, Kaufman [Page 36] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 Appendix: Base 64 Encoding The following encoding technique is taken from RFC 1521 by Borenstein and Freed. It is reproduced here in an edited form for convenience. A 65-character subset of US-ASCII is used, enabling 6 bits to be represented per printable character. (The extra 65th character, "=", is used to signify a special processing function.) The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating 3 8-bit input groups. These 24 bits are then treated as 4 concatenated 6-bit groups, each of which is translated into a single digit in the base64 alphabet. Each 6-bit group is used as an index into an array of 64 printable characters. The character referenced by the index is placed in the output string. Table 1: The Base64 Alphabet Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. A full encoding quantum is always completed at the end of a quantity. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Padding at the end of the data is performed using the '=' character. Since all base64 input is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) Eastlake, Kaufman [Page 37] INTERNET-DRAFT DNS Protocol Security Extensions March 1995 the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character. Eastlake, Kaufman [Page 38]