WDIFF

draft-ietf-dnsext-dnssec-intro-00.txt --> draft-ietf-dnsext-dnssec-intro-01.txt

DNSEXT

Network Working Group R. Arends
Internet-Draft Nominum
Expires: August 30, 2002 M. Larson
VeriSign
D. Massey
Internet Draft
USC/ISI
S. Rose
Expires: December 2001
NIST
Category: Informational June 2001
Updates: RFC 2535
March 1, 2002

DNS Security Introduction and Requirements
------------------------------
<draft-ietf-dnsext-dnssec-intro-00.txt>
draft-ietf-dnsext-dnssec-intro-01

Status of this Document Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Distribution of this
document is unlimited. Comments regarding this document should be
sent to the author.

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.

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 http://
www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 30, 2002.

Abstract

The Domain Name System Security Extensions (DNSSEC) provides provide data and
origin authentication and data integrity. This document introduces the
new DNS
these extensions and describes the their capabilities and limitations of
DNS Security. limitations.
The services that the security extensions provide and do not provide
are discusses. discussed. Lastly, the group of documents that describe the DNS
security extensions and their inter-relationships interrelationships is discussed.

Massey, Rose

Arends, et al. Expires August 30, 2002 [Page 1]

INTERNET-DRAFT

Internet-Draft DNSSEC Intro. and Requirements March 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. 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
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

Arends, et al. Expires August 30, 2002 [Page 2]

Internet-Draft DNSSEC Intro. and Requirements June 2001 March 2002

1. Introduction

This document introduces the Domain Name System Security Extensions
(DNSSEC). It, This document and a collection of following documents, are an related documents update
of
RFC 2535 [2] and following its related documents in an attempt 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 [RFC1035]. [3]. The new records and
protocol modifications are not fully described in this document, but
in a family of documents that is described outlined in section Section 8. The threat model DNS
that the security was extensions are designed to protect against is
described in section Section 2. The capabilities and limitations of the
security extensions are described in greater detail in section Section 3 and
4
Section 4, respectively. Lastly, the impacts DNS effect that these security
extensions will have on resolvers, zones, zones and servers are is discussed in sections 5 through 7.
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.

The DNS security extensions provide data and source origin authentication and
data integrity protection as well as a means for of public key
distribution. The security extensions do not provide protection
against other types of attack or attack, nor do they provide confidentiality.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",

Arends, et al. Expires August 30, 2002 [Page 3]

Internet-Draft DNSSEC Intro. and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. It is also
assumed the reader has some knowledge of the Domain Name System
[RFC1035]. Requirements March 2002

2. Threat Model

The Domain Name System (DNS) protocol has been the target of several
well-publicized attacks since it's its creation. These attacks are
centered on altering A more detailed threat
model for DNS traffic in transit, or sending erroneous
referral messages to caching servers (i.e. "cache poisoning"). The
result of these attacks are traffic redirection or complete "zone
hijacking" if the malicious referral code is allowed to propagate.

The goal the subject of [4]. A brief description of the
major attacks that the DNS security extensions is were designed to
protect the integrity
of DNS data and provide a means of source and data authentication.
No effort against is given below.

2.1 Packet Interception and/or Modification

The attacker has been made access to protect against other forms of attack such
as attacks against server implementations the network and denial of service.

3. Services Provided by observes (and possibly
modifies) DNS Security

The Domain Name System (DNS) protocol security extensions provide
three distinct services: Data origin authentication and integrity,
key distribution, and transaction and request authentication, as
described below.

Massey, Rose [Page 2]

INTERNET-DRAFT DNSSEC Intro. and Requirements June 2001

3.1 Source and Data Authentication and Integrity

Authentication message data. This is provided by cryptographically generated digital
signatures associated with DNS resource record sets (RRsets
[RFC2181]). Commonly, there will be a single private key that
authenticates a zone's data, but there might be multiple keys for
different algorithms, etc. If a security aware resolver reliably
learns a public key form of the zone, it can authenticate signed zone
data. The data origin authentication key(s) are associated with "man in the
zone
middle" attack and not 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 servers that store copies of queried name server's reply reaches the zone data.

A resolver resolver. Message
modification could learn lead to incorrect information being returned to a public key of
resolver, or a zone either by reading it
from the different query being sent to a name server.

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 having it statically configured. To reliably
learn an attacker would result
in a public key by reading it from the DNS, signature verification error at the learned key itself
must be signed with resolver. DNSSEC also
provices a key means for authenticating the resolver trusts. New zone non-existence of DNS data.

