From f48695f5490087d31f13eac7b6aa1f9c07b31864 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Fri, 26 Jul 2002 21:59:18 +0000 Subject: [PATCH] new draft --- ... => draft-ietf-dnsext-dnssec-intro-02.txt} | 526 +++++++----------- 1 file changed, 207 insertions(+), 319 deletions(-) rename doc/draft/{draft-ietf-dnsext-dnssec-intro-01.txt => draft-ietf-dnsext-dnssec-intro-02.txt} (64%) diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-02.txt similarity index 64% rename from doc/draft/draft-ietf-dnsext-dnssec-intro-01.txt rename to doc/draft/draft-ietf-dnsext-dnssec-intro-02.txt index 55f2f7f8ba..6637146e52 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-intro-01.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-intro-02.txt @@ -2,17 +2,17 @@ Network Working Group R. Arends Internet-Draft Nominum -Expires: August 30, 2002 M. Larson +Expires: January 21, 2003 M. Larson VeriSign D. Massey USC/ISI S. Rose NIST - March 1, 2002 + July 23, 2002 DNS Security Introduction and Requirements - draft-ietf-dnsext-dnssec-intro-01 + draft-ietf-dnsext-dnssec-intro-02 Status of this Memo @@ -35,7 +35,7 @@ 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 August 30, 2002. + This Internet-Draft will expire on January 21, 2003. Copyright Notice @@ -52,9 +52,9 @@ Abstract -Arends, et al. Expires August 30, 2002 [Page 1] +Arends, et al. Expires January 21, 2003 [Page 1] -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 2002 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -64,29 +64,26 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1 Packet Interception and/or Modification . . . . . . . . . . 4 - 2.2 Name Based Attacks (a.k.a. Cache Poisoning) . . . . . . . . 4 - 2.3 Attacks Not Covered by DNSSEC . . . . . . . . . . . . . . . 5 - 3. Services Provided by DNS Security . . . . . . . . . . . . . 6 - 3.1 Data Origin Authentication and Data Integrity . . . . . . . 6 - 3.1.1 Authenticating Name and Type Non-Existence . . . . . . . . . 7 - 3.2 Key Distribution . . . . . . . . . . . . . . . . . . . . . . 7 + 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 . . . . . . . . . . . 9 - 5. Resolver Considerations . . . . . . . . . . . . . . . . . . 10 - 6. Zone Considerations . . . . . . . . . . . . . . . . . . . . 11 - 7. Server Considerations . . . . . . . . . . . . . . . . . . . 12 - 8. DNS Security Document Family . . . . . . . . . . . . . . . . 13 - 8.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . 13 - 8.2 Categories of DNS Security Documents . . . . . . . . . . . . 13 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 - 10. Security Considerations . . . . . . . . . . . . . . . . . . 16 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 - References . . . . . . . . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 - A. Definitions of Important DNSSEC Terms . . . . . . . . . . . 20 - Full Copyright Statement . . . . . . . . . . . . . . . . . . 21 + 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 @@ -108,9 +105,12 @@ Table of Contents -Arends, et al. Expires August 30, 2002 [Page 2] + + + +Arends, et al. Expires January 21, 2003 [Page 2] -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 2002 1. Introduction @@ -122,17 +122,12 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 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 threat model - that the security extensions are designed to protect against is - described in Section 2. 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. - - Appendix A provides definitions for important DNSSEC terms. A term - that appears in Appendix A is followed by an asterisk (*) upon first - use in the body of the document. + 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 @@ -164,121 +159,70 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 -Arends, et al. Expires August 30, 2002 [Page 3] + + + + + +Arends, et al. Expires January 21, 2003 [Page 3] -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 2002 -2. Threat Model +2. Definitions of Important DNSSEC Terms - The Domain Name System (DNS) protocol has been the target of several - well-publicized attacks since its creation. A more detailed threat - model for DNS is the subject of [4]. A brief description of the - major attacks that the DNS security extensions were designed to - protect against is given below. + trusted 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 as trusted in the resolver's + configuration. Second, if a new key is referenced by a DS record + that is signed by an already trusted key, and the signature + verifies, the new key becomes trusted. -2.1 Packet Interception and/or Modification + chain of trust: 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 trusted key can verify all + subsequent signatures. Thus all subsequent data in the chain is + trusted. - The attacker has access to the network and observes (and possibly - modifies) DNS message data. This is a form of the "man in the - middle" attack and can be either passive (observation only) or active - (interception and modification). It is also possible that the - attacker responds to a resolver's query with bogus information before - the queried name server's reply reaches the resolver. Message - modification could lead to incorrect information being returned to a - resolver, or a different query being sent to a name server. + 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 trusted keys to verify signatures + over RRsets and (optionally) DNS messages. - DNSSEC uses a digital signature scheme for DNS RRsets (defined in - [5]) or entire DNS messages to provide integrity checks and source - authentication. Any modifications made by an attacker would result - in a signature verification error at the resolver. DNSSEC also - provices a means for authenticating the non-existence of DNS data. + 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". - A conscious DNSSEC design decision was keeping DNS information in - plaintext. DNSSEC does use any cryptographic techniques to provide - confidentiality for any DNS information. + unsecure server: The proper term for the opposite of a security-aware + server. -2.2 Name Based Attacks (a.k.a. Cache Poisoning) + unsigned zone: The proper term for the opposite of a secure zone. - This type of attack allows the attacker to hijack a DNS zone by - injecting false data into a response in the form of resource records - (RRs) in the authority and additional sections, usually pointing to a - false authoritative server. This attack depends on the targeted - resolver caching these records and using them to answer future - queries from other resolvers. This attack allows the attacker to - subvert a single recursive server and redirect all queries for the - targeted domain name to the attacker's name server, essentially - hijacking the DNS zone from its legitimate servers. - - Since this attack modifies the contents of DNS messages, the - signature scheme in DNSSEC protects against it. The keys that - resolvers use to verify DNS data must either be configured as a - trusted key*, or be part of a chain of trust* back to a trusted key. - The DNSSEC trust model ensures that as long as zone administrators - follow reasonable key-signing policies, the key used by an attacker - to sign malicious DNS data would not be trusted. + secure zone: A zone whose RRsets are signed and which contains + properly constructed KEY, SIG, NXT and (optionally) DS records. -Arends, et al. Expires August 30, 2002 [Page 4] + + + + + + + + + + + +Arends, et al. Expires January 21, 2003 [Page 4] -Internet-Draft DNSSEC Intro. and Requirements March 2002 - - - Note, however, that referrals are not signed in DNSSEC. It is - expected that the a zone's authoritative servers will provide digital - signatures for RRsets in the answer, authority and additional - sections, as necessary. - -2.3 Attacks Not Covered by DNSSEC - - Denial of Service (DoS) attacks are not addressed by DNSSEC. DoS - attacks are easy to detect, but difficult to protect against, in a - protocol like DNS. Name server and resolver implementations can - protect against some DoS attacks (by providing system security), but - there are no protocol features in DNSSEC to defend against DoS - attacks. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 30, 2002 [Page 5] - -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 2002 3. Services Provided by DNS Security @@ -288,6 +232,9 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 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 @@ -295,15 +242,15 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 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 + 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 pair(s) that sign a zone's data are - 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. + 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 @@ -322,22 +269,23 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 zone's public key in the DNS reply message along with the public key itself, provided there is space available in the message. - The chain of trust specified in the original DNS security extentions + The chain of trust specified in the original DNS security 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 - record is stored at a delegation point in a parent zone and specifies - the keys used by the child zone to self-sign its KEY records. The - child, in turn, uses one of these keys to sign its zone data. The + signer (DS), has been added for additional flexibility. The DS RRset -Arends, et al. Expires August 30, 2002 [Page 6] +Arends, et al. Expires January 21, 2003 [Page 5] -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 2002 - chain of trust is therefore DS->KEY->[DS->KEY->...]->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 chain of trust 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 @@ -347,27 +295,28 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 3.1.1 Authenticating Name and Type Non-Existence - The above security mechanism 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. + 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 (or another entity's) public key - when establishing a chain of trust. + resolvers can query for a zone's public key when establishing a chain + of trust. - The syntax of a KEY resource record (and the other additional + 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. @@ -376,42 +325,42 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 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 [11] and certificates [12] used by other + storing public keys [14] and certificates [15] used by other protocols and applications in the DNS. A secure DNS tree could then be used as a lightweight trust mechanism. Some administrators and users may consider a validated DNSSEC signature to be sufficient to + + + +Arends, et al. Expires January 21, 2003 [Page 6] + +Internet-Draft DNSSEC Intro. and Requirements July 2002 + + trust a public key stored in the DNS. 3.3 Transaction Security The data origin authentication and data integrity service described - - - -Arends, et al. Expires August 30, 2002 [Page 7] - -Internet-Draft DNSSEC Intro. and Requirements March 2002 - - 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) - [13] or SIG record with a type covered field of zero (a "SIG(0)", see - [14]). Such a signature can be used to verify the integrity of the + [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 name servers - 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. + 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) [15] + 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 @@ -439,14 +388,9 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 - - - - - -Arends, et al. Expires August 30, 2002 [Page 8] +Arends, et al. Expires January 21, 2003 [Page 7] -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 2002 4. Services Not Provided by DNS Security @@ -460,7 +404,7 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 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 headers. + interpreting and/or setting DNS message header fields. @@ -500,9 +444,9 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 -Arends, et al. Expires August 30, 2002 [Page 9] +Arends, et al. Expires January 21, 2003 [Page 8] -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 2002 5. Resolver Considerations @@ -524,9 +468,9 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 security policy. A security-aware resolver needs to communicate with only security- - aware servers. If an unsecure server* or an unsigned 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 + 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 trusting responses. @@ -556,15 +500,15 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 -Arends, et al. Expires August 30, 2002 [Page 10] +Arends, et al. Expires January 21, 2003 [Page 9] -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 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, + 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 @@ -612,22 +556,22 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 -Arends, et al. Expires August 30, 2002 [Page 11] +Arends, et al. Expires January 21, 2003 [Page 10] -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 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 zone server + 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 + necessary security-related records (SIG, KEY, DS and NXT) in responses as DNS message space permits. - A caching security-aware server must also take a signature's + 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. @@ -636,7 +580,7 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 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 using the server's local policy). + (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 @@ -668,9 +612,9 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 -Arends, et al. Expires August 30, 2002 [Page 12] +Arends, et al. Expires January 21, 2003 [Page 11] -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 2002 8. DNS Security Document Family @@ -716,7 +660,7 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 8.2 Categories of DNS Security Documents - The "DNSSEC protocol" document set refers to the three documents that + 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) @@ -724,15 +668,15 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 -Arends, et al. Expires August 30, 2002 [Page 13] +Arends, et al. Expires January 21, 2003 [Page 12] -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 2002 2. Resource Records for DNS Security Extensions [9] 3. Protocol Modifications for the DNS Security Extensions (not yet - published) [14] + published) [12] The "Dig. Sig. Algorithm Impl." document set refers to the group of documents that describe how a specific digital signature algorithm is @@ -746,8 +690,8 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 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 [12] and - individual user public keys (PGP, e-mail, etc.) [11]. + use of DNS in the storage and distribution of certificates [15] and + individual user public keys (PGP, e-mail, etc.) [14]. @@ -780,9 +724,9 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 -Arends, et al. Expires August 30, 2002 [Page 14] +Arends, et al. Expires January 21, 2003 [Page 13] -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 2002 9. IANA Considerations @@ -836,9 +780,9 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 -Arends, et al. Expires August 30, 2002 [Page 15] +Arends, et al. Expires January 21, 2003 [Page 14] -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 2002 10. Security Considerations @@ -848,9 +792,7 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 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. The DNS security - extensions can also be used to support key distribution for other - security protocols. + 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 @@ -892,9 +834,11 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 -Arends, et al. Expires August 30, 2002 [Page 16] + + +Arends, et al. Expires January 21, 2003 [Page 15] -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 2002 11. Acknowledgements @@ -948,12 +892,12 @@ Internet-Draft DNSSEC Intro. and Requirements March 2002 -Arends, et al. Expires August 30, 2002 [Page 17] +Arends, et al. Expires January 21, 2003 [Page 16] -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 2002 -References +Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -964,12 +908,12 @@ References [3] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. - [4] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name - System", draft-ietf-dnsext-dns-threats-00 (work in progress), - November 2001. + [4] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. - [5] Elz, R. and R. Bush, "Clarifications to the DNS Specification", - RFC 2181, July 1997. + [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. @@ -985,41 +929,41 @@ References 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-01 (work in - progress), January 2002. + Record", draft-ietf-dnsext-restrict-key-for-dnssec-02 (work in + progress), March 2002. - [11] Schlyter, J., "Storing application public keys in the DNS", - draft-schlyter-appkey-02 (work in progress), February 2002. - - [12] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the - Domain Name System (DNS)", RFC 2538, March 1999. - - [13] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. - [14] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol + [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 - - - -Arends, et al. Expires August 30, 2002 [Page 18] - -Internet-Draft DNSSEC Intro. and Requirements March 2002 - - progress), to be published in 2002. - [15] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC + [13] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. + + + + +Arends, et al. Expires January 21, 2003 [Page 17] + +Internet-Draft DNSSEC Intro. and Requirements July 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. - [17] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - Authors' Addresses @@ -1060,65 +1004,9 @@ Authors' Addresses -Arends, et al. Expires August 30, 2002 [Page 19] +Arends, et al. Expires January 21, 2003 [Page 18] -Internet-Draft DNSSEC Intro. and Requirements March 2002 - - -Appendix A. Definitions of Important DNSSEC Terms - - trusted 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 as trusted in the resolver's - configuration. Second, if a new key is referenced by a DS record - that is signed by an already trusted key, and the signature - verifies, the new key becomes trusted. - - chain of trust: 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 trusted key can verify all - subsequent signatures. Thus all subsequent data in the chain is - trusted. - - security-aware resolver: A resolver (defined in section 2.4 of [17]) - that understands the DNS security extensions. In particular, a - security-aware resolver uses trusted keys to verify signatures - over RRsets and (optionally) DNS messages. - - security-aware server: A name server (also defined in section 2.4 of - [17]) 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 temr for the opposite of a security-aware - server. - - unsigned zone: The proper term for the opposite of a secure zone. - - secure zone: A zone whose RRsets are signed and which contains - properly constructed KEY, SIG, NXT and (optionally) DS records. - - - - - - - - - - - - - - -Arends, et al. Expires August 30, 2002 [Page 20] - -Internet-Draft DNSSEC Intro. and Requirements March 2002 +Internet-Draft DNSSEC Intro. and Requirements July 2002 Full Copyright Statement @@ -1172,5 +1060,5 @@ Acknowledgement -Arends, et al. Expires August 30, 2002 [Page 21] +Arends, et al. Expires January 21, 2003 [Page 19]