idnits 2.17.1 draft-ietf-dnssec-secext-04.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-23) 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-04.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-secext-04.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-secext-04.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-04.txt,', but the file name used is 'draft-ietf-dnssec-secext-04' == 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 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 413: '... implementations MUST be designed to h...' RFC 2119 keyword, line 868: '... be 1) SHALL be not less than 512 bi...' RFC 2119 keyword, line 869: '... and e SHOULD be chosen such that th...' RFC 2119 keyword, line 937: '...ty aware servers MUST, for every autho...' RFC 2119 keyword, line 945: '... MUST be considered truncated....' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 811 has weird spacing: '..." field is de...' == Line 1326 has weird spacing: '...gorithm may b...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 2. when a SIG RR is present for an RR to be included in the additional information section, the response MUST not be considered truncated if space does not permit the inclusion of the SIG RR. == 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 (25 June 1995) is 10530 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 1530' is mentioned on line 466, but not defined == Unused Reference: 'RFC1032' is defined on line 1588, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1593, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 1596, but no explicit reference was found in the text == Unused Reference: 'RFC1305' is defined on line 1598, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 1600, but no explicit reference was found in the text == Unused Reference: 'RFC1750' is defined on line 1603, but no explicit reference was found in the text -- 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 ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA FAQ' Summary: 16 errors (**), 1 flaw (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 2 318 Acton Street +1 508-371-7148(fax) dee@world.std.com 3 Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) 4 DNS Security Working Group Donald E. Eastlake, 3rd 5 INTERNET-DRAFT CyberCash 6 Charles W. Kaufman 7 Iris 8 Expires: 24 December 1995 25 June 1995 10 Domain Name System Security Extensions 11 ------ ---- ------ -------- ---------- 13 Status of This Document 15 This draft, file name draft-ietf-dnssec-secext-04.txt, is intended to 16 be become a Proposed Standard RFC. Distribution of this document is 17 unlimited. Comments should be sent to the DNS Security Working Group 18 mailing list or to the authors. 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months. Internet-Drafts may be updated, replaced, or obsoleted by 27 other documents at any time. It is not appropriate to use Internet- 28 Drafts as reference material or to cite them other than as a 29 ``working draft'' or ``work in progress.'' 31 To learn the current status of any Internet-Draft, please check the 32 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 33 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, 34 munnari.oz.au, or ftp.is.co.za. 36 Abstract 38 The Domain Name System (DNS) has become a critical operational part 39 of the Internet infrastructure yet it has no strong security 40 mechanisms to assure data integrity or authentication. Extensions to 41 the DNS are described that provide these services to security aware 42 resolvers or applications through the use of cryptographic digital 43 signatures. These digital signatures are included in secured zones 44 as resource records. Security can still be provided even through 45 non-security aware DNS servers in many cases. 47 The extensions also provide for the storage of authenticated public 48 keys in the DNS. This storage of keys can support general public key 49 distribution service as well as DNS security. The stored keys enable 50 security aware resolvers to learn the authenticating key of zones in 51 addition to keys for which they are initially configured. Keys 52 associated with DNS names can be retrieved to support other 53 protocols. Provision is made for a variety of key types and 54 algorithms. 56 In addition, the security extensions provide for the optional 57 authentication of DNS protocol transactions. 59 Acknowledgements 61 The significant contributions of the following persons (in alphabetic 62 order) to this draft are gratefully acknowledged: 64 Madelyn Badger, Matt Crawford, James M. Galvin, Olafur 65 Gudmundsson, Sandy Murphy, Masataka Ohta, Michael A. Patton, 66 Jeffrey I. Schiller. 68 Table of Contents 70 Status of This Document....................................1 72 Abstract...................................................2 73 Acknowledgements...........................................2 75 Table of Contents..........................................3 77 1. Overview of Contents....................................5 79 2. Overview of the Extensions.............................6 80 2.1 Services Not Provided..................................6 81 2.2 Key Distribution.......................................6 82 2.3 Data Origin Authentication and Integrity...............7 83 2.3.1 The SIG Resource Record..............................7 84 2.3.2 Authenticating Name and Type Non-existence...........8 85 2.3.3 Special Considerations With Time-to-Live.............8 86 2.3.4 Special Considerations at Delegation Points..........9 87 2.3.5 Special Considerations with CNAME RRs................9 88 2.3.6 Signers Other Than The Zone..........................9 89 2.4 DNS Transaction Authentication........................10 91 3. The KEY Resource Record................................11 92 3.1 KEY RDATA format......................................11 93 3.2 Object Types, DNS Names, and Keys.....................11 94 3.3 The KEY RR Flag Field.................................12 95 3.4 The Protocol Octet....................................14 96 3.5 The KEY Algorithm Number and the MD5/RSA Algorithm....14 97 3.6 Interaction of Flags, Algorithm, and Protocol Bytes...15 98 3.7 KEY RRs in the Construction of Responses..............16 99 3.8 File Representation of KEY RRs........................16 101 4. The SIG Resource Record................................18 102 4.1 SIG RDATA Format......................................18 103 4.1.1 Signature Data......................................20 104 4.1.2 MD5/RSA Algorithm Signature Calculation.............21 105 4.1.3 Zone Transfer (AXFR) SIG............................22 106 4.1.4 Transaction SIGs....................................22 107 4.2 SIG RRs in the Construction of Responses..............23 108 4.3 Processing Responses and SIG RRs......................23 109 4.4 Signature Expiration, TTLs, and Validity..............24 110 4.5 File Representation of SIG RRs........................25 112 5. Non-existent Names and Types...........................26 113 5.1 The NXT Resource Record...............................26 114 5.2 NXT RDATA Format......................................27 115 5.3 Example...............................................27 116 5.4 Interaction of NXT RRs and Wildcard RRs...............28 117 5.5 Blocking NXT Pseudo-Zone Transfers....................28 118 5.6 Special Considerations at Delegation Points...........29 120 6. The AD and CD Bits and How to Resolve Securely.........30 121 6.1 The AD and CD Header Bits.............................30 122 6.2 Boot File Format......................................31 123 6.3 Chaining Through Zones................................32 124 6.4 Secure Time...........................................33 126 7. Operational Considerations.............................34 127 7.1 Key Size Considerations...............................34 128 7.2 Key Storage...........................................35 129 7.3 Key Generation........................................35 130 7.4 Key Lifetimes.........................................35 131 7.5 Signature Lifetime....................................36 132 7.6 Root..................................................36 134 8. Conformance............................................37 135 8.1 Server Conformance....................................37 136 8.2 Resolver Conformance..................................37 138 9. Security Considerations................................38 139 References................................................38 141 Authors Addresses.........................................39 142 Expiration and File Name..................................39 144 Appendix: Base 64 Encoding................................40 146 1. Overview of Contents 148 This draft describes extensions of the Domain Name System (DNS) 149 protocol to support DNS security and public key distribution. It 150 assumes that the reader is familiar with the Domain Name System, 151 particularly as described in RFCs 1034 and 1035. 153 Section 2 provides an overview of the extensions and the key 154 distribution, data origin authentication, and transaction security 155 they provide. 157 Section 3 discusses the KEY resource record, its structure, use in 158 DNS responses, and file representation. These resource records 159 represent the pubic keys of entities named in the DNS and are used 160 for key distribution. 162 Section 4 discusses the SIG digital signature resource record, its 163 structure, use in DNS responses, and file representation. These 164 resource records are used to authenticate other resource records in 165 the DNS and optionally to authenticate DNS transactions. 167 Section 5 discusses the NXT resource record and its use in DNS 168 responses. The NXT RR permits authenticated denial in the DNS of the 169 existence of a name or of a particular type for an existing name. 171 Section 6 discusses how a resolver can be configured with a starting 172 key or keys and proceed to securely resolve DNS requests. 173 Interactions between resolvers and servers are discussed for all 174 combinations of security aware and security non-aware. Two 175 additional query header bits are defined for signaling between 176 resolvers and servers. 178 Section 7 reviews a variety of operational considerations including 179 key generation, lifetime, and storage. 181 Section 8 defines levels of conformance for resolvers and servers. 183 Section 9 provides a few paragraphs on overall security 184 considerations. 186 An Appendix is provided that gives some details of base64 encoding 187 which is used in the file representation of some RR's defined in this 188 draft. 190 2. Overview of the Extensions 192 The Domain Name System (DNS) protocol security extensions provide 193 three distinct services: key distribution as described in Section 2.2 194 below, data origin authentication as described in Section 2.3 below, 195 and transaction authentication, described in Section 2.4 below. 197 Special considerations related to time to live, CNAMEs, and 198 delegation points are also discussed in Section 2.3. 200 2.1 Services Not Provided 202 It is part of the design philosophy of the DNS that the data in it is 203 public and that the DNS gives the same answers to all inquirers. 205 Following this philosophy, no attempt has been made to include any 206 sort of access control lists or other means to differentiate 207 inquirers. 209 In addition, no effort has been made to provide for any 210 confidentiality for queries or responses. (This service may be 211 available via other protocols such as a network level security 212 protocol providing confidentiality.) 214 2.2 Key Distribution 216 Resource records (RRs) are defined to associate keys with DNS names. 217 This permits the DNS to be used as a general public key distribution 218 mechanism in support of the data origin authentication and 219 transaction authentication DNS services as well as other security 220 services. 222 The syntax of a KEY resource record (RR) is described in Section 3. 223 It includes an algorithm identifier, flags indicating the type of 224 entity the key is associated with and/or asserting that there is no 225 key associated with that entity, and the actual public key 226 parameters. 228 Under conditions described in Section 3, security aware DNS servers 229 may automatically attempt to return KEY resources as additional 230 information, along with those resource records actually requested, to 231 minimize the number of queries needed. 233 2.3 Data Origin Authentication and Integrity 235 Security is provided by associating with resource records in the DNS 236 cryptographically generated digital signatures. Commonly, there will 237 be a single private key that signs for an entire zone. If a security 238 aware resolver reliably learns the public key of the zone, it can 239 verify, for any data read from that zone, that it was properly 240 authorized and is reasonably current. The expected implementation is 241 for the zone private key to be kept off-line and used to re-sign all 242 of the records in the zone periodically. 244 The data origin authentication key belongs to the zone and not to the 245 servers that store copies of the data. That means compromise of a 246 server or even all servers for a zone will not necessarily affect the 247 degree of assurance that a resolver has that the data is genuine. 249 A resolver can learn the public key of a zone either by reading it 250 from DNS or by having it staticly configured. To reliably learn the 251 public key by reading it from DNS, the key itself must be signed. 252 Thus, to provide a reasonable degree of security, the resolver must 253 be configured with at least the public key of one zone that it can 254 use to authenticate signatures. From that, it can securely read the 255 public keys of other zones if the intervening zones in the DNS tree 256 are secure. (It is in principle more secure to have the resolver 257 manually configured with the public keys of multiple zones, since 258 then the compromise of a single zone would not permit the faking of 259 information from other zones. It is also more administratively 260 cumbersome, however, particularly when public keys change.) 262 Adding origin authentication and integrity requires no change to the 263 "on-the-wire" DNS protocol beyond the addition of the signature 264 resource types (and, as a practical matter, the key resource type 265 needed for key distribution). This service can be supported by 266 existing resolver and server implementations so long as they can 267 support the additional resource types (see Section 8) with the one 268 exception that CNAME referals can not be authenticated if they are 269 from non-security aware servers (see Section 2.3.5). 271 If signatures are always separately retrieved and verified when 272 retrieving the information they authenticate, there will be more 273 trips to the server and performance will suffer. To avoid this, 274 security aware servers mitigate that degradation by always sending 275 the signature(s) needed. 277 2.3.1 The SIG Resource Record 279 The syntax of a SIG resource record (signature) is described in 280 Section 4. It includes the type of the RR(s) being signed, the name 281 of the signer, the time at which the signature was created, the time 282 it expires (when it is no longer to be believed), its original time 283 to live (which may be longer than its current time to live but cannot 284 be shorter), the cryptographic algorithm in use, and the actual 285 signature. 287 Every name in a zone supporting signed data will have associated with 288 it at least one SIG resource record for each resource type under that 289 name. A security aware server supporting the performance enhanced 290 version of the DNS protocol security extensions will attempt to 291 return, with all records retrieved, the corresponding SIGs. If a 292 server does not support the protocol, the resolver must retrieve all 293 the SIG records for a name and select the one or ones that sign the 294 resource record(s) that resolver is interested in. 296 2.3.2 Authenticating Name and Type Non-existence 298 The above security mechanism provides only a way to sign existing RRs 299 in a zone. "Data origin" authentication is not obviously provided 300 for the non-existence of a domain name in a zone or the non-existence 301 of a type for an existing name. This gap is filled by the NXT RR 302 which authenticatably asserts a range of non-existent names in a zone 303 and the non-existence types for the initial name in that range. 305 Section 5 below covers the NXT RR. 307 2.3.3 Special Considerations With Time-to-Live 309 A digital signature will fail to verify if any change has occurred to 310 the data between the time it was originally signed and the time the 311 signature is verified. This conflicts with our desire to have the 312 time-to-live field tick down when resource records are cached. 314 This could be avoided by leaving the time-to-live out of the digital 315 signature, but that would allow unscrupulous servers to set 316 arbitrarily long time to live values undetected. Instead, we include 317 the "original" time-to-live in the signature and communicate that 318 data in addition to the current time-to-live. Unscrupulous servers 319 under this scheme can manipulate the time to live but a security 320 aware resolver will bound the TTL value it uses at the original 321 signed value. Separately, signatures include a time signed and an 322 expiration time. A resolver that knows the absolute time can 323 determine securely whether a signature has expired. It is not 324 possible to rely solely on the signature expiration as a substitute 325 for the TTL, however, since non-security aware servers must still be 326 supported. 328 2.3.4 Special Considerations at Delegation Points 330 DNS security would like to view each zone as a unit of data 331 completely under the control of the zone owner and signed by the 332 zone's key. But the operational DNS views the leaf nodes in a zone 333 which are also the apex nodes of a subzone (i.e., delegation points) 334 as "really" belonging to the subzone. These nodes occur in two 335 master files and will have RRs signed by both the upper and lower 336 zone's keys. A retrieval could get a mixture of these RRs and SIGs, 337 especially since one server could be serving both the zone above and 338 below a delegation point. 340 In general, the KEY RR from the superzone is authoritative while for 341 all other RRs, the data from the subzone is more authoritative. To 342 avoid conflicts, only the KEY RR in the superzone should be signed 343 and the NS and any A (glue) RRs should only be signed in the subzone 344 along with the SOA and any other RRs that have the zone name as 345 owner. The only exception is the NXT RR type that will always appear 346 differently and authoritatively in both the superzone and subzone, if 347 both are secure, as described in Section 5. 349 2.3.5 Special Considerations with CNAME RRs 351 There is a significant problem with security related RRs with the 352 same owner name as a CNAME RR when retrieved from a non-security- 353 aware server. In particular, an initial retrieval for the CNAME or 354 any other type will not retrieve an associated signature, key, or NXT 355 RR. For types other than CNAME it will retrieve that type at the 356 target name of the CNAME (or chain of CNAMEs) and will return the 357 CNAME as additional info. In particular, a specific retrieval for 358 type SIG will not get the SIG, if any, at the original domain name 359 but rather an SIG at the target name. 361 In general, security aware servers must be used to securely CNAME in 362 DNS. Security aware servers must (1) allow KEY, SIG, and NXT RRs 363 along with CNAME RRs, (2) suppress CNAME processing on retrieval of 364 these types as well as on retrieval of the type CNAME, and (3) 365 automatically return SIG RRs authenticating the CNAME or CNAMEs 366 encountered in resolving a query. 368 2.3.6 Signers Other Than The Zone 370 There are two cases where a SIG resource record is signed by other 371 than the zone private key. One is for future support of dynamic 372 update where an entity is permitted to authenticate/update its own 373 records. The public key of the entity must be present in the DNS and 374 be appropriately signed but the other RR(s) may be signed with the 375 entity's key. The other is for support of transaction authentication 376 as described in Section 2.4 below. 378 2.4 DNS Transaction Authentication 380 The data origin authentication service described above protects 381 resource records but provides no protection for DNS message headers. 382 If header bits are falsely set by a server, there is little that can 383 be done. However, it is possible to add transaction authentication. 384 Such authentication means that a resolver can be sure it is at least 385 getting messages from the server it thinks it queried, that the 386 response is from the query it sent, and that these messages have not 387 been diddled in transit. 389 This is accomplished by optionally adding a special SIG resource 390 record to the end of the reply which digitally signs the 391 concatenation of the server's response and the resolver's query. The 392 private key used belongs to the host composing the reply, not to the 393 zone being queried. The corresponding public key is stored in and 394 retrieved from the DNS. Because replies are highly variable, message 395 authentication SIGs can not be pre-calculated. Thus it will be 396 necessary to keep the private key on-line, for example in software or 397 in a directly connected piece of hardware. 399 DNS level transaction authentication would be unnecessary if a lower 400 level (i.e., IP level) end-to-end security protocol were available. 401 However, such a protocol is not yet standardized and when it is, 402 there will be a significant time during which there will be systems 403 on which it will be hard to add such a protocol but relatively easy 404 to replace the DNS components. 406 3. The KEY Resource Record 408 The KEY resource record (RR) is used to document a key that is 409 associated with a Domain Name System (DNS) name. It will be a public 410 key as only public keys are stored in the DNS. This can be the 411 public key of a zone, of a host or other end entity, or a user. A 412 KEY RR is, like any other RR, authenticated by a SIG RR. Security 413 aware DNS implementations MUST be designed to handle at least two 414 simultaneously valid keys of the same type associated with a name. 416 The type number for the KEY RR is 25. 418 3.1 KEY RDATA format 420 The RDATA for a KEY RR consists of flags, a protocol octet, the 421 algorithm number, and the public key itself. The format is as 422 follows: 424 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | flags | protocol | algorithm | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | / 430 / public key / 431 / / 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 434 The meaning of the KEY RR owner name, flags, and protocol octet are 435 described in Sections 3.2, 3.3 and 3.4 below respectively. The flags 436 and protocol must be examined before any following data as they 437 control the format and even whether there is any following data. The 438 algorithm and public key fields are described in Section 3.5. The 439 format of the public key is algorithm dependent. 441 3.2 Object Types, DNS Names, and Keys 443 The public key in a KEY RR belongs to the object named in the owner 444 name. 446 This DNS name may refer to up to three different things. For 447 example, dee.cybercash.com could be (1) a zone, (2) a host or other 448 end entity , and (3) the mapping into a DNS name of the user or 449 account dee@cybercash.com . Thus, there are flags in the KEY RR to 450 indicate with which of these roles the owner name and public key are 451 associated as described below. 453 Although the same name can be used for up to all three of these 454 contexts, such overloading of a name is discouraged. It is also 455 possible to use the same key for different things with the same name 456 or even different names, but this is strongly discouraged. In 457 particular, the use of a zone key as a non-zone key will usually 458 require that the private key be kept on line and thereby become much 459 more vulnerable. 461 It would be desirable for the growth of DNS to be managed so that 462 additional possible simultaneous uses for names are NOT added. New 463 uses should be distinguished by exclusive domains. For example, all 464 IP autonomous system numbers have been mapped into the in-as.arpa 465 domain [draft-ietf-dnssec-as-map-*.txt] and all telephone numbers in 466 the world have been mapped into the tpc.int domain [RFC 1530]. This 467 is much preferable to having the same name possibly be an autonomous 468 system number, telephone number, and/or host as well as a zone and a 469 user. 471 In addition to the name type bits, there are additional control bits, 472 the "no key" bit, the "experimental" bit, the "signatory" field, 473 etc., as described below. 475 3.3 The KEY RR Flag Field 477 In the "flags" field: 479 Bit 0 is the "no key" bit. If this bit is on, there is no key 480 information and the RR stops after the algorithm octet. By the use 481 of this bit, a signed KEY RR can authenticatably assert that, for 482 example, a zone is not secured. 484 Bit 1 is the "experimental" bit. It is ignored if the "no key" 485 bit is on and the following description assumes the "no key" bit to 486 be off. Keys may be associated with zones, entities, or users for 487 experimental, trial, or optional use, in which case this bit will be 488 one. If this bit is a zero, it means that the use or availability of 489 security based on the key is "mandatory". Thus, if this bit is off 490 for a zone key, the zone should be assumed secured by SIG RRs and any 491 responses indicating the zone is not secured should be considered 492 bogus. If this bit is a one for a host or end entity, it might 493 sometimes operate in a secure mode and at other times operate without 494 security. The experimental bit, like all other aspects of the KEY 495 RR, is only effective if the KEY RR is appropriately signed by a SIG 496 RR. The experimental bit must be zero for safe secure operation and 497 should only be a one for a minimal transition period. 499 Bits 2-4 are reserved and must be zero. 501 Bit 5 on indicates that this is a key associated with a "user" 502 or "account" at an end entity, usually a host. The coding of the 503 owner name is that used for the responsible individual mailbox in the 504 SOA record: The owner name is the user name as the name of a node 505 under the entity name. For example, "j.random_user" on 506 host.subdomain.domain could have a public key associated through a 507 KEY RR with name j\.random_user.host.subdomain.domain. It could be 508 used in an security protocol where authentication of a user was 509 desired. This key would be useful in IP or other security for a user 510 level service such a telnet, ftp, rlogin, etc. 512 Bit 6 on indicates that this is a key associated with the non- 513 zone "entity" whose name is the RR owner name. This will commonly be 514 a host but could, in some parts of the DNS tree, be some other type 515 of entity such as an Autonomous System [draft-ietf-dnssec-as-map- 516 *.txt]. This is the public key used in connection with the optional 517 DNS transaction authentication service that can be used if the owner 518 name is a DNS server host. It could also be used in an IP-security 519 protocol where authentication of a host was desired such as routing, 520 NTP, etc. 522 Bit 7 is the "zone" bit and indicates that this is a zone key 523 for the zone whose name is the KEY RR owner name. This is the 524 fundamental type of DNS data origin authentication public key. 526 Bits 8 is reserved to be the "IPSEC" bit and indicate that this 527 key is valid for use in a future IP level security protocol. This 528 key could be used in connection with secured communication on behalf 529 of an end entity or user whose name is the owner name of the KEY RR 530 if the entity or user bits are on. The presence of a KEY resource 531 with the IPSEC and entity bits on and experimental and no-key bits 532 off is a guarantee that the host speaks IPSEC. 534 Bits 9-11 are reserved and must be zero. 536 Bits 12-15 are the "signatory" field. If non-zero, it indicates 537 that the key can validly sign RRs of the same name. If the owner 538 name is a wildcard, then RRs with any name which is in the wildcard's 539 scope can be signed. Fifteen different non-zero values are possible 540 for this field and any differences in their meaning are reserved for 541 definition in connection with possible future DNS dynamic update or 542 other new DNS commands. This field is meaningless for zone keys 543 which always have authority to sign any RRs in the zone. The 544 signatory field, like all other aspects of the KEY RR, is only 545 effective if the KEY RR is appropriately signed by a SIG RR. 547 3.4 The Protocol Octet 549 It is anticipated that keys stored in DNS will be used in conjunction 550 with Internet protocols other than DNS (keys with zone bit or 551 signatory field non-zero) and IPSEC (keys with IPSEC bit set). The 552 protocol octet is provided to indicate that a key is valid for such 553 use and, for end entity keys or the host part of user keys, that the 554 secure version of that protocol is implemented on that entity or 555 host. 557 Values between 1 and 191 decimal inclusive are available for 558 assignment by IANA for such protocols. The 63 values between 192 and 559 254 inclusive will not be assigned to a specific protocol and are 560 available for experimental use under bilateral agreement. Value 0 561 indicates, for a particular key, that it is not valid for any 562 particular additional protocol beyond those indicated in the flag 563 field. And value 255 indicates that the key is valid for all assigned 564 protocols (those in the 1 to 191 range). 566 It is intended that new uses of DNS stored keys would initially be 567 implemented, and operational experience gained, using the 568 experimental range of the protocol octet. If demand for widespread 569 deployment for the indefinite future warrants, a value in the 570 assigned range would then be designated for the protocol. Finally, 571 (1) should the protocol become so widespread in conjunction with 572 other protocols which are indicated via the protocol octet and with 573 which it shares key values that duplicate RRs are a serious burden 574 and (2) should the protocol provide substantial facilities not 575 available in any protocol for which a flags field bit has been 576 allocated, then a flag field bit may be allocated to the protocol. 577 Then a key can be simultaneously indicated as valid for that protocol 578 and the entity or host can be simultaneously flagged as implementing 579 the secure version of that protocol, along with other protocols for 580 which flag field bits have been assigned. 582 Note that the IPSEC protocol being developed may provide facilities 583 adequate for all point to point IP communication meaning that 584 additional flag field bits would only be assigned, when appropriate 585 as indicated above, to protocols with a store-and-forward nature 586 (other than DNS) or otherwise not subsumed into a point-to-point 587 paradigm. 589 3.5 The KEY Algorithm Number and the MD5/RSA Algorithm 591 This octet is the key algorithm parallel to the same field for the 592 SIG resource. The MD5/RSA algorithm described in this draft is 593 number 1. Numbers 2 through 253 are available for assignment should 594 sufficient reason arise. However, the designation of a new algorithm 595 could have a major impact on interoperability and requires an IETF 596 standards action. Number 254 is reserved for private use and will 597 never be assigned a specific algorithm. For number 254, the public 598 key area shown in the packet diagram above will actually begin with 599 an Object Identifier (OID) indicating the private algorithm in use 600 and the remainder of the area is whatever is required by that 601 algorithm. Values 0 and 255 are reserved. 603 If the no key bit is zero and the algorithm field is 1, indicating 604 the MD5/RSA algorithm, the public key field is structured as follows: 606 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | pub exp length| public key exponent / 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | / 612 +- modulus / 613 | / 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ 616 To promote interoperability, the exponent and modulus are limited to 617 2552 bits in length. The public key exponent is a variable length 618 unsigned integer. Its length in octets is represented as one octet 619 if it is in the range of 1 to 255 and by a zero octet followed by a 620 two octet unsigned length if it is longer than 255 bytes. The public 621 key modulus field is a multiprecision unsigned integer. The length 622 of the modulus can be determined from the RDLENGTH and the preceding 623 RDATA fields including the exponent. Leading zero bytes are 624 prohibited in the exponent and modulus. 626 3.6 Interaction of Flags, Algorithm, and Protocol Bytes 628 Various combinations of the no-key bit, algorithm byte, protocol 629 byte, and any protocol indicating flags (such as the reserved IPSEC 630 flag) are possible. (Not that the zone flag bit being on or the 631 signatory field being non-zero is effectively a DNS protocol flag 632 on.) The meaning of these combinations is indicated below: 634 NK = no key flag 635 AL = alogrithm byte 636 PR = protocols indicated by protocol byte or protocol flags 638 x represents any valid non-zero value. 640 AL PR NK Meaning 641 0 0 0 Illegal, claims key but has bad algorithm field. 642 0 0 1 Authenticates total lack of security for owner. 644 0 x 0 Illegal, claims key but has bad algorithm field. 645 0 x 1 Specified protocols insecure, others may be secure. 646 x 0 0 Useless. Gives key but no protocols to use it. 647 x 0 1 Useless. Denies key but for no protocols. 648 x x 0 Authenticates key for protocols and certifies 649 that those protocols are implemented with 650 security. 651 x x 1 Algorithm not understood for protocol. 653 (remember, in reference to the above table, that a protocol 654 byte of 255 means all protocols with protocol bytes assigned) 656 3.7 KEY RRs in the Construction of Responses 658 An explicit request for KEY RRs does not cause any special additional 659 information processing except, of course, for the corresponding SIG 660 RR from a security aware server. 662 Security aware DNS servers will include KEY RRs as additional 663 information in responses where appropriate including the following: 665 (1) On the retrieval of NS RRs, the zone key KEY RR(s) for the zone 666 served by these name servers will be included as additional 667 information. If not all additional info will fit, the KEY RR(s) have 668 higher priority than type A (or AAAA) glue RRs. 670 (2) On retrieval of type A (or AAAA) RRs, the end entity KEY RR(s) 671 will be included. On inclusion of A (or AAAA) RRs as additional 672 information, their KEY RRs will also be included but with lower 673 priority than the relevant A (or AAAA) RRs. 675 3.8 File Representation of KEY RRs 677 KEY RRs may appear as lines in a zone data file. 679 The flag field, protocol, and algorithm number octets are then 680 represented as unsigned integers. Note that if the "no key" flag is 681 on in the flags, nothing appears after the algorithm octet. 683 The remaining public key portion is represented in base 64 (see 684 Appendix) and may be divided up into any number of white space 685 separated substrings, down to single base 64 digits, which are 686 concatenated to obtain the full signature. These substrings can span 687 lines using the standard parenthesis. 689 Note that the public key may have internal sub-fields but these do 690 not appear in the master file representation. For example, with 691 algorithm 1 there is a public exponent and then a modulus and with 692 algorithm 254, there will be an OID followed by algorithm dependent 693 information. 695 4. The SIG Resource Record 697 The SIG or "signature" resource record (RR) is the fundamental way 698 that data is authenticated in the secure Domain Name System (DNS). As 699 such it is the heart of the security provided. 701 The SIG RR unforgably authenticates other RRs of a particular type, 702 class, and name and binds them to a time interval and the signer's 703 domain name. This is done using cryptographic techniques and the 704 signer's private key. The signer is frequently the owner of the zone 705 from which the RR originated. 707 4.1 SIG RDATA Format 709 The RDATA portion of a SIG RR is as shown below. The integrity of 710 the RDATA information is protected by the signature field. 712 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 713 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 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | type covered | algorithm | labels | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | original TTL | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | signature expiration | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | time signed | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | key footprint | / 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name / 725 / / 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | / 728 +- signature / 729 / / 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 The value of the SIG RR type is 24. 734 The "type covered" is the type of the other RRs covered by this SIG. 736 The algorithm number is an octet specifying the digital signature 737 algorithm used parallel to the algorithm octet for the KEY RR. The 738 MD5/RSA algorithm described in this draft is number 1. Numbers 2 739 through 253 are available for assignment should sufficient reason 740 arise to allocate them. However, the designation of a new algorithm 741 could have a major impact on the interoperability of the global DNS 742 systems and requires an IETF standards action. Number 254 is 743 reserved for private use and will not be assigned a specific 744 algorithm. For number 254, the "signature" area shown above will 745 actually begin with an Object Identifier (OID) indicating the private 746 algorithm in use and the remainder of the signature area is whatever 747 is required by that algorithm. Values 0 and 255 are reserved. 749 The "labels" octet is an unsigned count of how many labels there are 750 in the original SIG RR owner name not counting the null label for 751 root and not counting any initial "*" for a wildcard. If a secured 752 retrieval is the result of wild card substitution, it is necessary 753 for the resolver to use the original form of the name in verifying 754 the digital signature. This field helps optimize the determination 755 of the original form reducing the effort in authenticating signed 756 data. 758 If, on retrieval, the RR appears to have a longer name than indicated 759 by "labels", the resolver can tell it is the result of wildcard 760 substitution. If the RR owner name appears to be shorter than the 761 labels count, the SIG RR should be considered corrupt and ignored. 762 The maximum number of labels possible in the current DNS is 127 but 763 the entire octet is reserved and would be required should DNS names 764 ever be expanded to 255 labels. The following table give some 765 examples. The value of "labels" is at the top, the retrieved owner 766 name on the left, and the table entry is the name to use in signature 767 verification except that "bad" means the RR is corrupt. 769 labels= | 0 | 1 | 2 | 3 | 4 | 770 --------+-----+------+--------+----------+----------+ 771 .| . | bad | bad | bad | bad | 772 d.| *. | d. | bad | bad | bad | 773 c.d.| *. | *.d. | c.d. | bad | bad | 774 b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad | 775 a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. | 777 The "original TTL" field is included in the RDATA portion to avoid 778 (1) authentication problems that caching servers would otherwise 779 cause by decrementing the real TTL field and (2) security problems 780 that unscrupulous servers could otherwise cause by manipulating the 781 real TTL field. This original TTL is protected by the signature 782 while the current TTL field is not. 784 NOTE: The "original TTL" must be restored into the covered RRs when 785 the signature is verified. This implies that the RRs for a 786 particular type need to all have the same TTL to start with. 788 The SIG is valid until the "signature expiration" time which is an 789 unsigned number of seconds since the start of 1 January 1970, GMT, 790 ignoring leap seconds. (See also Section 4.4.) 792 The "time signed" field is an unsigned number of seconds since the 793 start of 1 January 1970, GMT, ignoring leap seconds. 795 The "key footprint" is a 16 bit quantity that is used to help 796 efficiently select between multiple keys which may be applicable and 797 as a quick check that a public key about to be used for the 798 computationally expensive effort to check the signature is possibly 799 valid. Its exact meaning is algorithm dependent. For the MD5/RSA 800 algorithm, it is the next to the bottom two octets of the public key 801 modulus needed to decode the signature field. That is to say, the 802 most significant 16 of the lest significant 24 bits of this quantity 803 in network order. 805 The "signer's name" field is the domain name of the signer generating 806 the SIG RR. This is frequently the zone which contained the RR(s) 807 being authenticated. The signer's name may be compressed with 808 standard DNS name compression when being transmitted over the 809 network. 811 The structure of the "signature" field is described below. 813 4.1.1 Signature Data 815 The actual signature portion of the SIG RR binds the other RDATA 816 fields to all of the "type covered" RRs with that owner name. These 817 covered RRs are thereby authenticated. To accomplish this, a data 818 sequence is constructed as follows: 820 data = RDATA | RR(s)... 822 where | is concatenation, RDATA is all the RDATA fields in the SIG RR 823 itself before the signature, and RR(s) are all the RR(s) of the type 824 covered with the same owner name and class as the SIG RR in canonical 825 form and order. 827 For purposes of DNS security, the canonical form for an RR is the RR 828 with domain names (1) fully expanded (no name compression via 829 pointers) and (2) all domain name letters set to lower case. For 830 purposes of DNS security, the canonical order for RRs is to sort them 831 in ascending order by name, then by type, as left justified unsigned 832 octet sequences in network (transmission) order where a missing octet 833 sorts before a zero octet. (See also ordering discussion in Section 834 5.1.) Within any particular name and type they are similarly sorted 835 by RDATA as a left justified unsigned octet sequence. EXCEPT that the 836 type SIG RR(s) covering any particular type appear immediately after 837 the other RRs of that type. Thus if at name a.b there is one A RR 838 and one KEY RR, their order with SIGs for concatenating the "data" to 839 be signed would be as follows: 841 a.b. A .... 842 a.b. SIG A ... 843 a.b. KEY ... 844 a.b. SIG KEY ... 846 (SIGs on type ANY should not be included in a zone.) 848 How this data sequence is processed into the signature is algorithm 849 dependent. 851 4.1.2 MD5/RSA Algorithm Signature Calculation 853 For the MD5/RSA algorithm, the signature is as follows 855 hash = MD5 ( data ) 857 signature = ( 01 | FF* | 00 | hash ) ** e (mod n) 859 where MD5 is the message digest algorithm documented in RFC 1321, "|" 860 is concatenation, "e" is the secret key exponent of the signer, and 861 "n" is the public modulus of the signer's public key. 01, FF, and 00 862 are fixed octets of the corresponding hexadecimal value. The FF 863 octet is repeated the maximum number of times such that the value of 864 the quantity being exponentiated is one octet shorter than the value 865 of n. 867 The size of n, including most and least significant bits (which will 868 be 1) SHALL be not less than 512 bits and not more than 2552 bits. n 869 and e SHOULD be chosen such that the public exponent is small. 871 Leading zeros bytes are not permitted in the MD5/RSA algorithm 872 signature. 874 The above specifications are similar to Public Key Cryptographic 875 Standard #1 [PKCS1]. 877 A public exponent of 3 minimizes the effort needed to decode a 878 signature. Use of 3 as the public exponent may be weak for 879 confidentiality uses since, if the same data can be collected 880 encrypted under three different keys with an exponent of 3 then, 881 using the Chinese Remainder Theorem, the original plain text can be 882 easily recovered. This weakness is not significant for DNS because 883 we seek only authentication, not confidentiality. 885 4.1.3 Zone Transfer (AXFR) SIG 887 The above SIG mechanisms assure the authentication of all zone signed 888 RRs of a particular name, class and type. However, to efficiently 889 secure complete zone transfers, a SIG RR owned by the zone name must 890 be created with a type covered of AXFR that covers all zone signed 891 RRs other than the SIG AXFR itself. It will be calculated by hashing 892 together all other static zone RRs, including SIGs. The RRs are 893 ordered and concatenated for hashing as described in Section 4.1.1. 894 (See also ordering discussion in Section 5.1.) 896 The AXFR SIG must be calculated last of all zone key signed SIGs in 897 the zone. It really belongs to the zone as a whole, not to the zone 898 name. The AXFR SIG is only retrieved as part of a zone transfer. 899 After validation of the AXFR SIG, the zone may be considered valid 900 without verification of all the internal zone SIGs in the zone; 901 however, any SIGs signed by entity keys or the like must still be 902 validated. The AXFR SIG is transmitted first in a zone transfer so 903 the receiver can tell immediately that they may be able to avoid 904 verifying other zone signed SIGs. 906 Dynamic zone RRs which might be added by some future dynamic zone 907 update protocol and signed by an end entity or user key rather than a 908 zone key (see Section 3.2) are not included. They originate in the 909 network and will not, in general, be migrated to the recommended off 910 line zone signing procedure (see Section 8.2). Thus such dynamic RRs 911 are not directly signed by the zone, are not included in the AXFR 912 SIG, and are not generally protected against omission during zone 913 transfers. 915 4.1.4 Transaction SIGs 917 A response message from a security aware server may optionally 918 contain a special SIG as the last item in the additional information 919 section to authenticate the transaction. 921 This SIG has a "type covered" field of zero, which is not a valid RR 922 type. It is calculated by using a "data" (see Section 4.1.2) of the 923 entire preceding DNS reply message, including DNS header, 924 concatenated with the entire DNS query message that produced this 925 response, including the query's DNS header. That is 927 data = full response (less trailing message SIG) | full query 929 Verification of the transaction SIG (which is signed by the server 930 host key, not the zone key) by the requesting resolver shows that the 931 query and response were not tampered with in transit, that the 932 response corresponds to the intended query, and that the response 933 comes from the queried server. 935 4.2 SIG RRs in the Construction of Responses 937 Security aware servers MUST, for every authoritative RR the query 938 will return, attempt to send the available SIG RRs which authenticate 939 the requested RR. The following rules apply to the inclusion of SIG 940 RRs in responses: 942 1. when an RR is placed in a response, its SIG RR has a higher 943 priority for inclusion than other RRs that may need to be 944 included. If space does not permit its inclusion, the response 945 MUST be considered truncated. 947 2. when a SIG RR is present for an RR to be included in the 948 additional information section, the response MUST not be 949 considered truncated if space does not permit the inclusion of the 950 SIG RR. 952 Sending SIGs to authenticate non-authoritative data (glue records and 953 NS RRs for subzones) is unnecessary and must be avoided. Note that 954 KEYs for subzones are authoritative. 956 If a SIG covers any RR that would be in the answer section of the 957 response, its automatic inclusion MUST be the answer section. If it 958 covers an RR that would appear in the authority section, its 959 automatic inclusion MUST be in the authority section. If it covers 960 an RR that would appear in the additional information section it MUST 961 appear in the additional information section. 963 Optionally, DNS transactions may be authenticated by a SIG RR at the 964 end of the response in the additional information section (Section 965 4.1.4). Such SIG RRs are signed by the DNS server originating the 966 response. Although the signer field must be the name of the 967 originating server host, the owner name, class, TTL, and original 968 TTL, are meaningless. The class and TTL fields can be zero. To 969 conserve space, the owner name SHOULD be root (a single zero octet). 970 If transaction authentication is desired, that SIG RR must be 971 considered higher priority than any other RR in the answer. 973 4.3 Processing Responses and SIG RRs 975 The following rules apply to the processing of SIG RRs included in a 976 response: 978 1. a security aware resolver that receives a response from what it 979 believes to be a security aware server via a communication path 980 that it believes to be secure with the AD bit (see Section 6.1) 981 set, MAY choose to accept the RRs as received 982 without verifying the SIG RRs. 984 2. in other cases, a security aware resolver SHOULD verify the SIG 985 RRs for the RRs of interest. This may involve initiating 986 additional queries for SIG or KEY RRs, at least in the case of 987 getting a response from an insecure server. (As explained in 4.2 988 above, it will not be possible to secure CNAMEs being served up by 989 old resolvers.) 991 NOTE: Implementors might expect the SHOULD to be a MUST. However, 992 local policy or the calling application may not require the 993 security services. 995 3. If SIG RRs are received in response to a user query explicitly 996 specifying the SIG type, no special processing is required. 998 If the message does not pass reasonable checks or the SIG does not 999 check against the signed RRs, the SIG RR is invalid and should be 1000 ignored. If all of the SIG RR(s) purporting to authenticate a set of 1001 RRs are invalid, then the set of RR(s) is not authenticated. 1003 If the SIG RR is the last RR in a response in the additional 1004 information section and has a type covered of zero, it is a 1005 transaction signature of the response and the query that produced the 1006 response. It MAY be optionally checked and the message rejected if 1007 the checks fail. But even if the checks succeed, such a transaction 1008 authentication SIG does NOT authenticate any RRs in the message. 1009 Only a proper SIG RR signed by the zone can authenticate RRs. If a 1010 resolver does not implement transaction SIGs, it MUST at least ignore 1011 them without error. 1013 If all reasonable checks indicate that the SIG RR is valid then RRs 1014 verified by it should be considered authenticated. 1016 4.4 Signature Expiration, TTLs, and Validity 1018 Security aware servers must not consider SIG RRs to be authentic 1019 after their expiration time and not consider any RR to be 1020 authenticated after its signatures have expired. Within that 1021 constraint, servers should continue to follow DNS TTL aging. Thus 1022 authoritative servers should continue to follow the zone refresh and 1023 expire parameters and a non-authoritative server should count down 1024 the TTL and discard RRs when the TTL is zero. In addition, when RRs 1025 are transmitted in a query response, the TTL should be trimmed so 1026 that current time plus the TTL does not extend beyond the signature 1027 expiration time. Thus, in general, the TTL on an transmitted RR 1028 would be 1030 min(sigExpTim,max(zoneMinTTL,min(originalTTL,currentTTL))) 1032 4.5 File Representation of SIG RRs 1034 A SIG RR can be represented as a single logical line in a zone data 1035 file [RFC1033] but there are some special problems as described 1036 below. (It does not make sense to include a transaction 1037 authenticating SIG RR in a file as it is a transient authentication 1038 that covers data including an ephemeral transaction number so it must 1039 be calculated in real time by the DNS server.) 1041 There is no particular problem with the signer, covered type, and 1042 times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY 1043 is the year, the first MM is the month number (01-12), DD is the day 1044 of the month (01-31), HH is the hour in 24 hours notation (00-23), 1045 the second MM is the minute (00-59), and SS is the second (00-59). 1047 The original TTL and algorithm fields appear as unsigned integers. 1049 The "labels" field does not appear in the file representation as it 1050 can be calculated from the owner name. 1052 The key footprint appears as an unsigned decimal number. 1054 However, the signature itself can be very long. It is the last data 1055 field and is represented in base 64 (see Appendix) and may be divided 1056 up into any number of white space separated substrings, down to 1057 single base 64 digits, which are concatenated to obtain the full 1058 signature. These substrings can be split between lines using the 1059 standard parenthesis. 1061 5. Non-existent Names and Types 1063 The SIG RR mechanism described in Section 4 above provides strong 1064 authentication of RRs that exist in a zone. But is it not 1065 immediately clear how to authenticatably deny the existence of a name 1066 in a zone or a type for an existent name. 1068 The nonexistence of a name in a zone is indicated by the NXT ("next") 1069 RR for a name interval containing the nonexistent name. An NXT RR and 1070 its SIG are returned in the authority section, along with the error, 1071 if the server is security aware. The same is true for a non-existent 1072 type under an existing name. NXT RRs will also be returned if an 1073 explicit query is made for the NXT type. 1075 The existence of a complete set of NXT records in a zone means that 1076 any query for any name and type to a security aware server serving 1077 the zone should result in an reply containing at least one signed RR. 1079 NXT RRs do not appear in zone master files since they can be derived 1080 from the rest of the zone. 1082 5.1 The NXT Resource Record 1084 The NXT resource record is used to securely indicate that RRs with an 1085 owner name in a certain name interval do not exist in a zone and to 1086 indicate what zone signed type RRs are present for an existing name. 1088 The owner name of the NXT RR is an existing name in the zone. It's 1089 RDATA is a "next" name and a type bit map. The presence of the NXT RR 1090 means that generally no name between its owner name and the name in 1091 its RDATA area exists and that no other types exist under its owner 1092 name. This implies a canonical ordering of all domain names in a 1093 zone. 1095 The ordering is to sort labels as unsigned left justified octet 1096 strings where the absence of a octet sorts before a zero octet. 1097 Names are then sorted by sorting on the highest level label and then, 1098 within those names with the same highest level label by the next 1099 lower label, etc. Since we are talking about a zone, the zone name 1100 itself always exists and all other names are the zone name with some 1101 prefix of lower level labels. Thus the zone name itself always sorts 1102 first. 1104 There is a problem with the last NXT in a zone as it wants to have an 1105 owner name which is the last existing name in sort order, which is 1106 easy, but it is not obvious what name to put in its RDATA to indicate 1107 the entire remainder of the name space. This is handled by treating 1108 the name space as circular and putting the zone name in the RDATA of 1109 the last NXT. 1111 There are special considerations due to interaction with wildcards as 1112 explained below. 1114 The NXT RRs for a zone should be automatically calculated and added 1115 to the zone by the same recommended off-line process that signs the 1116 zone. The NXT RR's TTL should not exceed the zone minimum TTL. 1118 5.2 NXT RDATA Format 1120 The RDATA for an NXT RR consists simply of a domain name followed by 1121 a bit map. 1123 The type number for the NXT RR is 30. 1125 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1126 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 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | next domain name / 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | type bit map / 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 The size of the bit map can be inferred from the RDLENGTH and the 1134 length of the next domain name. 1136 5.3 Example 1138 Assume zone foo.bar has entries for 1140 big.foo.bar, 1141 medium.foo.bar. 1142 small.foo.bar. 1143 tiny.foo.bar. 1145 Then a query to a security aware server for huge.foo.bar would 1146 produce an error reply with the authority section data including the 1147 following: 1149 big.foo.bar. NXT medium.foo.bar. 130 1150 big.foo.bar. SIG NXT ... 1152 Note that this response implies that big.foo.bar is an existing name 1153 in the zone and thus has other RR types associated with it than NXT. 1154 However, only the NXT (and its SIG) RR appear in the response to this 1155 query for huge.foo.bar, which is a non-existent name. 1157 5.4 Interaction of NXT RRs and Wildcard RRs 1159 Since, in some sense, a wildcard RR causes all possible names in an 1160 interval to exist, there should not be an NXT RR that would cover any 1161 part of this interval. Thus if *.X.ZONE exists you would expect an 1162 NXT RR that ends at X.ZONE and one that starts with the last name 1163 covered by *.X.ZONE. However, this "last name covered" is something 1164 very ugly and long like \255\255\255....X.zone. So the NXT for the 1165 interval following is simply given the owner name *.X.ZONE. This "*" 1166 type name is not expanded when the NXT is returned as authority 1167 information in connection with a query for a non-existent name. 1169 If there could be any wildcard RRs in a zone and thus wildcard NXTs, 1170 care must be taken in interpreting the results of explicit NXT 1171 retrievals as the owner name may be a wildcard expansion. 1173 The existence of one or more wildcard RRs covering a name interval 1174 makes it possible for a malicious server to hide any more specificly 1175 named RRs in the internal. The server can just falsely return the 1176 wildcard match NXT instead of the more specificly named RRs. If 1177 there is a zone wide wildcard, there will be an NXT RR whose owner 1178 name is the wild card and whose RDATA is the zone name. In this case 1179 a server could conceal the existence of any more specific RRs in the 1180 zone. (It would be possible to design a more strict NXT feature 1181 which would eliminate this possibility. But it would be more complex 1182 and might be so constraining as to make any future dynamic update 1183 feature that could create new names very difficult (see Section 1184 3.2).) 1186 What name should be put into the RDATA of an RR with a name that is 1187 within a wild card scope? Since the "next" existing name will be one 1188 that matches the wild card, the wild card name should be used. 1190 5.5 Blocking NXT Pseudo-Zone Transfers 1192 In a secure zone, a resolver can query for the initial NXT associated 1193 with the zone name. Using the next domain name RDATA field from that 1194 RR, it can query for the next NXT RR. By repeating this, it can walk 1195 through all the NXTs in the zone. If there are no wildcards, it can 1196 use this technique to find all names in a zone. If it does type ANY 1197 queries, it can incrementally get all information in the zone and 1198 perhaps defeat attempts to administratively block zone transfers. 1200 If there are any wildcards, this NXT walking technique will not find 1201 any more specific RR names in the part of the name space the wildcard 1202 covers. By doing explicit retrievals for wildcard names, a resolver 1203 could determine what intervals are covered by wildcards but still 1204 could not, with these techniques, find any names inside such 1205 intervals except by trying every name. 1207 If it is desired to block NXT walking, the recommended method is to 1208 add a zone wide wildcard of the KEY type with the no key bit on and 1209 with no type (zone, entity, or user) bit on. This will cause there 1210 to be one zone covering NXT RR and leak no information about what 1211 real names exist in the zone. This protection from pseudo-zone 1212 transfers is bought at the expense of eliminating the data origin 1213 authentication of the non-existence of names that NXT RRs can 1214 provide. If an entire zone is covered by a wildcard, a malicious 1215 server can return an RR produced by matching the resulting wildcard 1216 NXT and can thus hide all the real data and delegations with more 1217 specific names in the zone. 1219 5.6 Special Considerations at Delegation Points 1221 A name other than root which is the head of a zone also appears as 1222 the leaf in a superzone. If both are secure, there will always be 1223 two different NXT RRs with the same name. They can be distinguished 1224 by their signers and next domain name fields. Security aware servers 1225 should return the correct NXT automatically when required to 1226 authenticate the non-existence of a name and both NXTs, if available, 1227 on explicit query for type NXT. 1229 Insecure servers will never automatically return an NXT and may only 1230 return the NXT from the subzone on explicit queries. 1232 6. The AD and CD Bits and How to Resolve Securely 1234 Retrieving or resolving authentic data from the Domain Name System 1235 (DNS) involves starting with one or more trusted public keys. With 1236 trusted keys, a browser willing to perform cryptography can progress 1237 securely through the secure DNS zone structure to the zone of 1238 interest as described in Section 6.3. Such trusted public keys would 1239 normally be configured in a manner similar to that described in 1240 Section 6.2. However, as a practical matter, a security aware 1241 resolver would still gain some confidence in the results it returns 1242 even if it was not configured with any keys but trusted what it got 1243 from a local well known server as a starting point. 1245 Data stored at a server needs security labels of Authenticated, 1246 Pending, or Insecure. There is also a fourth transient state of Bad 1247 which indicates that SIG checks have explicitly failed on the data. 1248 Such data is not retained at a security aware server. Authenticated 1249 means that the data has a valid SIG under a KEY traceable via a chain 1250 of zero or more SIG and KEY RRs to a KEY configured at the resolver 1251 via its boot file. Pending data has no authenticated SIGs and at 1252 least one additional SIG the browser is still trying to authenticate. 1253 Insecure data is data which it is known can never be either 1254 authenticated or found bad because it is in a zone with no key or an 1255 experimental key. Behavior in terms of control of and flagging based 1256 on such data labels is described in Section 6.1. 1258 The proper validation of signatures requires a reasonably secure 1259 shared opinion of the absolute time between resolvers and servers as 1260 described in Section 6.4. 1262 In getting to the data of interest to respond to a query, a secure 1263 resolver may encounter genuine non-secure zones. It may proceed 1264 through such zones but should report this as described in Section 1265 6.5. 1267 6.1 The AD and CD Header Bits 1269 Two unused bits are allocated out of the DNS query/response format 1270 header. The AD (authentic data) bit indicates in a response that the 1271 data included has been verified by the server providing it. The CD 1272 (checking disabled) bit indicates in a query that non-verified data 1273 is acceptable to the resolver sending the query. 1275 These bits are allocated from the must-be-zero Z field as follows: 1277 1 1 1 1 1 1 1278 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1279 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1280 | ID | 1281 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1282 |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | 1283 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1284 | QDCOUNT | 1285 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1286 | ANCOUNT | 1287 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1288 | NSCOUNT | 1289 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1290 | ARCOUNT | 1291 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1293 These bits are zero in old servers and resolvers. Thus the responses 1294 of old servers are not flagged as authenticated to security aware 1295 resolvers and queries from non-security aware resolvers do not assert 1296 the checking disabled bit and thus will be answered by security aware 1297 servers only with authenticated data. Of course security aware 1298 resolvers can not trust the AD bit unless they trust the server they 1299 are talking to and have a secure path to it. 1301 Any security aware resolver willing to do cryptography should assert 1302 the CD bit on all queries to reduce DNS latency time by allowing 1303 security aware servers to answer before they have resolved the 1304 validity of data. 1306 Security aware servers never return bad data. For non-security aware 1307 resolvers or security aware resolvers requesting service by having 1308 the CD bit clear, security aware servers return only authenticated or 1309 insecure data with the AD bit set in the response. Security aware 1310 resolvers will know that if data is insecure versus authentic by the 1311 absence of SIG RRs. Security aware servers may return pending data 1312 to security aware resolvers requesting the service by clearing the AD 1313 bit in the response. The AD bit may only be set on a response if the 1314 RRs in the response are either authenticated or insecure. 1316 6.2 Boot File Format 1318 The format for a boot file directive to configure a starting zone key 1319 is as follows: 1321 pubkey name flags protocol algorithm key-data 1323 for a public key. "name" is the owner name (if the line is 1324 translated into a KEY RR). Flags indicates the type of key and is 1325 the same as the flag octet in the KEY RR. In particular, if the "no 1326 key" bit is on in flags, then all fields after algorithm may be 1327 omitted. Algorithm is the algorithm in use where one is the MD5/RSA 1328 algorithm and 254 indicates a private algorithm. The material after 1329 the algorithm is algorithm dependent and, for private algorithms, 1330 starts with the algorithm's identifying OID. It is encoded in base 1331 64 (see Appendix). 1333 A file of keys for cross certification or other purposes can be 1334 configured though the keyfile directive as follows: 1336 keyfile filename 1338 The file looks like a master file except that it can only contain KEY 1339 and SIG RRs with the SIGs signed under a key configured with the 1340 pubkey directive. 1342 While it might seem logical for everyone to start with the key for 1343 the root zone, this has problems. The logistics of updating every 1344 DNS resolver in the world when the root key changes would be 1345 excessive. It may be some time before there even is a root key. 1346 Furthermore, many organizations will explicitly wish their "interior" 1347 DNS implementations to completely trust only their own zone. These 1348 interior resolvers can then go through the organization's zone server 1349 to access data outsize the organization's domain. 1351 6.3 Chaining Through Zones 1353 Starting with one or more trusted keys for a zone, it should be 1354 possible to retrieve signed keys for its subzones which have a key 1355 and, if the zone is not root, for some superzone. Every authoritative 1356 secure zone server should also include the KEY RR for a super-zone 1357 signed by the secure zone via a keyfile directive. This makes it 1358 possible to climb the tree of zones if one starts below root. A 1359 secure sub-zone is indicated by a KEY RR appearing with the NS RRs 1360 for the sub-zone. These make it possible to descend within the tree 1361 of zones. 1363 A resolver should keep track of the number of successive secure zones 1364 traversed from a starting point to any secure zone it can reach. In 1365 general, the lower such a distance number is, the greater the 1366 confidence in the data. Data configured via a boot file directive 1367 should be given a distance number of zero. Should a query encounter 1368 different data for the same query with different distance values, 1369 that with a larger value should be ignored. 1371 A security conscious resolver should completely refuse to step from a 1372 secure zone into a non-secure zone unless the non-secure zone is 1373 certified to be non-secure or only experimentally secure by the 1374 presence of an authenticated KEY RR for the non-secure zone with a no 1375 key flag or the presence of a KEY RR with the experimental bit set. 1376 Otherwise the resolver is probably getting completely bogus or 1377 spoofed data. 1379 If legitimate non-secure zones are encountered in traversing the DNS 1380 tree, then no zone can be trusted as secure that can be reached only 1381 via information from such non-secure zones. Since the non-secure zone 1382 data could have been spoofed, the "secure" zone reach via it could be 1383 counterfeit. The "distance" to data in such zones or zones reached 1384 via such zones could be set to 512 or more as this exceeds the 1385 largest possible distance through secure zones in the DNS. 1386 Nevertheless, continuing to apply secure checks within "secure" zones 1387 reached via non-secure zones will, as a practical matter, provide 1388 some increase in security. 1390 6.4 Secure Time 1392 Coordinated interpretation of the time fields in SIG RRs requires 1393 that reasonably consistent time be available to the hosts 1394 implementing the DNS security extensions. 1396 A variety of time synchronization protocols exist including the 1397 Network Time Protocol (NTP, RFC1305). If such protocols are used, 1398 they should be used securely so that time can not be spoofed. 1399 Otherwise, for example, a host could get its clock turned back and 1400 might then believe old SIG and KEY RRs which were valid but no longer 1401 are. 1403 7. Operational Considerations 1405 This section discusses a variety of considerations in secure 1406 operation of the Domain Name System (DNS) using these proposed 1407 protocol extensions. 1409 7.1 Key Size Considerations 1411 There are a number of factors that effect public key size choice for 1412 use in the DNS security extension. Unfortunately, these factors 1413 usually do not all point in the same direction. Choice of zone key 1414 size should generally be made by the zone administrator depending on 1415 their local conditions. 1417 For most schemes, larger keys are more secure but slower. Given a 1418 small public exponent, verification (the most common operation) for 1419 the MD5/RSA algorithm will vary roughly with the square of the 1420 modulus length, signing will vary with the cube of the modulus 1421 length, and key generation (the least common operation) will vary 1422 with the fourth power of the modulus length. The current best 1423 algorithms for factoring a modulus and breaking RSA security vary 1424 roughly with the square of the modulus itself. Thus going from a 640 1425 bit modulus to a 1280 bit modulus only increases the verification 1426 time by a factor of 4 but increases the work factor of breaking the 1427 key by over 2^3000. [RSA FAQ] An upper bound of 2552 bit has been 1428 established for the MD4/RSA DNS security algorithm for 1429 interoperability purposes. 1431 However, larger keys increase size of the KEY and SIG RRs. This 1432 increases the chance of DNS UDP packet overflow and the possible 1433 necessity for using higher overhead TCP in responses. 1435 The recommended minimum RSA algorithm modulus size, 640 bits, is 1436 believed by the authors to be secure at this time and for some years 1437 but high level zones in the DNS tree may wish to set a higher 1438 minimum, perhaps 1000 bits, for security reasons. (Since the United 1439 States National Security Agency generally permits export of 1440 encryption systems using an RSA modulus of up to 512 bits, use of 1441 that small a modulus, i.e. n, must be considered weak.) 1443 For a key used only to secure data and not to secure other keys, 640 1444 bits should be entirely adequate. 1446 7.2 Key Storage 1448 It is strongly recommended that zone private keys and the zone file 1449 master copy be kept and used in off-line non-network connected 1450 physically secure machines only. Periodically an application can be 1451 run to re-sign the RRs in a zone by adding NXT and SIG RRs. Then the 1452 augmented file can be transferred, perhaps by sneaker-net, to the 1453 networked zone primary server machine. 1455 The idea is to have a one way information flow to the network to 1456 avoid the possibility of tampering from the network. Keeping the 1457 zone master file on-line on the network and simply cycling it through 1458 an off-line signer does not do this. The on-line version could still 1459 be tampered with if the host it resides on is compromised. For 1460 maximum security, the master copy of the zone file should be off net 1461 and should not be updated based on an unsecured network mediated 1462 communication. 1464 Note, however, that secure resolvers need to be configured with some 1465 trusted on-line public key information (or a secure path to such a 1466 resolver). 1468 Non-zone private keys, such as host or user keys, may have to be kept 1469 on line to be used for real-time purposes such a IPSEC session set-up 1470 or secure mail. 1472 7.3 Key Generation 1474 Careful key generation is a sometimes over looked but absolutely 1475 essential element in any cryptographically secure system. The 1476 strongest algorithms used with the longest keys are still of no use 1477 if an adversary can guess enough to lower the size of the likely key 1478 space so that it can be exhaustively searched. Suggestions will be 1479 found in RFC 1750. 1481 It is strongly recommended that key generation also occur off-line, 1482 perhaps on the machine used to sign zones (see Section 7.2). 1484 7.4 Key Lifetimes 1486 No key should be used forever. The longer a key is in use, the 1487 greater the probability that it will have been compromised through 1488 carelessness, accident, espionage, or cryptanalysis. Furthermore, if 1489 key rollover is a rare event, there is an increased risk that, when 1490 the time does come up change the key, no one at the site will 1491 remember how to do it or other problems will have developed in the 1492 procedures. 1494 While key lifetime is a matter of local policy, these considerations 1495 suggest that no zone key should have a lifetime significantly over 1496 four years. A reasonable maximum lifetime for zone keys that are 1497 kept off-line and carefully guarded is 13 months with the intent that 1498 they be replaced every year. A reasonable maximum lifetime for end 1499 entity keys that are used for IP-security or the like and are kept on 1500 line is 36 days with the intent that they be replaced monthly or more 1501 often. In some cases, an entity key lifetime of somewhat over a day 1502 may be reasonable. 1504 7.5 Signature Lifetime 1506 Signature expiration times must be set far enough in the future that 1507 it is quite certain that new signatures can be generated before the 1508 old ones expire. However, setting expiration too far into the future 1509 could, if bad data or signatures were ever generated, mean a long 1510 time to flush such badness. 1512 It is recommended that signature lifetime be a small multiple of the 1513 TTL but not less than a reasonable re-signing interval. 1515 7.6 Root 1517 It should be noted that in DNS the root is a zone unto itself. Thus 1518 the root zone key should only be seen signing itself or signing RRs 1519 with names one level below root, such as .aq, .edu, or .arpa. 1520 Implementations MAY reject as bogus any purported root signature of 1521 records with a name more than one level below root. 1523 8. Conformance 1525 Several levels of server and resolver conformance are defined. 1527 8.1 Server Conformance 1529 Two levels of server conformance are defined as follows: 1531 Minimal server compliance is the ability to store and retrieve 1532 (including zone transfer) SIG, KEY, and NXT RRs. Any secondary, 1533 caching, or other server for a secure zone must be at least minimally 1534 compliant and even then some things, such as secure CNAMEs, will not 1535 work. 1537 Full server compliance adds the following to basic compliance: 1538 (1) ability to read SIG, KEY, and NXT RRs in zone files and (2) 1539 ability, given a zone file and private key, to add appropriate SIG 1540 and NXT RRs, possibly via a separate application, (3) proper 1541 automatic inclusion of SIG, KEY, and NXT RRs in responses, (4) 1542 suppression of CNAME following on retrieval of the security type RRs, 1543 (5) recognize the CD query header bit and set the AD query header 1544 bit, as appropriate, and (6) proper handling of the two NXT RRs at 1545 delegation points. Primary servers for secure zones MUST be fully 1546 compliant and for completely successful secure operation, all 1547 secondary, caching, and other servers handling the zone should be 1548 fully compliant as well. 1550 8.2 Resolver Conformance 1552 Two levels of resolver compliance are defined: 1554 A basic compliance resolver can handle SIG, KEY, and NXT RRs 1555 when they are explicitly requested. 1557 A fully compliant resolver (1) understands KEY, SIG, and NXT 1558 RRs, (2) maintains appropriate information in its local caches and 1559 database to indicate which RRs have been authenticated and to what 1560 extent they have been authenticated, (3) performs additional queries 1561 as necessary to attempt to obtain KEY, SIG, or NXT RRs from non- 1562 security aware servers, (4) normally sets the CD query header bit on 1563 its queries. 1565 9. Security Considerations 1567 This document concerns technical details of extensions to the Domain 1568 Name System (DNS) protocol to provide data integrity and data origin 1569 authentication, public key distribution, and optional transaction 1570 security. 1572 If should be noted that, at most, these extensions guarantee the 1573 validity of resource records, including KEY resource records, 1574 retrieved from the DNS. They do not magically solve other security 1575 problems. For example, using secure DNS you can have high confidence 1576 in the IP address you retrieve for a host; however, this does not 1577 stop someone for substituting an unauthorized host at that address or 1578 capturing packets sent to that address and responding with packets 1579 apparently from that address. Any reasonably complete security 1580 system will require the protection of many other facets of the 1581 Internet. 1583 References 1585 [PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 1586 3 June 1991, Version 1.4. 1588 [RFC1032] - Domain Administrators Guide, M. Stahl, November 1987 1590 [RFC1033] - Domain Administrators Operations Guide, M. Lottor, 1591 November 1987 1593 [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, 1594 November 1987 1596 [RFC1035] - Domain Names - Implementation and Specifications 1598 [RFC1305] - Network Time Protocol (v3), D. Mills, April 9 1992. 1600 [RFC1321] - The MD5 Message-Digest Algorithm, R. Rivest, April 16 1601 1992. 1603 [RFC1750] - Randomness Requirements for Security, D. Eastlake, S. 1604 Crocker, J. Schiller, December 1994. 1606 [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. 1608 Authors Addresses 1610 Donald E. Eastlake, 3rd 1611 CyberCash, Inc. 1612 318 Acton Street 1613 Carlisle, MA 01741 USA 1615 Telephone: +1 508 287 4877 1616 EMail: dee@cybercash.com 1618 Charles W. Kaufman 1619 Iris Associates 1620 1 Technology Park Drive 1621 Westford, MA 01886 USA 1623 Telephone: +1 508-392-5276 1624 EMail: charlie_kaufman@iris.com 1626 Expiration and File Name 1628 This draft expires 24 December 1995. 1630 Its file name is draft-ietf-dnssec-secext-04.txt. 1632 Appendix: Base 64 Encoding 1634 The following encoding technique is taken from RFC 1521 by Borenstein 1635 and Freed. It is reproduced here in an edited form for convenience. 1637 A 65-character subset of US-ASCII is used, enabling 6 bits to be 1638 represented per printable character. (The extra 65th character, "=", 1639 is used to signify a special processing function.) 1641 The encoding process represents 24-bit groups of input bits as output 1642 strings of 4 encoded characters. Proceeding from left to right, a 1643 24-bit input group is formed by concatenating 3 8-bit input groups. 1644 These 24 bits are then treated as 4 concatenated 6-bit groups, each 1645 of which is translated into a single digit in the base64 alphabet. 1647 Each 6-bit group is used as an index into an array of 64 printable 1648 characters. The character referenced by the index is placed in the 1649 output string. 1651 Table 1: The Base64 Alphabet 1653 Value Encoding Value Encoding Value Encoding Value Encoding 1654 0 A 17 R 34 i 51 z 1655 1 B 18 S 35 j 52 0 1656 2 C 19 T 36 k 53 1 1657 3 D 20 U 37 l 54 2 1658 4 E 21 V 38 m 55 3 1659 5 F 22 W 39 n 56 4 1660 6 G 23 X 40 o 57 5 1661 7 H 24 Y 41 p 58 6 1662 8 I 25 Z 42 q 59 7 1663 9 J 26 a 43 r 60 8 1664 10 K 27 b 44 s 61 9 1665 11 L 28 c 45 t 62 + 1666 12 M 29 d 46 u 63 / 1667 13 N 30 e 47 v 1668 14 O 31 f 48 w (pad) = 1669 15 P 32 g 49 x 1670 16 Q 33 h 50 y 1672 Special processing is performed if fewer than 24 bits are available 1673 at the end of the data being encoded. A full encoding quantum is 1674 always completed at the end of a quantity. When fewer than 24 input 1675 bits are available in an input group, zero bits are added (on the 1676 right) to form an integral number of 6-bit groups. Padding at the 1677 end of the data is performed using the '=' character. Since all 1678 base64 input is an integral number of octets, only the following 1679 cases can arise: (1) the final quantum of encoding input is an 1680 integral multiple of 24 bits; here, the final unit of encoded output 1681 will be an integral multiple of 4 characters with no "=" padding, (2) 1682 the final quantum of encoding input is exactly 8 bits; here, the 1683 final unit of encoded output will be two characters followed by two 1684 "=" padding characters, or (3) the final quantum of encoding input is 1685 exactly 16 bits; here, the final unit of encoded output will be three 1686 characters followed by one "=" padding character.