A conscious DNSSEC design decision was keeping DNS information
is authenticated in
plaintext. DNSSEC does use any cryptographic techniques to provide
confidentiality for any DNS information.

2.2 Name Based Attacks (a.k.a. Cache Poisoning)

This type of attack allows the attacker to hijack a DNS zone by forming
injecting false data into a "chain response in the form of trust" from resource records
(RRs) in the authority and additional sections, usually pointing to a newly learned
zone back
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 trusted (pre-configured or previously learned) single recursive server and redirect all queries for the
targeted domain name to the attacker's name server, essentially
hijacking the DNS zone
key. Therefore, from its legitimate servers.

Since this attack modifies the resolver 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 with at least a
public key that authenticates one zone as a starting point. To
establish this
trusted key*, or be part of a chain of trust, security aware servers attempt trust* back to send a trusted key.
The DNSSEC trust model ensures that as long as zone administrators
follow reasonable key-signing policies, the signature(s) needed to authenticate key used by an RRset with the DNS reply,
providing there is available space in the DNS message packet.

Adding data origin authentication and integrity requires no change attacker
to
the "on-the-wire" sign malicious DNS protocol beyond the addition of the signature
resource type (SIG record) data would not be trusted.

Arends, et al. Expires August 30, 2002 [Page 4]

Internet-Draft DNSSEC Intro. and Requirements March 2002

Note, however, that referrals are not signed in DNSSEC. It is
expected that the key resource type (KEY record)
needed a zone's authoritative servers will provide digital
signatures for key distribution. Existing resolver RRsets in the answer, authority and caching 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 support this service so long
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

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 they can support
the new resource record types.

3.2 Key Distribution

A resource record format described
below.

3.1 Data Origin Authentication and Data Integrity

Authentication is defined to associate public keys provided by cryptographically generated digital
signatures associated with DNS
names. This permits RRsets. These digital signatures are
stored in a new resource record, the DNS to SIG record. Typically, there
will be used as a public single private key distribution
mechanism in support of DNS security itself and other protocols.
Security aware resolvers can query for that signs a zone's or other entities'
public key when establishing data, but multiple
keys are possible; e.g., for different digital signature algorithms.
If a chain of trust.

The syntax of security-aware resolver* reliably learns a KEY resource record (RR) zone's public key, it
can authenticate that zone's signed data. An important DNSSEC
concept is described in a separate
document [proto ref]. It includes identifiers for that the key algorithm,
and information on the entity the key is associated with.

3.3 Authenticating Name and Type Non-Existence

The above security mechanism only provides a way to pair(s) that sign existing
RRsets in a zone. The problem of sending negative responses zone's data are
associated with the

Massey, Rose [Page 3]

INTERNET-DRAFT DNSSEC Intro. and Requirements June 2001

same level of authentication zone itself and integrity requires not with the use of zone's authoritative
servers (although hosts can also have key pairs in DNSSEC; see the
Non-existence (NXT) record type. The NXT record allows a negative
reply (either for name or type non-existence)
reference to be authenticated the
same way other DNS replies. NXT records exist SIG(0) in Section 3.3 below). Security-aware servers*
attempt to cover send the gaps signature(s) needed to authenticate an RRset in
the canonical representation of a zone namespace. Each NXT record is
signed and authenticated DNS reply message along with the same way as any other RRset itself, provided there is
space available in the DNS.

3.4 Transaction Security

The data origin authentication service described above protects
retrieved resource records and message.

A resolver could learn a zone's public key by having the non-existence of resource records
but provides no protection for complete key
statically configured or by normal DNS messages, including 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
transfers data must be kept secure and dynamic updates. best practices call for them
to be stored offline.) To reliably discover a public key by DNS message can
resolution, the key itself needs to be signed by another key that the
resolver trusts. Zone information is authenticated by including forming a special signature RR
at the end
chain of the request, either trust from a Transaction SIG (TSIG) or SIG[0]
[Proto doc ref]. A Transaction signature included at the end of newly learned public key back to a
response can be used to verify the integrity of the DNS message.
Authenticating requests serves no function in older DNS servers trusted
public key (which is either statically configured or previously
learned and
requests verified). Therefore, the resolver must be configured
with at least one public key that authenticates one zone as a non-empty additional information section may produce
error returns or be ignored. Unlike the SIG RR discussed above,
transaction security involves
starting point. To establish this chain of trust, security-aware
servers attempt to send the individual host machines signature(s) needed to authenticate a
zone's public key in the DNS reply message transaction, so the cryptographic keys used in with
transaction security are associated along with individual systems and not
DNS zones.

