draft-ietf-dnsop-dnssec-trust-anchor-02.txt | draft-ietf-dnsop-dnssec-trust-anchor-03.txt | |||
---|---|---|---|---|
DNS Operations M. Larson | Intended Status: Informational M. Larson | |||
Internet-Draft VeriSign | DNS Operations VeriSign | |||
Expires: January 15, 2009 O. Gudmundsson | Internet-Draft O. Gudmundsson | |||
OGUD Consulting LLC | Expires: September 10, 2009 OGUD Consulting LLC | |||
July 14, 2008 | March 9, 2009 | |||
DNSSEC Trust Anchor Configuration and Maintenance | DNSSEC Trust Anchor Configuration and Maintenance | |||
draft-ietf-dnsop-dnssec-trust-anchor-02 | draft-ietf-dnsop-dnssec-trust-anchor-03 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | This Internet-Draft is submitted to IETF in full conformance with the | |||
applicable patent or other IPR claims of which he or she is aware | provisions of BCP 78 and BCP 79. This document may contain material | |||
have been or will be disclosed, and any of which he or she becomes | from IETF Documents or IETF Contributions published or made publicly | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | available before November 10, 2008. The person(s) controlling the | |||
copyright in some of this material may not have granted the IETF | ||||
Trust the right to allow modifications of such material outside the | ||||
IETF Standards Process. Without obtaining an adequate license from | ||||
the person(s) controlling the copyright in such materials, this | ||||
document may not be modified outside the IETF Standards Process, and | ||||
derivative works of it may not be created outside the IETF Standards | ||||
Process, except to format it for publication as an RFC or to | ||||
translate it into languages other than English. | ||||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on January 15, 2009. | This Internet-Draft will expire on September 10, 2009. | |||
Copyright Notice | ||||
Copyright (c) 2009 IETF Trust and the persons identified as the | ||||
document authors. All rights reserved. | ||||
This document is subject to BCP 78 and the IETF Trust's Legal | ||||
Provisions Relating to IETF Documents in effect on the date of | ||||
publication of this document (http://trustee.ietf.org/license-info). | ||||
Please review these documents carefully, as they describe your rights | ||||
and restrictions with respect to this document. | ||||
Abstract | Abstract | |||
This document recommends a preferred format for specifying trust | This document recommends a preferred format for specifying trust | |||
anchors in DNSSEC validating security-aware resolvers and describes | anchors in DNSSEC validating security-aware resolvers and describes | |||
how such a resolver should initialize trust anchors for use. This | how such a resolver should initialize trust anchors for use. This | |||
document also describes different mechanisms for keeping trust | document also describes different mechanisms for keeping trust | |||
anchors up to date over time. | anchors up to date over time. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Trust Anchor Format . . . . . . . . . . . . . . . . . . . . . 4 | 2. Trust Anchor Format . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Trust Anchor Priming . . . . . . . . . . . . . . . . . . . . . 5 | 3. Trust Anchor Priming . . . . . . . . . . . . . . . . . . . . . 6 | |||
4. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . . 7 | 4. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . . 8 | |||
5. Security considerations . . . . . . . . . . . . . . . . . . . 9 | 5. Security considerations . . . . . . . . . . . . . . . . . . . 10 | |||
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 | 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . . 14 | ||||
1. Introduction | 1. Introduction | |||
The DNSSEC standards documents ([RFC4033], [RFC4034] and [RFC4035]) | The DNSSEC standards documents ([RFC4033], [RFC4034] and [RFC4035]) | |||
describe the need for trust anchors and how they are used. A | describe the need for trust anchors and how they are used. A | |||
validating security-aware resolver (subsequently referred to as a | validating security-aware resolver (subsequently referred to as a | |||
"validating resolver") needs to be configured with one or more trust | "validating resolver") needs to be configured with one or more trust | |||
anchors, which specify the public keys of signed zones. To | anchors, which specify the public keys of signed zones. To | |||
authenticate DNS data, a validating resolver builds a chain of trust | authenticate DNS data, a validating resolver builds a chain of trust | |||
from a configured trust anchor to that data. | from a configured trust anchor to that data. | |||
skipping to change at page 4, line 43 | skipping to change at page 6, line 5 | |||
RRSet from one of the zone's authoritative servers. It should be | RRSet from one of the zone's authoritative servers. It should be | |||
noted that in practice, priming is almost always required because | noted that in practice, priming is almost always required because | |||
data in the trust anchor zone will usually be signed with a different | 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 | key than the one configured as the trust anchor, thus requiring the | |||
validating resolver to obtain all keys in the DNSKEY RRSet. | validating resolver to obtain all keys in the DNSKEY RRSet. | |||
Using a DS format is also recommended because it is smaller than the | Using a DS format is also recommended because it is smaller than the | |||
DNSKEY format and is easier to enter manually, either by typing or | DNSKEY format and is easier to enter manually, either by typing or | |||
cutting and pasting. | cutting and pasting. | |||
Another advantage of configuring a trust anchor using a DS record is | ||||
that the entire hash of the public key in the DS RDATA need not | ||||
necessarily be specified. A validating resolver MAY support | ||||
configuration using a truncated DS hash value as a human-factors | ||||
convenience: shorter strings are easier to type and less prone to | ||||
error when entered manually. Even with a truncated hash configured, | ||||
a validating resolver can still verify that the corresponding DNSKEY | ||||
is present in the trust anchor zone's apex DNSKEY RRSet. RFC 2104 | ||||
[RFC2104] offers guidance on acceptable truncation lengths. | ||||
3. Trust Anchor Priming | 3. Trust Anchor Priming | |||
A validating resolver needs to obtain and validate the DNSKEY RRSet | A validating resolver needs to obtain and validate the DNSKEY RRSet | |||
corresponding to a configured DS for that trust anchor to be usable | corresponding to a configured DS for that trust anchor to be usable | |||
in DNSSEC validation. This process is called "priming" the trust | in DNSSEC validation. This process is called "priming" the trust | |||
anchor. Priming can occur when the validating resolver starts, but a | anchor. Priming can occur when the validating resolver starts, but a | |||
validating resolver SHOULD defer priming of individual trust anchors | validating resolver SHOULD defer priming of individual trust anchors | |||
until each is first needed for verification. This priming on demand | until each is first needed for verification. This priming on demand | |||
is especially important when a validating resolver is configured with | is especially important when a validating resolver is configured with | |||
a large number of trust anchors to avoid sending a large number of | a large number of trust anchors to avoid sending a large number of | |||
skipping to change at page 5, line 48 | skipping to change at page 6, line 48 | |||
found in the previous step, i.e., that there exists a valid RRSIG | found in the previous step, i.e., that there exists a valid RRSIG | |||
(cryptographically and temporally) for the DNSKEY RRSet generated | (cryptographically and temporally) for the DNSKEY RRSet generated | |||
with the private key corresponding to the DNSKEY found in the | with the private key corresponding to the DNSKEY found in the | |||
previous step. | previous step. | |||
If the validating resolver can successfully complete the steps above, | If the validating resolver can successfully complete the steps above, | |||
all DNSKEY RRs in the RRSet ought to be considered authenticated and | all DNSKEY RRs in the RRSet ought to be considered authenticated and | |||
can be used to authenticate RRSets at or below the trust anchor. | can be used to authenticate RRSets at or below the trust anchor. | |||
If any of the steps above result in an error, the validating resolver | If any of the steps above result in an error, the validating resolver | |||
SHOULD log them. | SHOULD log them and abort the verification as specified in section 5 | |||
of RFC 4035 [RFC4035]. | ||||
If there are multiple trust anchors configured for a zone, any one of | If there are multiple trust anchors configured for a zone, any one of | |||
them is sufficient to validate data in the zone. For this reason, | them is sufficient to validate data in the zone. For this reason, | |||
old trust anchors SHOULD be removed from a validating resolver's | old trust anchors SHOULD be removed from a validating resolver's | |||
trust anchor list soon after the corresponding keys are no longer | trust anchor list soon after the corresponding keys are no longer | |||
used by the zone. If there are multiple trust anchors configured for | used by the zone. If there are multiple trust anchors configured for | |||
a zone, any one of them is sufficient to validate data in the zone. | a zone, any one of them is sufficient to validate data in the zone. | |||
For this reason, old trust anchors SHOULD be removed from a | For this reason, old trust anchors SHOULD be removed from a | |||
validating resolver's trust anchor list soon after the corresponding | validating resolver's trust anchor list soon after the corresponding | |||
keys are no longer used by the zone, as described in RFC 5011 | keys are no longer used by the zone, as described in RFC 5011 | |||
[RFC5011]. | [RFC5011]. | |||
If a validating resolver is unable to retrieve a signed DNSKEY RRSet | If a validating resolver is unable to retrieve a signed DNSKEY RRSet | |||
corresponding to a trust anchor (i.e., prime the trust anchor), it | corresponding to a trust anchor (i.e., prime the trust anchor), it | |||
SHOULD log this condition as an error. Inability to prime a zone's | SHOULD log this condition as an error. Inability to prime a zone's | |||
trust anchor results in the validating resolver's inability to | trust anchor results in the validating resolver's inability to | |||
validate data from the corresponding zone. The validating resolver | validate data from the corresponding zone. The validating resolver | |||
SHOULD treat this zone as bogus. | MUST treat this zone as bogus, until such time it is able to get a | |||
DNSKEY set validated by a Trust anchor. The processing of trust | ||||
anchor and DS from parent errors MUST follow the same rules. | ||||
4. Trust Anchor Maintenance | 4. Trust Anchor Maintenance | |||
Trust anchors correspond to zones' key signing keys and these keys do | Trust anchors correspond to zones' key signing keys and these keys do | |||
change in the course of normal operation. It is up to validating | change in the course of normal operation. It is up to validating | |||
resolver operators to ensure that configured trust anchor information | resolver operators to ensure that configured trust anchor information | |||
remains current and does not go stale: each configured trust anchor | remains current and does not go stale: each configured trust anchor | |||
SHOULD correspond to a DNSKEY RR in the trust anchor zone's apex | SHOULD correspond to a DNSKEY RR in the trust anchor zone's apex | |||
DNSKEY RRSet. This process is called trust anchor maintenance. | DNSKEY RRSet. This process is called trust anchor maintenance. | |||
(Initial trust anchor configuration requires human intervention to | (Initial trust anchor configuration requires human intervention to | |||
skipping to change at page 11, line 8 | skipping to change at page 12, line 8 | |||
configured to treat responses from the zone as bogus, causing | configured to treat responses from the zone as bogus, causing | |||
resolution failures. | resolution failures. | |||
6. IANA considerations | 6. IANA considerations | |||
This document does not have any IANA actions. | This document does not have any IANA actions. | |||
7. Acknowledgments | 7. Acknowledgments | |||
This work was undertaken at the suggestion of the DNSSEC Deployment | This work was undertaken at the suggestion of the DNSSEC Deployment | |||
working group (www.dnssec-deployment.org). | working group (www.dnssec-deployment.org). Following people are | |||
acknowledged for contributing to this document, Alfred Hoenes, Edward | ||||
8. References | Lewis, Geoff Huston, Paul Hoffman, Matthijs Mekking, Scott Rose Paul | |||
Wouters. | ||||
8.1. Normative References | 8. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "DNS Security Introduction and Requirements", | Rose, "DNS Security Introduction and Requirements", | |||
RFC 4033, March 2005. | RFC 4033, March 2005. | |||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "Resource Records for the DNS Security Extensions", | Rose, "Resource Records for the DNS Security Extensions", | |||
RFC 4034, March 2005. | RFC 4034, March 2005. | |||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "Protocol Modifications for the DNS Security | Rose, "Protocol Modifications for the DNS Security | |||
Extensions", RFC 4035, March 2005. | Extensions", RFC 4035, March 2005. | |||
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer | [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer | |||
(DS) Resource Records (RRs)", RFC 4509, May 2006. | (DS) Resource Records (RRs)", RFC 4509, May 2006. | |||
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | ||||
Hashing for Message Authentication", RFC 2104, | ||||
February 1997. | ||||
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) | [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) | |||
Trust Anchors", RFC 5011, September 2007. | Trust Anchors", RFC 5011, September 2007. | |||
8.2. Informative References | ||||
Authors' Addresses | Authors' Addresses | |||
Matt Larson | Matt Larson | |||
VeriSign, Inc. | VeriSign, Inc. | |||
21345 Ridgetop Circle | 21345 Ridgetop Circle | |||
Dulles, VA 20166-6503 | Dulles, VA 20166-6503 | |||
USA | USA | |||
Email: mlarson@verisign.com | Email: mlarson@verisign.com | |||
Olafur Gudmundsson | Olafur Gudmundsson | |||
OGUD Consulting LLC | OGUD Consulting LLC | |||
3821 Village Park Drive | 3821 Village Park Drive | |||
Chevy Chase, MD 20815 | Chevy Chase, MD 20815 | |||
USA | USA | |||
Email: ogud@ogud.com | Email: ogud@ogud.com | |||
Full Copyright Statement | ||||
Copyright (C) The IETF Trust (2008). | ||||
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, THE IETF TRUST 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. | ||||
End of changes. 13 change blocks. | ||||
45 lines changed or deleted | 49 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |