idnits 2.17.1 draft-ietf-dnsext-keyrr-key-signing-flag-07.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC2119. -- 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 (January 2003) is 7771 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) == Unused Reference: '1' is defined on line 298, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 301, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (ref. '2') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 3090 (ref. '3') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 3445 (ref. '4') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-15) exists of draft-ietf-dnsext-delegation-signer-14 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions O. Kolkman 3 Internet-Draft RIPE NCC 4 Expires: July 2, 2003 J. Schlyter 5 Carlstedt Research & 6 Technology 7 E. Lewis 8 ARIN 9 January 2003 11 KEY RR Secure Entry Point (SEP) Flag 12 draft-ietf-dnsext-keyrr-key-signing-flag-07 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 2, 2003. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 With the DS resource record the concept of a key acting as a secure 44 entry point has been introduced. During key-exchanges with the 45 parent there is a need to differentiate secure entry point keys from 46 other keys in the KEY resource record set. A flag bit in the KEY RR 47 is defined to indicate that KEY is to be used as a secure entry 48 point. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. The Secure Entry Point (SEP) Flag . . . . . . . . . . . . . . 4 54 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . 4 55 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 7. Internationalization Considerations . . . . . . . . . . . . . 6 59 8. Document Changes . . . . . . . . . . . . . . . . . . . . . . . 6 60 8.1 draft version 00 -> 01 . . . . . . . . . . . . . . . . . . . . 6 61 8.2 draft version 01 -> 02 . . . . . . . . . . . . . . . . . . . . 6 62 8.3 draft version 02 -> 03 . . . . . . . . . . . . . . . . . . . . 6 63 8.4 draft version 03 -> 04 . . . . . . . . . . . . . . . . . . . . 6 64 8.5 draft version 04 -> 05 . . . . . . . . . . . . . . . . . . . . 7 65 8.6 draft version 05 -> 06 . . . . . . . . . . . . . . . . . . . . 7 66 8.7 draft version 06 -> 07 . . . . . . . . . . . . . . . . . . . . 7 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 68 Normative References . . . . . . . . . . . . . . . . . . . . . 7 69 Informative References . . . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 71 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 "All keys are equal but some keys are more equal than others" [6] 77 With the definition of the DS Resource Record [5] it has become 78 important to differentiate between the zone keys that are (to be) 79 pointed to by parental DS RRs and other keys in the zone. We refer 80 to these keys as Secure Entry Point (SEP) keys. A SEP key is either 81 used to generate a DS RR or is distributed to resolvers that use the 82 key as the root of a trusted subtree[3]. 84 In early deployment tests, the use of two (kinds of) keys in each 85 zone has been prevalent. One key is used to sign just the zone's KEY 86 RR set and is the key referenced by a DS RR at the parent or 87 configured statically in a resolver. Another key is used to sign the 88 rest of the zone's data sets. The former key is called a key-signing 89 key (KSK) and the latter is called a zone-signing key (ZSK). In 90 practice there have been usually one of each kind of key, but there 91 will be multiples of each at times. 93 It should be noted that division of zone keys into KSK's and ZSK's is 94 not mandatory in any definition of DNSSEC, not even with the 95 introduction of the DS RR. But, in testing, this distinction has 96 been helpful when designing key roll over (key super-cession) 97 schemes. Given that the distinction has proven helpful, the labels 98 KSK and ZSK have begun to stick. 100 The reason for the term "SEP" is a result of the observation that the 101 distinction between KSK and ZSK is only significant to the signer 102 element of the DNS. Servers, resolvers and verifiers do not need to 103 make the distinction. Further, distinguishing between a KSK and ZSK 104 requires more than one bit, as a key could be fulfilling both roles. 105 Hence, there is no definition for a ZSK bit and another for a KSK 106 bit, just a single bit to assist operational procedures to correctly 107 generate DS RRs, or to indicate what keys are intended for static 108 configuration. 110 The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", 111 "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be 112 interpreted as described in RFC2119. 114 2. The Secure Entry Point (SEP) Flag 116 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | flags |S| protocol | algorithm | 120 | |E| | | 121 | |P| | | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | / 124 / public key / 125 / / 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 KEY RR Format 130 The SEP bit (TBD) in the flags field is assigned to be the secure 131 entry point flag. If the the bit is set to 1 the key is intended to 132 be used as secure entry point key. One SHOULD NOT assign special 133 meaning to the key if the bit is set to 0. The document proposes 134 using the current 15th bit [4] as the SEP bit. This way operators 135 can recognize the secure entry point key by the even or odd-ness of 136 the decimal representation of the flag field. 138 3. DNSSEC Protocol Changes 140 The bit MUST NOT be used during the resolving and verification 141 process. The SEP flag is only used to provide a hint about the 142 different administrative properties of the key and therefore the use 143 of the SEP flag does not change the DNS resolution and resolution 144 protocol. 146 4. Operational Guidelines 148 The SEP bit is set by the key-generator and MAY be used by the zone 149 signer to decide whether the key is to be prepared for input to a DS 150 RR generation function. As the SEP bit is within the data that is 151 used to compute a KEY RR's footprint, changing the SEP bit will 152 change the identity of the key within DNS. 154 When a key pair is created, the operator needs to indicate whether 155 the SEP bit is to be set in the KEY RR. The SEP bit is recommended 156 whenever the public key of the key pair will be distributed to the 157 parent zone to build the authentication chain or if the public key is 158 to be distributed for static configuration in verifiers. 160 When signing a zone, it is intended that the key(s) with the SEP bit 161 set (if such keys exist) are used to sign the KEY RR set of the zone. 162 The same key can be used to sign the rest of the zone data too. It 163 is conceivable that not all keys with a SEP bit set will sign the KEY 164 RR set, such keys might be pending retirement or not yet in use. 166 When verifying a RR set, the SEP bit is not intended to play a role. 167 How the key is used by the verifier is not intended to be a 168 consideration at key creation time. 170 Although the SEP flag provides a hint on which key to be used as 171 trusted root, administrators can choose to ignore the fact that a KEY 172 has its SEP bit set or not when configuring a trusted root for their 173 resolvers. 175 Using the flag a key roll over can be automated. The parent can use 176 an existing trust relation to verify key sets in which a new key with 177 the SEP flag appears. 179 5. Security Considerations 181 As stated in Section 3 the flag is not to used in the resolution 182 protocol or to determine the security status of a key. The flag is 183 to be used for administrative purposes only. 185 No trust in a key should be inferred from this flag - trust MUST be 186 inferred from an existing chain of trust or an out-of-band exchange. 188 Since this flag might be used for automating key exchanges, we think 189 the following consideration is in place. 191 Automated mechanisms for roll over of the DS RR might be vulnerable 192 to a class of replay attacks. This might happen after a key exchange 193 where a key set, containing two keys with the SEP flag set, is sent 194 to the parent. The parent verifies the key set with the existing 195 trust relation and creates the new DS RR from the key that the 196 current DS is not pointing to. This key exchange might be replayed. 197 Parents are encouraged to implement a replay defense. A simple 198 defense can be based on a registry of keys that have been used to 199 generate DS RRs during the most recent roll over. These same 200 considerations apply to entities that configure keys in resolvers. 202 6. IANA Considerations 204 draft-ietf-dnsext-restrict-key-for-dnssec [4] eliminates all flags 205 field except for the zone key flag in the KEY RR. We propose to use 206 the 15'th bit as the SEP bit; the decimal representation of the 207 flagfield will then be odd for key-signing keys. 209 7. Internationalization Considerations 211 Although SEP is a popular acronym in many different languages, there 212 are no internationalization considerations. 214 8. Document Changes 216 8.1 draft version 00 -> 01 218 Clean up of references and correction of typos; 220 modified Abstract text a little; 222 Added explicit warning for replay attacks to the security section; 224 Removed the text that hinted on a distinction between a key- 225 signing key configured in resolvers and in parent zones. 227 8.2 draft version 01 -> 02 229 Added IANA and Internationalization section. 231 Split references into informational and normative. 233 Spelling and style corrections. 235 8.3 draft version 02 -> 03 237 Changed the name from KS to KSK, this to prevent confusion with 238 NS, DS and other acronyms in DNS. 240 In the security section: Rewrote the section so that it does not 241 suggest to use a particular type of registry and that it is clear 242 that a key registry is only one of the defenses possible. 244 Spelling and style corrections. 246 8.4 draft version 03 -> 04 248 Text has been made consistent with the statement: ' No special 249 meaning should be assigned to the bit not being set.' 251 Made explicit that the key tag changes in SIG RR. 253 8.5 draft version 04 -> 05 255 One occurrence of must and one occurrence of should uppercased 256 (RFC2119). 258 Reordering of sentences in section 3, so that the point of the bit 259 NOT being used in resolving is made directly. 261 To make explicit that the KSK is used at key generation and at 262 signing time I added the first sentence to section 4. 264 Some minor style and spelling corrections. 266 8.6 draft version 05 -> 06 268 References and acronyms where stripped from the Abstract. the 269 Introduction and the the Operational Guideline section were 270 rewritten in such a way that the draft does not suggest any use of 271 the bit in the verification process and that the draft does not 272 enforce, but suggests, the use of a key- and zone-signing key. 274 Added 'and verification' in the sentence "MUST NOT be used during 275 the resolving and verification process" (protocol changes 276 section). 278 8.7 draft version 06 -> 07 280 Based on comments during the last call we changed the name from 281 KSK-flag to SEP flag. The introduction was rewritten to reflect 282 the motivations of this name change and to stress that the SEP key 283 is not relevant to the signer process. 285 9. Acknowledgments 287 The ideas documented in this document are inspired by communications 288 we had with numerous people and ideas published by other folk. Among 289 others Mark Andrews, Miek Gieben, Olafur Gudmundsson, Daniel 290 Karrenberg, Dan Massey, Marcos Sanz and Sam Weiler have contributed 291 ideas and provided feedback. 293 This document saw the light during a workshop on DNSSEC operations 294 hosted by USC/ISI. 296 Normative References 298 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 299 Levels", BCP 14, RFC 2119, March 1997. 301 [2] Eastlake, D., "Domain Name System Security Extensions", RFC 302 2535, March 1999. 304 [3] Lewis, E., "DNS Security Extension Clarification on Zone 305 Status", RFC 3090, March 2001. 307 [4] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 308 Record (RR)", RFC 3445, December 2002. 310 Informative References 312 [5] Gudmundsson, O., "Delegation Signer Resource Record", draft- 313 ietf-dnsext-delegation-signer-14 (work in progress), May 2003. 315 [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy 316 Story"", ISBN 0151002177 (50th anniversery edition), April 1996. 318 Authors' Addresses 320 Olaf M. Kolkman 321 RIPE NCC 322 Singel 256 323 Amsterdam 1016 AB 324 NL 326 Phone: +31 20 535 4444 327 EMail: olaf@ripe.net 328 URI: http://www.ripe.net/ 330 Jakob Schlyter 331 Carlstedt Research & Technology 332 Stora Badhusgatan 18-20 333 Goteborg SE-411 21 334 Sweden 336 EMail: jakob@crt.se 337 URI: http://www.crt.se/~jakob/ 338 Edward P. Lewis 339 ARIN 340 3635 Concorde Parkway Suite 200 341 Chantilly, VA 20151 342 US 344 Phone: +1 703 227 9854 345 EMail: edlewis@arin.net 346 URI: http://www.arin.net/ 348 Full Copyright Statement 350 Copyright (C) The Internet Society (2003). All Rights Reserved. 352 This document and translations of it may be copied and furnished to 353 others, and derivative works that comment on or otherwise explain it 354 or assist in its implementation may be prepared, copied, published 355 and distributed, in whole or in part, without restriction of any 356 kind, provided that the above copyright notice and this paragraph are 357 included on all such copies and derivative works. However, this 358 document itself may not be modified in any way, such as by removing 359 the copyright notice or references to the Internet Society or other 360 Internet organizations, except as needed for the purpose of 361 developing Internet standards in which case the procedures for 362 copyrights defined in the Internet Standards process must be 363 followed, or as required to translate it into languages other than 364 English. 366 The limited permissions granted above are perpetual and will not be 367 revoked by the Internet Society or its successors or assigns. 369 This document and the information contained herein is provided on an 370 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 371 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 372 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 373 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 374 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 376 Acknowledgement 378 Funding for the RFC Editor function is currently provided by the 379 Internet Society.