In addition to the ability to use transaction signatures, public key
itself, provided there is
additional support for the use of key agreement protocols to support
transaction security using symmetric encryption keys. This service
uses space available in the transaction key (TKEY) resource record. message.

The use chain of the TKEY
record in a key agreement transaction depends on the algorithm used,
and each key agreement protocol is described trust specified in a separate document
for each algorithm.

4. What Services Are Not Provided

It is part of the design philosophy of the original DNS that the data in it is
public security extentions
proceeded from signed KEY record to signed KEY record, as necessary,
and that finally to the DNS gives queried RRset. A new record, the same answers to all inquirers.
Following this philosophy, no attempt has been made to include any
sort of access control lists or other means to differentiate
inquirers.

No effort delegation
signer (DS), has been made to provide for any confidentiality added for
queries or responses.

Denial of service is not protected against.

Massey, Rose [Page 4]

INTERNET-DRAFT DNSSEC Intro. and Requirements June 2001 additional flexibility. The use of SIGs DS
record is stored at a delegation point in a parent zone and/or and specifies
the use of transaction signatures
will not protect against errors in DNS zone information or servers
incorrectly interpreting/setting DNS message headers.

5. Resolver Considerations

A security aware resolver will have to be able to perform necessary
cryptographic functions to verify digital signatures using at least keys used by the mandatory child zone to implement algorithms. Also, security aware
resolvers must be capable self-sign its KEY records. The
child, in turn, uses one of forming a these keys to sign its zone data. The

Arends, et al. Expires August 30, 2002 [Page 6]

Internet-Draft DNSSEC Intro. and Requirements March 2002

chain of trust from a newly
learned zone back to a known secure public key. This might require
additional queries is therefore DS->KEY->[DS->KEY->...]->RRset.

Adding data origin authentication and data integrity requires minor
changes to intermediate the on-the-wire DNS zones for necessary keys protocol. Several new resource record
types are required, including the aforementioned SIG, KEY and
signatures. It DS.
EDNS0 support [6] for larger message sizes [7] is assumed that a required, as is
support for the OK bit [8].

3.1.1 Authenticating Name and Type Non-Existence

The above security aware resolver will be
pre-configured with at least one public key mechanism only provides a way to aid in this.

The stub resolver found sign existing
RRsets in many host systems may be augmented to
provide a different set zone. The problem of security features instead providing negative responses with
the same level of authentication and integrity requires the full
security awareness found in a complete resolver. The use of
transaction security could help to secure
another new resource record, the final message passing
between a stub resolver and non-existence (NXT) record. The NXT
record allows a primary recursive negative reply (either for name or type non-
existence) to be authenticated the same way as other DNS server. It is replies.
NXT records require a
matter of local security policy.

It is necessary canonical representation and order for a security aware resolver only communicate with
security aware servers. If an unsecure server domain
names in zones. NXT records exist to cover the gaps, or an unsecure zone "empty
space", between domain names in a zone, as well as non-existent
record types for existing names. Each NXT record is
part of 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 chain,
names. This record permits the resolver cannot insure security. If DNS to be used as a
security aware resolver must rely on an unsecure server (or unsigned
zone), it is not possible public key
distribution mechanism in support of DNSSEC. Security-aware
resolvers can query for the resolver to verify DNS responses,
and should rely on local policy a zone's (or another entity's) public key
when trusting responses.

6. Zone Considerations

A secure zone will have several differences from an unsecure zone. A
secure zone will have establishing a chain of trust.

The syntax of a KEY resource record (and the other additional security
resource records (SIG, KEY, and NXT
records) added to the zone data. It required for DNSSEC) is possible that described in [9]. It
includes identifiers for the security
records are added before algorithm the zone key is loaded by a server. In this
case, the server must generate the signatures used for and NXT records before
loading the zone. Also, zone
information on the entity the key is only valid and
considered secure for a definable time period. associated with.

The SIG records that
accompany zone data have a defined inception original DNSSEC specification allowed other protocols and expiration times.
These times establish
applications to use the KEY record as a validity period for general-purpose mechanism to
store public keys. For reasons documented in [10], the signatures and the
zone data 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
protocols and applications in the signatures covers.

