From 744c84229d07732200db965251d8fd94368bc3ca Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 20 Feb 2003 22:42:43 +0000 Subject: [PATCH] new draft --- .../draft-ietf-dnsext-dnssec-intro-04.txt | 1120 -------------- .../draft-ietf-dnsext-dnssec-intro-05.txt | 1288 +++++++++++++++++ ...ietf-dnsext-keyrr-key-signing-flag-06.txt} | 296 ++-- 3 files changed, 1464 insertions(+), 1240 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-intro-04.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-intro-05.txt rename doc/draft/{draft-ietf-dnsext-keyrr-key-signing-flag-05.txt => draft-ietf-dnsext-keyrr-key-signing-flag-06.txt} (61%) diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-04.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-04.txt deleted file mode 100644 index 370f9fbac6..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-intro-04.txt +++ /dev/null @@ -1,1120 +0,0 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: June 1, 2003 M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - December 2002 - - - DNS Security Introduction and Requirements - draft-ietf-dnsext-dnssec-intro-04 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - 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 June 1, 2003. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - The Domain Name System Security Extensions (DNSSEC) provide data - origin authentication and data integrity. This document introduces - these extensions and describes their capabilities and limitations. - The services that the security extensions provide and do not provide - are discussed. Lastly, the group of documents that describe the DNS - security extensions and their interrelationships is discussed. - - - -Arends, et al. Expires June 1, 2003 [Page 1] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 - 3. Services Provided by DNS Security . . . . . . . . . . . . . . 5 - 3.1 Data Origin Authentication and Data Integrity . . . . . . . . 5 - 3.2 Authenticating Name and Type Non-Existence . . . . . . . . . . 6 - 4. Services Not Provided by DNS Security . . . . . . . . . . . . 7 - 5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 8 - 6. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 6.1 TTL values vs. SIG validity period . . . . . . . . . . . . . . 10 - 6.2 New Temporal Issues for Zones . . . . . . . . . . . . . . . . 10 - 7. Server Considerations . . . . . . . . . . . . . . . . . . . . 11 - 8. DNS Security Document Family . . . . . . . . . . . . . . . . . 12 - 8.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . . 12 - 8.2 Categories of DNS Security Documents . . . . . . . . . . . . . 12 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 - Normative References . . . . . . . . . . . . . . . . . . . . . 17 - Informative References . . . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20 - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires June 1, 2003 [Page 2] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - -1. Introduction - - This document introduces the Domain Name System Security Extensions - (DNSSEC). This document and a collection of related documents update - RFC 2535 [3] and its related documents to further clarify and refine - the security extensions defined in RFC 2535. These security - extensions consist of a set of new resource record types and - modifications to the existing DNS protocol [2]. The new records and - protocol modifications are not fully described in this document, but - in a family of documents outlined in Section 8. The capabilities and - limitations of the security extensions are described in greater - detail in Section 3 and Section 4, respectively. - - These three documents update/obsolete RFC's: 2525, 3008, 3090, 3225, - 3226, 3445 and Internet Drafts: "Redefinition of the AD bit", - "Delegation Signer Resource Record", "DNSSEC Opt-In". See [18] for - more details of these documents. - - Lastly, the effect that these security extensions will have on - resolvers, zones and servers is discussed in Section 5, Section 6 and - Section 7, respectively. - - The DNS security extensions provide data origin authentication and - data integrity protection as well as a means of public key - distribution. The security extensions do not provide protection - against other types of attack, nor do they provide confidentiality. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires June 1, 2003 [Page 3] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - -2. Definitions of Important DNSSEC Terms - - authentication key: A public key, for a zone or a host, that a - resolver trusts and that can therefore be used to verify data. A - key can become trusted in two ways: First, it can be statically - configured and declared in the resolver's initial configuration. - Second, if a new key is referenced by a DS record that is signed - by an already known authentication key, and the signature - verifies, the new key becomes trusted by the resolver. - - key signing key: Described in [14] An authentication key that is only - used to sign a DNSSEC authentication key. The zone authentication - key may be changed frequently (according to local policy), while - the key signing key is used as a more static secure entry point - for the zone. Designating a key signing key is an operational - issue only, the key is treated the same way as an authentication - key by the DNS. - - authentication chain: In DNSSEC, a key signs a DS record, which - points to another key (or key signing key), which in turn signs - another DS record, which points to yet another key, etc. - Eventually ending with a key that has generated a SIG over a RR - set. This alternating succession of KEY and DS records forms a - chain of signed data, with each link in the chain vouching for the - next. A resolver starting at a piece of data in the chain signed - by a known authentication key can verify all subsequent - signatures. Thus all subsequent data in the chain is verified and - authenticated. - - security-aware resolver: A resolver (defined in section 2.4 of [1]) - that understands the DNS security extensions defined in this - document set. In particular, a security-aware resolver uses known - authentication keys to verify signatures over RRsets and - (optionally) DNS messages. - - security-aware server: A name server (also defined in section 2.4 of - [1]) that understands the DNS security extensions. In particular, - it supports the KEY, SIG, DS and NXT record types, a larger DNS - message size via EDNS0, and other protocol changes such as support - for the OK bit. Also called a "secure server". - - unsecure server: The proper term for the opposite of a security-aware - server. - - signed zone: A zone whose RRsets are signed and which contains - properly constructed KEY, SIG, NXT and (optionally) DS records. - - unsigned zone: The proper term for the opposite of a secure zone. - - - -Arends, et al. Expires June 1, 2003 [Page 4] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - -3. Services Provided by DNS Security - - The Domain Name System (DNS) protocol security extensions provide - data origin authentication and data integrity assurance. In - addition, a means of providing an authenticated denial of existence - is provided, as described below. - - These services protect against the threats to the Domain Name System - described in [11]. - -3.1 Data Origin Authentication and Data Integrity - - Authentication is provided by cryptographically generated digital - signatures associated with DNS RRsets. These digital signatures are - stored in a new resource record, the SIG record. Typically, there - will be a single private key that signs a zone's data, but multiple - keys are possible; e.g., for different digital signature algorithms. - If a security-aware resolver reliably learns a zone's public key, it - can authenticate that zone's signed data. An important DNSSEC - concept is that the key that signs a zone's data is associated with - the zone itself and not with the zone's authoritative servers - (although hosts/services can also have key pairs in DNSSEC; see the - reference to SIG(0) in [7] ). Security-aware servers attempt to send - the signature(s) needed to authenticate an RRset in the DNS reply - message along with the RRset itself, provided there is space - available in the message. - - A resolver could learn a zone's public key by having the key - statically configured or by normal DNS resolution. To allow the - latter, public keys are stored in a new resource record, the KEY - record. Note that the private keys used to sign zone data must be - kept secure and best practices call for them to be stored offline. - To reliably discover a public key by DNS resolution, the key itself - needs to be signed by either a statically configured authentication - key or another key that has been previously authenticated. Zone - information is authenticated by forming a chain from a newly learned - public key back to a previously known authentication public key - (which is either statically configured or previously learned and - verified). Therefore, the resolver must be configured with at least - one public key (either a zone signing key or key signing key) that - authenticates one zone (or zone key, in the case of a key signing - key) as a starting point. To establish this authentication chain, - security-aware servers attempt to send the signature(s) needed to - authenticate a zone's public key in the DNS reply message along with - the public key itself, provided there is space available in the - message. - - The authentication chain specified in the original DNS security - - - -Arends, et al. Expires June 1, 2003 [Page 5] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - - extensions proceeded from signed KEY record to signed KEY record, as - necessary, and finally to the queried RRset. A new record, the - delegation signer (DS), has been added for additional flexibility. - The DS RRset resides at a delegation point in a parent zone and - specifies the keys used by the specified child zone to self-sign the - KEY RRset at its apex. The child, in turn, uses one of these keys to - sign its zone data. The authentication chain is therefore DS->KEY- - >[DS->KEY->...]->RRset. - - This authentication chain is normally constructed "top down" (i.e. - from the root "." to the leaf zones). However, this is base DNSSEC - protocol only. Local policy on authentication of RR sets may - override this policy. Ultimately, authentication is a matter of - local, resolver policy which may extend, or even override the - protocol extensions defined in this document set. - - Adding data origin authentication and data integrity requires minor - changes to the on-the-wire DNS protocol. Four new resource record - types are required: SIG, KEY, DS and NXT. EDNS0 support [4] for - larger message sizes [9] is required, as is support for the OK bit - [8]. EDNS0 support is required for the larger DNS message sizes that - result when DNSSEC RRs are added. Support for the OK bit (part of - EDNS0) is required for a security aware resolver to indicate that it - is security-aware and wishes for DNSSEC RR types to be added to the - response. - -3.2 Authenticating Name and Type Non-Existence - - The security mechanism referenced above in Section 3.1 only provides - a way to sign existing RRsets in a zone. The problem of providing - negative responses with the same level of authentication and - integrity requires the use of another new resource record, the non- - existence (NXT) record. The NXT record allows a negative reply - (either for name or type non-existence) to be authenticated the same - way as other DNS replies. NXT records require a canonical - representation and order for domain names in zones. NXT records - exist to cover the gaps, or "empty space", between domain names in a - zone, as well as non-existent record types for existing names. Each - NXT record is signed and authenticated in the same way as any other - RRset. - - - - - - - - - - - -Arends, et al. Expires June 1, 2003 [Page 6] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - -4. Services Not Provided by DNS Security - - The DNS design philosophy calls for all DNS data to be public and - uniform answers to all inquirers. Accordingly, confidentiality for - queries or responses is not provided, nor are any sort of access - control lists or other means to differentiate inquirers. - - There is no protection against denial of service attacks. Security- - aware resolvers and security-aware servers are vulnerable to another - class of DoS based on cryptographic operations. See the Security - Considerations section below. - - The DNSSEC extensions provide data and origin authentication of DNS - data. No protection is extended to operations such as zone transfers - and dynamic update [16]. Message authentication schemes described in - [5] and [7] address security operations that pertain to these - transactions. - - Signed zone data and/or the use of transaction authentication will - not protect against errors in DNS zone information or servers - incorrectly interpreting and/or setting DNS message header fields. - The security extensions cannot insure the correctness of DNS - information. - - Ultimately, final authentication is a matter of local policy. A - local policy might extend or override the protocol extensions defined - in this document set. - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires June 1, 2003 [Page 7] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - -5. Resolver Considerations - - A security-aware resolver needs to be able to perform necessary - cryptographic functions to verify digital signatures using at least - the mandatory-to-implement algorithms. Security-aware resolvers must - also be capable of forming a authentication chain from a newly - learned zone back to a authentication key (as defined above). This - process might require additional queries of intermediate DNS zones - for necessary KEY, DS and SIG records. It is assumed that a - security-aware resolver will be configured with at least one - authentication key to establish an authentication chain. - - The stub resolver found in many hosts may be augmented to provide a - different set of security features instead of the full security - awareness found in a security-aware resolver. The use of transaction - authentication (i.e. SIG(0) or TSIG) could help secure the final - message passing between a security-aware DNS server and a stub - resolver. This a matter of local security policy. Note that - transaction authentication changes the DNS protocol. Using SIG(0) or - TSIG keys means that DNS clients now can have identity and are no - longer anonymous. Possession of a key used for transaction - authentication could allow a security aware server to identify a - resolver and segregate resolvers it accepts queries from. - - A security aware stub resolver ought to be configured to make use of - a security aware full resolver (e.g. part of a security-aware - caching server) and to communicate with it using some form of - integrity protection for queries and responses. Examples of - integrity protection are transaction authentication schemes as - defined in the context of DNS and/or IPsec to protect all traffic - from the stub resolver's host to the host of a security aware full - resolver. - - If a security aware full resolver is configured to forward queries to - another full resolver, the latter is recommended to be security aware - also. If not, the security aware resolver might not be able to - obtain the data needed to make a security determination. A security - aware resolver ought to be capable of contacting the authoritative - servers directly, but do so with the consideration of performance - impacts. - - If a security aware resolver is separated from authoritative servers - by a caching resolver that is not security aware, it is possible that - the security aware resolver will only be able to operate in an - insecure mode. For example, if a security aware resolver's packets - are routed through a device (such as a Network Address Translator) - that acts as a DNS proxy and is not security aware, it might not be - possible to deliver secured responses. This is because the base DNS - - - -Arends, et al. Expires June 1, 2003 [Page 8] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - - protocol does not provide means to remotely manage intermediate DNS - caches, hence, it is possible that some data may be 'stuck' or - dropped in the cache and prevent construction of the authentication - chain by the client resolver. - - If an unsecure server or an unsigned zone results in a break in the - authentication chain, the resolver cannot ensure security. If a - security-aware resolver must rely on an unsecure server (or unsigned - zone) that cannot supply the necessary security RRs, the resolver - cannot verify DNS responses and should rely on local policy when - accepting responses. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires June 1, 2003 [Page 9] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - -6. Zone Considerations - - A secure zone will have several differences from an unsigned zone. A - secure zone will contain additional security-related records (SIG, - KEY, DS and NXT records). SIG and NXT records may be generated by a - signing process prior to serving the zone. Zone data is only valid - and considered secure for a definable time period. The SIG records - that accompany zone data have defined inception and expiration times. - These times establish a validity period for the signatures and the - zone data the signatures cover. - -6.1 TTL values vs. SIG validity period - - It is important to note the distinction between an RRset's TTL value - and the signature validity period specified in the SIG RR covering an - RRset. DNSSEC does not change the definition of the TTL value, which - is intended to maintain database coherency in caches: stale RRsets - are purged from caches after the period of time defined in the TTL - field. - - The inception and expiration fields in the SIG RR [12], on the other - hand, specify the time period when the signature can be used to - validate its covering RRset. Zone data is only (cryptographically) - valid and secure (pending verification of the signature) for a - specific time period and these fields establish the time period that - a given signature covers the RRset. The TTL value should not be used - to artificially extend the validity period of signed RR sets in a - cache, but the signature validity period may decrease the TTL of - signed RRsets in a cache. - -6.2 New Temporal Issues for Zones - - With the addition of the security extensions, zone information now - has a temporal factor that did not previously exist in the DNS - protocol. The signature validity period is a time period for which - an RRset can be considered valid, and applies only to the specific - RRset, not to the zone as a whole. A signed zone requires regular - maintenance to ensure each RRset in the zone has a temporally valid - SIG RR. This might also require a "zone load" which will be defined - as an increase in a SOA serial number, indicating a zone change has - occurred and may cause zone transfers to take place (IXFR or AXFR). - - - - - - - - - - -Arends, et al. Expires June 1, 2003 [Page 10] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - -7. Server Considerations - - A security-aware server must be capable of performing the following - operations in addition to the normal operations of a DNS server - described in [2]: - - A security-aware server should make all attempts to include - necessary security-related records (SIG, KEY, DS and NXT) in - responses as DNS message space permits. - - A caching (i.e. recursive) security-aware server should also take - a signature's validation period into consideration when - determining the time to live (TTL) of cached data: signed data - should not be cached beyond the signature validity period. - - All means of restricting query, zone transfer, dynamic update and - administrative access to an authoritative security-aware server - fall under the category of operational security and are not - addressed by the DNS security extensions. Such issues fall under - the need for transaction security (see [5] and [7] ). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires June 1, 2003 [Page 11] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - -8. DNS Security Document Family - - The DNSSEC set of documents can be partitioned into five main groups - as depicted in Figure 1. All these documents are in turn under the - larger umbrella of the DNS base protocol documents described in [18]. - -8.1 DNS Security Document Roadmap - - --------------------------------------------------------------------- - - - +--------------------------------+ - | | - | Base DNS Protocol Docs | - | [RFC1035, RFC2181, etc.] | - | | - +--------------------------------+ - | - | - +-----------+ +-------------+ - | DNSSEC | | New | - | Protocol |--------->| Security | - | Documents | | Uses | - +-----------+ +-------------+ - | - | - +---------------- - - - - - - -+ - | . - | . - +------------+ +---------------+ - | Dig. Sig. | | | - | Algorithm | | Transaction | - | Impl. | | Impl. | - | | | | - +------------+ +---------------+ - - Figure 1: DNSSEC Document Roadmap - - --------------------------------------------------------------------- - - -8.2 Categories of DNS Security Documents - - The "DNSSEC protocol document set" refers to the three documents that - form the core of the DNS security extensions: - - 1. DNS Security Introduction and Requirements (this document) - - - - -Arends, et al. Expires June 1, 2003 [Page 12] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - - 2. Resource Records for DNS Security Extensions [12] - - 3. Protocol Modifications for the DNS Security Extensions [13] - - The "Dig. Sig. Algorithm Impl." document set refers to the group of - documents that describe how specific digital signature algorithms - should be implemented to fit the DNSSEC resource record format. Each - of these documents deals with a specific digital signature algorithm. - - The "Transaction Impl." document set refers to the group of documents - that deal with DNS message authentication, including secret key - establishment and verification. While not strictly part of the DNS - Security specification as defined in this set of documents, it should - be included here to note its relationship to the DNS Security - extensions. - - The final document set, "New Security Uses", refers to documents that - seek to use proposed DNS Security extensions for other security - related purposes. The DNSSEC extensions does not provide any direct - security for these new uses, by may be used to support them. - Documents that fall in this category include the use of DNS in the - storage and distribution of certificates [15] and individual user - public keys (PGP, e-mail, etc.) [17]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires June 1, 2003 [Page 13] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - -9. IANA Considerations - - This document introduces no new IANA considerations. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires June 1, 2003 [Page 14] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - -10. Security Considerations - - This document introduces the DNS security extensions and describes - the document set that contains the new security records and DNS - protocol modifications. The capabilities and limitations of these - extensions are discussed. The extensions provide data origin - authentication and data integrity using digital signatures over - resource record sets. - - In order for a secure resolver to validate a DNS response, all the - intermediate zones and servers must be capable of DNS security - processing as defined in this document set. A security-aware - resolver cannot verify responses originating from an unsigned zone or - a zone served by a non-security-aware server. If there is a break in - the authentication chain (i.e., no authentication key can be - obtained), then a security aware resolver cannot verify those DNS - responses. Other methods of adding security to a DNS query such as - using a secure channel (e.g. IPSec tunnel, etc.) or using - transaction authentication over DNS messages are not discussed in - these documents. Local security policy may extend or override the - protocol modifications described in this document set. - - The DNS security extensions do not protect against denial of service - (DoS) attacks or provide confidentiality. The DNSSEC extensions does - open a new class of cryptographic based class of DoS attacks against - a security-aware resolver or security-aware server. These attacks - attempt to occupy a system's resources with cryptographic operations. - - There is now also the ability to enumerate all the names in a zone by - following the NXT chain. The NXT RR indicates which names do not - exist in a zone by linking a name to the next canonical name in a - zone. A resolver can query these NXT RRs to obtain all the hostnames - in a zone. While this might not be considered an attack to the - public DNS, this could allow a mapping of network hosts by - enumerating the contents of a zone. - - - - - - - - - - - - - - - - -Arends, et al. Expires June 1, 2003 [Page 15] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - -11. Acknowledgements - - This document was created from the input and ideas of several members - of the DNS Extensions Working Group. The authors would like to - acknowledge (in alphabetical order) the following people for their - contributions and comments on this document: - - Derek Atkins - Rob Austein - Donald Eastlake - Miek Gieben - Olafur Gudmundsson - Olaf Kolkman - Ed Lewis - Ted Lindgreen - Bill Manning - Brian Wellington - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires June 1, 2003 [Page 16] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - -Normative References - - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [3] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [4] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - - [5] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - - [6] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC - 2930, September 2000. - - [7] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [8] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, - December 2001. - - [9] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - - [10] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource - Record (RR)", RFC 3445, December 2002. - - [11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name - System", draft-ietf-dnsext-dns-threats-02 (work in progress), - February 2002. - - [12] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource - Records for DNS Security Extensions", draft-ietf-dnsext-dnssec- - records-02 (work in progress), November 2002. - - [13] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol - Modifications for the DNS Security Extensions", draft-ietf- - dnsext-dnssec-protocol-00 (work in progress), October 2002. - - [14] Kolkman, O. and J. Schlyter, "KEY RR Key Signing Key (KSK) - Flag", draft-ietf-dnsext-keyrr-key-signing-flag-05 (work in - progress), December 2002. - - - -Arends, et al. Expires June 1, 2003 [Page 17] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - -Informative References - - [15] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the - Domain Name System (DNS)", RFC 2538, March 1999. - - [16] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [17] Schlyter, J., "Storing application public keys in the DNS", - draft-schlyter-appkey-02 (work in progress), February 2002. - - [18] Rose, S., "DNS Security Document Roadmap", draft-ietf-dnsext- - dnssec-roadmap-06 (work in progress), November 2001. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy@logmess.com - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - - - - - - - -Arends, et al. Expires June 1, 2003 [Page 18] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires June 1, 2003 [Page 19] - -Internet-Draft DNSSEC Intro. and Requirements December 2002 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - 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. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - 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. - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires June 1, 2003 [Page 20] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-05.txt new file mode 100644 index 0000000000..7eee7845d3 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-intro-05.txt @@ -0,0 +1,1288 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: August 15, 2003 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + February 14, 2003 + + + DNS Security Introduction and Requirements + draft-ietf-dnsext-dnssec-intro-05 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + 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 August 15, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + The Domain Name System Security Extensions (DNSSEC) add data origin + authentication and data integrity to the Domain Name System. This + document introduces these extensions, and describes their + capabilities and limitations. This document also discusses the + + + +Arends, et al. Expires August 15, 2003 [Page 1] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + + services that the DNS security extensions do and do not provide. + Last, this document describes the interrelationships between the + group of documents that collectively describe DNSSEC. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 + 3. Services Provided by DNS Security . . . . . . . . . . . . . . 6 + 3.1 Data Origin Authentication and Data Integrity . . . . . . . . 6 + 3.2 Authenticating Name and Type Non-Existence . . . . . . . . . . 7 + 4. Services Not Provided by DNS Security . . . . . . . . . . . . 9 + 5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 10 + 6. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 11 + 7. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 7.1 TTL values vs. SIG validity period . . . . . . . . . . . . . . 12 + 7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 12 + 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 13 + 9. DNS Security Document Family . . . . . . . . . . . . . . . . . 14 + 9.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . . 14 + 9.2 Categories of DNS Security Documents . . . . . . . . . . . . . 14 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 + Normative References . . . . . . . . . . . . . . . . . . . . . 20 + Informative References . . . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23 + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 2] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +1. Introduction + + This document introduces the Domain Name System Security Extensions + (DNSSEC). This document and its two companion documents ([13] and + [14]) update, clarify, and refine the security extensions originally + defined in RFC 2535 [3]. These security extensions consist of a set + of new resource record types and modifications to the existing DNS + protocol [2]. The new records and protocol modifications are not + fully described in this document, but are described in a family of + documents outlined in Section 9. Section 3 and Section 4 describe + the capabilities and limitations of the security extensions in + greater detail. Section 5, Section 6, Section 7, and Section 8 + discuss the effect that these security extensions will have on + resolvers, stub resolvers, zones and name servers. + + This document and its two companions update and obsolete RFCs 2535, + 3008, 3090, 3225, 3226, and 3445, as well as several works in + progress: "Redefinition of the AD bit", "Delegation Signer Resource + Record", and "DNSSEC Opt-In". See [18] for more details on these + documents. + + The DNS security extensions provide origin authentication and + integrity protection for DNS data, as well as a means of public key + distribution. These extensions do not provide protection against + other types of attack, nor do they provide confidentiality. + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 3] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +2. Definitions of Important DNSSEC Terms + + authentication chain: In the DNSSEC model, a KEY RR signs a DS RR, + which hashes one RR in another KEY RRset, which in turn signs + another DS RR, which hashes one RR in yet another KEY RRset, and + so forth, finally ending, if all goes well, with a KEY RR which + signs whatever DNS data the end user was looking for in the first + place. This alternating succession of KEY RRsets and DS RRs forms + a chain of signed data, with each link in the chain vouching for + the next. If a signature somewhere in this chain has been + generated by an authentication key known to a security-aware + resolver, then the resolver can attempt to verify and authenticate + the signed chain of KEY and DS RRs from that point down to the + target data. + + authentication key: A public key which a security-aware resolver + trusts and can therefore use to verify data. A security-aware + resolver can discover trusted authentication keys in three ways. + First, the resolver is generally preconfigured to know about at + least one key which it should trust. Second, the resolver may be + able to discover both a new key and an associated DS RR which + contains a valid hash of the new key and which has been signed by + a key which the resolver trusts. Third, the resolver may be able + to determine that a new key has been signed by another key which + the resolver trusts. Note that the resolver must always be guided + by local policy when deciding whether to trust a new key, even if + the local policy is simply to trust any new key for which the + resolver is able verify the signature. + + key signing key: An authentication key which is used to sign one or + more other authentication keys. Typically, a key signing key will + sign a zone signing key, which in turn will sign other zone data. + Local policy may require the zone signing key to be changed + frequently, while the key signing key may have a longer validity + period in order to provide a more stable secure entry point into + the zone. Designating an authentication key as a key signing key + is purely an operational issue: DNSSEC itself does not distinguish + between key signing keys and other DNSSEC authentication keys. + Key signing keys are discussed in more detail in [12]. + + security-aware name server: An entity acting in the role of a name + server (defined in section 2.4 of [1]) which understands the DNS + security extensions defined in this document set. In particular, + a security-aware name server is an entity which receives DNS + queries, sends DNS responses, supports the EDNS0 [4] message size + extension and the DO bit [8], and supports the RR types and + message header bits defined in this document set. + + + + +Arends, et al. Expires August 15, 2003 [Page 4] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + + security-aware recursive name server: An entity which acts in both + the security-aware name server and security-aware resolver roles. + A more cumbersome equivalent phrase would be "a security-aware + name server which offers recursive service". + + security-aware resolver: An entity acting in the role of a resolver + (defined in section 2.4 of [1]) which understands the DNS security + extensions defined in this document set. In particular, a + security-aware resolver is an entity which sends DNS queries, + receives DNS responses, supports the EDNS0 [4] message size + extension and the DO bit [8], and is capable of using the RR types + and message header bits defined in this document set to provide + DNSSEC services. + + security-aware stub resolver: An entity acting in the role of a + resolver (defined in section 2.4 of [1]) which has at least a + minimal understanding the DNS security extensions defined in this + document set, but which trusts one or more security-aware + recursive name servers to perform most of the tasks discussed in + this document set on its behalf. In particular, a security-aware + stub resolver is an entity which sends DNS queries, receives DNS + responses, and is capable of establishing an appropriately secured + channel to a security-aware recursive name server which will + provide these services on behalf of the security-aware stub + resolver. Note that the distinction between security-aware + resolvers and security-aware stub resolvers is different from the + distinction between iterative-mode and recursive-mode resolvers in + the base DNS specification: a particular security-aware resolver + may operate exclusively in recursive mode, but still performs its + own DNSSEC signature validity checks, while a security-aware stub + resolver does not, by definition. + + security-oblivious: The opposite of "security-aware". + + signed zone: A zone whose RRsets are signed and which contains + properly constructed KEY, SIG, NXT and (optionally) DS records. + + unsigned zone: The opposite of a "signed zone". + + zone signing key: An authentication key which is used to sign a zone. + See key signing key, above. Typically a zone signing key will be + part of the same KEY RRset as the key signing key which signs it, + but is used for a slightly different purpose and may differ from + the key signing key in other ways, such as validity lifetime. + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 5] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +3. Services Provided by DNS Security + + The Domain Name System (DNS) security extensions provide origin + authentication and integrity assurance services for DNS data, + including mechanisms for authenticated denial of existence of DNS + data. These mechanisms are described below. + + These mechanisms require minor changes to the DNS protocol. DNSSEC + adds four new resource record types (SIG, KEY, DS and NXT) and two + new message header bits (CD and AD). In order to support the larger + DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also + requires EDNS0 support [4]. Finally, DNSSEC requires support for the + DO bit [8], so that a security-aware resolver can indicate in its + queries that it wishes to receive DNSSEC RRs in response messages. + + These services protect against most of the threats to the Domain Name + System described in [11]. + +3.1 Data Origin Authentication and Data Integrity + + DNSSEC provides authentication by associating cryptographically + generated digital signatures with DNS RRsets. These digital + signatures are stored in a new resource record, the SIG record. + Typically, there will be a single private key that signs a zone's + data, but multiple keys are possible: for example, there may be keys + for each of several different digital signature algorithms. If a + security-aware resolver reliably learns a zone's public key, it can + authenticate that zone's signed data. An important DNSSEC concept is + that the key that signs a zone's data is associated with the zone + itself and not with the zone's authoritative name servers (public + keys for DNS transaction authentication mechanisms may also appear in + zones, as described in [7], but DNSSEC itself is concerned with + object security of DNS data, not channel security of DNS + transactions). + + A security-aware resolver can learn a zone's public key either by + having the key preconfigured into the resolver or by normal DNS + resolution. To allow the latter, public keys are stored in a new + type of resource record, the KEY RR. Note that the private keys used + to sign zone data must be kept secure, and should be stored offline + when practical to do so. To discover a public key reliably via DNS + resolution, the target key itself needs to be signed by either a + preconfigured authentication key or another key that has been + authenticated previously. Security-aware resolvers authenticate zone + information by forming an authentication chain from a newly learned + public key back to a previously known authentication public key, + which in turn either must have been preconfigured into the resolver + or must have been learned and verified previously. Therefore, the + + + +Arends, et al. Expires August 15, 2003 [Page 6] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + + resolver must be configured with at least one public key: if the + preconfigured key is a zone signing key, then it will authenticate + the associated zone; if the preconfigured key is a key signing key, + it will authenticate a zone signing key. To help security-aware + resolvers establish this authentication chain, security-aware name + servers attempt to send the signature(s) needed to authenticate a + zone's public key in the DNS reply message along with the public key + itself, provided there is space available in the message. + + The authentication chain specified in the original DNS security + extensions proceeded from signed KEY record to signed KEY record, as + necessary, and finally to the queried RRset. The current + specification adds a new Delegation Signer (DS) RR type to simplify + some of the administrative tasks involved in signing delegations + across organizational boundaries. The DS RRset resides at a + delegation point in a parent zone and indicates the key or keys used + by the delegated child zone to self-sign the KEY RRset at the child + zone's apex. The child zone, in turn, uses one or more of the keys + in this KEY RRset to sign its zone data. The authentication chain is + therefore KEY->[DS->KEY]*->RRset, where "*" denotes zero or more DS- + >KEY subchains. + + This authentication chain is normally constructed from the root of + the DNS hierarchy down to the leaf zones, and is normally based on + preconfigured knowledge of the public key for the root. Local + policy, however, may also allow a security-aware resolver to trust + one or more preconfigured keys other than the root key, or may not + provide preconfigured knowledge of the root key, or may even prevent + the resolver from trusting particular keys for arbitrary reasons even + if those keys are properly signed with verifiable signatures. DNSSEC + provides mechanisms by which a security-aware resolver can determine + whether an RRset's signature is "valid" within the meaning of DNSSEC, + but authentication and trust, in the final analysis, are matters of + local policy, which may extend or even override the protocol + extensions defined in this document set. + +3.2 Authenticating Name and Type Non-Existence + + The security mechanism described in Section 3.1 only provides a way + to sign existing RRsets in a zone. The problem of providing negative + responses with the same level of authentication and integrity + requires the use of another new resource record type, the NXT record. + The NXT record allows a security-aware resolver to authenticate a + negative reply for either name or type non-existence via the same + mechanisms used to authenticate other DNS replies. Use of NXT + records require a canonical representation and ordering for domain + names in zones. Chains of NXT records explicitly describe the gaps, + or "empty space", between domain names in a zone, as well as listing + + + +Arends, et al. Expires August 15, 2003 [Page 7] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + + the types of RRsets present at existing names. Each NXT record is + signed and authenticated using the mechanisms described in Section + 3.1. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 8] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +4. Services Not Provided by DNS Security + + DNS was originally designed with the assumptions that the DNS will + return the same answer to any given query regardless of who may have + issued the query, and that all data in the DNS is thus visible. + Accordingly, DNSSEC is not designed to provide confidentiality, + access control lists, or other means of differentiating between + inquirers. + + DNSSEC provides no protection against denial of service attacks. + Security-aware resolvers and security-aware name servers are + vulnerable to an additional class of denial of service attacks based + on cryptographic operations. Please see Section 11 for details. + + The DNS security extensions provide data and origin authentication + for DNS data. The mechanisms outlined above extend no protection to + operations such as zone transfers and dynamic update [16]. Message + authentication schemes described in [5] and [7] address security + operations that pertain to these transactions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 9] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +5. Resolver Considerations + + A security-aware resolver needs to be able to perform necessary + cryptographic functions to verify digital signatures using at least + the mandatory-to-implement algorithms. Security-aware resolvers must + also be capable of forming a authentication chain from a newly + learned zone back to a authentication key, as described above. This + process might require additional queries to intermediate DNS zones to + obtain necessary KEY, DS and SIG records. A security-aware resolver + should be configured with at least one authentication key as the + starting point from which it will attempt to establish authentication + chains. + + If a security-aware resolver is separated from the relevant + authoritative name servers by a recursive name server or by any sort + of device which acts as a proxy for DNS, and if the recursive name + server or proxy is not security-aware, the security-aware resolver + may not be able to operate in a secure mode. For example, if a + security-aware resolver's packets are routed through a network + address translation device that includes a DNS proxy which is not + security-aware the security-aware resolver may find it difficult or + impossible to obtain or validate signed DNS data. + + If a security-aware resolver must rely on an unsigned zone or a name + server that is not security aware, the resolver may not be able to + validate DNS responses, and will need a local policy on whether to + accept unverified responses. + + A security-aware resolver should take a signature's validation period + into consideration when determining the TTL of data in its cache, to + avoid caching signed data beyond the validity period of the + signature, but should also allow for the possibility that the + security-aware resolver's own clock is wrong. Thus, a security-aware + resolver which is part of a security-aware recursive name server will + need to pay careful attention to the DNSSEC "checking disabled" (CD) + bit [13] in order to avoid blocking valid signatures from getting + through to other security-aware resolvers which are clients of this + recursive name server and which are capable of performing their own + DNSSEC validity checks. + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 10] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +6. Stub Resolver Considerations + + Although not strictly required to do so by the protocol, most DNS + queries originate from stub resolvers. Stub resolvers, by + definition, are minimal DNS resolvers which use recursive query mode + to offload most of the work of DNS resolution to a recursive name + server. Given the widespread use of stub resolvers, the DNSSEC + architecture has to take stub resolvers into account, but the + security features needed in a stub resolver differ in some respects + from those needed in a full security-aware resolver. + + Even an unaugmented stub resolver may get some benefit from DNSSEC if + the recursive name servers it uses are security-aware, but for the + stub resolver to place any real reliance on DNSSEC services, the stub + resolver must trust both the recursive name servers in question and + the communication channels between itself and those name servers. + The first of these issues is a local policy issue: in essence, a stub + resolver has no real choice but to place itself at the mercy of the + recursive name servers that it uses, since it does not perform DNSSEC + validity checks on its own. The second issue requires some kind of + channel security mechanism; proper use of DNS transaction + authentication mechanisms such as SIG(0) or TSIG would suffice, as + would appropriate use of IPsec, and particular implementations may + have other choices available, such as operating system specific + interprocess communication mechanisms. Confidentiality is not needed + for this channel, but data integrity and message authentication are. + + {{AD bit currently ratholed, update this when its fate is settled}} + + There is one more step which a security-aware stub resolver can take + if, for whatever reason, it is not able to establish a useful trust + relationship with the recursive name servers which it uses: it can + perform its own signature validation, by setting the Checking + Disabled (CD) bit in its query messages. Upon taking this step, the + resolver is no longer really a stub resolver at all anymore (in the + terminology used in this document set, anyway), and is now a + security-aware resolver with somewhat limited functionality. + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 11] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +7. Zone Considerations + + There are several differences between signed and unsigned zones. A + signed zone will contain additional security-related records (SIG, + KEY, DS and NXT records). SIG and NXT records may be generated by a + signing process prior to serving the zone. The SIG records that + accompany zone data have defined inception and expiration times, + which establish a validity period for the signatures and the zone + data the signatures cover. + +7.1 TTL values vs. SIG validity period + + It is important to note the distinction between an RRset's TTL value + and the signature validity period specified by the SIG RR covering + that RRset. DNSSEC does not change the definition or function of the + TTL value, which is intended to maintain database coherency in + caches. A caching resolver purges RRsets from its cache no later + than the end of the time period specified by the TTL fields of those + RRsets, regardless of whether or not the resolver is security-aware. + + The inception and expiration fields in the SIG RR [13], on the other + hand, specify the time period during which the signature can be used + to validate the RRset that it covers. The signatures associated with + signed zone data are only valid for the time period specified by + these fields in the SIG RRs in question. TTL values cannot extend + the validity period of signed RRsets in a resolver's cache, but the + resolver may use the time remaining before expiration of the + signature validity period of a signed RRset as an upper bound for the + TTL of the signed RRset and its associated SIG RR in the resolver's + cache. + +7.2 New Temporal Dependency Issues for Zones + + Information in a signed zone has a temporal dependency which did not + exist in the original DNS protocol. A signed zone requires regular + maintenance to ensure that each RRset in the zone has a current valid + SIG RR. The signature validity period of a SIG RR is a interval + during which the signature for one particular signed RRset can be + considered valid, and the signatures of different RRsets in a zone + may expire at different times. Re-signing one or more RRsets in a + zone will change one or more SIG RRs, which in turn will require + incrementing the zone's SOA serial number to indicate that a zone + change has occurred and re-signing the SOA RRset itself. Thus, re- + signing any RRset in a zone may also trigger DNS NOTIFY messages and + zone transfers operations. + + + + + + +Arends, et al. Expires August 15, 2003 [Page 12] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +8. Name Server Considerations + + A security-aware name server should include the appropriate DNSSEC + records (SIG, KEY, DS and NXT) in all responses to queries from + resolvers which have signaled their willingness to receive such + records via use of the DO bit in the EDNS header, subject to message + size limitations. For this reason a security-aware name server must + support the EDNS mechanism size extension, since otherwise inclusion + of DNSSEC RRs could easily cause UDP message truncation and fallback + to TCP. + + If possible, the private half of each DNSSEC key pair should be kept + offline, but this will not be possible for a zone for which DNS + dynamic update has been enabled. In the dynamic update case, the + primary master server for the zone will have to re-sign the zone when + updated, so the private half of the zone signing key will have to be + kept online. This is an example of a situation where the ability to + separate the zone's KEY RRset into zone signing key(s) and key + signing key(s) may be useful, since the key singing key(s) in such a + case can still be kept offline. + + DNSSEC, by itself, is not enough to protect the integrity of an + entire zone during zone transfer operations, since even a signed zone + contains some unsigned data, so zone maintenance operations will + require some additional mechanisms (most likely some form of channel + security, such as TSIG, SIG(0), or IPsec). + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 13] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +9. DNS Security Document Family + + The DNSSEC set of documents can be partitioned into five main groups + as depicted in Figure 1. All these documents are in turn under the + larger umbrella of the DNS base protocol documents described in [18]. + +9.1 DNS Security Document Roadmap + + --------------------------------------------------------------------- + + + +----------------------------------+ + | Base DNS Protocol Documents | + | [RFC1035, RFC2181, et sequentia] | + +----------------------------------+ + | + | + +-----------+ +----------+ + | DNSSEC | | New | + | Protocol |--------->| Security | + | Documents | | Uses | + +-----------+ +----------+ + | + | + +---------------- - - - - - - -+ + | . + | . + +------------------+ . + | Digital | +------------------+ + | Signature | | Transaction | + | Algorithm | | Authentication | + | Implementations | | Implementations | + +------------------+ +------------------+ + + Figure 1: DNSSEC Document Roadmap + + --------------------------------------------------------------------- + + +9.2 Categories of DNS Security Documents + + The "DNSSEC protocol document set" refers to the three documents + which form the core of the DNS security extensions: + + 1. DNS Security Introduction and Requirements (this document) + + 2. Resource Records for DNS Security Extensions [13] + + + + +Arends, et al. Expires August 15, 2003 [Page 14] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + + 3. Protocol Modifications for the DNS Security Extensions [14] + + The "Digital Signature Algorithm Implementations" document set refers + to the group of documents that describe how specific digital + signature algorithms should be implemented to fit the DNSSEC resource + record format. Each of these documents deals with a specific digital + signature algorithm. + + The "Transaction Authentication Implementations" document set refers + to the group of documents that deal with DNS message authentication, + including secret key establishment and verification. While not + strictly part of the DNSSEC specification as defined in this set of + documents, this group is noted to show its relationship to DNSSEC. + + The final document set, "New Security Uses", refers to documents that + seek to use proposed DNS Security extensions for other security + related purposes. DNSSEC does not provide any direct security for + these new uses, but may be used to support them. Documents that fall + in this category include the use of DNS in the storage and + distribution of certificates [15] and individual user public keys + (PGP, e-mail, and so forth) [17]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 15] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +10. IANA Considerations + + This document introduces no new IANA considerations. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 16] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +11. Security Considerations + + This document introduces the DNS security extensions and describes + the document set that contains the new security records and DNS + protocol modifications. This document discusses the capabilities and + limitations of these extensions. The extensions provide data origin + authentication and data integrity using digital signatures over + resource record sets. + + In order for a security-aware resolver to validate a DNS response, + all of the intermediate zones must be signed, and all of the + intermediate name servers must be security-aware, as defined in this + document set. A security-aware resolver cannot verify responses + originating from an unsigned zone, from a zone not served by a + security-aware name server, or for any DNS data which the resolver is + only able to obtain through a recursive name server which is not + security-aware. If there is a break in the authentication chain such + that a security-aware resolver cannot obtain and validate the + authentication keys it needs, then the security-aware resolver cannot + validate the affected DNS data. + + This document briefly discusses other methods of adding security to a + DNS query, such as using a channel secured by IPsec or using a DNS + transaction authentication mechanism, but transaction security is not + part of DNSSEC per se. + + A security-aware stub resolver, by definition, does not perform + DNSSEC signature validation on its own, and thus is vulnerable both + to attacks on (and by) the security-aware recursive name servers + which perform these checks on its behalf and also to attacks on its + communication with those security-aware recursive name servers. + Security-aware stub resolvers should use some form of channel + security to defend against the latter threat. The only known defense + against the former threat would be for the security-aware stub + resolver to perform its own signature validation, at which point, + again by definition, it would no longer be a security-aware stub + resolver. + + DNSSEC does not protect against denial of service attacks. DNSSEC + makes DNS vulnerable to a new class of denial of service attacks + based on cryptographic operations against security-aware resolvers + and security-aware name servers, since an attacker can attempt to use + DNSSEC mechanisms to consume a victim's resources. This class of + attacks takes at least two forms. An attacker may be able to consume + resources in a security-aware resolver's signature validation code by + tampering with SIG RRs in response messages or by constructing + needlessly complex signature chains. An attacker may also be able to + consume resources in a security-aware name server which supports DNS + + + +Arends, et al. Expires August 15, 2003 [Page 17] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + + dynamic update, by sending a stream of update messages that force the + security-aware name server to re-sign some RRsets in the zone more + frequently than would otherwise be necessary. + + DNSSEC add the ability for a hostile party to enumerate all the names + in a zone by following the NXT chain. NXT RRs assert which names do + not exist in a zone by linking from existing name to existing name + along a canonical ordering of all the names within a zone. Thus, an + attacker can query these NXT RRs in sequence to obtain all the names + in a zone. While not an attack on the DNS itself, this could allow + an attacker to map network hosts or other resources by enumerating + the contents of a zone. + + DNSSEC does not provide confidentiality, due to a deliberate design + choice. + + DNSSEC does not protect against tampering with unsigned zone data. + Non-authoritative data at zone cuts (glue and NS RRs in the parent + zone) are not signed. Thus, while DNSSEC can provide data origin + authentication and data integrity for RRsets, it cannot do so for + zones, and other mechanisms must be used to protect zone transfer + operations. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 18] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +12. Acknowledgements + + This document was created from the input and ideas of several members + of the DNS Extensions Working Group. The authors would like to + acknowledge (in alphabetical order) the following people for their + contributions and comments on this document: + + Derek Atkins + Donald Eastlake + Miek Gieben + Olafur Gudmundsson + Olaf Kolkman + Ed Lewis + Ted Lindgreen + Bill Manning + Brian Wellington + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 19] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [4] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. + + [5] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + + [6] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC + 2930, September 2000. + + [7] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [8] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, + December 2001. + + [9] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + [10] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + Record (RR)", RFC 3445, December 2002. + + [11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name + System", draft-ietf-dnsext-dns-threats-02 (work in progress), + February 2002. + + [12] Kolkman, O. and J. Schlyter, "KEY RR Key Signing Key (KSK) + Flag", draft-ietf-dnsext-keyrr-key-signing-flag-05 (work in + progress), December 2002. + + [13] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource + Records for DNS Security Extensions", draft-ietf-dnsext-dnssec- + records-02 (work in progress), November 2002. + + [14] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol + Modifications for the DNS Security Extensions", draft-ietf- + dnsext-dnssec-protocol-00 (work in progress), October 2002. + + + +Arends, et al. Expires August 15, 2003 [Page 20] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +Informative References + + [15] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the + Domain Name System (DNS)", RFC 2538, March 1999. + + [16] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [17] Schlyter, J., "Storing application public keys in the DNS", + draft-schlyter-appkey-02 (work in progress), February 2002. + + [18] Rose, S., "DNS Security Document Roadmap", draft-ietf-dnsext- + dnssec-roadmap-06 (work in progress), November 2001. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Software Consortium + 40 Gavin Circle + Reading, MA 01867 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 21] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 22] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + 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. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + 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. + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 23] + diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-05.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt similarity index 61% rename from doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-05.txt rename to doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt index c0116581fa..dba5f909f8 100644 --- a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-05.txt +++ b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt @@ -2,16 +2,16 @@ DNS Extensions O. Kolkman Internet-Draft RIPE NCC -Expires: July 4, 2003 J. Schlyter +Expires: August 18, 2003 J. Schlyter Carlstedt Research & Technology E. Lewis ARIN - January 3, 2003 + February 17, 2003 KEY RR Key-Signing Key (KSK) Flag - draft-ietf-dnsext-keyrr-key-signing-flag-05 + draft-ietf-dnsext-keyrr-key-signing-flag-06 Status of this Memo @@ -19,13 +19,12 @@ Status of this Memo all provisions of Section 10 of RFC2026. 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. + 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 + 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:// @@ -34,27 +33,28 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 4, 2003. + This Internet-Draft will expire on August 18, 2003. Copyright Notice - Copyright (C) The Internet Society (2003). All Rights Reserved. + Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract - With the DS resource record the concept of key-signing and zone- - signing keys has been introduced. During key-exchanges with the - parent there is a need to differentiate between these zone- and key- - signing keys. We propose a flag to indicate which key is used as + With the DS resource record the concept of key-signing and + zone-signing keys has been introduced. During key-exchanges with the + parent there is a need to differentiate between these zone- and + key-signing keys. We propose a flag to indicate which key is used as key-signing key. -Kolkman, et al. Expires July 4, 2003 [Page 1] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003 + +Kolkman, et al. Expires August 18, 2003 [Page 1] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 Table of Contents @@ -65,18 +65,19 @@ Table of Contents 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 - 7. Internationalization Considerations . . . . . . . . . . . . . 6 + 7. Internationalization Considerations . . . . . . . . . . . . . 5 8. Document Changes . . . . . . . . . . . . . . . . . . . . . . . 6 8.1 draft version 00 -> 01 . . . . . . . . . . . . . . . . . . . . 6 8.2 draft version 01 -> 02 . . . . . . . . . . . . . . . . . . . . 6 8.3 draft version 02 -> 03 . . . . . . . . . . . . . . . . . . . . 6 8.4 draft version 03 -> 04 . . . . . . . . . . . . . . . . . . . . 6 - 8.5 draft version 04 -> 05 . . . . . . . . . . . . . . . . . . . . 7 + 8.5 draft version 04 -> 05 . . . . . . . . . . . . . . . . . . . . 6 + 8.6 draft version 05 -> 06 . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 Normative References . . . . . . . . . . . . . . . . . . . . . 7 - Informative References . . . . . . . . . . . . . . . . . . . . 7 + Informative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 + Intellectual Property and Copyright Statements . . . . . . . . 9 @@ -107,10 +108,9 @@ Table of Contents +Kolkman, et al. Expires August 18, 2003 [Page 2] -Kolkman, et al. Expires July 4, 2003 [Page 2] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003 +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 1. Introduction @@ -164,47 +164,47 @@ Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003 -Kolkman, et al. Expires July 4, 2003 [Page 3] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003 +Kolkman, et al. Expires August 18, 2003 [Page 3] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 2. The Key-Signing Key (KSK) Flag + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | flags |K| protocol | algorithm | + | |S| | | + | |K| | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | flags |K| protocol | algorithm | - | |S| | | - | |K| | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / public key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + KEY RR Format - KEY RR Format - - - - The KSK bit (TBD) in the flags field is assigned to be the key- - signing key flag. If the the bit is set to 1 the key is intended to - be used as key-signing key. No special meaning should be assigned to - the bit is set to 0. The draft proposes using the current 15th bit - [1] as the KSK bit. This way operators can recognize the key-signing - by the even or odd-ness of the decimal representation of the flag - field. + The KSK bit (TBD) in the flags field is assigned to be the + key-signing key flag. If the the bit is set to 1 the key is intended + to be used as key-signing key. One SHOULD NOT assign special meaning + to the key if the bit is set to 0. The document proposes using the + current 15th bit [1] as the KSK bit. This way operators can recognize + the key-signing by the even or odd-ness of the decimal representation + of the flag field. 3. DNSSEC Protocol Changes - The use of the KSK flag does not change the DNS resolution and - resolution protocol. The KSK flag is only used to provide a hint - about the different administrative properties and MUST NOT be used - during the resolving and verification process. + The bit MUST NOT be used during the resolving and verification + process. The KSK flag is only used to provide a hint about the + different administrative properties of the key and therefore the use + of the KSK flag does not change the DNS resolution and resolution + protocol. 4. Operational Guidelines + The KSK bit is set by the key-generator and used by the zone signer: + The KSK bit is used to indicate that the key represented in the KEY RR is intended to sign the KEY RR set of the zone. As the KSK bit is within the data that is used to compute a KEY RR's footprint, @@ -216,21 +216,21 @@ Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003 parent zone to build the authentication chain or if the public key is to be distributed for static configuration in verifiers. - When signing a zone, it is intended that a key with the KSK bit set + When signing a zone, it is intended that the key(s) with the KSK bit -Kolkman, et al. Expires July 4, 2003 [Page 4] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003 +Kolkman, et al. Expires August 18, 2003 [Page 4] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 - be used to sign the KEY RR set of the zone. The same key can be used - to sign the rest of the zone data too. It is conceivable that not - all keys with a KSK bit set will sign the KEY RR set, such keys might - be pending retirement or not yet in use. + set (if such keys exist) are used to sign the KEY RR set of the zone. + The same key can be used to sign the rest of the zone data too. It + is conceivable that not all keys with a KSK bit set will sign the KEY + RR set, such keys might be pending retirement or not yet in use. - When verifying an RR set, the KSK bit is not intended to play a role. + When verifying a RR set, the KSK bit is not intended to play a role. How the key is used by the verifier is not intended to be a consideration at key creation time. @@ -238,17 +238,17 @@ Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003 trusted root, administrators can choose to ignore the flag when configuring a trusted root for their resolvers. - Using the flag a key roll over can be automated. The parent can use + Using the flag a key roll over can be automated. The parent can use an existing trust relation to verify key sets in which a new key with the KSK flag appears. 5. Security Considerations As stated in Section 3 the flag is not to used in the resolution - protocol or to determine the security status of a key. The flag is - to be used for administrative purposes only. + protocol or to determine the security status of a key. The flag is to + be used for administrative purposes only. - No trust in a key should be inferred from this flag - trust must be + No trust in a key should be inferred from this flag - trust MUST be inferred from an existing chain of trust or an out-of-band exchange. Since this flag might be used for automating key exchanges, we think @@ -260,30 +260,28 @@ Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003 to the parent. The parent verifies the key set with the existing trust relation and creates the new DS RR from the key that the current DS is not pointing to. This key exchange might be replayed. - Parents are encouraged to implement a replay defence. A simple + Parents are encouraged to implement a replay defence. A simple defence can be based on a registry of keys that have been used to generate DS RRs during the most recent roll over. 6. IANA Considerations draft-ietf-dnsext-restrict-key-for-dnssec [1] eliminates all flags - field except for the zone key flag in the KEY RR. We propose to use + field except for the zone key flag in the KEY RR. We propose to use the 15'th bit as the KSK bit; the decimal representation of the flagfield will then be odd for key-signing keys. - - - - - -Kolkman, et al. Expires July 4, 2003 [Page 5] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003 - - 7. Internationalization Considerations - There are no internationalization considerations + + + +Kolkman, et al. Expires August 18, 2003 [Page 5] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 + + + There are no internationalization considerations. 8. Document Changes @@ -295,8 +293,8 @@ Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003 Added explicit warning for replay attacks to the security section; - Removed the text that hinted on a distinction between a key- - signing key configured in resolvers and in parent zones. + Removed the text that hinted on a distinction between a + key-signing key configured in resolvers and in parent zones. 8.2 draft version 01 -> 02 @@ -317,29 +315,42 @@ Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003 suggest to use a particular type of registry and that it is clear that a key registry is only one of the defences possible. - Spelling and style corrections + Spelling and style corrections. 8.4 draft version 03 -> 04 - Text has been made consistent with the statement: ' No special + Text has been made consistent with the statement: 'No special meaning should be assigned to the bit not being set.' Made explicit that the keytag changes in SIG RR. - - - - -Kolkman, et al. Expires July 4, 2003 [Page 6] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003 - - 8.5 draft version 04 -> 05 - References and acronyms where stripped from the Abstract. the + One occurrence of must and one occurrence of should uppercased + + + +Kolkman, et al. Expires August 18, 2003 [Page 6] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 + + + (RFC2119). + + Reordering of sentences in section 3, so that the point of the bit + NOT being used in resolving is made directly. + + To make explicit that the KSK is used at key generation and at + signing time I added the first sentence to section 4. + + Some minor style and spelling corrections. + + +8.6 draft version 05 -> 06 + + References and acronyms where stripped from the Abstract. the Introduction and the the Operational Guideline section were rewritten in such a way that the draft does not suggest any use of the bit in the verification process and that the draft does not @@ -352,8 +363,8 @@ Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003 9. Acknowledgements - The ideas documented in this draft are inspired by communications we - had with numerous people and ideas published by other folk. Among + The ideas documented in this document are inspired by communications + we had with numerous people and ideas published by other folk. Among others Mark Andrews, Olafur Gudmundsson, Daniel Karrenberg, Dan Massey, Marcos Sanz and Sam Weiler have contributed ideas and provided feedback. @@ -374,25 +385,26 @@ Normative References 2535, March 1999. [4] Lewis, E., "DNS Security Extension Clarification on Zone + + + +Kolkman, et al. Expires August 18, 2003 [Page 7] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 + + Status", RFC 3090, March 2001. Informative References - [5] Gudmundsson, O., "Delegation Signer Resource Record", draft- - ietf-dnsext-delegation-signer-12 (work in progress), December - 2002. + [5] Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-12 (work in progress), + December 2002. [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy Story"", ISBN 0151002177 (50th anniversery edition), April 1996. - - -Kolkman, et al. Expires July 4, 2003 [Page 7] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003 - - Authors' Addresses Olaf M. Kolkman @@ -432,33 +444,44 @@ Authors' Addresses +Kolkman, et al. Expires August 18, 2003 [Page 8] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 +Intellectual Property Statement + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. - - - - - - - - -Kolkman, et al. Expires July 4, 2003 [Page 8] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003 + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. Full Copyright Statement - Copyright (C) The Internet Society (2003). All Rights Reserved. + Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to 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 + 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 @@ -468,15 +491,24 @@ Full Copyright Statement English. The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. + revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Kolkman, et al. Expires August 18, 2003 [Page 9] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 + + 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 @@ -500,5 +532,29 @@ Acknowledgement -Kolkman, et al. Expires July 4, 2003 [Page 9] - + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Expires August 18, 2003 [Page 10] +