From 82e3c7f81e22e4a8c5595cbee9e8c20b128ffb80 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 6 Feb 2003 20:49:37 +0000 Subject: [PATCH] new draft --- .../draft-ietf-dnsext-dnssec-intro-03.txt | 1064 ---------------- .../draft-ietf-dnsext-dnssec-intro-04.txt | 1120 +++++++++++++++++ ...> draft-ietf-dnsext-dnssec-roadmap-07.txt} | 317 +++-- 3 files changed, 1306 insertions(+), 1195 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-intro-03.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-intro-04.txt rename doc/draft/{draft-ietf-dnsext-dnssec-roadmap-06.txt => draft-ietf-dnsext-dnssec-roadmap-07.txt} (74%) diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-03.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-03.txt deleted file mode 100644 index 570e1edd3d..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-intro-03.txt +++ /dev/null @@ -1,1064 +0,0 @@ - - -DNS Extensions R. Arends -Internet-Draft -Expires: April 24, 2003 M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - October 24, 2002 - - - DNS Security Introduction and Requirements - draft-ietf-dnsext-dnssec-intro-03 - -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 April 24, 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 April 24, 2003 [Page 1] - -Internet-Draft DNSSEC Intro. and Requirements October 2002 - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [1]. - -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.1.1 Authenticating Name and Type Non-Existence . . . . . . . . . 6 - 3.2 Key Distribution . . . . . . . . . . . . . . . . . . . . . . 6 - 3.3 Transaction Security . . . . . . . . . . . . . . . . . . . . 7 - 4. Services Not Provided by DNS Security . . . . . . . . . . . 8 - 5. Resolver Considerations . . . . . . . . . . . . . . . . . . 9 - 6. Zone Considerations . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 19 - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 24, 2003 [Page 2] - -Internet-Draft DNSSEC Intro. and Requirements October 2002 - - -1. Introduction - - This document introduces the Domain Name System Security Extensions - (DNSSEC). This document and a collection of related documents update - RFC 2535 [2] 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 [3]. 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. 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 April 24, 2003 [Page 3] - -Internet-Draft DNSSEC Intro. and Requirements October 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. - - authentication path: In DNSSEC, a key signs a DS record, which points - to another key, which in turn signs another DS record, which - points to yet another key, etc. 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 [4]) - that understands the DNS security extensions. 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 - [4]) 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. - - unsigned zone: The proper term for the opposite of a secure zone. - - signed zone: A zone whose RRsets are signed and which contains - properly constructed KEY, SIG, NXT and (optionally) DS records. - - - - - - - - - - - - - - -Arends, et al. Expires April 24, 2003 [Page 4] - -Internet-Draft DNSSEC Intro. and Requirements October 2002 - - -3. Services Provided by DNS Security - - The Domain Name System (DNS) protocol security extensions provide - three distinct services: Data origin authentication and data - integrity, key distribution, and transaction security, as described - below. - - These services protect against the threats to the Domain Name System - described in [5]. - -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 can also have key pairs in DNSSEC; see the reference - to SIG(0) in Section 3.3 below). 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 (see Section 3.2 below). (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 that authenticates one zone - 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 - extensions proceeded from signed KEY record to signed KEY record, as - - - -Arends, et al. Expires April 24, 2003 [Page 5] - -Internet-Draft DNSSEC Intro. and Requirements October 2002 - - - 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. - - Adding data origin authentication and data integrity requires minor - changes to the on-the-wire DNS protocol. Several new resource record - types are required, including the aforementioned SIG, KEY and DS. - EDNS0 support [6] for larger message sizes [7] is required, as is - support for the OK bit [8]. - -3.1.1 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. - -3.2 Key Distribution - - The KEY resource record is defined to associate public keys with DNS - names. This record permits the DNS to be used as a public key - distribution mechanism in support of DNSSEC. Security-aware - resolvers can query for a zone's public key when establishing a - authentication chain. - - The syntax of the KEY resource record (and the other additional - resource records required for DNSSEC) is described in [9]. It - includes identifiers for the algorithm the key is used for and - information on the entity the key is associated with. - - The original DNSSEC specification allowed other protocols and - applications to use the KEY record as a general-purpose mechanism to - store public keys. For reasons documented in [10], the KEY record is - now restricted for use with DNSSEC only. Work is in progress on - storing public keys [14] and certificates [15] used by other - protocols and applications in the DNS. A secure DNS tree could then - - - -Arends, et al. Expires April 24, 2003 [Page 6] - -Internet-Draft DNSSEC Intro. and Requirements October 2002 - - - be used as a lightweight key distribution mechanism that could - support other protocols. However, this should not lead to the - conclusion that the DNS is then safe to use as a trusted protocol or - a Public Key Infrastructure. DNSSEC lacks many features found in a - PKI such as a Certificate Revocation List (CRL). - -3.3 Transaction Security - - The data origin authentication and data integrity service described - above authenticates retrieved RRsets and the non-existence of RRsets, - but provides no protection for complete DNS messages, e.g., when they - occur in zone transfers and dynamic updates. - - A DNS message can be authenticated by including a special signature - RR at the end of the message, either a transaction signature (TSIG) - [11] or SIG record with a type covered field of zero (a "SIG(0)", see - [12]). Such a signature can be used to verify the integrity of the - DNS message. (The signature record in the additional section of a - query may produce an error or simply be ignored by older DNS - implementations that don't support transaction security.) Unlike the - mechanism described in Section 3.1, transaction security is specific - to the individual hosts exchanging DNS messages. The cryptographic - keys used with transaction security are associated with individual - hosts and not DNS zones. - - In addition to transaction signatures, there is also support for key - agreement protocols to support transaction security using symmetric - encryption keys. This service uses the transaction key (TKEY) [13] - resource record. The use of the TKEY record in a key agreement - transaction depends on the algorithm used, and each key agreement - protocol is described in a separate document specific to each - algorithm. - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 24, 2003 [Page 7] - -Internet-Draft DNSSEC Intro. and Requirements October 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. - - Denial of service is not protected against. - - Signed zone data and/or the use of transaction signatures will not - protect against errors in DNS zone information or servers incorrectly - interpreting and/or setting DNS message header fields. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 24, 2003 [Page 8] - -Internet-Draft DNSSEC Intro. and Requirements October 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. Also, security-aware - resolvers must be capable of forming a authentication chain from a - newly learned zone back to a trusted authentication key. This might - require additional queries to 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 - aid this process. - - 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 complete resolver. The use of transaction - security could help secure the final message passing between a - recursive DNS server and a stub resolver. This a matter of local - security policy. - - A security-aware resolver needs to communicate with only security- - aware servers. If an unsecure server or an unsigned/unsecure zone is - part of the DNS resolution path, the resolver cannot ensure security. - If a security-aware resolver must rely on an unsecure server (or - unsigned zone), the resolver cannot verify DNS responses and should - rely on local policy when following responses. - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 24, 2003 [Page 9] - -Internet-Draft DNSSEC Intro. and Requirements October 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. If SIG and NXT records - are not present in the zone, an authoritative server needs to - generate them before 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 24, 2003 [Page 10] - -Internet-Draft DNSSEC Intro. and Requirements October 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 [3]: - - 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 security-aware caching server must 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. - - A security-aware server should have a means of employing - transaction security, such as transaction signatures (TSIG) or - SIG(0). Transaction security is primarily used when performing - other DNS operations such as zone transfers and dynamic updates - (if they are permitted according to the server's local policy). - - All other means of restricting query, zone transfer, dynamic - update and administrative access to a security-aware server fall - under the category of operational security and are not addressed - by the DNS security extensions. - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 24, 2003 [Page 11] - -Internet-Draft DNSSEC Intro. and Requirements October 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 [16]. - -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 April 24, 2003 [Page 12] - -Internet-Draft DNSSEC Intro. and Requirements October 2002 - - - 2. Resource Records for DNS Security Extensions [9] - - 3. Protocol Modifications for the DNS Security Extensions (not yet - published) [12] - - The "Dig. Sig. Algorithm Impl." document set refers to the group of - documents that describe how a specific digital signature algorithm is - 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 transaction security, including secret key - establishment and verification. - - The final document set, "New Security Uses", refers to documents that - seek to use proposed DNS Security extensions for other security - related purposes. 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.) [14]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 24, 2003 [Page 13] - -Internet-Draft DNSSEC Intro. and Requirements October 2002 - - -9. IANA Considerations - - This document introduces no new IANA considerations. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 24, 2003 [Page 14] - -Internet-Draft DNSSEC Intro. and Requirements October 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 records and (optionally) DNS messages. - - In order for a secure resolver to validate a DNS response, all the - intermediate zones and servers must be capable of DNS security - processing. A security-aware resolver cannot verify responses sent - by an non-security-aware server. - - The DNS security extensions do not protect against denial of service - (DoS) attacks or provide confidentiality. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 24, 2003 [Page 15] - -Internet-Draft DNSSEC Intro. and Requirements October 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 April 24, 2003 [Page 16] - -Internet-Draft DNSSEC Intro. and Requirements October 2002 - - -Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [3] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [4] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [5] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name - System", draft-ietf-dnsext-dns-threats-01 (work in progress), - February 2002. - - [6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - - [7] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - - [8] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, - December 2001. - - [9] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource - Records for DNS Security Extensions", draft-ietf-dnsext-dnssec- - records-00 (work in progress), March 2002. - - [10] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource - Record", draft-ietf-dnsext-restrict-key-for-dnssec-02 (work in - progress), March 2002. - - [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - - [12] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol - Modifications for the DNS Security Extensions (Not yet - published)", draft-ietf-dnsext-dnssec-protocol-00 (work in - progress), to be published in 2002. - - [13] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC - 2930, September 2000. - - - - - -Arends, et al. Expires April 24, 2003 [Page 17] - -Internet-Draft DNSSEC Intro. and Requirements October 2002 - - -Informative References - - [14] Schlyter, J., "Storing application public keys in the DNS", - draft-schlyter-appkey-02 (work in progress), February 2002. - - [15] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the - Domain Name System (DNS)", RFC 2538, March 1999. - - [16] Rose, S., "DNS Security Document Roadmap", draft-ietf-dnsext- - dnssec-roadmap-05 (work in progress), November 2001. - - -Authors' Addresses - - Roy Arends - Bankastraat 41-E - 1094 EB Amsterdam - 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 - - - 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 April 24, 2003 [Page 18] - -Internet-Draft DNSSEC Intro. and Requirements October 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 April 24, 2003 [Page 19] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-04.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-04.txt new file mode 100644 index 0000000000..370f9fbac6 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-intro-04.txt @@ -0,0 +1,1120 @@ + + +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-roadmap-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-roadmap-07.txt similarity index 74% rename from doc/draft/draft-ietf-dnsext-dnssec-roadmap-06.txt rename to doc/draft/draft-ietf-dnsext-dnssec-roadmap-07.txt index f20ac7dc55..b56f293cea 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-roadmap-06.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-roadmap-07.txt @@ -2,11 +2,11 @@ DNS Extensions S. Rose Internet-Draft NIST -Expires: March 6, 2003 September 5, 2002 +Expires: August 5, 2003 February 4, 2003 DNS Security Document Roadmap - draft-ietf-dnsext-dnssec-roadmap-06 + draft-ietf-dnsext-dnssec-roadmap-07 Status of this Memo @@ -29,11 +29,11 @@ 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 March 6, 2003. + This Internet-Draft will expire on August 5, 2003. Copyright Notice - Copyright (C) The Internet Society (2002). All Rights Reserved. + Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract @@ -52,9 +52,9 @@ Abstract -Rose Expires March 6, 2003 [Page 1] - -Internet-Draft DNSSEC Document Roadmap September 2002 +Rose Expires August 5, 2003 [Page 1] + +Internet-Draft DNSSEC Document Roadmap February 2003 Table of Contents @@ -70,9 +70,10 @@ Table of Contents 4.4 The Use of DNS Security Extensions with Other Protocols . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 + Normative References . . . . . . . . . . . . . . . . . . . . . 13 + Informative References . . . . . . . . . . . . . . . . . . . . 15 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16 @@ -107,10 +108,9 @@ Table of Contents - -Rose Expires March 6, 2003 [Page 2] - -Internet-Draft DNSSEC Document Roadmap September 2002 +Rose Expires August 5, 2003 [Page 2] + +Internet-Draft DNSSEC Document Roadmap February 2003 1. Introduction @@ -119,14 +119,14 @@ Internet-Draft DNSSEC Document Roadmap September 2002 of supplemental documents describing security extensions to the Domain Name System (DNS). - The main goal of the DNS Security (DNSSEC) protocol extensions is to - add data authentication and integrity services to the DNS protocol. - These protocol extensions should be differentiated from DNS - operational security issues, which are beyond the scope of this - effort. DNS Security documents fall into one or possibly more of the - following sub-categories: new DNS security resource records, - implementation details of specific digital signing algorithms for use - in DNS Security and Secure DNS transactions. Since the goal of DNS + The main goal of the DNS Security (DNSSEC) extensions is to add data + authentication and integrity services to the DNS protocol. These + protocol extensions should be differentiated from DNS operational + security issues, which are beyond the scope of this effort. DNS + Security documents fall into one or possibly more of the following + sub-categories: new DNS security resource records, implementation + details of specific digital signing algorithms for use in DNS + Security and DNS transaction authentication. Since the goal of DNS Security extensions is to become part of the DNS protocol standard, additional documents that seek to refine a portion of the security extensions will be introduced as the specifications progress along @@ -146,12 +146,10 @@ Internet-Draft DNSSEC Document Roadmap September 2002 important to securing a DNS zone, but they do not directly address the proposed DNS security extensions. Authors of documents that seek to address the operational concerns of DNS security should be aware - of the structure of DNS Security documentation if they wish to - include their documents in the DNSEXT Working Group in addition to - the DNS Operations WG. + of the structure of DNS Security documentation. It is assumed the reader has some knowledge of the Domain Name System - [2] and the Domain Name System Security Extensions [1]. + [2] and the Domain Name System Security Extensions. @@ -164,9 +162,11 @@ Internet-Draft DNSSEC Document Roadmap September 2002 -Rose Expires March 6, 2003 [Page 3] -Internet-Draft DNSSEC Document Roadmap September 2002 + +Rose Expires August 5, 2003 [Page 3] + +Internet-Draft DNSSEC Document Roadmap February 2003 2. Interrelationship of DNS Security Documents @@ -220,9 +220,9 @@ Internet-Draft DNSSEC Document Roadmap September 2002 -Rose Expires March 6, 2003 [Page 4] - -Internet-Draft DNSSEC Document Roadmap September 2002 +Rose Expires August 5, 2003 [Page 4] + +Internet-Draft DNSSEC Document Roadmap February 2003 --------------------------------------------------------------------- @@ -247,8 +247,8 @@ Internet-Draft DNSSEC Document Roadmap September 2002 | | +----------------------+*********************** - | | * - | | * + | * * + | * * +------------+ +---------------+ +-*-*-*-*-*-*-*-*-+ | DS | | | | Implementation | | Algorithm | | Transactions | * Notes * @@ -266,40 +266,43 @@ Internet-Draft DNSSEC Document Roadmap September 2002 up the groundwork for adding security to the DNS protocol [1]and updates to this document. RFC 2535 laid out the goals and expectations of DNS Security and the new security-related Resource - Records KEY, SIG, DS [19] and NXT. Expanding from this document, + Records KEY, SIG, DS, and NXT [23]. Expanding from this document, related document groups include the implementation documents of various digital signature algorithms with DNSSEC, and documents further refining the transaction of messages. It is expected that RFC 2535 will be obsoleted by one or more documents that refine the - set of security extensions and DNS security transactions [22], [23], - [24]. Documents that seek to modify or clarify the base protocol + set of security extensions [22], [23], [24]. Documents that seek to + modify or clarify the base protocol documents should state so clearly -Rose Expires March 6, 2003 [Page 5] - -Internet-Draft DNSSEC Document Roadmap September 2002 +Rose Expires August 5, 2003 [Page 5] + +Internet-Draft DNSSEC Document Roadmap February 2003 - documents should state so clearly in the introduction of the document - (as well as proscribe to the IETF guidelines of RFC/Internet Draft - author guidelines). Also, the portions of the specification to be - modified should be synopsized in the new document for the benefit of - the reader. The "DNSSEC protocol" set includes the documents [1], - [11], [12], [9], [14], [15], [21], [20], [OPTIN], [16] and their - derivative documents. + in the introduction of the document (as well as proscribe to the IETF + guidelines of RFC/Internet Draft author guidelines). Also, the + portions of the specification to be modified should be synopsized in + the new document for the benefit of the reader. The "DNSSEC + protocol" set includes the documents [1], [11], [12], [9], [14], + [15], [21], [16], [OPTIN], [17] and their derivative documents. The "New Security RRs" set refers to the group of documents that seek to add additional Resource Records to the set of base DNS Record types. These new records can be related to securing the DNS protocol [1], [8], or using DNS security for other purposes such as storing - certificates [5]. + certificates [5]. Another related document is [26]. While not + detailing a new RR type, it defines a flag bit in the existing KEY + RR. This flag bit does not affect the protocol interpretation of the + RR, only a possible operational difference. Therefore, this draft is + place here and not with the protocol document set. The "DS Algorithm Impl" document set refers to the group of documents that describe how a specific digital signature algorithm is implemented to fit the DNSSEC Resource Record format. Each one of these documents deals with one specific digital signature algorithm. - Examples of this set include [4], [5], [25], [18][17] and [13]. + Examples of this set include [4], [5], [25], [19][18] and [13]. The "Transactions" document set refers to the group of documents that deal with the message transaction sequence of security-related DNS @@ -326,28 +329,27 @@ Internet-Draft DNSSEC Document Roadmap September 2002 Lastly, there is a set of documents that should be classified as "Implementation Notes". Because the DNS security extensions are still in the developmental stage, there is an audience for documents + + + +Rose Expires August 5, 2003 [Page 6] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + that detail the transition and implementation of the security extensions. These have more to do with the practical side of DNS operations, but can also point to places in the protocol - - - -Rose Expires March 6, 2003 [Page 6] - -Internet-Draft DNSSEC Document Roadmap September 2002 - - - specifications that need improvement. Documents in this set may be - offspring of both the DNSEXT and/or DNSOP Working Groups. An example - of this type is the report on the CAIRN DNSSEC testbed [CAIRN] This - document was submitted through the DNSOP Working Group, however the - main concern of this document is the implementation and limitations - of the DNS security extensions, hence their interest to the DNS - security community. The CAIRN draft deals with the implementation of - a secure DNS. Authors of documents that deal with the implementation - and operational side of the DNSSEC specifications would be advised/ - encouraged to submit their documents to the DNSEXT Working Group as - well. + specifications that need improvement. An example of this type is the + report on the CAIRN DNSSEC testbed [CAIRN] This document was + submitted through the DNSOP Working Group at the time of this + writing, however the main concern of this document is the + implementation and limitations of the DNS security extensions, hence + their interest to the DNS security community. The CAIRN draft deals + with the implementation of a secure DNS. Authors of documents that + deal with the implementation and operational side of the DNSSEC + specifications would be advised/encouraged to submit their documents + to any other relevant DNS related WG meeting in the problem space. @@ -386,22 +388,18 @@ Internet-Draft DNSSEC Document Roadmap September 2002 - - -Rose Expires March 6, 2003 [Page 7] - -Internet-Draft DNSSEC Document Roadmap September 2002 +Rose Expires August 5, 2003 [Page 7] + +Internet-Draft DNSSEC Document Roadmap February 2003 3. Relationship of DNS Security Documents to other DNS Documents The DNS security-related extensions should be considered a subset of - the DNS protocol. The DNS Security Working Group of the IETF - (DNSSEC) has been absorbed into the larger DNS Extensions Working - Group (DNSEXT). Therefore, all DNS security-related documents should - be seen as a subset of the main DNS architecture documents. It is a - good idea for authors of future DNS security documents to be familiar - with the contents of these base protocol documents. + the DNS protocol. Therefore, all DNS security-related documents + should be seen as a subset of the main DNS architecture documents. + It is a good idea for authors of future DNS security documents to be + familiar with the contents of these base protocol documents. @@ -444,9 +442,11 @@ Internet-Draft DNSSEC Document Roadmap September 2002 -Rose Expires March 6, 2003 [Page 8] -Internet-Draft DNSSEC Document Roadmap September 2002 + +Rose Expires August 5, 2003 [Page 8] + +Internet-Draft DNSSEC Document Roadmap February 2003 4. Recommended Content for new DNS Security Documents @@ -465,8 +465,10 @@ Internet-Draft DNSSEC Document Roadmap September 2002 Since the addition of security to the DNS protocol is now considered a general extension to the DNS protocol, any guideline for the - contents of a DNS Security document could be taken as a suggestion - for the contents of any DNS extension document. + contents of a DNS Security document could be taken as a framework + suggestion for the contents of any DNS extension document. The + development process of the DNS security extensions could be used as a + model framework for any, more general DNS extensions. 4.1 Security Related Resource Records @@ -496,15 +498,14 @@ Internet-Draft DNSSEC Document Roadmap September 2002 signatures schemes are introduced) for use with DNS Security should include the following information: + + +Rose Expires August 5, 2003 [Page 9] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + o The format/encoding of the algorithm's public key for use in a KEY - - - -Rose Expires March 6, 2003 [Page 9] - -Internet-Draft DNSSEC Document Roadmap September 2002 - - Resource Record; o the acceptable key size for use with the algorithm; @@ -545,7 +546,7 @@ Internet-Draft DNSSEC Document Roadmap September 2002 other Internet protocols and applications that could make use of, or extend, the DNS security protocols. Examples of this type of document include the use of DNS to support IPSEC [IPSEC-DNS], SSH - [SSH-DNS} the Public Key Infrastructure (PKI). It is beyond the + [SSH-DNS] the Public Key Infrastructure (PKI). It is beyond the scope of this roadmap to describe the contents of this class of documents. However, if uses or extensions require the addition or modification of a DNS Resource Record type or DNS query/response @@ -555,18 +556,18 @@ Internet-Draft DNSSEC Document Roadmap September 2002 - -Rose Expires March 6, 2003 [Page 10] - -Internet-Draft DNSSEC Document Roadmap September 2002 +Rose Expires August 5, 2003 [Page 10] + +Internet-Draft DNSSEC Document Roadmap February 2003 5. Security Considerations This document provides a roadmap and guidelines for writing DNS - Security related documents. The reader should follow all the - security procedures and guidelines described in the DNS Security - Extensions document [1]. + Security related documents. This document does not discuss the + aspects of the DNS security extensions. The reader should refer to + the documents outlined here for the details of the services and + shortcomings of DNS security. @@ -611,10 +612,9 @@ Internet-Draft DNSSEC Document Roadmap September 2002 - -Rose Expires March 6, 2003 [Page 11] - -Internet-Draft DNSSEC Document Roadmap September 2002 +Rose Expires August 5, 2003 [Page 11] + +Internet-Draft DNSSEC Document Roadmap February 2003 6. Acknowledgements @@ -668,12 +668,12 @@ Internet-Draft DNSSEC Document Roadmap September 2002 -Rose Expires March 6, 2003 [Page 12] - -Internet-Draft DNSSEC Document Roadmap September 2002 +Rose Expires August 5, 2003 [Page 12] + +Internet-Draft DNSSEC Document Roadmap February 2003 -References +Normative References [1] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. @@ -724,41 +724,101 @@ References -Rose Expires March 6, 2003 [Page 13] - -Internet-Draft DNSSEC Document Roadmap September 2002 +Rose Expires August 5, 2003 [Page 13] + +Internet-Draft DNSSEC Document Roadmap February 2003 - [16] Austein, R. and D. Atkins, "Threat Analysis of the Domain Name + [16] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + Record (RR)", RFC 3445, December 2002. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose Expires August 5, 2003 [Page 14] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + +Informative References + + [17] Austein, R. and D. Atkins, "Threat Analysis of the Domain Name System (Work in Progress)", RFC XXXX. - [17] Eastlake, R., "Storage of Diffie-Hellman Keys in the Domain + [18] Eastlake, R., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS) (Work in Progress)", RFC XXXX. - [18] Eastlake, D. and R. Schroeppel, "Elliptic Curve KEYs in the DNS + [19] Eastlake, D. and R. Schroeppel, "Elliptic Curve KEYs in the DNS (Work in Progress)", RFC XXXX. - [19] Gundmundsson, O., "Delegation Signer Record in Parent (Work in + [20] Gundmundsson, O., "Delegation Signer Record in Parent (Work in Progress)", RFC XXXX. - [20] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource - Record (Work in Progress)", RFC XXXX. - [21] Wellington, B., "Redefinition of the DNS AD bit (Work in Progress)", RFC XXXX. [22] Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security Introduction and Requirements (Work in Progress)", RFC XXXX. - [23] Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security - Introduction and Requirements (Work in Progress)", RFC XXXX. + [23] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource + Records for DNS Security Extensions (Work in Progress)", RFC + XXXX. - [24] Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security - Introduction and Requirements (Work in Progress)", RFC XXXX. + [24] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol + Modifications for the DNS Security Extensions (Work in + Progress)", RFC XXXX. [25] Kwan, S., Garg, P., Gilroy, J. and L. Esibov, "GSS Algorithm for TSIG (Work in Progress)", RFC XXXX. + [26] Kolkman, O. and J. Schlyter, "KEY RR Key-Signing-Key (KSK) Flag + (Work in Progress)", RFC XXXX. + Author's Address @@ -776,18 +836,14 @@ Author's Address - - - - -Rose Expires March 6, 2003 [Page 14] - -Internet-Draft DNSSEC Document Roadmap September 2002 +Rose Expires August 5, 2003 [Page 15] + +Internet-Draft DNSSEC Document Roadmap February 2003 Full Copyright Statement - Copyright (C) The Internet Society (2002). 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 @@ -836,6 +892,5 @@ Acknowledgement -Rose Expires March 6, 2003 [Page 15] - - +Rose Expires August 5, 2003 [Page 16] +