DNS Operations M. Larson
Internet-Draft VeriSign
Intended status: Informational O. Gudmundsson
Expires: July 16, 2007 OGUD Consulting LLC
January 12, 2007
DNSSEC Trust Anchor Configuration and Maintenance
draft-larson-dnsop-trust-anchor-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 16, 2007.
Copyright Notice
Copyright (C) The Internet Society (2007).
Larson & Gudmundsson Expires July 16, 2007 [Page 1]
Internet-Draft DNSSEC Trust Anchor Config and Maint. January 2007
Abstract
This document recommends a single preferred format for specifying
trust anchors in DNSSEC validating resolvers and describes how the
validating resolver should initalize the trust anchor for use upon
start-up. This document also describes different mechanisms for
keeping trust anchors up to date over time.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Trust Anchor Format . . . . . . . . . . . . . . . . . . . . . 4
3. Trust Anchor Priming . . . . . . . . . . . . . . . . . . . . . 5
4. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Internationalization considerations . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Larson & Gudmundsson Expires July 16, 2007 [Page 2]
Internet-Draft DNSSEC Trust Anchor Config and Maint. January 2007
1. Introduction
The DNSSEC standards documents ([2], [3] and [4]) describe the need
for trust anchors and how they are used. A DNSSEC validating
resolver must be configured with one or more trust anchors, which
specify the public keys of signed zones. To authenticate DNS data, a
validating resolver builds a chain of trust from a configured trust
anchor to that data. This document augments the DNSSEC standards
documents by specifying a standardized format for describing trust
anchors in validating resolver configuration data, describing how to
initialize trust anchors for use and listing options for keeping
trust anchor information current over time.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Larson & Gudmundsson Expires July 16, 2007 [Page 3]
Internet-Draft DNSSEC Trust Anchor Config and Maint. January 2007
2. Trust Anchor Format
A validating resolver's configuration MUST allow one or more trust
anchors to be specified. Each trust anchor SHOULD be specified as a
DS resource record (RR). (DS records are defined in Section 5 of RFC
4034 [3].) A DS RR used to specify a trust anchor in this manner
SHOULD use a digest algorithm of SHA-256 [5], which is DS digest type
2. DS RRs using SHA-1 (DS digest type 1) are NOT RECOMMENDED.
Either a DS RR (which contains the hash of a DNSKEY RR) or the DNSKEY
RR itself can be used to specify a trust anchor. Using the DS RR
offers a slight advantage because it forces a DNS query to obtain the
trust anchor's complete DNSKEY RRSet during a priming operation
(described below). If only a DNSKEY record were specified, an
implementor could conceivably avoid the priming step (though in
practice, priming is almost always required because data in the trust
anchor zone will usually be signed with a different key than the one
configured as the trust anchor, thus requiring the validating
resolver to have all keys in the DNSKEY RRSet).
Using a DS RR is also recommended because it is smaller than the
DNSKEY RR and is easier to enter manually, either by typing or
cutting and pasting.
Truncation of the configured trust anchor MAY be supported by
validating resolvers as a human-factors convenience.
Larson & Gudmundsson Expires July 16, 2007 [Page 4]
Internet-Draft DNSSEC Trust Anchor Config and Maint. January 2007
3. Trust Anchor Priming
A validating resolver needs to obtain and validate the DNSKEY RRSet
corresponding to a configured DS RR for that trust anchor to be
usable in DNSSEC validation. This process is called "priming" the
trust anchor and typically occurs when the validating resolver
starts. This section adds additional details to the discussion of
trust anchors in Section 5 of RFC 4035 [4].
Following are the steps a validating resolver SHOULD take to prime a
configured trust anchor:
1. Read the trust anchor's DS RR from the validating resolver's
configuration (e.g., a text file).
2. Look up the DNSKEY RRset corresponding to the owner name of the
DS RR. (The validating resolver can either perform iterative
resolution or request recursive service from a recursive name
server, depending on its capabilities.)
3. Verify that the DNSKEY RR corresponding to the configured DS RR
(i.e., the DNSKEY whose hash appears in the DS record) appears in
the DNSKEY RRset and that the DNSKEY RR has the Zone Key Flag
(DNSKEY RDATA bit 7) set.
4. Verify that the DNSKEY RRSet is signed by one of the DNSKEYs
found in the previous step, i.e., that there exists a valid RRSIG
(cryptographically and temporally) for the DNSKEY RRSet generated
with the private key corresponding to the DNSKEY found in the
previous step.
If the validating resolver can successfully complete the steps above,
all DNSKEY RRs in the RRSet may be considered authenticated and used
authenticate RRSets at or below the trust anchor.
TBD: Need a discussion of exception handling. What actions should be
taken if any of the steps above fail? One or all DS at a name
needed, when to log, when to throw error?
Larson & Gudmundsson Expires July 16, 2007 [Page 5]
Internet-Draft DNSSEC Trust Anchor Config and Maint. January 2007
4. Trust Anchor Maintenance
Trust anchors correspond to zones' key signing keys and these keys do
change in the course of normal operation. Validating resolver
operators MUST ensure that configured trust anchor information
remains current and does not go stale: each configured trust anchor
DS RR SHOULD correspond to a DNSKEY RR in the trust anchor zone's
apex DNSKEY RRSet. This process is called trust anchor maintenance.
(Initial trust anchor configuration requires human intervention to
verify the trust anchor's authenticity using out-of-band means and is
outside the scope of this document.)
This section provides a brief overview of mechanisms to keep trust
anchor information current:
Manual configuration: The validating resolver operator MAY choose to
maintain trust anchor information completely manually. In this
case, the operator assumes responsibility for noticing stale trust
anchor information (i.e., DS records that no longer point to a
corresponding DNSKEY RR in the trust anchor zone's apex DNSKEY
RRSet) and updating that information. This process MAY require
the operator to use the same out-of-band verification mechanism
used to initial configuration to ensure that the new trust anchor
DS RR is trustworthy. Because manual maintenance is burdensome
and prone to error, and because other automated trust anchor
maintenance processes either exist or are in development, manual
trust anchor maintenance is NOT RECOMMENDED.
Trusted update mechanism: Updated trust anchor information MAY be
obtained via a trusted non-DNS update mechanism. One possibility
is the operating system update mechanism provided by most software
vendors; for example, Windows Update, Apple Software Update,
individual Linux vendor package update mechanisms, etc. Operators
must already place considerable trust in this mechansim, so it is
reasonable to extend this trust to allow distribution and update
of DNSSEC key material. Another possibility is to obtain trust
anchor configuration directly from the validating resolver
software vendor. For example, the Internet Systems Consortium,
developers of BIND, ship a current root hints file in the BIND
source code distribution. Trust anchor configuration could
conceivably be added to the source code distribution, as well.
DNSSEC In-band Update: The IETF DNS Extensions Working Group has
developed a protocol to automatically update DNSSEC trust anchors
entitled "Automated Updates of DNSSEC Trust Anchors" [6]. This
protocol relies on a small DNSSEC protocol change (an additional
flag in the DNSKEY record) and can be run either inside the
validating resolver or in an external program with access to the
Larson & Gudmundsson Expires July 16, 2007 [Page 6]
Internet-Draft DNSSEC Trust Anchor Config and Maint. January 2007
trust anchor configuration data. This protocol is capable of
keeping trust anchors up to date indefinitely if the trust anchor
zone's operator follows the proper procedures.
Larson & Gudmundsson Expires July 16, 2007 [Page 7]
Internet-Draft DNSSEC Trust Anchor Config and Maint. January 2007
5. Acknowledgments
This work was undertaken at the suggestion of the DNSSEC Deployment
working group (www.dnssec-deployment.org).
Larson & Gudmundsson Expires July 16, 2007 [Page 8]
Internet-Draft DNSSEC Trust Anchor Config and Maint. January 2007
6. Security considerations
TBD: The security considerations section has not yet been written.
Larson & Gudmundsson Expires July 16, 2007 [Page 9]
Internet-Draft DNSSEC Trust Anchor Config and Maint. January 2007
7. IANA considerations
This document does not have any IANA actions.
Larson & Gudmundsson Expires July 16, 2007 [Page 10]
Internet-Draft DNSSEC Trust Anchor Config and Maint. January 2007
8. Internationalization considerations
There are no new internationalization considerations introduced by
this memo.
Larson & Gudmundsson Expires July 16, 2007 [Page 11]
Internet-Draft DNSSEC Trust Anchor Config and Maint. January 2007
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[5] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
Resource Records (RRs)", RFC 4509, May 2006.
9.2. Informative References
[6] StJohns, M., "Automated Updates of DNSSEC Trust Anchors",
draft-ietf-dnsext-trustupdate-timers-05 (work in progress),
November 2006.
Larson & Gudmundsson Expires July 16, 2007 [Page 12]
Internet-Draft DNSSEC Trust Anchor Config and Maint. January 2007
Authors' Addresses
Matt Larson
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
Email: mlarson@verisign.com
Olafur Gudmundsson
OGUD Consulting LLC
3821 Village Park Drive
Chevy Chase, MD 20815
USA
Email: ogud@ogud.com
Larson & Gudmundsson Expires July 16, 2007 [Page 13]
Internet-Draft DNSSEC Trust Anchor Config and Maint. January 2007
Full Copyright Statement
Copyright (C) The Internet Society (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Larson & Gudmundsson Expires July 16, 2007 [Page 14]