1 Network Working Group H. Eland
2 Request for Comments: 4986 Afilias Limited
3 Category: Informational R. Mundy
4 SPARTA, Inc.
5 S. Crocker
6 Shinkuro Inc.
7 S. Krishnaswamy
8 SPARTA, Inc.
9 August 2007
10
11
12 Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover
13
14 Status of This Memo
15
16 This memo provides information for the Internet community. It does
17 not specify an Internet standard of any kind. Distribution of this
18 memo is unlimited.
19
20 Abstract
21
22 Every DNS security-aware resolver must have at least one Trust Anchor
23 to use as the basis for validating responses from DNS signed zones.
24 For various reasons, most DNS security-aware resolvers are expected
25 to have several Trust Anchors. For some operations, manual
26 monitoring and updating of Trust Anchors may be feasible, but many
27 operations will require automated methods for updating Trust Anchors
28 in their security-aware resolvers. This document identifies the
29 requirements that must be met by an automated DNS Trust Anchor
30 rollover solution for security-aware DNS resolvers.
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Eland, et al. Informational [Page 1]
53 RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
62 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
63 5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 6
64 5.2. No Known Intellectual Property Encumbrance . . . . . . . . 6
65 5.3. General Applicability . . . . . . . . . . . . . . . . . . . 7
66 5.4. Support Private Networks . . . . . . . . . . . . . . . . . 7
67 5.5. Detection of Stale Trust Anchors . . . . . . . . . . . . . 7
68 5.6. Manual Operations Permitted . . . . . . . . . . . . . . . . 7
69 5.7. Planned and Unplanned Rollovers . . . . . . . . . . . . . . 7
70 5.8. Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 8
71 5.9. High Availability . . . . . . . . . . . . . . . . . . . . . 8
72 5.10. New RR Types . . . . . . . . . . . . . . . . . . . . . . . 8
73 5.11. Support for Trust Anchor Maintenance Operations . . . . . . 8
74 5.12. Recovery from Compromise . . . . . . . . . . . . . . . . . 8
75 5.13. Non-Degrading Trust . . . . . . . . . . . . . . . . . . . . 8
76 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
78 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Eland, et al. Informational [Page 2]
108 RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007
109
110
111 1. Introduction
112
113 The Domain Name System Security Extensions (DNSSEC), as described in
114 [2], [3], and [4], define new records and protocol modifications to
115 DNS that permit security-aware resolvers to validate DNS Resource
116 Records (RRs) from one or more Trust Anchors held by such security-
117 aware resolvers.
118
119 Security-aware resolvers will have to initially obtain their Trust
120 Anchors in a trustworthy manner to ensure the Trust Anchors are
121 correct and valid. There are a number of ways that this initial step
122 can be accomplished; however, details of this step are beyond the
123 scope of this document. Once an operator has obtained Trust Anchors,
124 initially entering the Trust Anchors into their security-aware
125 resolvers will in many instances be a manual operation.
126
127 For some operational environments, manual management of Trust Anchors
128 might be a viable approach. However, many operational environments
129 will require a more automated, specification-based method for
130 updating and managing Trust Anchors. This document provides a list
131 of requirements that can be used to measure the effectiveness of any
132 proposed automated Trust Anchor rollover mechanism in a consistent
133 manner.
134
135 2. Terminology
136
137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
139 document are to be interpreted as described in RFC 2119 [1].
140
141 The use of RFC 2119 words in the requirements is intended to
142 unambiguously describe a requirement. If a tradeoff is to be made
143 between conflicting requirements when choosing a solution, the
144 requirement with MUST language will have higher preference than
145 requirements with SHOULD, MAY, or RECOMMENDED language. It is
146 understood that a tradeoff may need to be made between requirements
147 that both contain RFC 2119 language.
148
149 3. Background
150
151 DNS resolvers need to have one or more starting points to use in
152 obtaining DNS answers. The starting points for stub resolvers are
153 normally the IP addresses for one or more recursive name servers.
154 The starting points for recursive name servers are normally IP
155 addresses for DNS Root name servers. Similarly, security-aware
156 resolvers must have one or more starting points to use for building
157 the authenticated chain to validate a signed DNS response. Instead
158 of IP addresses, DNSSEC requires that each resolver trust one or more
159
160
161
162 Eland, et al. Informational [Page 3]
163 RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007
164
165
166 DNSKEY RRs or DS RRs as their starting point. Each of these starting
167 points is called a Trust Anchor.
168
169 It should be noted that DNSKEY RRs and DS RRs are not Trust Anchors
170 when they are created by the signed zone operator nor are they Trust
171 Anchors because the records are published in the signed zone. A
172 DNSKEY RR or DS RR becomes a Trust Anchor when an operator of a
173 security-aware resolver determines that the public key or hash will
174 be used as a Trust Anchor. Thus, the signed zone operator that
175 created and/or published these RRs may not know if any of the DNSKEY
176 RRs or DS RRs associated with their zone are being used as Trust
177 Anchors by security-aware resolvers. The obvious exceptions are the
178 DNSKEY RRs for the Root Zone, which will be used as Trust Anchors by
179 many security-aware resolvers. For various reasons, DNSKEY RRs or DS
180 RRs from zones other than Root can be used by operators of security-
181 aware resolvers as Trust Anchors. It follows that responsibility
182 lies with the operator of the security-aware resolver to ensure that
183 the DNSKEY and/or DS RRs they have chosen to use as Trust Anchors are
184 valid at the time they are used by the security-aware resolver as the
185 starting point for building the authentication chain to validate a
186 signed DNS response.
187
188 When operators of security-aware resolvers choose one or more Trust
189 Anchors, they must also determine the method(s) they will use to
190 ensure that they are using valid RRs and that they are able to
191 determine when RRs being used as Trust Anchors should be replaced or
192 removed. Early adopters of DNS signed zones have published
193 information about the processes and methods they will use when their
194 DNSKEY and/or DS RRs change so that operators of security-aware
195 resolvers can manually change the Trust Anchors at the appropriate
196 time. This manual approach will not scale and, therefore, drives the
197 need for an automated specification-based approach for rollover of
198 Trust Anchors for security-aware resolvers.
199
200 4. Definitions
201
202 This document uses the definitions contained in RFC 4033, section 2,
203 plus the following additional definitions:
204
205 Trust Anchor: From RFC 4033, "A configured DNSKEY RR or DS RR hash
206 of a DNSKEY RR. A validating security-aware resolver uses this
207 public key or hash as a starting point for building the
208 authentication chain to a signed DNS response." Additionally, a
209 DNSKEY RR or DS RR is associated with precisely one point in the
210 DNS hierarchy, i.e., one DNS zone. Multiple Trust Anchors MAY be
211 associated with each DNS zone and MAY be held by any number of
212 security-aware resolvers. Security-aware resolvers MAY have Trust
213 Anchors from multiple DNS zones. Those responsible for the
214
215
216
217 Eland, et al. Informational [Page 4]
218 RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007
219
220
221 operation of security-aware resolvers are responsible for
222 determining the set of RRs that will be used as Trust Anchors by
223 that resolver.
224
225 Initial Trust Relationship: Operators of security-aware resolvers
226 must ensure that they initially obtain any Trust Anchors in a
227 trustworthy manner. For example, the correctness of the Root Zone
228 DNSKEY RR(s) could be verified by comparing what the operator
229 believes to be the Root Trust Anchor(s) with several 'well-known'
230 sources such as the IANA web site, the DNS published Root Zone and
231 the publication of the public key in well-known hard-copy forms.
232 For other Trust Anchors, the operator must ensure the accuracy and
233 validity of the DNSKEY and/or DS RRs before designating them Trust
234 Anchors. This might be accomplished through a combination of
235 technical, procedural, and contractual relationships, or use other
236 existing trust relationships outside the current DNS protocol.
237
238 Trust Anchor Distribution: The method or methods used to convey the
239 DNSKEY and/or DS RR(s) between the signed zone operator and the
240 security-aware resolver operator. The method or methods MUST be
241 deemed sufficiently trustworthy by the operator of the security-
242 aware resolver to ensure source authenticity and integrity of the
243 new RRs to maintain the Initial Trust Relationship required to
244 designate those RRs as Trust Anchors.
245
246 Trust Anchor Maintenance: Any change in a validating security-aware
247 resolver to add a new Trust Anchor, delete an existing Trust
248 Anchor, or replace an existing Trust Anchor with another. This
249 change might be accomplished manually or in some automated manner.
250 Those responsible for the operation of the security-aware resolver
251 are responsible for establishing policies and procedures to ensure
252 that a sufficient Initial Trust Relationship is in place before
253 adding Trust Anchors for a particular DNS zone to their security-
254 aware resolver configuration.
255
256 Trust Anchor Revocation and Removal: The invalidation of a
257 particular Trust Anchor that results when the operator of the
258 signed zone revokes or removes a DNSKEY RR or DS RR that is being
259 used as a Trust Anchor by any security-aware resolver. It is
260 possible that a zone administrator may invalidate more than one RR
261 at one point in time; therefore, it MUST be clear to both the zone
262 administrator and the security-aware resolver the exact RR(s) that
263 have been revoked or removed so the proper Trust Anchor or Trust
264 Anchors are removed.
265
266
267
268
269
270
271
272 Eland, et al. Informational [Page 5]
273 RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007
274
275
276 Trust Anchor Rollover: The method or methods necessary for the
277 secure replacement of one or multiple Trust Anchors held by
278 security-aware resolvers. Trust Anchor Rollover should be
279 considered a subset of Trust Anchor Maintenance.
280
281 Normal or Pre-Scheduled Trust Anchor Rollover: The operator of a
282 DNSSEC signed zone has issued a new DNSKEY and/or DS RR(s) as a
283 part of an operational routine.
284
285 Emergency or Non-Scheduled Trust Anchor Rollover: The operator of a
286 signed zone has issued a new DNSKEY and/or DS RR(s) as part of an
287 exceptional event.
288
289 Emergency Trust Anchor Revocation: The operator of a signed zone
290 wishes to indicate that the current DNSKEY and/or DS RR(s) are no
291 longer valid as part of an exceptional event.
292
293 5. Requirements
294
295 Following are the requirements for DNSSEC automated specification-
296 based Trust Anchor Rollover:
297
298 5.1. Scalability
299
300 The automated Trust Anchor Rollover solution MUST be capable of
301 scaling to Internet-wide usage. The probable largest number of
302 instances of security-aware resolvers needing to rollover a Trust
303 Anchor will be those that use the public key(s) for the Root Zone as
304 Trust Anchor(s). This number could be extremely large if a number of
305 applications have embedded security-aware resolvers.
306
307 The automated Trust Anchor Rollover solution MUST be able to support
308 Trust Anchors for multiple zones and multiple Trust Anchors for each
309 DNS zone. The number of Trust Anchors that might be configured into
310 any one validating security-aware resolver is not known with
311 certainty at this time; in most cases it will be less than 20 but it
312 may even be as high as one thousand.
313
314 5.2. No Known Intellectual Property Encumbrance
315
316 Because trust anchor rollover is likely to be "mandatory-to-
317 implement", section 8 of [5] requires that the technical solution
318 chosen must not be known to be encumbered or must be available under
319 royalty-free terms.
320
321 For this purpose, "royalty-free" is defined as follows: worldwide,
322 irrevocable, perpetual right to use, without fee, in commerce or
323 otherwise, where "use" includes descriptions of algorithms,
324
325
326
327 Eland, et al. Informational [Page 6]
328 RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007
329
330
331 distribution and/or use of hardware implementations, distribution
332 and/or use of software systems in source and/or binary form, in all
333 DNS or DNSSEC applications including registry, registrar, domain name
334 service including authority, recursion, caching, forwarding, stub
335 resolver, or similar.
336
337 In summary, no implementor, distributor, or operator of the
338 technology chosen for trust anchor management shall be expected or
339 required to pay any fee to any IPR holder for the right to implement,
340 distribute, or operate a system which includes the chosen mandatory-
341 to-implement solution.
342
343 5.3. General Applicability
344
345 The solution MUST provide the capability to maintain Trust Anchors in
346 security-aware resolvers for any and all DNS zones.
347
348 5.4. Support Private Networks
349
350 The solution MUST support private networks with their own DNS
351 hierarchy.
352
353 5.5. Detection of Stale Trust Anchors
354
355 The Trust Anchor Rollover solution MUST allow a validating security-
356 aware resolver to be able to detect if the DNSKEY and/or DS RR(s) can
357 no longer be updated given the current set of actual trust-anchors.
358 In these cases, the resolver should inform the operator of the need
359 to reestablish initial trust.
360
361 5.6. Manual Operations Permitted
362
363 The operator of a security-aware resolver may choose manual or
364 automated rollover, but the rollover protocol must allow the
365 implementation to support both automated and manual Trust Anchor
366 Maintenance operations. Implementation of the rollover protocol is
367 likely to be mandatory, but that's out of scope for this requirements
368 document.
369
370 5.7. Planned and Unplanned Rollovers
371
372 The solution MUST permit both planned (pre-scheduled) and unplanned
373 (non-scheduled) rollover of Trust Anchors. Support for providing an
374 Initial Trust Relationship is OPTIONAL.
375
376
377
378
379
380
381
382 Eland, et al. Informational [Page 7]
383 RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007
384
385
386 5.8. Timeliness
387
388 Resource Records used as Trust Anchors SHOULD be able to be
389 distributed to security-aware resolvers in a timely manner.
390
391 Security-aware resolvers need to acquire new and remove revoked
392 DNSKEY and/or DS RRs that are being used as Trust Anchors for a zone
393 such that no old RR is used as a Trust Anchor for long after the zone
394 issues new or revokes existing RRs.
395
396 5.9. High Availability
397
398 Information about the zone administrator's view of the state of
399 Resource Records used as Trust Anchors SHOULD be available in a
400 trustworthy manner at all times to security-aware resolvers.
401 Information about Resource Records that a zone administrator has
402 invalidated and that are known to be used as Trust Anchors should be
403 available in a trustworthy manner for a reasonable length of time.
404
405 5.10. New RR Types
406
407 If a Trust Anchor Rollover solution requires new RR types or protocol
408 modifications, this should be considered in the evaluation of
409 solutions. The working group needs to determine whether such changes
410 are a good thing or a bad thing or something else.
411
412 5.11. Support for Trust Anchor Maintenance Operations
413
414 The Trust Anchor Rollover solution MUST support operations that allow
415 a validating security-aware resolver to add a new Trust Anchor,
416 delete an existing Trust Anchor, or replace an existing Trust Anchor
417 with another.
418
419 5.12. Recovery from Compromise
420
421 The Trust Anchor Rollover solution MUST allow a security-aware
422 resolver to be able to recover from the compromise of any of its
423 configured Trust Anchors for a zone so long as at least one other
424 key, which is known to have not been compromised, is configured as a
425 Trust Anchor for that same zone at that resolver.
426
427 5.13. Non-Degrading Trust
428
429 The Trust Anchor Rollover solution MUST provide sufficient means to
430 ensure authenticity and integrity so that the existing trust relation
431 does not degrade by performing the rollover.
432
433
434
435
436
437 Eland, et al. Informational [Page 8]
438 RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007
439
440
441 6. Security Considerations
442
443 This document defines overall requirements for an automated
444 specification-based Trust Anchor Rollover solution for security-aware
445 resolvers but specifically does not define the security mechanisms
446 needed to meet these requirements.
447
448 7. Acknowledgements
449
450 This document reflects the majority opinion of the DNSEXT Working
451 Group members on the topic of requirements related to DNSSEC trust
452 anchor rollover. The contributions made by various members of the
453 working group to improve the readability and style of this document
454 are graciously acknowledged.
455
456 8. Normative References
457
458 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
459 Levels", RFC 2119, March 1997.
460
461 [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
462 "DNS Security Introduction and Requirements", RFC 4033,
463 March 2005.
464
465 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
466 "Resource Records for the DNS Security Extensions", RFC 4034,
467 March 2005.
468
469 [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
470 "Protocol Modifications for the DNS Security Extensions",
471 RFC 4035, March 2005.
472
473 [5] Bradner, S., "Intellectual Property Rights in IETF Technology",
474 RFC 3979, March 2005.
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492 Eland, et al. Informational [Page 9]
493 RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007
494
495
496 Authors' Addresses
497
498 Howard Eland
499 Afilias Limited
500 300 Welsh Road
501 Building 3, Suite 105
502 Horsham, PA 19044
503 USA
504
505 EMail: heland@afilias.info
506
507
508 Russ Mundy
509 SPARTA, Inc.
510 7110 Samuel Morse Dr.
511 Columbia, MD 21046
512 USA
513
514 EMail: mundy@sparta.com
515
516
517 Steve Crocker
518 Shinkuro Inc.
519 1025 Vermont Ave, Suite 820
520 Washington, DC 20005
521 USA
522
523 EMail: steve@shinkuro.com
524
525
526 Suresh Krishnaswamy
527 SPARTA, Inc.
528 7110 Samuel Morse Dr.
529 Columbia, MD 21046
530 USA
531
532 EMail: suresh@sparta.com
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547 Eland, et al. Informational [Page 10]
548 RFC 4986 DNSSEC Trust Anchor Rollover Requirements August 2007
549
550
551 Full Copyright Statement
552
553 Copyright (C) The IETF Trust (2007).
554
555 This document is subject to the rights, licenses and restrictions
556 contained in BCP 78, and except as set forth therein, the authors
557 retain all their rights.
558
559 This document and the information contained herein are provided on an
560 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
561 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
562 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
563 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
564 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
565 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
566
567 Intellectual Property
568
569 The IETF takes no position regarding the validity or scope of any
570 Intellectual Property Rights or other rights that might be claimed to
571 pertain to the implementation or use of the technology described in
572 this document or the extent to which any license under such rights
573 might or might not be available; nor does it represent that it has
574 made any independent effort to identify any such rights. Information
575 on the procedures with respect to rights in RFC documents can be
576 found in BCP 78 and BCP 79.
577
578 Copies of IPR disclosures made to the IETF Secretariat and any
579 assurances of licenses to be made available, or the result of an
580 attempt made to obtain a general license or permission for the use of
581 such proprietary rights by implementers or users of this
582 specification can be obtained from the IETF on-line IPR repository at
583 http://www.ietf.org/ipr.
584
585 The IETF invites any interested party to bring to its attention any
586 copyrights, patents or patent applications, or other proprietary
587 rights that may cover technology that may be required to implement
588 this standard. Please address the information to the IETF at
589 ietf-ipr@ietf.org.
590
591
592
593
594
595
596
597
598
599
600
601
602 Eland, et al. Informational [Page 11]
603
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.