7. Server Considerations DNS. A security aware server must secure DNS tree could then
be capable of performing used as a lightweight trust mechanism. Some administrators and
users may consider a validated DNSSEC signature to be sufficient to
trust a public key stored in the following

Massey, Rose DNS.

3.3 Transaction Security

The data origin authentication and data integrity service described

Arends, et al. Expires August 30, 2002 [Page 5]

INTERNET-DRAFT 7]

Internet-Draft DNSSEC Intro. and Requirements June 2001

additional operations, in addition to March 2002

above authenticates retrieved RRsets and the normal operations non-existence of a RRsets,
but provides no protection for complete DNS
zone server described in [RFC1035]:

A security aware server should make all attempts to include necessary
security related records messages, e.g., when they
occur in DNS responses. This includes all
necessary signatures zone transfers and public key records, as dynamic updates.

A DNS message space
permits.

A caching security aware server must also take the signatures
validation period into consideration when determining can be authenticated by including a special signature
RR at the Time-To-
Live (TTL) end of cached data.

A security aware server should have the message, either a means of employing transaction
security such as transactions signatures signature (TSIG)
[13] 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).

All other means SIG record with a type covered field of restricting query, zone transfer, dynamic update
and administration access to zero (a "SIG(0)", see
[14]). Such a security aware server falls under signature can be used to verify the
category integrity of operational security and are not addressed by the
DNS
security extensions.

8. DNS Security Document Family

The DNSSEC set of documents can be partitioned 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.

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]
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 August 30, 2002 [Page 8]

Internet-Draft DNSSEC Intro. and Requirements March 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 headers.

Arends, et al. Expires August 30, 2002 [Page 9]

Internet-Draft DNSSEC Intro. and Requirements March 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 chain of trust from a newly
learned zone back to a trusted 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 trusted 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 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.

Arends, et al. Expires August 30, 2002 [Page 10]

Internet-Draft DNSSEC Intro. and Requirements March 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 August 30, 2002 [Page 11]

Internet-Draft DNSSEC Intro. and Requirements March 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
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 caching security-aware 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 using 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 August 30, 2002 [Page 12]

Internet-Draft DNSSEC Intro. and Requirements March 2002

8. DNS Security Document Family

The DNSSEC set of documents can be partitioned into five main groups
as depicted in Figure 1. All 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 August 30, 2002 [Page 13]

Internet-Draft DNSSEC Intro. and Requirements March 2002

2. Resource Records for DNS Security Extensions [9]

3. Protocol Modifications for the DNS Security Extensions (not yet
published) [14]

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 [12] and
individual user public keys (PGP, e-mail, etc.) [11].

Arends, et al. Expires August 30, 2002 [Page 14]

Internet-Draft DNSSEC Intro. and Requirements March 2002

9. IANA Considerations

This document introduces no new IANA considerations.

Arends, et al. Expires August 30, 2002 [Page 15]

Internet-Draft DNSSEC Intro. and Requirements March 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. The DNS security
extensions can also be used to support key distribution for other
security protocols.

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 August 30, 2002 [Page 16]

Internet-Draft DNSSEC Intro. and Requirements March 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 August 30, 2002 [Page 17]

Internet-Draft DNSSEC Intro. and Requirements March 2002

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] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
System", draft-ietf-dnsext-dns-threats-00 (work in progress),
November 2001.

[5] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
RFC 2181, July 1997.

[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 these documents 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 turn are under progress), March 2002.

[10] Massey, D. and S. Rose, "Limiting the larger umbrella group Scope of the KEY Resource
Record", draft-ietf-dnsext-restrict-key-for-dnssec-01 (work in
progress), January 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,
"Secret Key Transaction Authentication for DNS base protocol documents.

8.1 (TSIG)", RFC
2845, May 2000.

[14] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol
Modifications for the DNS Security Document Roadmap

+--------------------------------+
| |
| Base DNS Protocol Docs. |
| [RFC1035, RFC2181, etc.] |
| |
+--------------------------------+
|
|
+-----------+ +-------------+
| Extensions (Not yet
published)", draft-ietf-dnsext-dnssec-protocol-00 (work in

Arends, et al. Expires August 30, 2002 [Page 18]

progress), to be published in 2002.

[15] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
2930, September 2000.

Massey, 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

Roy Arends
Nominum, Inc.
2385 Bay Street
Redwood City, CA 94063
USA

