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