idnits 2.17.1 draft-ietf-dnssec-secext-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-dnssec-secext-09.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-secext-09.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-secext-09.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-dnssec-secext-09.txt,', but the file name used is 'draft-ietf-dnssec-secext-09' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 11 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 431: '... implementations MUST be designed to h...' RFC 2119 keyword, line 713: '...ese name servers MUST be included as a...' RFC 2119 keyword, line 944: '... be 1) SHALL be not less than 512 bi...' RFC 2119 keyword, line 945: '... and e SHOULD be chosen such that th...' RFC 2119 keyword, line 985: '... SIG, the zone MAY be considered val...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (30 January 1996) is 10313 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 1825' is mentioned on line 561, but not defined ** Obsolete undefined reference: RFC 1825 (Obsoleted by RFC 2401) == Missing Reference: 'RFC 1530' is mentioned on line 549, but not defined == Unused Reference: 'RFC1032' is defined on line 1724, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1729, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 1732, but no explicit reference was found in the text == Unused Reference: 'RFC1305' is defined on line 1734, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 1736, but no explicit reference was found in the text == Unused Reference: 'RFC1530' is defined on line 1739, but no explicit reference was found in the text == Unused Reference: 'RFC1750' is defined on line 1742, but no explicit reference was found in the text == Unused Reference: 'RFC1825' is defined on line 1745, but no explicit reference was found in the text == Unused Reference: 'RSA FAQ' is defined on line 1748, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'NETSEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' ** Downref: Normative reference to an Unknown state RFC: RFC 1032 ** Downref: Normative reference to an Unknown state RFC: RFC 1033 ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 1530 ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA FAQ' Summary: 20 errors (**), 1 flaw (~~), 16 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNS Security Working Group Donald E. Eastlake, 3rd 2 INTERNET-DRAFT CyberCash 3 UPDATES RFC 1034, 1035 Charles W. Kaufman 4 Iris 5 Expires: 29 July 1996 30 January 1996 7 Domain Name System Security Extensions 8 ------ ---- ------ -------- ---------- 10 Status of This Document 12 This draft, file name draft-ietf-dnssec-secext-09.txt, is intended to 13 be become a Proposed Standard RFC. Distribution of this document is 14 unlimited. Comments should be sent to the DNS Security Working Group 15 mailing list or to the authors. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months. Internet-Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet- 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 30 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 31 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 32 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 34 Abstract 36 The Domain Name System (DNS) has become a critical operational part 37 of the Internet infrastructure yet it has no strong security 38 mechanisms to assure data integrity or authentication. Extensions to 39 the DNS are described that provide these services to security aware 40 resolvers or applications through the use of cryptographic digital 41 signatures. These digital signatures are included in secured zones 42 as resource records. Security can still be provided even through 43 non-security aware DNS servers in many cases. 45 The extensions also provide for the storage of authenticated public 46 keys in the DNS. This storage of keys can support general public key 47 distribution service as well as DNS security. The stored keys enable 48 security aware resolvers to learn the authenticating key of zones in 49 addition to those for which they are initially configured. Keys 50 associated with DNS names can be retrieved to support other 51 protocols. Provision is made for a variety of key types and 52 algorithms. 54 In addition, the security extensions provide for the optional 55 authentication of DNS protocol transactions. 57 Acknowledgments 59 The significant contributions of the following persons (in alphabetic 60 order) to this draft are gratefully acknowledged: 62 Madelyn Badger 63 Matt Crawford 64 James M. Galvin 65 Olafur Gudmundsson 66 Edie Gunter 67 Sandy Murphy 68 Masataka Ohta 69 Michael A. Patton 70 Jeffrey I. Schiller 72 Table of Contents 74 Status of This Document....................................1 76 Abstract...................................................2 77 Acknowledgments............................................2 79 Table of Contents..........................................3 81 1. Overview of Contents....................................5 83 2. Overview of the Extensions.............................6 84 2.1 Services Not Provided..................................6 85 2.2 Key Distribution.......................................6 86 2.3 Data Origin Authentication and Integrity...............7 87 2.3.1 The SIG Resource Record..............................8 88 2.3.2 Authenticating Name and Type Non-existence...........8 89 2.3.3 Special Considerations With Time-to-Live.............8 90 2.3.4 Special Considerations at Delegation Points..........9 91 2.3.5 Special Considerations with CNAME RRs................9 92 2.3.6 Signers Other Than The Zone.........................10 93 2.4 DNS Transaction and Request Authentication............10 95 3. The KEY Resource Record................................12 96 3.1 KEY RDATA format......................................12 97 3.2 Object Types, DNS Names, and Keys.....................12 98 3.3 The KEY RR Flag Field.................................13 99 3.4 The Protocol Octet....................................15 100 3.5 The KEY Algorithm Number and the MD5/RSA Algorithm....16 101 3.6 Interaction of Flags, Algorithm, and Protocol Bytes...17 102 3.7 KEY RRs in the Construction of Responses..............17 103 3.8 File Representation of KEY RRs........................18 105 4. The SIG Resource Record................................19 106 4.1 SIG RDATA Format......................................19 107 4.1.1 Signature Data......................................21 108 4.1.2 MD5/RSA Algorithm Signature Calculation.............22 109 4.1.3 Zone Transfer (AXFR) SIG............................23 110 4.1.4 Transaction and Request SIGs........................24 111 4.2 SIG RRs in the Construction of Responses..............24 112 4.3 Processing Responses and SIG RRs......................25 113 4.4 Signature Expiration, TTLs, and Validity..............26 114 4.5 File Representation of SIG RRs........................27 116 5. Non-existent Names and Types...........................28 117 5.1 The NXT Resource Record...............................28 118 5.2 NXT RDATA Format......................................29 119 5.3 Example...............................................30 120 5.4 Interaction of NXT RRs and Wildcard RRs...............30 121 5.5 Blocking NXT Pseudo-Zone Transfers....................31 122 5.6 Special Considerations at Delegation Points...........32 123 6. The AD and CD Bits and How to Resolve Securely.........33 124 6.1 The AD and CD Header Bits.............................33 125 6.2 Boot File Format......................................34 126 6.3 Chaining Through Zones................................35 127 6.4 Secure Time...........................................36 129 7. Operational Considerations.............................37 130 7.1 Key Size Considerations...............................37 131 7.2 Key Storage...........................................37 132 7.3 Key Generation........................................38 133 7.4 Key Lifetimes.........................................38 134 7.5 Signature Lifetime....................................39 135 7.6 Root..................................................39 137 8. Conformance............................................40 138 8.1 Server Conformance....................................40 139 8.2 Resolver Conformance..................................40 141 9. Security Considerations................................41 143 References................................................42 145 Authors Addresses.........................................43 146 Expiration and File Name..................................43 148 Appendix: Base 64 Encoding................................44 150 1. Overview of Contents 152 This draft describes extensions of the Domain Name System (DNS) 153 protocol to support DNS security and public key distribution. It 154 assumes that the reader is familiar with the Domain Name System, 155 particularly as described in RFCs 1033, 1034, and 1035. 157 Section 2 provides a detailed overview of the extensions and the key 158 distribution, data origin authentication, and transaction and request 159 security they provide. 161 Section 3 discusses the KEY resource record, its structure, use in 162 DNS responses, and file representation. These resource records 163 represent the public keys of entities named in the DNS and are used 164 for key distribution. 166 Section 4 discusses the SIG digital signature resource record, its 167 structure, use in DNS responses, and file representation. These 168 resource records are used to authenticate other resource records in 169 the DNS and optionally to authenticate DNS transactions and requests. 171 Section 5 discusses the NXT resource record and its use in DNS 172 responses. The NXT RR permits authenticated denial in the DNS of the 173 existence of a name or of a particular type for an existing name. 175 Section 6 discusses how a resolver can be configured with a starting 176 key or keys and proceed to securely resolve DNS requests. 177 Interactions between resolvers and servers are discussed for all 178 combinations of security aware and security non-aware. Two 179 additional query header bits are defined for signaling between 180 resolvers and servers. 182 Section 7 reviews a variety of operational considerations including 183 key generation, lifetime, and storage. 185 Section 8 defines levels of conformance for resolvers and servers. 187 Section 9 provides a few paragraphs on overall security 188 considerations. 190 An Appendix is provided that gives some details of base 64 encoding 191 which is used in the file representation of some RR's defined in this 192 draft. 194 2. Overview of the Extensions 196 The Domain Name System (DNS) protocol security extensions provide 197 three distinct services: key distribution as described in Section 2.2 198 below, data origin authentication as described in Section 2.3 below, 199 and transaction and request authentication, described in Section 2.4 200 below. 202 Special considerations related to "time to live", CNAMEs, and 203 delegation points are also discussed in Section 2.3. 205 2.1 Services Not Provided 207 It is part of the design philosophy of the DNS that the data in it is 208 public and that the DNS gives the same answers to all inquirers. 210 Following this philosophy, no attempt has been made to include any 211 sort of access control lists or other means to differentiate 212 inquirers. 214 In addition, no effort has been made to provide for any 215 confidentiality for queries or responses. (This service may be 216 available via IPSEC [RFC 1825].) 218 2.2 Key Distribution 220 Resource records (RRs) are defined to associate keys with DNS names. 221 This permits the DNS to be used as a general public key distribution 222 mechanism in support of the data origin authentication and 223 transaction authentication DNS services as well as other security 224 services. 226 The syntax of a KEY resource record (RR) is described in Section 3. 227 It includes an algorithm identifier, the actual public key 228 parameters, and a variety of flags including those indicating the 229 type of entity the key is associated with and/or asserting that there 230 is no key associated with that entity. 232 Under conditions described in Section 3, security aware DNS servers 233 will automatically attempt to return KEY resources as additional 234 information, along with those resource records actually requested, to 235 minimize the number of queries needed. 237 2.3 Data Origin Authentication and Integrity 239 Authentication is provided by associating with resource records in 240 the DNS cryptographically generated digital signatures. Commonly, 241 there will be a single private key that signs for an entire zone. If 242 a security aware resolver reliably learns the public key of the zone, 243 it can verify, for signed data read from that zone, that it was 244 properly authorized and is reasonably current. The expected 245 implementation is for the zone private key to be kept off-line and 246 used to re-sign all of the records in the zone periodically. 248 This data origin authentication key belongs to the zone and not to 249 the servers that store copies of the data. That means compromise of 250 a server or even all servers for a zone will not necessarily affect 251 the degree of assurance that a resolver has that it can determine 252 whether data is genuine. 254 A resolver can learn the public key of a zone either by reading it 255 from DNS or by having it staticly configured. To reliably learn the 256 public key by reading it from DNS, the key itself must be signed. 257 Thus, to provide a reasonable degree of security, the resolver must 258 be configured with at least the public key of one zone that it can 259 use to authenticate signatures. From there, it can securely read the 260 public keys of other zones, if the intervening zones in the DNS tree 261 are secure. (It is in principle more secure to have the resolver 262 manually configured with the public keys of multiple zones, since 263 then the compromise of a single zone would not permit the faking of 264 information from other zones. It is also more administratively 265 cumbersome, however, particularly when public keys change.) 267 Adding data origin authentication and integrity requires no change to 268 the "on-the-wire" DNS protocol beyond the addition of the signature 269 resource type and, as a practical matter, the key resource type 270 needed for key distribution. This service can be supported by 271 existing resolver and server implementations so long as they can 272 support the additional resource types (see Section 8). The one 273 exception is that CNAME referrals from a secure zone can not be 274 authenticated if they are from non-security aware servers (see 275 Section 2.3.5). 277 If signatures are always separately retrieved and verified when 278 retrieving the information they authenticate, there will be more 279 trips to the server and performance will suffer. To avoid this, 280 security aware servers mitigate that degradation by always attempting 281 to send the signature(s) needed. 283 2.3.1 The SIG Resource Record 285 The syntax of a SIG resource record (signature) is described in 286 Section 4. It includes the type of the RR(s) being signed, the name 287 of the signer, the time at which the signature was created, the time 288 it expires (when it is no longer to be believed), its original time 289 to live (which may be longer than its current time to live but cannot 290 be shorter), the cryptographic algorithm in use, and the actual 291 signature. 293 Every name in a secured zone will have associated with it at least 294 one SIG resource record for each resource type under that name. A 295 security aware server supporting the performance enhanced version of 296 the DNS protocol security extensions will attempt to return, with all 297 records retrieved, the corresponding SIGs. If a server does not 298 support the protocol, the resolver must retrieve all the SIG records 299 for a name and select the one or ones that sign the resource 300 record(s) that resolver is interested in. 302 2.3.2 Authenticating Name and Type Non-existence 304 The above security mechanism provides only a way to sign existing RRs 305 in a zone. "Data origin" authentication is not obviously provided 306 for the non-existence of a domain name in a zone or the non-existence 307 of a type for an existing name. This gap is filled by the NXT RR 308 which authenticatably asserts a range of non-existent names in a zone 309 and the non-existence of types for the name just before that range. 311 Section 5 below covers the NXT RR. 313 2.3.3 Special Considerations With Time-to-Live 315 A digital signature will fail to verify if any change has occurred to 316 the data between the time it was originally signed and the time the 317 signature is verified. This conflicts with our desire to have the 318 time-to-live field tick down when resource records are cached. 320 This could be avoided by leaving the time-to-live out of the digital 321 signature, but that would allow unscrupulous servers to set 322 arbitrarily long time to live values undetected. Instead, we include 323 the "original" time-to-live in the signature and communicate that 324 data in addition to the current time-to-live. Unscrupulous servers 325 under this scheme can manipulate the time to live but a security 326 aware resolver will bound the TTL value it uses at the original 327 signed value. Separately, signatures include a time signed and an 328 expiration time. A resolver that knows the absolute time can 329 determine securely whether a signature has expired. It is not 330 possible to rely solely on the signature expiration as a substitute 331 for the TTL, however, since the TTL is primarily a database 332 consistency mechanism and, in any case, non-security aware servers 333 that depend on TTL must still be supported. 335 2.3.4 Special Considerations at Delegation Points 337 DNS security would like to view each zone as a unit of data 338 completely under the control of the zone owner and signed by the 339 zone's key. But the operational DNS views the leaf nodes in a zone 340 which are also the apex nodes of a subzone (i.e., delegation points) 341 as "really" belonging to the subzone. These nodes occur in two 342 master files and may have RRs signed by both the upper and lower 343 zone's keys. A retrieval could get a mixture of these RRs and SIGs, 344 especially since one server could be serving both the zone above and 345 below a delegation point. 347 In general, there must be a zone KEY RR for the subzone in the 348 superzone and the copy signed in the superzone is controlling. For 349 all other RRs that should appearing in both the superzone and 350 subzone, the data from the subzone is more authoritative. To avoid 351 conflicts, only the KEY RR in the superzone should be signed and the 352 NS and any A (glue) RRs should only be signed in the subzone. The SOA 353 and any other RRs that have the zone name as owner should appear only 354 in the subzone and thus are signed there. The NXT RR type is an 355 exceptional case that will always appear differently and 356 authoritatively in both the superzone and subzone, if both are 357 secure, as described in Section 5. 359 2.3.5 Special Considerations with CNAME RRs 361 There is a significant problem when security related RRs with the 362 same owner name as a CNAME RR are retrieved from a non-security-aware 363 server. In particular, an initial retrieval for the CNAME or any 364 other type will not retrieve any associated signature, key, or NXT 365 RR. For types other than CNAME, it will retrieve that type at the 366 target name of the CNAME (or chain of CNAMEs) and will return the 367 CNAME as additional information. In particular, a specific retrieval 368 for type SIG will not get the SIG, if any, at the original CNAME 369 domain name but rather a SIG at the target name. 371 In general, security aware servers must be used to securely CNAME in 372 DNS. Security aware servers must (1) allow KEY, SIG, and NXT RRs 373 along with CNAME RRs, (2) suppress CNAME processing on retrieval of 374 these types as well as on retrieval of the type CNAME, and (3) 375 automatically return SIG RRs authenticating the CNAME or CNAMEs 376 encountered in resolving a query. This is a change from the previous 377 DNS standard which prohibited any other RR type at a node where a 378 CNAME RR was present. 380 2.3.6 Signers Other Than The Zone 382 There are two cases where a SIG resource record is signed by other 383 than the zone private key. One is for support of dynamic update 384 where an entity is permitted to authenticate/update its own records. 385 The public key of the entity must be present in the DNS and be 386 appropriately signed but the other RR(s) may be signed with the 387 entity's key. The other is for support of transaction and request 388 authentication as described in Section 2.4 immediately below. 390 2.4 DNS Transaction and Request Authentication 392 The data origin authentication service described above protects 393 retrieved resource records but provides no protection for DNS 394 requests or for message headers. 396 If header bits are falsely set by a server, there is little that can 397 be done. However, it is possible to add transaction authentication. 398 Such authentication means that a resolver can be sure it is at least 399 getting messages from the server it thinks it queried, that the 400 response is from the query it sent, and that these messages have not 401 been diddled in transit. This is accomplished by optionally adding a 402 special SIG resource record at the end of the reply which digitally 403 signs the concatenation of the server's response and the resolver's 404 query. 406 Requests can also be authenticated by including a special SIG RR at 407 the end of the request. Authenticating requests serves no function 408 in the current DNS and requests with a non-empty additional 409 information section are ignored by almost all current DNS servers. 410 However, this syntax for signing requests is defined in connection 411 with authenticating future secure dynamic update requests or the 412 like. 414 The private key used in transaction security belongs to the host 415 composing the reply message, not to the zone involved. The 416 corresponding public key is normally stored in and retrieved from the 417 DNS. 419 Because requests and replies are highly variable, message 420 authentication SIGs can not be pre-calculated. Thus it will be 421 necessary to keep the private key on-line, for example in software or 422 in a directly connected piece of hardware. 424 3. The KEY Resource Record 426 The KEY resource record (RR) is used to document a key that is 427 associated with a Domain Name System (DNS) name. It will be a public 428 key as only public keys are stored in the DNS. This can be the 429 public key of a zone, a host or other end entity, or a user. A KEY 430 RR is, like any other RR, authenticated by a SIG RR. Security aware 431 DNS implementations MUST be designed to handle at least two 432 simultaneously valid keys of the same type associated with a name. 434 The type number for the KEY RR is 25. 436 3.1 KEY RDATA format 438 The RDATA for a KEY RR consists of flags, a protocol octet, the 439 algorithm number, and the public key itself. The format is as 440 follows: 442 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | flags | protocol | algorithm | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | / 448 / public key / 449 / / 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 452 The meaning of the KEY RR owner name, flags, and protocol octet are 453 described in Sections 3.2, 3.3 and 3.4 below respectively. The flags 454 and algorithm must be examined before any data following the 455 algorithm octet as they control the format and even whether there is 456 any following data. The algorithm and public key fields are 457 described in Section 3.5. The format of the public key is algorithm 458 dependent. 460 3.2 Object Types, DNS Names, and Keys 462 The public key in a KEY RR belongs to the object named in the owner 463 name. 465 This DNS name may refer to up to three different categories of 466 things. For example, dee.cybercash.com could be (1) a zone, (2) a 467 host or other end entity , and (3) the mapping into a DNS name of the 468 user or account dee@cybercash.com. Thus, there are flags, as 469 described below, in the KEY RR to indicate with which of these roles 470 the owner name and public key are associated. Note that an 471 appropriate zone KEY RR must occur at the apex node of a secure zone 472 and at every leaf node which is a delegation point (and thus the same 473 owner name as the apex of a subzone) within a secure zone. 475 Although the same name can be used for up to all three of these 476 categories, such overloading of a name is discouraged. It is also 477 possible to use the same key for different things with the same name 478 or even different names, but this is strongly discouraged. In 479 particular, the use of a zone key as a non-zone key will usually 480 require that the corresponding private key be kept on line and 481 thereby become more vulnerable. 483 It would be desirable for the growth of DNS to be managed so that 484 additional possible simultaneous uses for names are NOT added. New 485 uses should be distinguished by exclusive domains. For example, all 486 IP autonomous system numbers have been mapped into the in-as.arpa 487 domain [draft-ietf-dnssec-as-map-*.txt (may have an RFC number if 488 issued simultaneously with this draft)], all telephone numbers in the 489 world have been mapped into the tpc.int domain [RFC 1530], and all 490 IPv4 addresses (i.e., all IPv4 globally addressable interfaces) have 491 been mapped into the in-addr.arpa domain. This is much preferable to 492 having the same fully qualified name simultaneously be a possible 493 autonomous system number, telephone number, IPv4 interface, and/or 494 host as well as a zone and a user. 496 In addition to the name type bits, there are additional flag bits 497 including the "type" field, "experimental" bit, "signatory" field, 498 etc., as described below. 500 3.3 The KEY RR Flag Field 502 In the "flags" field: 504 Bit 0 and 1 are the "type" field. Bit 0 a one indicates that 505 use of the key is prohibited for authentication. Bit 1 a one 506 indicates that use of the key is prohibited for confidentiality. If 507 this field is zero, then use of the key for authentication and/or 508 confidentiality is permitted. Note that DNS security makes use of 509 keys for authentication only. Confidentiality use flagging is 510 provided for use of keys in other protocols. If both bits of this 511 field are one, "no key" value, there is no key information and the RR 512 stops after the algorithm octet. By the use of this "no key" value, 513 a signed KEY RR can authenticatably assert that, for example, a zone 514 is not secured. 516 Bit 2 is the "experimental" bit. It is ignored if the type 517 field indicates "no key" and the following description assumes that 518 type field to be non-zero. Keys may be associated with zones, 519 entities, or users for experimental, trial, or optional use, in which 520 case this bit will be one. If this bit is a zero, it means that the 521 use or availability of security based on the key is "mandatory". 522 Thus, if this bit is off for a zone key, the zone should be assumed 523 secured by SIG RRs and any responses indicating the zone is not 524 secured should be considered bogus. If this bit is a one for a host 525 or end entity, it might sometimes operate in a secure mode and at 526 other times operate without security. The experimental bit, like all 527 other aspects of the KEY RR, is only effective if the KEY RR is 528 appropriately signed by a SIG RR. The experimental bit must be zero 529 for safe secure operation and should only be a one for a minimal 530 transition period. 532 Bits 3-4 are reserved and must be zero. 534 Bit 5 on indicates that this is a key associated with a "user" 535 or "account" at an end entity, usually a host. The coding of the 536 owner name is that used for the responsible individual mailbox in the 537 SOA and RP RRs: The owner name is the user name as the name of a node 538 under the entity name. For example, "j.random_user" on 539 host.subdomain.domain could have a public key associated through a 540 KEY RR with name j\.random_user.host.subdomain.domain and the user 541 bit a one. It could be used in an security protocol where 542 authentication of a user was desired. This key might be useful in IP 543 or other security for a user level service such a telnet, ftp, 544 rlogin, etc. 546 Bit 6 on indicates that this is a key associated with the non- 547 zone "entity" whose name is the RR owner name. This will commonly be 548 a host but could, in some parts of the DNS tree, be some other type 549 of entity such as a telephone number [RFC 1530] or autonomous system 550 number [draft-ietf-dnssec-as-map-*.txt (may have an RFC number if 551 issued simultaneously with this draft)]. This is the public key used 552 in connection with the optional DNS transaction authentication 553 service if the owner name is a DNS server host. It could also be 554 used in an IP-security protocol where authentication of at the host, 555 rather than user, level was desired, such as routing, NTP, etc. 557 Bit 7 is the "zone" bit and indicates that this is a zone key 558 for the zone whose name is the KEY RR owner name. This is the 559 primary type of DNS data origin authentication public key. 561 Bit 8 is reserved to be the IPSEC [RFC 1825] bit and indicate 562 that this key is valid for use in conjunction with that security 563 standard. This key could be used in connection with secured 564 communication on behalf of an end entity or user whose name is the 565 owner name of the KEY RR if the entity or user bits are on. The 566 presence of a KEY resource with the IPSEC and entity bits on and 567 experimental and no-key bits off is a guarantee that the host speaks 568 IPSEC. 570 Bit 9 is reserved to be the "email" bit and indicate that this 571 key is valid for use in conjunction with MIME security multiparts. 572 This key could be used in connection with secured communication on 573 behalf of an end entity or user whose name is the owner name of the 574 KEY RR if the entity or user bits are on. 576 Bits 10-11 are reserved and must be zero. 578 Bits 12-15 are the "signatory" field. If non-zero, they 579 indicate that the key can validly sign RRs or updates of the same 580 name. If the owner name is a wildcard, then RRs or updates with any 581 name which is in the wildcard's scope can be signed. Fifteen 582 different non-zero values are possible for this field and any 583 differences in their meaning are reserved for definition in 584 connection with DNS dynamic update or other new DNS commands. Zone 585 keys always have authority to sign any RRs in the zone regardless of 586 the value of this field. The signatory field, like all other aspects 587 of the KEY RR, is only effective if the KEY RR is appropriately 588 signed by a SIG RR. 590 3.4 The Protocol Octet 592 It is anticipated that some keys stored in DNS will be used in 593 conjunction with Internet protocols other than DNS (keys with zone 594 bit or signatory field non-zero) and IPSEC/email (keys with IPSEC 595 and/or email bit set). The protocol octet is provided to indicate 596 that a key is valid for such use and, for end entity keys or the host 597 part of user keys, that the secure version of that protocol is 598 implemented on that entity or host. 600 Values between 1 and 191 decimal inclusive are available for 601 assignment by IANA for such protocols. The 63 values between 192 and 602 254 inclusive will not be assigned to a specific protocol and are 603 available for experimental use under bilateral agreement. Value 0 604 indicates, for a particular key, that it is not valid for any 605 particular additional protocol beyond those indicated in the flag 606 field. And value 255 indicates that the key is valid for all assigned 607 protocols (those in the 1 to 191 range). 609 It is intended that new uses of DNS stored keys would initially be 610 implemented, and operational experience gained, using the 611 experimental range of the protocol octet. If demand for widespread 612 deployment for the indefinite future warrants, a value in the 613 assigned range would then be designated for the protocol. Finally, 614 (1) should the protocol become so widespread in conjunction with 615 other protocols and with which it shares key values that duplicate 616 RRs are a serious burden and (2) should the protocol provide 617 substantial facilities not available in any protocol for which a 618 flags field bit has been allocated, then one of the four remaining 619 flag field bits may be allocated to the protocol. When such a bit has 620 been allocated, a key can be simultaneously indicated as valid for 621 that protocol and the entity or host can be simultaneously flagged as 622 implementing the secure version of that protocol, along with other 623 protocols for which flag field bits have been assigned. 625 Note that the IPSEC protocol being developed may provide facilities 626 adequate for all point to point communication over IP meaning that 627 additional flag field bits would only be assigned, when appropriate 628 as indicated above, to protocols with a store-and-forward nature or 629 otherwise not subsumed into a point-to-point paradigm. 631 3.5 The KEY Algorithm Number and the MD5/RSA Algorithm 633 This octet is the key algorithm parallel to the same field for the 634 SIG resource. The MD5/RSA algorithm described in this draft is 635 number 1. Numbers 2 through 252 are available for assignment should 636 sufficient reason arise. However, the designation of a new algorithm 637 could have a major impact on interoperability and requires an IETF 638 standards action. Number 254 is reserved for private use and will 639 never be assigned a specific algorithm. For number 254, the public 640 key area shown in the packet diagram above will actually begin with 641 an Object Identifier (OID) indicating the private algorithm in use 642 and the remainder of the area is whatever is required by that 643 algorithm. Number 253 is reserved as the "expiration date algorithm" 644 for use where the expiration date or other labeling fields of SIGs 645 are desired without any actual security. It is anticipated that this 646 algorithm will only be used in connection with some modes of DNS 647 dynamic update. For number 253, the public key area is null. Values 648 0 and 255 are reserved. 650 If the type field does not have the "no key" value and the algorithm 651 field is 1, indicating the MD5/RSA algorithm, the public key field is 652 structured as follows: 654 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | pub exp length| public key exponent / 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | / 660 +- modulus / 661 | / 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ 663 To promote interoperability, the exponent and modulus are each 664 limited to 2552 bits in length. The public key exponent is a 665 variable length unsigned integer. Its length in octets is 666 represented as one octet if it is in the range of 1 to 255 and by a 667 zero octet followed by a two octet unsigned length if it is longer 668 than 255 bytes. The public key modulus field is a multiprecision 669 unsigned integer. The length of the modulus can be determined from 670 the RDLENGTH and the preceding RDATA fields including the exponent. 671 Leading zero bytes are prohibited in the exponent and modulus. 673 3.6 Interaction of Flags, Algorithm, and Protocol Bytes 675 Various combinations of the no-key type value, algorithm byte, 676 protocol byte, and any protocol indicating flags (such as the 677 reserved IPSEC flag) are possible. (Note that the zone flag bit 678 being on or the signatory field being non-zero is effectively a DNS 679 protocol flag on.) The meaning of these combinations is indicated 680 below: 682 NK = no key type value 683 AL = algorithm byte 684 PR = protocols indicated by protocol byte or protocol flags 686 x represents any valid non-zero value(s). 688 AL PR NK Meaning 689 0 0 0 Illegal, claims key but has bad algorithm field. 690 0 0 1 Specifies total lack of security for owner. 691 0 x 0 Illegal, claims key but has bad algorithm field. 692 0 x 1 Specified protocols insecure, others may be secure. 693 x 0 0 Useless. Gives key but no protocols to use it. 694 x 0 1 Useless. Denies key but for no protocols. 695 x x 0 Specifies key for protocols and certifies that 696 those protocols are implemented with security. 697 x x 1 Algorithm not understood for protocol. 699 (remember, in reference to the above table, that a protocol 700 byte of 255 means all protocols with protocol byte values 701 assigned) 703 3.7 KEY RRs in the Construction of Responses 705 An explicit request for KEY RRs does not cause any special additional 706 information processing except, of course, for the corresponding SIG 707 RR from a security aware server. 709 Security aware DNS servers will include KEY RRs as additional 710 information in responses where appropriate including the following: 712 (1) On the retrieval of NS RRs, the zone key KEY RR(s) for the zone 713 served by these name servers MUST be included as additional 714 information. There will always be at least one such KEY RR in a 715 secure zone, even if it has the no-key type value to indicate that 716 the subzone is insecure. If not all additional information will fit, 717 the KEY RR(s) have higher priority than type A or AAAA glue RRs. If 718 such a KEY RR does not fit on a retrieval, the retrieval must be 719 considered truncated. 721 (2) On retrieval of type A or AAAA RRs, the end entity KEY RR(s) will 722 be included. On inclusion of A or AAAA RRs as additional 723 information, their KEY RRs will also be included but with lower 724 priority than the relevant A or AAAA RRs. 726 3.8 File Representation of KEY RRs 728 KEY RRs may appear as lines in a zone data master file. 730 The flag field, protocol, and algorithm number octets are then 731 represented as unsigned integers. Note that if the type field has 732 the "no key" value or the algorithm specified is 253, nothing appears 733 after the algorithm octet. 735 The remaining public key portion is represented in base 64 (see 736 Appendix) and may be divided up into any number of white space 737 separated substrings, down to single base 64 digits, which are 738 concatenated to obtain the full signature. These substrings can span 739 lines using the standard parenthesis. 741 Note that the public key may have internal sub-fields but these do 742 not appear in the master file representation. For example, with 743 algorithm 1 there is a public size, then a public exponent, and then 744 a modulus. With algorithm 254, there will be an OID followed by 745 algorithm dependent information. But in both cases only a single 746 logical base 64 string will appear in the master file. 748 4. The SIG Resource Record 750 The SIG or "signature" resource record (RR) is the fundamental way 751 that data is authenticated in the secure Domain Name System (DNS). As 752 such it is the heart of the security provided. 754 The SIG RR unforgably authenticates other RRs of a particular type, 755 class, and name and binds them to a time interval and the signer's 756 domain name. This is done using cryptographic techniques and the 757 signer's private key. The signer is frequently the owner of the zone 758 from which the RR originated. 760 4.1 SIG RDATA Format 762 The RDATA portion of a SIG RR is as shown below. The integrity of 763 the RDATA information is protected by the signature field. 765 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 766 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 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | type covered | algorithm | labels | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | original TTL | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | signature expiration | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | time signed | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | key footprint | / 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name / 778 / / 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | / 781 +- signature / 782 / / 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 The value of the SIG RR type is 24. 787 The "type covered" is the type of the other RRs covered by this SIG. 789 The algorithm number is an octet specifying the digital signature 790 algorithm used parallel to the algorithm octet for the KEY RR. The 791 MD5/RSA algorithm described in this draft is number 1. Numbers 2 792 through 252 are available for assignment should sufficient reason 793 arise to allocate them. However, the designation of a new algorithm 794 could have a major impact on the interoperability of the global DNS 795 system and requires an IETF standards action. Number 254 is reserved 796 for private use and will not be assigned a specific algorithm. For 797 number 254, the "signature" area shown above will actually begin with 798 an Object Identifier (OID) indicating the private algorithm in use 799 and the remainder of the signature area is whatever is required by 800 that algorithm. Number 253, known as the "expiration date 801 algorithm", is used when the expiration date or other non-signature 802 fields of the SIG are desired without any actual security. It is 803 anticipated that this algorithm will only be used in connection with 804 some modes of DNS dynamic update. For number 253, the signature 805 field will be null. Values 0 and 255 are reserved. 807 The "labels" octet is an unsigned count of how many labels there are 808 in the original SIG RR owner name not counting the null label for 809 root and not counting any initial "*" for a wildcard. If a secured 810 retrieval is the result of wild card substitution, it is necessary 811 for the resolver to use the original form of the name in verifying 812 the digital signature. This field helps optimize the determination 813 of the original form thus reducing the effort in authenticating 814 signed data. 816 If, on retrieval, the RR appears to have a longer name than indicated 817 by "labels", the resolver can tell it is the result of wildcard 818 substitution. If the RR owner name appears to be shorter than the 819 labels count, the SIG RR should be considered corrupt and ignored. 820 The maximum number of labels possible in the current DNS is 127 but 821 the entire octet is reserved and would be required should DNS names 822 ever be expanded to 255 labels. The following table gives some 823 examples. The value of "labels" is at the top, the retrieved owner 824 name on the left, and the table entry is the name to use in signature 825 verification except that "bad" means the RR is corrupt. 827 labels= | 0 | 1 | 2 | 3 | 4 | 828 --------+-----+------+--------+----------+----------+ 829 .| . | bad | bad | bad | bad | 830 d.| *. | d. | bad | bad | bad | 831 c.d.| *. | *.d. | c.d. | bad | bad | 832 b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad | 833 a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. | 835 The "original TTL" field is included in the RDATA portion to avoid 836 (1) authentication problems that caching servers would otherwise 837 cause by decrementing the real TTL field and (2) security problems 838 that unscrupulous servers could otherwise cause by manipulating the 839 real TTL field. This original TTL is protected by the signature 840 while the current TTL field is not. 842 NOTE: The "original TTL" must be restored into the covered RRs when 843 the signature is verified. This implies that all RRs for a 844 particular type, name, and class need to have the same TTL to start 845 with. 847 The SIG is valid until the "signature expiration" time which is an 848 unsigned number of seconds since the start of 1 January 1970, GMT, 849 ignoring leap seconds. (See also Section 4.4.) SIG RRs should not 850 have a date signed significantly in the future. To prevent 851 misordering of network request to update a zone dynamically, 852 monotonically increasing "time signed" dates may be necessary. 854 The "time signed" field is an unsigned number of seconds since the 855 start of 1 January 1970, GMT, ignoring leap seconds. 857 A SIG RR with an expiration date before the time signed should be 858 considered corrupt and ignored. 860 The "key footprint" is a 16 bit quantity that is used to help 861 efficiently select between multiple keys which may be applicable and 862 as a quick check that a public key about to be used for the 863 computationally expensive effort to check the signature is possibly 864 valid. Its exact meaning is algorithm dependent. For the MD5/RSA 865 algorithm, it is the next to the bottom two octets of the public key 866 modulus needed to decode the signature field. That is to say, the 867 most significant 16 of the lest significant 24 bits of the modulus in 868 network order. 870 The "signer's name" field is the domain name of the signer generating 871 the SIG RR. This is the owner of the public KEY RR that can be used 872 to verify the signature. It is frequently the zone which contained 873 the RR(s) being authenticated. The signer's name may be compressed 874 with standard DNS name compression when being transmitted over the 875 network. 877 The structure of the "signature" field is described below. 879 4.1.1 Signature Data 881 Except for algorithm number 253 where it is null, the actual 882 signature portion of the SIG RR binds the other RDATA fields to all 883 of the "type covered" RRs with that owner name and class. These 884 covered RRs are thereby authenticated. To accomplish this, a data 885 sequence is constructed as follows: 887 data = RDATA | RR(s)... 889 where "|" is concatenation, RDATA is all the RDATA fields in the SIG 890 RR itself before the signature, and RR(s) are all the RR(s) of the 891 type covered with the same owner name and class as the SIG RR in 892 canonical form and order. How this data sequence is processed into 893 the signature is algorithm dependent. 895 For purposes of DNS security, the canonical form for an RR is the RR 896 with domain names (1) fully expanded (no name compression via 897 pointers), (2) all domain name letters set to lower case, and (3) the 898 original TTL substituted for the current TTL. 900 For purposes of DNS security, the canonical order for RRs is to sort 901 them in ascending order by name, as left justified unsigned octet 902 sequences in network (transmission) order where a missing octet sorts 903 before a zero octet. (See also ordering discussion in Section 5.1.) 904 Within any particular name they are similarly sorted by type and then 905 RDATA as a left justified unsigned octet sequence. EXCEPT that the 906 type SIG RR(s) covering any particular type appear immediately after 907 the other RRs of that type. (This special consideration for SIG 908 RR(s) in ordering really only applies to calculating the AXFR SIG RR 909 as explained in section 4.1.3 below.) Thus if at name a.b there are 910 two A RRs and one KEY RR, their order with SIGs for concatenating the 911 "data" to be signed would be as follows: 913 a.b. A .... 914 a.b. A .... 915 a.b. SIG A ... 916 a.b. KEY ... 917 a.b. SIG KEY ... 919 SIGs covering type ANY should not be included in a zone. 921 4.1.2 MD5/RSA Algorithm Signature Calculation 923 For the MD5/RSA algorithm, the signature is as follows 925 hash = MD5 ( data ) 927 signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n) 929 where MD5 is the message digest algorithm documented in RFC 1321, "|" 930 is concatenation, "e" is the private key exponent of the signer, and 931 "n" is the public modulus of the signer's public key. 01, FF, and 00 932 are fixed octets of the corresponding hexadecimal value. "prefix" is 933 the ASN.1 BER MD5 algorithm designator prefix specified in PKCS1, 934 that is, 935 hex 3020300c06082a864886f70d020505000410 [NETSEC]. 936 This prefix is included to make it easier to use RSAREF or similar 937 packages. The FF octet is repeated the maximum number of times such 938 that the value of the quantity being exponentiated is one octet 939 shorter than the value of n. 941 (The above specifications are Public Key Cryptographic Standard #1 942 [PKCS1].) 943 The size of n, including most and least significant bits (which will 944 be 1) SHALL be not less than 512 bits and not more than 2552 bits. n 945 and e SHOULD be chosen such that the public exponent is small. 947 Leading zeros bytes are not permitted in the MD5/RSA algorithm 948 signature. 950 A public exponent of 3 minimizes the effort needed to decode a 951 signature. Use of 3 as the public exponent may be weak for 952 confidentiality uses since, if the same data can be collected 953 encrypted under three different keys with an exponent of 3 then, 954 using the Chinese Remainder Theorem, the original plain text can be 955 easily recovered. This weakness is not significant for DNS because 956 we seek only authentication, not confidentiality. 958 4.1.3 Zone Transfer (AXFR) SIG 960 The above SIG mechanisms assure the authentication of all zone signed 961 RRs of a particular name, class and type. However, to efficiently 962 assure the completeness of and secure zone transfers, a SIG RR owned 963 by the zone name must be created with a type covered of AXFR that 964 covers all RRs in the zone other than those signed by dynamic update 965 keys and the SIG AXFR itself. The RRs are ordered and concatenated 966 for hashing as described in Section 4.1.1. (See also ordering 967 discussion in Section 5.1.) 969 The AXFR SIG must be calculated last of all zone key signed SIGs in 970 the zone. In effect, when signing the zone, you order, as described 971 above, all RRs to be signed by the zone. You can then make one pass 972 inserting all the zone SIGs. As you proceed you hash RRs into both 973 an RRset hash and the zone hash. When the name or type changes you 974 calculate and insert the RRset SIG, clear the RRset hash, and hash 975 that SIG into the zone hash. When you have finished processing all 976 the starting RRs as described above, you can then use the cumulative 977 zone hash RR to calculate and insert an AXFR SIG covering the zone. 978 Of course any computational technique producing the same results as 979 above is permitted. 981 The AXFR SIG really belongs to the zone as a whole, not to the zone 982 name. Although it should be correct for the zone name, the labels 983 field of an AXFR SIG is otherwise meaningless. The AXFR SIG is only 984 retrieved as part of a zone transfer. After validation of the AXFR 985 SIG, the zone MAY be considered valid without verification of the 986 internal zone signed SIGs in the zone; however, any SIGs signed by 987 entity keys or the like must still be validated. The AXFR SIG SHOULD 988 be transmitted first in a zone transfer so the receiver can tell 989 immediately that they may be able to avoid verifying other zone 990 signed SIGs. 992 RRs which are authenticated by a dynamic update key and not by the 993 zone key (see Section 3.2) are not included in the AXFR SIG. They may 994 originate in the network and might not, in general, be migrated to 995 the recommended off line zone signing procedure (see Section 7.2). 996 Thus, such RRs are not directly signed by the zone, are not included 997 in the AXFR SIG, and are protected against omission from zone 998 transfers only to the extent that the server and communication can be 999 trusted. 1001 4.1.4 Transaction and Request SIGs 1003 A response message from a security aware server may optionally 1004 contain a special SIG as the last item in the additional information 1005 section to authenticate the transaction. 1007 This SIG has a "type covered" field of zero, which is not a valid RR 1008 type. It is calculated by using a "data" (see Section 4.1.2) of the 1009 entire preceding DNS reply message, including DNS header, 1010 concatenated with the entire DNS query message that produced this 1011 response, including the query's DNS header. That is 1013 data = full response (less final transaction SIG) | full query 1015 Verification of the transaction SIG (which is signed by the server 1016 host key, not the zone key) by the requesting resolver shows that the 1017 query and response were not tampered with in transit, that the 1018 response corresponds to the intended query, and that the response 1019 comes from the queried server. 1021 A DNS request may be optionally signed by including one or more SIGs 1022 at the end of the query. Such SIGs are identified by having a "type 1023 covered" field of zero. They sign the preceding DNS request message 1024 including DNS header but not including any preceding request SIGs. 1025 Such request SIGs are included in the "data" used to form any 1026 optional response transaction SIG. 1028 WARNING: Request SIGs are unnecessary for currently defined queries 1029 and will cause almost all existing DNS servers to completely ignore a 1030 query. However, such SIGs may be need to authenticate future DNS 1031 secure dynamic update or other requests. 1033 4.2 SIG RRs in the Construction of Responses 1035 Security aware DNS servers MUST, for every authoritative RR the query 1036 will return, attempt to send the available SIG RRs which authenticate 1037 the requested RR. The following rules apply to the inclusion of SIG 1038 RRs in responses: 1040 1. when an RR is placed in a response, its SIG RR has a higher 1041 priority for inclusion than other RRs that may need to be 1042 included. If space does not permit its inclusion, the response 1043 MUST be considered truncated except as provided in 2 below. 1045 2. when a SIG RR is present in the zone for an additional information 1046 section RR, the response MUST NOT be considered truncated merely 1047 because space does not permit the inclusion of its SIG RR. 1049 3. SIGs to authenticate non-authoritative data (glue records and NS 1050 RRs for subzones) are unnecessary and MUST NOT be sent. (Note 1051 that KEYs for subzones are controlling in a superzone so the 1052 superzone's signature on the KEY MUST be included (unless the KEY 1053 was additional information).) 1055 4. If a SIG covers any RR that would be in the answer section of the 1056 response, its automatic inclusion MUST be the answer section. If 1057 it covers an RR that would appear in the authority section, its 1058 automatic inclusion MUST be in the authority section. If it 1059 covers an RR that would appear in the additional information 1060 section it MUST appear in the additional information section. 1061 This is a change in the existing standard which contemplates only 1062 NS and SOA RRs in the authority section. 1064 5. Optionally, DNS transactions may be authenticated by a SIG RR at 1065 the end of the response in the additional information section 1066 (Section 4.1.4). Such SIG RRs are signed by the DNS server 1067 originating the response. Although the signer field MUST be the 1068 name of the originating server host, the owner name, class, TTL, 1069 and original TTL, are meaningless. The class and TTL fields 1070 SHOULD be zero. To conserve space, the owner name SHOULD be root 1071 (a single zero octet). If transaction authentication is desired, 1072 that SIG RR must be considered higher priority for inclusion than 1073 any other RR in the response. 1075 4.3 Processing Responses and SIG RRs 1077 The following rules apply to the processing of SIG RRs included in a 1078 response: 1080 1. a security aware resolver that receives a response from what it 1081 believes to be a security aware server via a secure communication 1082 with the AD bit (see Section 6.1) set, MAY choose to accept the 1083 RRs as received without verifying the SIG RRs. 1085 2. in other cases, a security aware resolver SHOULD verify the SIG 1086 RRs for the RRs of interest. This may involve initiating 1087 additional queries for SIG or KEY RRs, especially in the case of 1088 getting a response from an insecure server. (As explained in 4.2 1089 above, it will not be possible to secure CNAMEs being served up by 1090 non-secure resolvers.) 1092 NOTE: Implementers might expect the above SHOULD to be a MUST. 1093 However, local policy or the calling application may not require 1094 the security services. 1096 3. If SIG RRs are received in response to a user query explicitly 1097 specifying the SIG type, no special processing is required. 1099 If the message does not pass reasonable checks or the SIG does not 1100 check against the signed RRs, the SIG RR is invalid and should be 1101 ignored. If all of the SIG RR(s) purporting to authenticate a set of 1102 RRs are invalid, then the set of RR(s) is not authenticated. 1104 If the SIG RR is the last RR in a response in the additional 1105 information section and has a type covered of zero, it is a 1106 transaction signature of the response and the query that produced the 1107 response. It MAY be optionally checked and the message rejected if 1108 the checks fail. But even if the checks succeed, such a transaction 1109 authentication SIG does NOT authenticate any RRs in the message. 1110 Only a proper SIG RR signed by the zone or a key tracing its 1111 authority to the zone can authenticate RRs. If a resolver does not 1112 implement transaction and/or request SIGs, it MUST ignore them 1113 without error. 1115 If all reasonable checks indicate that the SIG RR is valid then RRs 1116 verified by it should be considered authenticated. 1118 4.4 Signature Expiration, TTLs, and Validity 1120 Security aware servers must not consider SIG RRs to authenticate 1121 anything after their expiration time and not consider any RR to be 1122 authenticated after its signatures have expired. Within that 1123 constraint, servers should continue to follow DNS TTL aging. Thus 1124 authoritative servers should continue to follow the zone refresh and 1125 expire parameters and a non-authoritative server should count down 1126 the TTL and discard RRs when the TTL is zero. In addition, when RRs 1127 are transmitted in a query response, the TTL should be trimmed so 1128 that current time plus the TTL does not extend beyond the signature 1129 expiration time. Thus, in general, the TTL on an transmitted RR 1130 would be 1132 min(sigExpTim,max(zoneMinTTL,min(originalTTL,currentTTL))) 1134 4.5 File Representation of SIG RRs 1136 A SIG RR can be represented as a single logical line in a zone data 1137 file [RFC1033] but there are some special considerations as described 1138 below. (It does not make sense to include a transaction or request 1139 authenticating SIG RR in a file as they are a transient 1140 authentication that covers data including an ephemeral transaction 1141 number and so must be calculated in real time.) 1143 There is no particular problem with the signer, covered type, and 1144 times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY 1145 is the year, the first MM is the month number (01-12), DD is the day 1146 of the month (01-31), HH is the hour in 24 hours notation (00-23), 1147 the second MM is the minute (00-59), and SS is the second (00-59). 1149 The original TTL and algorithm fields appear as unsigned integers. 1151 If the original TTL, which applies to the type signed, is the same as 1152 the TTL of the SIG RR itself, it may be omitted. The date field 1153 which follows it is larger than the maximum possible TTL so there is 1154 no ambiguity. 1156 The "labels" field does not appear in the file representation as it 1157 can be calculated from the owner name. 1159 The key footprint appears as an unsigned decimal number. 1161 However, the signature itself can be very long. It is the last data 1162 field and is represented in base 64 (see Appendix) and may be divided 1163 up into any number of white space separated substrings, down to 1164 single base 64 digits, which are concatenated to obtain the full 1165 signature. These substrings can be split between lines using the 1166 standard parenthesis. 1168 5. Non-existent Names and Types 1170 The SIG RR mechanism described in Section 4 above provides strong 1171 authentication of RRs that exist in a zone. But is it not 1172 immediately clear how to authenticatably deny the existence of a name 1173 in a zone or a type for an existent name. 1175 The nonexistence of a name in a zone is indicated by the NXT ("next") 1176 RR for a name interval containing the nonexistent name. A NXT RR and 1177 its SIG are returned in the authority section, along with the error, 1178 if the server is security aware. The same is true for a non-existent 1179 type under an existing name. This is a change in the existing 1180 standard which contemplates only NS and SOA RRs in the authority 1181 section. NXT RRs will also be returned if an explicit query is made 1182 for the NXT type. 1184 The existence of a complete set of NXT records in a zone means that 1185 any query for any name and any type to a security aware server 1186 serving the zone will always result in an reply containing at least 1187 one signed RR. 1189 NXT RRs do not appear in zone master files since they can be derived 1190 from the rest of the zone. 1192 5.1 The NXT Resource Record 1194 The NXT resource record is used to securely indicate that RRs with an 1195 owner name in a certain name interval do not exist in a zone and to 1196 indicate what zone signed RR types are present for an existing name. 1198 The owner name of the NXT RR is an existing name in the zone. It's 1199 RDATA is a "next" name and a type bit map. The presence of the NXT RR 1200 means that generally no name between its owner name and the name in 1201 its RDATA area exists and that no other zone signed types exist under 1202 its owner name. This implies a canonical ordering of all domain 1203 names in a zone. 1205 The ordering is to sort labels as unsigned left justified octet 1206 strings where the absence of a octet sorts before a zero octet and 1207 upper case letters are treated as lower case letters. Names are then 1208 sorted by sorting on the highest level label and then, within those 1209 names with the same highest level label by the next lower label, etc. 1210 down to leaf node labels. Since we are talking about a zone, the 1211 zone name itself always exists and all other names are the zone name 1212 with some prefix of lower level labels. Thus the zone name itself 1213 always sorts first. 1215 There is a problem with the last NXT in a zone as it wants to have an 1216 owner name which is the last existing name in sort order, which is 1217 easy, but it is not obvious what name to put in its RDATA to indicate 1218 the entire remainder of the name space. This is handled by treating 1219 the name space as circular and putting the zone name in the RDATA of 1220 the last NXT in a zone. 1222 There are special considerations due to interaction with wildcards as 1223 explained below. 1225 The NXT RRs for a zone should be automatically calculated and added 1226 to the zone by the same recommended off-line process that signs the 1227 zone (see Section 7.2). The NXT RR's TTL should not exceed the zone 1228 minimum TTL. 1230 5.2 NXT RDATA Format 1232 The RDATA for an NXT RR consists simply of a domain name followed by 1233 a bit map. 1235 The type number for the NXT RR is 30. 1237 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1238 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 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | next domain name / 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | type bit map / 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 The NXT RR type bit map is one bit per RR type present for the owner 1246 name similar to the WKS socket bit map. The first bit represents RR 1247 type zero (an illegal type which should not be present.) A one bit 1248 indicates that at least one RR of that type is present for the owner 1249 name. A zero indicates that no such RR is present. All bits not 1250 specified because they are beyond the end of the bit map are assumed 1251 to be zero. Note that bit 30, for NXT, will always be on so the 1252 minimum bit map length is actually four octets. The NXT bit map 1253 should be printed as a list of RR type mnemonics or decimal numbers 1254 similar to the WKS RR. 1256 The domain name may be compressed with standard DNS name compression 1257 when being transmitted over the network. The size of the bit map can 1258 be inferred from the RDLENGTH and the length of the next domain name. 1260 5.3 Example 1262 Assume zone foo.tld has entries for 1264 big.foo.tld, 1265 medium.foo.tld. 1266 small.foo.tld. 1267 tiny.foo.tld. 1269 Then a query to a security aware server for huge.foo.tld would 1270 produce an error reply with the authority section data including 1271 something like the following: 1273 big.foo.tld. NXT medium.foo.tld. A MX SIG NXT 1274 big.foo.tld. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3 1275 19960102030405 ;signature expiration 1276 19951211100908 ;time signed 1277 2143658709 ;key footprint 1278 foo.tld. ;signer 1279 MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU 1280 1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits) 1281 ) 1283 Note that this response implies that big.foo.tld is an existing name 1284 in the zone and thus has other RR types associated with it than NXT. 1285 However, only the NXT (and its SIG) RR appear in the response to this 1286 query for huge.foo.tld, which is a non-existent name. 1288 5.4 Interaction of NXT RRs and Wildcard RRs 1290 Since, in some sense, a wildcard RR causes all possible names in an 1291 interval to exist, there should not be an NXT RR that would cover any 1292 part of this interval. Thus if *.X.ZONE exists you would expect an 1293 NXT RR that ends at X.ZONE and one that starts with the last name 1294 covered by *.X.ZONE. However, this "last name covered" is something 1295 very ugly and long like \255\255\255....X.zone. So the NXT for the 1296 interval following is simply given the owner name *.X.ZONE. This "*" 1297 type name is not expanded when the NXT is returned as authority 1298 information in connection with a query for a non-existent name. 1300 If there could be any wildcard RRs in a zone and thus wildcard NXTs, 1301 care must be taken in interpreting the results of explicit NXT 1302 retrievals as the owner name may be a wildcard expansion. 1304 The existence of one or more wildcard RRs covering a name interval 1305 makes it possible for a malicious server to hide any more 1306 specifically named RRs in the internal. The server can just falsely 1307 return the wildcard match NXT instead of the more specifically named 1308 RRs. If there is a zone wide wildcard, there will be an NXT RR whose 1309 owner name is the wild card and whose RDATA is the zone name. In 1310 this case a server could conceal the existence of any more specific 1311 RRs in the zone. (It would be possible to design a more strict NXT 1312 feature which would eliminate this possibility. But it would be more 1313 complex and might be so constraining as to make any dynamic update 1314 feature very difficult.) 1316 What name should be put into the RDATA of an NXT RR with an owner 1317 name that is within a wild card scope? Since the "next" existing 1318 name will be one that matches the wild card, the wild card name 1319 should be used. Inclusion of such NXTs for names interior to a wild 1320 card scope is optional. 1322 5.5 Blocking NXT Pseudo-Zone Transfers 1324 In a secure zone, a resolver can query for the initial NXT associated 1325 with the zone name. Using the next domain name RDATA field from that 1326 RR, it can query for the next NXT RR. By repeating this, it can walk 1327 through all the NXTs in the zone. If there are no wildcards, it can 1328 use this technique to find all names in a zone. If it does type ANY 1329 queries, it can incrementally get all information in the zone and 1330 perhaps defeat attempts to administratively block zone transfers. 1332 If there are any wildcards, this NXT walking technique will not find 1333 any more specific RR names in the part of the name space the wildcard 1334 covers. By doing explicit retrievals for wildcard names, a resolver 1335 could determine what intervals are covered by wildcards but still 1336 could not, with these techniques, find any names inside such 1337 intervals except by trying every name. 1339 If it is desired to block NXT walking, the recommended method is to 1340 add a zone wide wildcard of the KEY type with the no-key type value 1341 and with no type (zone, entity, or user) bit on. This will cause 1342 there to be one zone covering NXT RR and leak no information about 1343 what real names exist in the zone. This protection from pseudo-zone 1344 transfers is bought at the expense of eliminating the data origin 1345 authentication of the non-existence of names that NXT RRs can 1346 provide. If an entire zone is covered by a wildcard, a malicious 1347 server can return an RR produced by matching the resulting wildcard 1348 NXT and can thus hide all the real data and delegations with more 1349 specific names in the zone. 1351 5.6 Special Considerations at Delegation Points 1353 A name (other than root) which is the head of a zone also appears as 1354 the leaf in a superzone. If both are secure, there will always be 1355 two different NXT RRs with the same name. They can be distinguished 1356 by their signers and next domain name fields. Security aware servers 1357 should return the correct NXT automatically when required to 1358 authenticate the non-existence of a name and both NXTs, if available, 1359 on explicit query for type NXT. 1361 Insecure servers will never automatically return an NXT and some 1362 implementations may only return the NXT from the subzone on explicit 1363 queries. 1365 6. The AD and CD Bits and How to Resolve Securely 1367 Retrieving or resolving authentic data from the Domain Name System 1368 (DNS) involves starting with one or more trusted public keys for one 1369 or more zones. With trusted keys, a resolver willing to perform 1370 cryptography can progress securely through the secure DNS zone 1371 structure to the zone of interest as described in Section 6.3. Such 1372 trusted public keys would normally be configured in a manner similar 1373 to that described in Section 6.2. However, as a practical matter, a 1374 security aware resolver would still gain some confidence in the 1375 results it returns even if it was not configured with any keys but 1376 trusted what it got from a local well known server as a starting 1377 point. 1379 Data stored at a security aware server needs to be internally 1380 categorized as Authenticated, Pending, or Insecure. There is also a 1381 fourth transient state of Bad which indicates that all SIG checks 1382 have explicitly failed on the data. Such Bad data is not retained at 1383 a security aware server. Authenticated means that the data has a 1384 valid SIG under a KEY traceable via a chain of zero or more SIG and 1385 KEY RRs to a KEY configured at the resolver via its boot file. 1386 Pending data has no authenticated SIGs and at least one additional 1387 SIG the resolver is still trying to authenticate. Insecure data is 1388 data which it is known can never be either Authenticated or found Bad 1389 because it is in or has been reached via a non-secured zone. Behavior 1390 in terms of control of and flagging based on such data labels is 1391 described in Section 6.1. 1393 The proper validation of signatures requires a reasonably secure 1394 shared opinion of the absolute time between resolvers and servers as 1395 described in Section 6.4. 1397 6.1 The AD and CD Header Bits 1399 Two unused bits are allocated out of the DNS query/response format 1400 header. The AD (authentic data) bit indicates in a response that the 1401 data included has been verified by the server providing it. The CD 1402 (checking disabled) bit indicates in a query that non-verified data 1403 is acceptable to the resolver sending the query. 1405 These bits are allocated from the must-be-zero Z field as follows: 1407 1 1 1 1 1 1 1408 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1409 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1410 | ID | 1411 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1412 |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | 1413 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1414 | QDCOUNT | 1415 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1416 | ANCOUNT | 1417 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1418 | NSCOUNT | 1419 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1420 | ARCOUNT | 1421 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1423 These bits are zero in old servers and resolvers. Thus the responses 1424 of old servers are not flagged as authenticated to security aware 1425 resolvers and queries from non-security aware resolvers do not assert 1426 the checking disabled bit and thus will be answered by security aware 1427 servers only with authenticated data. Of course security aware 1428 resolvers can not trust the AD bit unless they trust the server they 1429 are talking to and either have a secure path to it or use DNS 1430 transaction security. 1432 Any security aware resolver willing to do cryptography SHOULD assert 1433 the CD bit on all queries to reduce DNS latency time by allowing 1434 security aware servers to answer before they have resolved the 1435 validity of data. 1437 Security aware servers NEVER return Bad data. For non-security aware 1438 resolvers or security aware resolvers requesting service by having 1439 the CD bit clear, security aware servers return only Authenticated or 1440 Insecure data with the AD bit set in the response. Security aware 1441 resolvers will know that if data is Insecure versus Authentic by the 1442 absence of SIG RRs. Security aware servers may return Pending data 1443 to security aware resolvers requesting the service by clearing the AD 1444 bit in the response. The AD bit may only be set on a response if the 1445 RRs in the response are either Authenticated or Insecure. 1447 6.2 Boot File Format 1449 The format for a boot file directive to configure a starting zone key 1450 is as follows: 1452 pubkey name flags protocol algorithm key-data 1454 for a public key. "name" is the owner name (if the line is 1455 translated into a KEY RR). Flags indicates the type of key and is 1456 the same as the flag octet in the KEY RR. Protocol and algorithm 1457 also have the same meaning as they do in the KEY RR. The material 1458 after the algorithm is algorithm dependent and, for private 1459 algorithms (algorithm 254), starts with the algorithm's identifying 1460 OID. If the "no key" type value is set in flags or the algorithm is 1461 specified as 253, then the key-data after algorithm is null. It is 1462 treated as an octet stream and encoded in base 64 (see Appendix). 1464 A file of keys for cross certification or other purposes can be 1465 configured though the keyfile directive as follows: 1467 keyfile filename 1469 The file looks like a master file except that it can only contain KEY 1470 and SIG RRs with the SIGs signed under a key configured with the 1471 pubkey directive. 1473 While it might seem logical for everyone to start with the key for 1474 the root zone, this has problems. The logistics of updating every 1475 DNS resolver in the world when the root key changes would be 1476 excessive. It may be some time before there even is a root key. 1477 Furthermore, many organizations will explicitly wish their "interior" 1478 DNS implementations to completely trust only their own zone. These 1479 interior resolvers can then go through the organization's zone 1480 servers to access data outsize the organization's domain. 1482 6.3 Chaining Through Zones 1484 Starting with one or more trusted keys for a zone, it should be 1485 possible to retrieve signed keys for its subzones which have a key 1486 and, if the zone is not root, for its superzone. Every authoritative 1487 secure zone server MUST also include the KEY RR for a super-zone 1488 signed by the secure zone via a keyfile directive. This makes it 1489 possible to climb the tree of zones if one starts below root. A 1490 secure sub-zone is indicated by a KEY RR with non-null key 1491 information appearing with the NS RRs for the sub-zone. These make 1492 it possible to descend within the tree of zones. 1494 A resolver should keep track of the number of successive secure zones 1495 traversed from a starting point to any secure zone it can reach. In 1496 general, the lower such a distance number is, the greater the 1497 confidence in the data. Data configured via a boot file directive 1498 should be given a distance number of zero. Should a query encounter 1499 different data for the same query with different distance values, 1500 that with a larger value should be ignored. 1502 A security conscious resolver should completely refuse to step from a 1503 secure zone into a non-secure zone unless the non-secure zone is 1504 certified to be non-secure, or only experimentally secure, by the 1505 presence of an authenticated KEY RR for the non-secure zone with the 1506 no-key type value or the presence of a KEY RR with the experimental 1507 bit set. Otherwise the resolver is getting bogus or spoofed data. 1509 If legitimate non-secure zones are encountered in traversing the DNS 1510 tree, then no zone can be trusted as secure that can be reached only 1511 via information from such non-secure zones. Since the non-secure zone 1512 data could have been spoofed, the "secure" zone reach via it could be 1513 counterfeit. The "distance" to data in such zones or zones reached 1514 via such zones could be set to 512 or more as this exceeds the 1515 largest possible distance through secure zones in the DNS. 1516 Nevertheless, continuing to apply secure checks within "secure" zones 1517 reached via non-secure zones is a good practice and will, as a 1518 practical matter, provide some small increase in security. 1520 6.4 Secure Time 1522 Coordinated interpretation of the time fields in SIG RRs requires 1523 that reasonably consistent time be available to the hosts 1524 implementing the DNS security extensions. 1526 A variety of time synchronization protocols exist including the 1527 Network Time Protocol (NTP, RFC1305). If such protocols are used, 1528 they MUST be used securely so that time can not be spoofed. 1529 Otherwise, for example, a host could get its clock turned back and 1530 might then believe old SIG and KEY RRs which were valid but no longer 1531 are. 1533 7. Operational Considerations 1535 This section discusses a variety of considerations in secure 1536 operation of the Domain Name System (DNS) using these protocol 1537 extensions. 1539 7.1 Key Size Considerations 1541 There are a number of factors that effect public key size choice for 1542 use in the DNS security extension. Unfortunately, these factors 1543 usually do not all point in the same direction. Choice of zone key 1544 size should generally be made by the zone administrator depending on 1545 their local conditions. 1547 For most schemes, larger keys are more secure but slower. Given a 1548 small public exponent, verification (the most common operation) for 1549 the MD5/RSA algorithm will vary roughly with the square of the 1550 modulus length, signing will vary with the cube of the modulus 1551 length, and key generation (the least common operation) will vary 1552 with the fourth power of the modulus length. The current best 1553 algorithms for factoring a modulus and breaking RSA security vary 1554 roughly with the 1.6 power of the modulus itself. Thus going from a 1555 640 bit modulus to a 1280 bit modulus only increases the verification 1556 time by a factor of 4 but increases the work factor of breaking the 1557 key by over 2^900. An upper bound of 2552 bits has been established 1558 for the MD5/RSA DNS security algorithm for interoperability purposes. 1560 However, larger keys increase the size of the KEY and SIG RRs. This 1561 increases the chance of DNS UDP packet overflow and the possible 1562 necessity for using higher overhead TCP in responses. 1564 The recommended minimum RSA algorithm modulus size, 640 bits, is 1565 believed by the authors to be secure at this time but high level 1566 zones in the DNS tree may wish to set a higher minimum, perhaps 1000 1567 bits, for security reasons. (Since the United States National 1568 Security Agency generally permits export of encryption systems using 1569 an RSA modulus of up to 512 bits, use of that small a modulus, i.e. 1570 n, must be considered weak.) 1572 For a key used only to secure data and not to secure other keys, 640 1573 bits should be adequate. 1575 7.2 Key Storage 1577 It is recommended that zone private keys and the zone file master 1578 copy be kept and used in off-line non-network connected physically 1579 secure machines only. Periodically an application can be run to add 1580 authentication to a zone by adding SIG and NXT RRs and adding no-key 1581 type KEY RRs for subzones where a real KEY RR is not provided. Then 1582 the augmented file can be transferred, perhaps by sneaker-net, to the 1583 networked zone primary server machine. 1585 The idea is to have a one way information flow to the network to 1586 avoid the possibility of tampering from the network. Keeping the 1587 zone master file on-line on the network and simply cycling it through 1588 an off-line signer does not do this. The on-line version could still 1589 be tampered with if the host it resides on is compromised. For 1590 maximum security, the master copy of the zone file should be off net 1591 and should not be updated based on an unsecured network mediated 1592 communication. 1594 Note, however, that secure resolvers need to be configured with some 1595 trusted on-line public key information (or a secure path to such a 1596 resolver). 1598 Non-zone private keys, such as host or user keys, generally have to 1599 be kept on line to be used for real-time purposes such as DNS 1600 transaction security, IPSEC session set-up, or secure mail. 1602 7.3 Key Generation 1604 Careful key generation is a sometimes overlooked but absolutely 1605 essential element in any cryptographically secure system. The 1606 strongest algorithms used with the longest keys are still of no use 1607 if an adversary can guess enough to lower the size of the likely key 1608 space so that it can be exhaustively searched. Suggestions will be 1609 found in RFC 1750. 1611 It is strongly recommended that key generation also occur off-line, 1612 perhaps on the machine used to sign zones (see Section 7.2). 1614 7.4 Key Lifetimes 1616 No key should be used forever. The longer a key is in use, the 1617 greater the probability that it will have been compromised through 1618 carelessness, accident, espionage, or cryptanalysis. Furthermore, if 1619 key rollover is a rare event, there is an increased risk that, when 1620 the time does come up change the key, no one at the site will 1621 remember how to do it or other problems will have developed in the 1622 procedures. 1624 While key lifetime is a matter of local policy, these considerations 1625 suggest that no zone key should have a lifetime significantly over 1626 four years. A reasonable maximum lifetime for zone keys that are 1627 kept off-line and carefully guarded is 13 months with the intent that 1628 they be replaced every year. A reasonable maximum lifetime for end 1629 entity keys that are used for IP-security or the like and are kept on 1630 line is 36 days with the intent that they be replaced monthly or more 1631 often. In some cases, an entity key lifetime of somewhat over a day 1632 may be reasonable. 1634 7.5 Signature Lifetime 1636 Signature expiration times must be set far enough in the future that 1637 it is quite certain that new signatures can be generated before the 1638 old ones expire. However, setting expiration too far into the future 1639 could, if bad data or signatures were ever generated, mean a long 1640 time to flush such badness. 1642 It is recommended that signature lifetime be a small multiple of the 1643 TTL but not less than a reasonable re-signing interval. 1645 7.6 Root 1647 It should be noted that in DNS the root is a zone unto itself. Thus 1648 the root zone key should only be seen signing itself or signing RRs 1649 with names one level below root, such as .aq, .edu, or .arpa. 1650 Implementations MAY reject as bogus any purported root signature of 1651 records with a name more than one level below root. The root zone 1652 contains the root KEY RR signed by a SIG RR under the root key 1653 itself. 1655 8. Conformance 1657 Several levels of server and resolver conformance are defined. 1659 8.1 Server Conformance 1661 Two levels of server conformance are defined as follows: 1663 Minimal server compliance is the ability to store and retrieve 1664 (including zone transfer) SIG, KEY, and NXT RRs. Any secondary, 1665 caching, or other server for a secure zone must be at least minimally 1666 compliant and even then some things, such as secure CNAMEs, will not 1667 work. 1669 Full server compliance adds the following to basic compliance: 1670 (1) ability to read SIG, KEY, and NXT RRs in zone files and (2) 1671 ability, given a zone file and private key, to add appropriate SIG 1672 and NXT RRs, possibly via a separate application, (3) proper 1673 automatic inclusion of SIG, KEY, and NXT RRs in responses, (4) 1674 suppression of CNAME following on retrieval of the security type RRs, 1675 (5) recognize the CD query header bit and set the AD query header 1676 bit, as appropriate, and (6) proper handling of the two NXT RRs at 1677 delegation points. Primary servers for secure zones MUST be fully 1678 compliant and for completely successful secure operation, all 1679 secondary, caching, and other servers handling the zone should be 1680 fully compliant as well. 1682 8.2 Resolver Conformance 1684 Two levels of resolver compliance are defined: 1686 A basic compliance resolver can handle SIG, KEY, and NXT RRs 1687 when they are explicitly requested. 1689 A fully compliant resolver (1) understands KEY, SIG, and NXT 1690 RRs, (2) maintains appropriate information in its local caches and 1691 database to indicate which RRs have been authenticated and to what 1692 extent they have been authenticated, (3) performs additional queries 1693 as necessary to attempt to obtain KEY, SIG, or NXT RRs from non- 1694 security aware servers, (4) normally sets the CD query header bit on 1695 its queries. 1697 9. Security Considerations 1699 This document describes technical details of extensions to the Domain 1700 Name System (DNS) protocol to provide data integrity and origin 1701 authentication, public key distribution, and optional transaction 1702 security. 1704 If should be noted that, at most, these extensions guarantee the 1705 validity of resource records, including KEY resource records, 1706 retrieved from the DNS. They do not magically solve other security 1707 problems. For example, using secure DNS you can have high confidence 1708 in the IP address you retrieve for a host name; however, this does 1709 not stop someone for substituting an unauthorized host at that 1710 address or capturing packets sent to that address and falsely 1711 responding with packets apparently from that address. Any reasonably 1712 complete security system will require the protection of many other 1713 facets of the Internet. 1715 References 1717 [NETSEC] - Network Security: PRIVATE Communications in a PUBLIC 1718 World, Charlie Kaufman, Radia Perlman, & Mike Speciner, Prentice Hall 1719 Series in Computer Networking and Distributed Communications 1995. 1721 [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 1722 3 June 1991, Version 1.4. 1724 [RFC1032] - Domain Administrators Guide, M. Stahl, November 1987 1726 [RFC1033] - Domain Administrators Operations Guide, M. Lottor, 1727 November 1987 1729 [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, 1730 November 1987 1732 [RFC1035] - Domain Names - Implementation and Specifications 1734 [RFC1305] - Network Time Protocol (v3), D. Mills, April 9 1992. 1736 [RFC1321] - The MD5 Message-Digest Algorithm, R. Rivest, April 16 1737 1992. 1739 [RFC1530] - Principles of Operation for the TPC.INT Subdomain: 1740 General Principles and Policy, C. Malamud, M. Rose, October 6 1993. 1742 [RFC1750] - Randomness Requirements for Security, D. Eastlake, S. 1743 Crocker, J. Schiller, December 1994. 1745 [RFC1825] - Security Architecture for the Internet Protocol, R. 1746 Atkinson, August 9 1995. 1748 [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. 1750 Authors Addresses 1752 Donald E. Eastlake, 3rd 1753 CyberCash, Inc. 1754 318 Acton Street 1755 Carlisle, MA 01741 USA 1757 Telephone: +1 508-287-4877 1758 +1 508-371-7148(fax) 1759 +1 703-620-4200(main office, Reston, Virginia, USA) 1760 EMail: dee@cybercash.com 1762 Charles W. Kaufman 1763 Iris Associates 1764 1 Technology Park Drive 1765 Westford, MA 01886 USA 1767 Telephone: +1 508-392-5276 1768 EMail: charlie_kaufman@iris.com 1770 Expiration and File Name 1772 This draft expires 29 July 1996. 1774 Its file name is draft-ietf-dnssec-secext-09.txt. 1776 Appendix: Base 64 Encoding 1778 The following encoding technique is taken from RFC 1521 by N. Borenstein 1779 and N. Freed. It is reproduced here in an edited form for convenience. 1781 A 65-character subset of US-ASCII is used, enabling 6 bits to be 1782 represented per printable character. (The extra 65th character, "=", 1783 is used to signify a special processing function.) 1785 The encoding process represents 24-bit groups of input bits as output 1786 strings of 4 encoded characters. Proceeding from left to right, a 1787 24-bit input group is formed by concatenating 3 8-bit input groups. 1788 These 24 bits are then treated as 4 concatenated 6-bit groups, each 1789 of which is translated into a single digit in the base 64 alphabet. 1791 Each 6-bit group is used as an index into an array of 64 printable 1792 characters. The character referenced by the index is placed in the 1793 output string. 1795 Table 1: The Base 64 Alphabet 1797 Value Encoding Value Encoding Value Encoding Value Encoding 1798 0 A 17 R 34 i 51 z 1799 1 B 18 S 35 j 52 0 1800 2 C 19 T 36 k 53 1 1801 3 D 20 U 37 l 54 2 1802 4 E 21 V 38 m 55 3 1803 5 F 22 W 39 n 56 4 1804 6 G 23 X 40 o 57 5 1805 7 H 24 Y 41 p 58 6 1806 8 I 25 Z 42 q 59 7 1807 9 J 26 a 43 r 60 8 1808 10 K 27 b 44 s 61 9 1809 11 L 28 c 45 t 62 + 1810 12 M 29 d 46 u 63 / 1811 13 N 30 e 47 v 1812 14 O 31 f 48 w (pad) = 1813 15 P 32 g 49 x 1814 16 Q 33 h 50 y 1816 Special processing is performed if fewer than 24 bits are available 1817 at the end of the data being encoded. A full encoding quantum is 1818 always completed at the end of a quantity. When fewer than 24 input 1819 bits are available in an input group, zero bits are added (on the 1820 right) to form an integral number of 6-bit groups. Padding at the 1821 end of the data is performed using the '=' character. Since all base 1822 64 input is an integral number of octets, only the following cases 1823 can arise: (1) the final quantum of encoding input is an integral 1824 multiple of 24 bits; here, the final unit of encoded output will be 1825 an integral multiple of 4 characters with no "=" padding, (2) the 1826 final quantum of encoding input is exactly 8 bits; here, the final 1827 unit of encoded output will be two characters followed by two "=" 1828 padding characters, or (3) the final quantum of encoding input is 1829 exactly 16 bits; here, the final unit of encoded output will be three 1830 characters followed by one "=" padding character.