EMail: roy.arends@nominum.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-3460
USA

EMail: scott.rose@nist.gov

Arends, et al. Expires August 30, 2002 [Page 6]

INTERNET-DRAFT 19]

Internet-Draft DNSSEC Intro. and Requirements June 2001

8.2 Categories March 2002

Appendix A. Definitions of DNS Security Documents

The "DNSSEC protocol" document set refers to the document that makes
up the groundwork Important DNSSEC Terms

trusted key: A public key, for adding security to the DNS protocol [protocol
doc ref].

The "DS Algorithm Impl" document set refers 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 group of documents
that describe how resolver's
configuration. Second, if a specific digital signature algorithm new key is
implemented to fit referenced by a DS record
that is signed by an already trusted key, and the DNSSEC Resource Record format. Each one of
these documents deals with one specific digital signature algorithm.

The "Transactions" document set refers to the group of documents that
deal with
verifies, the message transaction sequence new key becomes trusted.

chain of security-related DNS
operations. Message transaction schemes to support DNSSEC operation
fall under this group, including secret trust: In DNSSEC, a key establishment and
verification.

The final document set, "New Security Uses", refers to documents that
seek signs a DS record, which points to use proposed DNS Security extensions for other security
related purposes. Documents that fall
another key, which in this category include the
use turn signs another DS record, which points
to yet another key, etc. This alternating succession of DNS in the storage KEY and distribution
DS records forms a chain of certificates and
individual user public keys (PGP, e-mail, etc.)

9. Security Considerations

This document introduces the DNS security extensions and describes signed data, with each link in the document set that contains
chain vouching for the new security records and DNS
protocol modifications. The capabilities and limitations next. A resolver starting at a piece of these
extensions are discussed. The extensions provide
data and source
authentication and integrity through in the use 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 digital signatures
over resource records and (optionally) DNS messages. The [17])
that understands the DNS
security extensions can also be used to support key distribution for
other security protocols.

Massey, Rose [Page 7]

INTERNET-DRAFT DNSSEC Intro. and Requirements June 2001 security extensions. In order for particular, a secure
security-aware resolver uses trusted keys to validate a DNS response, all the
intermediate zones verify signatures
over RRsets and servers must be capable of (optionally) DNS security
processing. messages.

security-aware server: A security aware resolver cannot verify responses sent
by an non-security aware server.

The name server (also defined in section 2.4 of
[17]) that understands the DNS security extensions do not protect against denial of service
(DoS) attacks or provide confidentiality.

10. Acknowledgements

This document was created from extensions. In
particular, it supports the input KEY, SIG, DS and ideas of several members
of the NXT record types, a
larger DNS Extensions WG. The authors would like to acknowledge message size via EDNS0, and other protocol changes such
as support for the
following people OK bit. Also called a "secure server".

unsecure server: The proper temr for their contributions and comments on this
document. In alphabetical order:

Donald Eastlake
Miek Gieben
Olafur Gudmundsson
Ted Lindgreen
Ed Lewis
Bill Manning
Brian Wellington

11. References

[RFC2119] Bradner, S., "Key words the opposite of a security-aware
server.

unsigned zone: The proper term for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities".
RFC 1034, November 1987.

[RFC1035] Mockapetris, P., "Domain Names - Implementation the opposite of a secure zone.

secure zone: A zone whose RRsets are signed and
Specifications", STD 13, RFC 1035, November 1987.

[RFC2181] Elz, R. which contains
properly constructed KEY, SIG, NXT and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.

[RFC3090] Lewis, E. "DNS Security Extensions Clarification on Zone
Status". RFC 3090, March 2001.

[RFC3007] Wellington, B. "Secure Domain Name System (DNS) Dynamic
Update". RFC 3007, November 2000.

12. Authors' Addresses

Massey, Rose (optionally) DS records.

Arends, et al. Expires August 30, 2002 [Page 8]

INTERNET-DRAFT 20]

Internet-Draft DNSSEC Intro. and Requirements June 2001

Dan Massey
USC/ISI
Email: masseyd@isi.edu

Scott Rose
National Institute for Standards and Technology
Gaithersburg, MD
Email: scott.rose@nist.gov

Expiration and File Name:

This draft, titled <draft-ietf-dnsext-dnssec-intro-00.txt> expires December 2001 March 2002

Full Copyright Statement

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."

Massey, Rose PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Arends, et al. Expires August 30, 2002 [Page 9] 21]

----