1 Network Working Group O. Kolkman
2 Request for Comments: 3757 RIPE NCC
3 Updates: 3755, 2535 J. Schlyter
4 Category: Standards Track NIC-SE
5 E. Lewis
6 ARIN
7 April 2004
8
9
10 Domain Name System KEY (DNSKEY) Resource Record (RR)
11 Secure Entry Point (SEP) Flag
12
13 Status of this Memo
14
15 This document specifies an Internet standards track protocol for the
16 Internet community, and requests discussion and suggestions for
17 improvements. Please refer to the current edition of the "Internet
18 Official Protocol Standards" (STD 1) for the standardization state
19 and status of this protocol. Distribution of this memo is unlimited.
20
21 Copyright Notice
22
23 Copyright (C) The Internet Society (2004). All Rights Reserved.
24
25 Abstract
26
27 With the Delegation Signer (DS) resource record (RR), the concept of
28 a public key acting as a secure entry point (SEP) has been
29 introduced. During exchanges of public keys with the parent there is
30 a need to differentiate SEP keys from other public keys in the Domain
31 Name System KEY (DNSKEY) resource record set. A flag bit in the
32 DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.
33 The flag bit is intended to assist in operational procedures to
34 correctly generate DS resource records, or to indicate what DNSKEYs
35 are intended for static configuration. The flag bit is not to be
36 used in the DNS verification protocol. This document updates RFC
37 2535 and RFC 3755.
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Kolkman, et al. Standard Track [Page 1]
53 RFC 3757 DNSKEY RR SEP Flag April 2004
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
59 2. The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . . 4
60 3. DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . . 4
61 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4
62 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
63 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
64 7. Internationalization Considerations. . . . . . . . . . . . . . 6
65 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 6
66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
67 9.1. Normative References . . . . . . . . . . . . . . . . . . 6
68 9.2. Informative References . . . . . . . . . . . . . . . . . 6
69 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
70 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
71
72 1. Introduction
73
74 "All keys are equal but some keys are more equal than others" [6].
75
76 With the definition of the Delegation Signer Resource Record (DS RR)
77 [5], it has become important to differentiate between the keys in the
78 DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
79 other keys in the DNSKEY RR set. We refer to these public keys as
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
80 Secure Entry Point (SEP) keys. A SEP key either used to generate a
81 DS RR or is distributed to resolvers that use the key as the root of
82 a trusted subtree [3].
83
84 In early deployment tests, the use of two (kinds of) key pairs for
85 each zone has been prevalent. For one kind of key pair the private
86 key is used to sign just the zone's DNSKEY resource record (RR) set.
87 Its public key is intended to be referenced by a DS RR at the parent
88 or configured statically in a resolver. The private key of the other
89 kind of key pair is used to sign the rest of the zone's data sets.
90 The former key pair is called a key-signing key (KSK) and the latter
91 is called a zone-signing key (ZSK). In practice there have been
92 usually one of each kind of key pair, but there will be multiples of
93 each at times.
94
95 It should be noted that division of keys pairs into KSK's and ZSK's
96 is not mandatory in any definition of DNSSEC, not even with the
97 introduction of the DS RR. But, in testing, this distinction has
98 been helpful when designing key roll over (key super-cession)
99 schemes. Given that the distinction has proven helpful, the labels
100 KSK and ZSK have begun to stick.
101
102
103
104
105
106
107 Kolkman, et al. Standard Track [Page 2]
108 RFC 3757 DNSKEY RR SEP Flag April 2004
109
110
111 There is a need to differentiate the public keys for the key pairs
112 that are used for key signing from keys that are not used key signing
113 (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
114 be sent for generating DS RRs, which DNSKEYs are to be distributed to
115 resolvers, and which keys are fed to the signer application at the
116 appropriate time.
117
118 In other words, the SEP bit provides an in-band method to communicate
119 a DNSKEY RR's intended use to third parties. As an example we
120 present 3 use cases in which the bit is useful:
121
122 The parent is a registry, the parent and the child use secured DNS
123 queries and responses, with a preexisting trust-relation, or plain
124 DNS over a secured channel to exchange the child's DNSKEY RR sets.
125 Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP
126 bit can be used to isolate the DNSKEYs for which a DS RR needs to
127 be created.
128
129 An administrator has configured a DNSKEY as root for a trusted
130 subtree into security aware resolver. Using a special purpose
131 tool that queries for the KEY RRs from that domain's apex, the
132 administrator will be able to notice the roll over of the trusted
133 anchor by a change of the subset of KEY RRs with the DS flag set.
134
135 A signer might use the SEP bit on the public key to determine
136 which private key to use to exclusively sign the DNSKEY RRset and
137 which private key to use to sign the other RRsets in the zone.
138
139 As demonstrated in the above examples it is important to be able to
140 differentiate the SEP keys from the other keys in a DNSKEY RR set in
141 the flow between signer and (parental) key-collector and in the flow
142 between the signer and the resolver configuration. The SEP flag is
143 to be of no interest to the flow between the verifier and the
144 authoritative data store.
145
146 The reason for the term "SEP" is a result of the observation that the
147 distinction between KSK and ZSK key pairs is made by the signer, a
148 key pair could be used as both a KSK and a ZSK at the same time. To
149 be clear, the term SEP was coined to lessen the confusion caused by
150 the overlap. (Once this label was applied, it had the side effect of
151 removing the temptation to have both a KSK flag bit and a ZSK flag
152 bit.)
153
154 The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
155 "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
156 interpreted as described in BCP 14, RFC 2119 [1].
157
158
159
160
161
162 Kolkman, et al. Standard Track [Page 3]
163 RFC 3757 DNSKEY RR SEP Flag April 2004
164
165
166 2. The Secure Entry Point (SEP) Flag
167
168 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
169 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
170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
171 | flags |S| protocol | algorithm |
172 | |E| | |
173 | |P| | |
174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
175 | /
176 / public key /
177 / /
178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
179
180 DNSKEY RR Format
181 This document assigns the 15th bit in the flags field as the secure
182 entry point (SEP) bit. If the bit is set to 1 the key is intended to
183 be used as secure entry point key. One SHOULD NOT assign special
184 meaning to the key if the bit is set to 0. Operators can recognize
185 the secure entry point key by the even or odd-ness of the decimal
186 representation of the flag field.
187
188 3. DNSSEC Protocol Changes
189
190 The bit MUST NOT be used during the resolving and verification
191 process. The SEP flag is only used to provide a hint about the
192 different administrative properties of the key and therefore the use
193 of the SEP flag does not change the DNS resolution protocol or the
194 resolution process.
195
196 4. Operational Guidelines
197
198 The SEP bit is set by the key-pair-generator and MAY be used by the
199 zone signer to decide whether the public part of the key pair is to
200 be prepared for input to a DS RR generation function. The SEP bit is
201 recommended to be set (to 1) whenever the public key of the key pair
202 will be distributed to the parent zone to build the authentication
203 chain or if the public key is to be distributed for static
204 configuration in verifiers.
205
206 When a key pair is created, the operator needs to indicate whether
207 the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within
208 the data that is used to compute the 'key tag field' in the SIG RR,
209 changing the SEP bit will change the identity of the key within DNS.
210 In other words, once a key is used to generate signatures, the
211 setting of the SEP bit is to remain constant. If not, a verifier
212 will not be able to find the relevant KEY RR.
213
214
215
216
217 Kolkman, et al. Standard Track [Page 4]
218 RFC 3757 DNSKEY RR SEP Flag April 2004
219
220
221 When signing a zone, it is intended that the key(s) with the SEP bit
222 set (if such keys exist) are used to sign the KEY RR set of the zone.
223 The same key can be used to sign the rest of the zone data too. It
224 is conceivable that not all keys with a SEP bit set will sign the
225 DNSKEY RR set, such keys might be pending retirement or not yet in
226 use.
227
228 When verifying a RR set, the SEP bit is not intended to play a role.
229 How the key is used by the verifier is not intended to be a
230 consideration at key creation time.
231
232 Although the SEP flag provides a hint on which public key is to be
233 used as trusted root, administrators can choose to ignore the fact
234 that a DNSKEY has its SEP bit set or not when configuring a trusted
235 root for their resolvers.
236
237 Using the SEP flag a key roll over can be automated. The parent can
238 use an existing trust relation to verify DNSKEY RR sets in which a
239 new DNSKEY RR with the SEP flag appears.
240
241 5. Security Considerations
242
243 As stated in Section 3 the flag is not to be used in the resolution
244 protocol or to determine the security status of a key. The flag is
245 to be used for administrative purposes only.
246
247 No trust in a key should be inferred from this flag - trust MUST be
248 inferred from an existing chain of trust or an out-of-band exchange.
249
250 Since this flag might be used for automating public key exchanges, we
251 think the following consideration is in place.
252
253 Automated mechanisms for roll over of the DS RR might be vulnerable
254 to a class of replay attacks. This might happen after a public key
255 exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
256 SEP flag set, is sent to the parent. The parent verifies the DNSKEY
257 RR set with the existing trust relation and creates the new DS RR
258 from the DNSKEY RR that the current DS RR is not pointing to. This
259 key exchange might be replayed. Parents are encouraged to implement
260 a replay defense. A simple defense can be based on a registry of
261 keys that have been used to generate DS RRs during the most recent
262 roll over. These same considerations apply to entities that
263 configure keys in resolvers.
264
265
266
267
268
269
270
271
272 Kolkman, et al. Standard Track [Page 5]
273 RFC 3757 DNSKEY RR SEP Flag April 2004
274
275
276 6. IANA Considerations
277
278 IANA has assigned the 15th bit in the DNSKEY Flags Registry (see
279 Section 4.3 of [4]) as the Secure Entry Point (SEP) bit.
280
281 7. Internationalization Considerations
282
283 Although SEP is a popular acronym in many different languages, there
284 are no internationalization considerations.
285
286 8. Acknowledgments
287
288 The ideas documented in this document are inspired by communications
289 we had with numerous people and ideas published by other folk. Among
290 others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
291 Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
292 have contributed ideas and provided feedback.
293
294 This document saw the light during a workshop on DNSSEC operations
295 hosted by USC/ISI in August 2002.
296
297 9. References
298
299 9.1. Normative References
300
301 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
302 Levels", BCP 14, RFC 2119, March 1997.
303
304 [2] Eastlake, D., "Domain Name System Security Extensions", RFC
305 2535, March 1999.
306
307 [3] Lewis, E., "DNS Security Extension Clarification on Zone
308 Status", RFC 3090, March 2001.
309
310 [4] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
311 (DS)", RFC 3755, April 2004.
312
313 9.2. Informative References
314
315 [5] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
316 RFC 3658, December 2003.
317
318 [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
319 Story", ISBN 0151002177 (50th anniversary edition), April 1996.
320
321
322
323
324
325
326
327 Kolkman, et al. Standard Track [Page 6]
328 RFC 3757 DNSKEY RR SEP Flag April 2004
329
330
331 10. Authors' Addresses
332
333 Olaf M. Kolkman
334 RIPE NCC
335 Singel 256
336 Amsterdam 1016 AB
337 NL
338
339 Phone: +31 20 535 4444
340 EMail: olaf@ripe.net
341 URI: http://www.ripe.net/
342
343
344 Jakob Schlyter
345 NIC-SE
346 Box 5774
347 SE-114 87 Stockholm
348 Sweden
349
350 EMail: jakob@nic.se
351 URI: http://www.nic.se/
352
353
354 Edward P. Lewis
355 ARIN
356 3635 Concorde Parkway Suite 200
357 Chantilly, VA 20151
358 US
359
360 Phone: +1 703 227 9854
361 EMail: edlewis@arin.net
362 URI: http://www.arin.net/
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382 Kolkman, et al. Standard Track [Page 7]
383 RFC 3757 DNSKEY RR SEP Flag April 2004
384
385
386 11. Full Copyright Statement
387
388 Copyright (C) The Internet Society (2004). This document is subject
389 to the rights, licenses and restrictions contained in BCP 78 and
390 except as set forth therein, the authors retain all their rights.
391
392 This document and the information contained herein are provided on an
393 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
394 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
395 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
396 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
397 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
398 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
399
400 Intellectual Property
401
402 The IETF takes no position regarding the validity or scope of any
403 Intellectual Property Rights or other rights that might be claimed
404 to pertain to the implementation or use of the technology
405 described in this document or the extent to which any license
406 under such rights might or might not be available; nor does it
407 represent that it has made any independent effort to identify any
408 such rights. Information on the procedures with respect to
409 rights in RFC documents can be found in BCP 78 and BCP 79.
410
411 Copies of IPR disclosures made to the IETF Secretariat and any
412 assurances of licenses to be made available, or the result of an
413 attempt made to obtain a general license or permission for the use
414 of such proprietary rights by implementers or users of this
415 specification can be obtained from the IETF on-line IPR repository
416 at http://www.ietf.org/ipr.
417
418 The IETF invites any interested party to bring to its attention
419 any copyrights, patents or patent applications, or other
420 proprietary rights that may cover technology that may be required
421 to implement this standard. Please address the information to the
422 IETF at ietf-ipr@ietf.org.
423
424 Acknowledgement
425
426 Funding for the RFC Editor function is currently provided by the
427 Internet Society.
428
429
430
431
432
433
434
435
436
437 Kolkman, et al. Standard Track [Page 8]
438
A SEP key either used to generate a DS RR or is distributed to resolvers that use the key as the root of a trusted subtree
A SEP key is either used to generate a DS RR or is distributed to resolvers that use the key as the root of a trusted subtree