idnits 2.17.1 draft-ietf-dnsext-signing-auth-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == 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 Introduction section. ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 'SHOULD not' in this paragraph: If the SIG record is a SIG(0) protecting a message, the name type of the associated KEY SHOULD be 00 (user) or 10 (host/entity). Transactions are initiated by a host or user, not a zone, so zone keys SHOULD not generate SIG(0) records. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2000) is 8587 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 section? 'RFC2119' on line 256 looks like a reference -- Missing reference section? 'RFC2535' on line 263 looks like a reference -- Missing reference section? 'RFC1034' on line 250 looks like a reference -- Missing reference section? 'RFC1035' on line 253 looks like a reference -- Missing reference section? 'RFC2931' on line 266 looks like a reference -- Missing reference section? 'SSU' on line 269 looks like a reference -- Missing reference section? 'RFC2136' on line 259 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSEXT Working Group Brian Wellington (Nominum) 2 INTERNET-DRAFT October 2000 4 6 Updates: RFC 2535 8 Domain Name System Security (DNSSEC) Signing Authority 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Comments should be sent to the authors or the DNSEXT WG mailing list 32 namedroppers@ops.ietf.org. 34 This draft expires on April 2, 2000. 36 Copyright Notice 38 Copyright (C) The Internet Society (2000). All rights reserved. 40 Abstract 42 This document proposes a revised model of Domain Name System Security 43 (DNSSEC) Signing Authority. The revised model is designed to clarify 44 earlier documents and add additional restrictions to simplify the 45 secure resolution process. Specifically, this affects the 46 authorization of keys to sign sets of records. 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [RFC2119]. 52 1 - Introduction 54 This document defines additional restrictions on DNSSEC signatures (SIG) 55 records relating to their authority to sign associated data. The intent 56 is to establish a standard policy followed by a secure resolver; this 57 policy can be augmented by local rules. This builds upon [RFC2535], 58 updating section 2.3.6 of that document. 60 The most significant change is that in a secure zone, zone data is 61 required to be signed by the zone key. 63 Familiarity with the DNS system [RFC1034, RFC1035] and the DNS security 64 extensions [RFC2535] is assumed. 66 2 - The SIG Record 68 A SIG record is normally associated with an RRset, and ``covers'' (that 69 is, demonstrates the authenticity and integrity of) the RRset. This is 70 referred to as a ``data SIG''. Note that there can be multiple SIG 71 records covering an RRset, and the same validation process should be 72 repeated for each of them. Some data SIGs are considered ``material'', 73 that is, relevant to a DNSSEC capable resolver, and some are 74 ``immaterial'' or ``extra-DNSSEC'', as they are not relevant to DNSSEC 75 validation. Immaterial SIGs may have application defined roles. SIG 76 records may exist which are not bound to any RRset; these are also 77 considered immaterial. The validation process determines which SIGs are 78 material; once a SIG is shown to be immaterial, no other validation is 79 necessary. 81 SIGs may also be used for transaction security. In this case, a SIG 82 record with a type covered field of 0 is attached to a message, and is 83 used to protect message integrity. This is referred to as a SIG(0) 84 [RFC2535, RFC2931]. 86 The following sections define requirements for all of the fields of a 87 SIG record. These requirements MUST be met in order for a DNSSEC 88 capable resolver to process this signature. If any of these 89 requirements are not met, the SIG cannot be further processed. 90 Additionally, once a KEY has been identified as having generated this 91 SIG, there are requirements that it MUST meet. 93 2.1 - Type Covered 95 For a data SIG, the type covered MUST be the same as the type of data in 96 the associated RRset. For a SIG(0), the type covered MUST be 0. 98 2.2 - Algorithm Number 100 The algorithm specified in a SIG MUST be recognized by the client, and 101 it MUST be an algorithm that has a defined SIG rdata format. 103 2.3 - Labels 105 The labels count MUST be less than or equal to the number of labels in 106 the SIG owner name, as specified in [RFC2535, section 4.1.3]. 108 2.4 - Original TTL 110 The original TTL MUST be greater than or equal to the TTL of the SIG 111 record itself, since the TTL cannot be increased by intermediate 112 servers. This field can be ignored for SIG(0) records. 114 2.5 - Signature Expiration and Inception 116 The current time at the time of validation MUST lie within the validity 117 period bounded by the inception and expiration times. 119 2.6 - Key Tag 121 There are no restrictions on the Key Tag field, although it is possible 122 that future algorithms will impose contraints. 124 2.7 - Signer's Name 126 The signer's name field of a data SIG MUST contain the name of the zone 127 to which the data and signature belong. The combination of signer's 128 name, key tag, and algorithm MUST identify a zone key if the SIG is to 129 be considered material. The only exception that the signer's name field 130 in a SIG KEY at a zone apex SHOULD contain the parent zone's name, 131 unless the KEY set is self-signed. This document defines a standard 132 policy for DNSSEC validation; local policy may override the standard 133 policy. 135 There are no restrictions on the signer field of a SIG(0) record. The 136 combination of signer's name, key tag, and algorithm MUST identify a key 137 if this SIG(0) is to be processed. 139 2.8 - Signature 141 There are no restrictions on the signature field. The signature will be 142 verified at some point, but does not need to be examined prior to 143 verification unless a future algorithm imposes constraints. 145 3 - The Signing KEY Record 147 Once a signature has been examined and its fields validated (but before 148 the signature has been verified), the resolver attempts to locate a KEY 149 that matches the signer name, key tag, and algorithm fields in the SIG. 150 If one is not found, the SIG cannot be verified and is considered 151 immaterial. If KEYs are found, several fields of the KEY record MUST 152 have specific values if the SIG is to be considered material and 153 authorized. If there are multiple KEYs, the following checks are 154 performed on all of them, as there is no way to determine which one 155 generated the signature until the verification is performed. 157 3.1 - Type Flags 159 The signing KEY record MUST have a flags value of 00 or 01 160 (authentication allowed, confidentiality optional) [RFC2535, 3.1.2]. A 161 DNSSEC resolver MUST only trust signatures generated by keys that are 162 permitted to authenticate data. 164 3.2 - Name Flags 166 The interpretation of this field is considerably different for data SIGs 167 and SIG(0) records. 169 3.2.1 - Data SIG 171 If the SIG record covers an RRset, the name type of the associated KEY 172 MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535, section 173 2.3.6. The DNSSEC validation process performed by a resolver MUST 174 ignore all keys that are not zone keys unless local policy dictates 175 otherwise. 177 The primary reason that RFC 2535 allows host and user keys to generate 178 material DNSSEC signatures is to allow dynamic update without online 179 zone keys; that is, avoid storing private keys in an online server. The 180 desire to avoid online signing keys cannot be achieved, though, because 181 they are necessary to sign NXT and SOA sets [SSU]. These online zone 182 keys can sign any incoming data. Removing the goal of having no online 183 keys removes the reason to allow host and user keys to generate material 184 signatures. 186 Limiting material signatures to zone keys simplifies the validation 187 process. The length of the verification chain is bounded by the name's 188 label depth. The authority of a key is clearly defined; a resolver does 189 not need to make a potentially complicated decision to determine whether 190 a key can sign data. amount of work to determine if all such keys have 191 the proper authority. 193 Finally, there is no additional flexibility granted by allowing 194 host/user key generated material signatures. As long as users and hosts 195 have the ability to authenticate update requests to the primary zone 196 server, signatures by zone keys are sufficient to protect the integrity 197 of the data to the world at large. 199 3.2.2 - SIG(0) 201 If the SIG record is a SIG(0) protecting a message, the name type of the 202 associated KEY SHOULD be 00 (user) or 10 (host/entity). Transactions 203 are initiated by a host or user, not a zone, so zone keys SHOULD not 204 generate SIG(0) records. 206 A client is either explicitly executed by a user or on behalf of a host, 207 therefore the name type of a SIG(0) generated by a client SHOULD be 208 either user or host. A nameserver is associated with a host, and its 209 use of SIG(0) is not associated with a particular zone, so the name type 210 of a SIG(0) generated by a nameserver SHOULD be host. 212 3.3 - Signatory Flags 214 This document does not assign any values to the signatory field, nor 215 require any values to be present. 217 3.4 - Protocol 219 The signing KEY record MUST have a protocol value of 3 (DNSSEC) or 255 220 (ALL). If a key is not specified for use with DNSSEC, a DNSSEC resolver 221 MUST NOT trust any signature that it generates. 223 3.5 - Algorithm Number 225 The algorithm field MUST be identical to that of the generated SIG 226 record, and MUST meet all requirements for an algorithm value in a SIG 227 record. 229 4 - Security considerations 231 This document defines a standard baseline for a DNSSEC capable resolver. 232 This is necessary for a thorough security analysis of DNSSEC, if one is 233 to be done. 235 Specifically, this document places additional restrictions on SIG 236 records that a resolver must validate before the signature can be 237 considered worthy of DNSSEC trust. This simplifies the protocol, making 238 it more robust and able to withstand scrutiny by the security community. 240 5 - Acknowledgements 242 The author would like to thank the following people for review and 243 informative comments (in alphabetical order): 245 Olafur Gudmundsson 246 Ed Lewis 248 6 - References 250 [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' 251 RFC 1034, ISI, November 1987. 253 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 254 Specification,'' RFC 1035, ISI, November 1987. 256 [RFC2119] S. Bradner, ``Key words for use in RFCs to Indicate 257 Requirement Levels,'' BCP 14, RFC 2119, Harvard, March 1997. 259 [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic 260 Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore 261 & Cisco & DEC, April 1997. 263 [RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC 264 2535, IBM, March 1999. 266 [RFC2931] D. Eastlake, ``DNS Request and Transaction Signatures ( 267 SIG(0)s ),'' RFC 2931, Motorola, September 2000. 269 [SSU] B. Wellington, ``Simple Secure Domain Name System (DNS) 270 Dynamic Update,'' draft-ietf-dnsext-simple-secure- 271 update-02.txt, Nominum, October 2000. 273 7 - Author's Address 275 Brian Wellington 276 Nominum, Inc. 277 950 Charter Street 278 Redwood City, CA 94063 279 +1 650 779 6022 280 282 8 - Full Copyright Statement 284 Copyright (C) The Internet Society (2000). All Rights Reserved. 286 This document and translations of it may be copied and furnished to 287 others, and derivative works that comment on or otherwise explain it or 288 assist in its implmentation may be prepared, copied, published and 289 distributed, in whole or in part, without restriction of any kind, 290 provided that the above copyright notice and this paragraph are included 291 on all such copies and derivative works. However, this document itself 292 may not be modified in any way, such as by removing the copyright notice 293 or references to the Internet Society or other Internet organizations, 294 except as needed for the purpose of developing Internet standards in 295 which case the procedures for copyrights defined in the Internet 296 Standards process must be followed, or as required to translate it into 297 languages other than English. 299 The limited permissions granted above are perpetual and will not be 300 revoked by the Internet Society or its successors or assigns. 302 This document and the information contained herein is provided on an "AS 303 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 304 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 305 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 306 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 307 FITNESS FOR A PARTICULAR PURPOSE."