draft-ietf-dnsext-signing-auth-01.txt   rfc3008.txt 
DNSIND Working Group Brian Wellington (Nominum) Network Working Group B. Wellington
INTERNET-DRAFT May 2000 Request for Comments: 3008 Nominum
Updates: 2535 November 2000
<draft-ietf-dnsext-signing-auth-01.txt> Category: Standards Track
Updates: RFC 2535
Domain Name System Security (DNSSEC) Signing Authority Domain Name System Security (DNSSEC) Signing Authority
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
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
Comments should be sent to the authors or the DNSIND WG mailing list
namedroppers@internic.net.
This draft expires on November 12, 2000.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All rights reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract Abstract
This document proposes a revised model of Domain Name System Security This document proposes a revised model of Domain Name System Security
(DNSSEC) Signing Authority. The revised model is designed to clarify (DNSSEC) Signing Authority. The revised model is designed to clarify
earlier documents and add additional restrictions to simplify the earlier documents and add additional restrictions to simplify the
secure resolution process. Specifically, this affects the secure resolution process. Specifically, this affects the
authorization of keys to sign sets of records. authorization of keys to sign sets of records.
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 [RFC2119].
1 - Introduction 1 - Introduction
This document defines additional restrictions on DNSSEC signatures (SIG) This document defines additional restrictions on DNSSEC signatures
records relating to their authority to sign associated data. The intent (SIG) records relating to their authority to sign associated data.
is to establish a standard policy followed by a secure resolver; this The intent is to establish a standard policy followed by a secure
policy can be augmented by local rules. This builds upon [RFC2535], resolver; this policy can be augmented by local rules. This builds
updating section 2.3.6 of that document. upon [RFC2535], updating section 2.3.6 of that document.
The most significant change is that in a secure zone, zone data is The most significant change is that in a secure zone, zone data is
required to be signed by the zone key. required to be signed by the zone key.
Familiarity with the DNS system [RFC1034, RFC1035] and the DNS security Familiarity with the DNS system [RFC1034, RFC1035] and the DNS
extensions [RFC2535] is assumed. security extensions [RFC2535] is assumed.
2 - The SIG Record 2 - The SIG Record
A SIG record is normally associated with an RRset, and ``covers'' (that A SIG record is normally associated with an RRset, and "covers" (that
is, demonstrates the authenticity and integrity of) the RRset. This is is, demonstrates the authenticity and integrity of) the RRset. This
referred to as a ``data SIG''. Note that there can be multiple SIG is referred to as a "data SIG". Note that there can be multiple SIG
records covering an RRset, and the same validation process should be records covering an RRset, and the same validation process should be
repeated for each of them. Some data SIGs are considered ``material'', repeated for each of them. Some data SIGs are considered "material",
that is, relevant to a DNSSEC capable resolver, and some are that is, relevant to a DNSSEC capable resolver, and some are
``immaterial'' or ``extra-DNSSEC'', as they are not relevant to DNSSEC "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC
validation. Immaterial SIGs may have application defined roles. SIG validation. Immaterial SIGs may have application defined roles. SIG
records may exist which are not bound to any RRset; these are also records may exist which are not bound to any RRset; these are also
considered immaterial. The validation process determines which SIGs are considered immaterial. The validation process determines which SIGs
material; once a SIG is shown to be immaterial, no other validation is are material; once a SIG is shown to be immaterial, no other
necessary. validation is necessary.
SIGs may also be used for transaction security. In this case, a SIG SIGs may also be used for transaction security. In this case, a SIG
record with a type covered field of 0 is attached to a message, and is record with a type covered field of 0 is attached to a message, and
used to protect message integrity. This is referred to as a SIG(0) is used to protect message integrity. This is referred to as a
[RFC2535]. SIG(0) [RFC2535, RFC2931].
The following sections define requirements for all of the fields of a The following sections define requirements for all of the fields of a
SIG record. These requirements MUST be met in order for a DNSSEC SIG record. These requirements MUST be met in order for a DNSSEC
capable resolver to process this signature. If any of these capable resolver to process this signature. If any of these
requirements are not met, the SIG cannot be further processed. requirements are not met, the SIG cannot be further processed.
Additionally, once a KEY has been identified as having generated this Additionally, once a KEY has been identified as having generated this
SIG, there are requirements that it MUST meet. SIG, there are requirements that it MUST meet.
2.1 - Type Covered 2.1 - Type Covered
For a data SIG, the type covered MUST be the same as the type of data in For a data SIG, the type covered MUST be the same as the type of data
the associated RRset. For a SIG(0), the type covered MUST be 0. in the associated RRset. For a SIG(0), the type covered MUST be 0.
2.2 - Algorithm Number 2.2 - Algorithm Number
The algorithm specified in a SIG MUST be recognized by the client, and The algorithm specified in a SIG MUST be recognized by the client,
it MUST be an algorithm that has a defined SIG rdata format. and it MUST be an algorithm that has a defined SIG rdata format.
2.3 - Labels 2.3 - Labels
The labels count MUST be less than or equal to the number of labels in The labels count MUST be less than or equal to the number of labels
the SIG owner name, as specified in [RFC2535, section 4.1.3]. in the SIG owner name, as specified in [RFC2535, section 4.1.3].
2.4 - Original TTL 2.4 - Original TTL
The original TTL MUST be greater than or equal to the TTL of the SIG The original TTL MUST be greater than or equal to the TTL of the SIG
record itself, since the TTL cannot be increased by intermediate record itself, since the TTL cannot be increased by intermediate
servers. This field can be ignored for SIG(0) records. servers. This field can be ignored for SIG(0) records.
2.5 - Signature Expiration and Inception 2.5 - Signature Expiration and Inception
The current time at the time of validation MUST lie within the validity The current time at the time of validation MUST lie within the
period bounded by the inception and expiration times. validity period bounded by the inception and expiration times.
2.6 - Key Tag 2.6 - Key Tag
There are no restrictions on the Key Tag field, although it is possible There are no restrictions on the Key Tag field, although it is
that future algorithms will impose contraints. possible that future algorithms will impose constraints.
2.7 - Signer's Name 2.7 - Signer's Name
The signer's name field of a data SIG MUST contain the name of the zone The signer's name field of a data SIG MUST contain the name of the
to which the data and signature belong. The combination of signer's zone to which the data and signature belong. The combination of
name, key tag, and algorithm MUST identify a zone key if the SIG is to signer's name, key tag, and algorithm MUST identify a zone key if the
be considered material. This document defines a standard policy for SIG is to be considered material. The only exception that the
DNSSEC validation; local policy may override the standard policy. signer's name field in a SIG KEY at a zone apex SHOULD contain the
parent zone's name, unless the KEY set is self-signed. This document
defines a standard policy for DNSSEC validation; local policy may
override the standard policy.
There are no restrictions on the signer field of a SIG(0) record. The There are no restrictions on the signer field of a SIG(0) record.
combination of signer's name, key tag, and algorithm MUST identify a key The combination of signer's name, key tag, and algorithm MUST
if this SIG(0) is to be processed. identify a key if this SIG(0) is to be processed.
2.8 - Signature 2.8 - Signature
There are no restrictions on the signature field. The signature will be There are no restrictions on the signature field. The signature will
verified at some point, but does not need to be examined prior to be verified at some point, but does not need to be examined prior to
verification unless a future algorithm imposes constraints. verification unless a future algorithm imposes constraints.
3 - The Signing KEY Record 3 - The Signing KEY Record
Once a signature has been examined and its fields validated (but before Once a signature has been examined and its fields validated (but
the signature has been verified), the resolver attempts to locate a KEY before the signature has been verified), the resolver attempts to
that matches the signer name, key tag, and algorithm fields in the SIG. locate a KEY that matches the signer name, key tag, and algorithm
If one is not found, the SIG cannot be verified and is considered fields in the SIG. If one is not found, the SIG cannot be verified
immaterial. If KEYs are found, several fields of the KEY record MUST and is considered immaterial. If KEYs are found, several fields of
have specific values if the SIG is to be considered material and the KEY record MUST have specific values if the SIG is to be
authorized. If there are multiple KEYs, the following checks are considered material and authorized. If there are multiple KEYs, the
performed on all of them, as there is no way to determine which one following checks are performed on all of them, as there is no way to
generated the signature until the verification is performed. determine which one generated the signature until the verification is
performed.
3.1 - Type Flags 3.1 - Type Flags
The signing KEY record MUST have a flags value of 00 or 01 The signing KEY record MUST have a flags value of 00 or 01
(authentication allowed, confidentiality optional) [RFC2535, 3.1.2]. A (authentication allowed, confidentiality optional) [RFC2535, 3.1.2].
DNSSEC resolver MUST only trust signatures generated by keys that are A DNSSEC resolver MUST only trust signatures generated by keys that
permitted to authenticate data. are permitted to authenticate data.
3.2 - Name Flags 3.2 - Name Flags
The interpretation of this field is considerably different for data SIGs The interpretation of this field is considerably different for data
and SIG(0) records. SIGs and SIG(0) records.
3.2.1 - Data SIG 3.2.1 - Data SIG
If the SIG record covers an RRset, the name type of the associated KEY If the SIG record covers an RRset, the name type of the associated
MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535, section KEY MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535,
2.3.6. The DNSSEC validation process performed by a resolver MUST section 2.3.6. The DNSSEC validation process performed by a resolver
ignore all keys that are not zone keys unless local policy dictates MUST ignore all keys that are not zone keys unless local policy
otherwise. dictates otherwise.
The primary reason that RFC 2535 allows host and user keys to generate The primary reason that RFC 2535 allows host and user keys to
material DNSSEC signatures is to allow dynamic update without online generate material DNSSEC signatures is to allow dynamic update
zone keys; that is, avoid storing private keys in an online server. The without online zone keys; that is, avoid storing private keys in an
desire to avoid online signing keys cannot be achieved, though, because online server. The desire to avoid online signing keys cannot be
they are necessary to sign NXT and SOA sets [SSU]. These online zone achieved, though, because they are necessary to sign NXT and SOA sets
keys can sign any incoming data. Removing the goal of having no online [RFC3007]. These online zone keys can sign any incoming data.
keys removes the reason to allow host and user keys to generate material Removing the goal of having no online keys removes the reason to
signatures. in the DNS. allow host and user keys to generate material signatures.
Limiting material signatures to zone keys simplifies the validation Limiting material signatures to zone keys simplifies the validation
process. The length of the verification chain is bounded by the name's process. The length of the verification chain is bounded by the
label depth. The authority of a key is clearly defined; a resolver does name's label depth. The authority of a key is clearly defined; a
not need to make a potentially complicated decision to determine whether resolver does not need to make a potentially complicated decision to
a key can sign data. amount of work to determine if all such keys have determine whether a key has the proper authority to sign data.
the proper authority.
Finally, there is no additional flexibility granted by allowing Finally, there is no additional flexibility granted by allowing
host/user key generated material signatures. As long as users and hosts host/user key generated material signatures. As long as users and
have the ability to authenticate update requests to the primary zone hosts have the ability to authenticate update requests to the primary
server, signatures by zone keys are sufficient to protect the integrity zone server, signatures by zone keys are sufficient to protect the
of the data to the world at large. integrity of the data to the world at large.
3.2.2 - SIG(0) 3.2.2 - SIG(0)
If the SIG record is a SIG(0) protecting a message, the name type of the If the SIG record is a SIG(0) protecting a message, the name type of
associated KEY SHOULD be 00 (user) or 10 (host/entity). Transactions the associated KEY SHOULD be 00 (user) or 10 (host/entity).
are initiated by a host or user, not a zone, so zone keys SHOULD not Transactions are initiated by a host or user, not a zone, so zone
generate SIG(0) records. keys SHOULD not generate SIG(0) records.
A client is either explicitly executed by a user or on behalf of a host, A client is either explicitly executed by a user or on behalf of a
therefore the name type of a SIG(0) generated by a client SHOULD be host, therefore the name type of a SIG(0) generated by a client
either user or host. A nameserver is associated with a host, and its SHOULD be either user or host. A nameserver is associated with a
use of SIG(0) is not associated with a particular zone, so the name type host, and its use of SIG(0) is not associated with a particular zone,
of a SIG(0) generated by a nameserver SHOULD be host. so the name type of a SIG(0) generated by a nameserver SHOULD be
host.
3.3 - Signatory Flags 3.3 - Signatory Flags
This document does not assign any values to the signatory field, nor This document does not assign any values to the signatory field, nor
require any values to be present. require any values to be present.
3.4 - Protocol 3.4 - Protocol
The signing KEY record MUST have a protocol value of 3 (DNSSEC) or 255 The signing KEY record MUST have a protocol value of 3 (DNSSEC) or
(ALL). If a key is not specified for use with DNSSEC, a DNSSEC resolver 255 (ALL). If a key is not specified for use with DNSSEC, a DNSSEC
MUST NOT trust any signature that it generates. resolver MUST NOT trust any signature that it generates.
3.5 - Algorithm Number 3.5 - Algorithm Number
The algorithm field MUST be identical to that of the generated SIG The algorithm field MUST be identical to that of the generated SIG
record, and MUST meet all requirements for an algorithm value in a SIG record, and MUST meet all requirements for an algorithm value in a
record. SIG record.
4 - Security considerations 4 - Security Considerations
This document defines a standard baseline for a DNSSEC capable resolver. This document defines a standard baseline for a DNSSEC capable
This is necessary for a thorough security analysis of DNSSEC, if one is resolver. This is necessary for a thorough security analysis of
to be done. DNSSEC, if one is to be done.
Specifically, this document places additional restrictions on SIG Specifically, this document places additional restrictions on SIG
records that a resolver must validate before the signature can be records that a resolver must validate before the signature can be
considered worthy of DNSSEC trust. This simplifies the protocol, making considered worthy of DNSSEC trust. This simplifies the protocol,
it more robust and able to withstand scrutiny by the security community. making it more robust and able to withstand scrutiny by the security
community.
5 - Acknowledgements 5 - Acknowledgements
The author would like to thank the following people for review and The author would like to thank the following people for review and
informative comments (in alphabetical order): informative comments (in alphabetical order):
Olafur Gudmundsson Olafur Gudmundsson
Ed Lewis Ed Lewis
6 - References 6 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC 1034, ISI, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification,'' RFC 1035, ISI, November 1987. Specification", STD 13, RFC 1035, November 1987.
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore Requirement Levels", BCP 14, RFC 2119, March 1997.
& Cisco & DEC, April 1997.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC [RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
2065, IBM, March 1999. "Dynamic Updates in the Domain Name System", RFC 2136,
April 1997.
[SSU] B. Wellington, ``Simple Secure Domain Name System (DNS) [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
Dynamic Update,'' draft-ietf-dnsext-simple-secure- RFC 2535, March 1999.
update-01.txt, Nominum, May 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s )", RFC 2931, September 2000.
[RFC3007] Wellington, B., "Simple Secure Domain Name System
(DNS) Dynamic Update", RFC 3007, November 2000.
7 - Author's Address 7 - Author's Address
Brian Wellington Brian Wellington
Nominum, Inc. Nominum, Inc.
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
+1 650 779 6022
<Brian.Wellington@nominum.com>
8 - Full Copyright Statement Phone: +1 650 381 6022
EMail: Brian.Wellington@nominum.com
Copyright (C) The Internet Society (2000). All Rights Reserved. 8 Full Copyright Statement
This document and translations of it may be copied and furnished to Copyright (C) The Internet Society (2000). All Rights Reserved.
others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be This document and translations of it may be copied and furnished to
revoked by the Internet Society or its successors or assigns. others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
This document and the information contained herein is provided on an "AS The limited permissions granted above are perpetual and will not be
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK revoked by the Internet Society or its successors or assigns.
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT This document and the information contained herein is provided on an
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
FITNESS FOR A PARTICULAR PURPOSE." TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 47 change blocks. 
185 lines changed or deleted 178 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/