draft-ietf-dnsext-signing-auth-00.txt   draft-ietf-dnsext-signing-auth-01.txt 
DNSIND Working Group Brian Wellington (NAILabs) DNSIND Working Group Brian Wellington (Nominum)
<draft-ietf-dnsext-signing-auth-00.txt> <draft-ietf-dnsext-signing-auth-01.txt>
Updates: RFC 2535 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 is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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
Comments should be sent to the authors or the DNSIND WG mailing list Comments should be sent to the authors or the DNSIND WG mailing list
namedroppers@internic.net. namedroppers@internic.net.
This draft expires on July 31, 2000. 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.
1 - Introduction 1 - Introduction
This document defines additional restrictions on DNSSEC signatures (SIG) This document defines additional restrictions on DNSSEC signatures (SIG)
records relating to their authority to sign associated data. The intent records relating to their authority to sign associated data. The intent
is to establish a standard policy followed by a secure resolver; this is to establish a standard policy followed by a secure resolver; this
policy can be augmented by local rules. This builds upon [RFC2535] and policy can be augmented by local rules. This builds upon [RFC2535],
updates section 2.3.6. 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 security
extensions [RFC2535] is assumed. 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
skipping to change at page 2, line 38 skipping to change at page 2, line 38
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 are
material; once a SIG is shown to be immaterial, no other validation is material; once a SIG is shown to be immaterial, no other validation is
necessary. 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 is
used to protect message integrity. This is referred to as a SIG(0). used to protect message integrity. This is referred to as a SIG(0)
[RFC2535].
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
skipping to change at page 3, line 41 skipping to change at page 3, line 41
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 possible
that future algorithms will impose contraints. that future algorithms will impose contraints.
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 zone
to which the data and signature belong. The combination of signer's to which the data and signature belong. The combination of signer's
name, key tag, and algorithm MUST identify a zone key if the SIG is to name, key tag, and algorithm MUST identify a zone key if the SIG is to
be considered material. As this document defines a standard policy, be considered material. This document defines a standard policy for
this can be overriden by local configuration. 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. The
combination of signer's name, key tag, and algorithm MUST identify a key combination of signer's name, key tag, and algorithm MUST identify a key
if this SIG(0) is to be processed. 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 be
verified at some point, but does not need to be examined prior to pre- 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 before
the signature has been verified), the resolver attempts to locate a KEY the signature has been verified), the resolver attempts to locate a KEY
that matches the signer name, key tag, and algorithm fields in the SIG. that matches the signer name, key tag, and algorithm fields in the SIG.
If one is not found, the SIG cannot be verified and is considered If one is not found, the SIG cannot be verified and is considered
immaterial. If KEYs are found, several fields of the KEY record MUST immaterial. If KEYs are found, several fields of the KEY record MUST
have specific values if the SIG is to be considered material and have specific values if the SIG is to be considered material and
authorized. If there are multiple KEYs, the following checks are authorized. If there are multiple KEYs, the following checks are
performed on all of them, as there is no way to determine which one performed on all of them, as there is no way to determine which one
generated the signature until the verification is performed. 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]. If (authentication allowed, confidentiality optional) [RFC2535, 3.1.2]. A
a key is not permitted to authenticate data, a DNSSEC resolver MUST NOT DNSSEC resolver MUST only trust signatures generated by keys that are
trust any signature that it generates. 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 SIGs
and SIG(0) records. 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 KEY
MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535, section MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535, section
2.3.6. The DNSSEC validation process performed by a resolver MUST 2.3.6. The DNSSEC validation process performed by a resolver MUST
ignore all keys that are not zone keys unless local policy dictates ignore all keys that are not zone keys unless local policy dictates
otherwise. otherwise.
The primary reason that host and/or user keys were allowed to generate The primary reason that RFC 2535 allows host and user keys to generate
material DNSSEC signatures was to allow dynamic update without online material DNSSEC signatures is to allow dynamic update without online
zone keys. The desire to avoid online signing keys cannot be achieved, zone keys; that is, avoid storing private keys in an online server. The
though, because they are necessary to sign NXT and SOA sets [SSU]. desire to avoid online signing keys cannot be achieved, though, because
These online zone keys can sign any incoming data, thus removing the they are necessary to sign NXT and SOA sets [SSU]. These online zone
need for host/user key signatures stored in the DNS. keys can sign any incoming data. Removing the goal of having no online
keys removes the reason to allow host and user keys to generate material
This simplifies the validation process. If data must be signed by a signatures. in the DNS.
zone key, determining whether a key is authorized to sign an RRset
requires finding the enclosing zone of the RRset, and following a chain Limiting material signatures to zone keys simplifies the validation
of trusted zone keys to a known trusted key (which may be the DNS root process. The length of the verification chain is bounded by the name's
key). If host and user keys were permitted to generate material label depth. The authority of a key is clearly defined; a resolver does
signatures, following a chain of trust to a trusted DNSSEC key could not need to make a potentially complicated decision to determine whether
involve any number of non-zone keys and a non-trivial amount of work to a key can sign data. amount of work to determine if all such keys have
determine if all such keys have the proper authority. 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 hosts
have the ability to authenticate update requests to the primary zone have the ability to authenticate update requests to the primary zone
server, signatures by zone keys are sufficient to protect the integrity server, signatures by zone keys are sufficient to protect the integrity
of the data to the world at large. 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 the
skipping to change at page 6, line 41 skipping to change at page 6, line 41
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
& Cisco & DEC, April 1997. & Cisco & DEC, April 1997.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC [RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC
2065, IBM, March 1999. 2065, IBM, March 1999.
[SSU] B. Wellington, ``Simple Secure Domain Name System (DNS) [SSU] B. Wellington, ``Simple Secure Domain Name System (DNS)
Dynamic Update,'' draft-ietf-dnsext-simple-secure- Dynamic Update,'' draft-ietf-dnsext-simple-secure-
update-00.txt, NAILabs, January 2000. update-01.txt, Nominum, May 2000.
7 - Author's Address 7 - Author's Address
Brian Wellington Brian Wellington
NAILabs Nominum, Inc.
Network Associates 950 Charter Street
3060 Washington Road (Rt. 97) Redwood City, CA 94063
Glenwood, MD 21738 +1 650 779 6022
+1 443 259 2369 <Brian.Wellington@nominum.com>
<bwelling@tislabs.com>
8 - Full Copyright Statement 8 - Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/