DNSEXT Working Group                                          D. Massey
Internet Draft                                                  USC/ISI
                                                                S. Rose
Expires: December 2001                                             NIST
Category: Informational                                       June 2001
Updates: RFC 2535





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


Status of this Document

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


Abstract

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




Massey, Rose                                                    [Page 1]


INTERNET-DRAFT       DNSSEC Intro. and Requirements            June 2001


1. Introduction

   This document introduces the Domain Name System Security Extensions
   (DNSSEC).  It, and a collection of following documents, are an update
   of RFC 2535 and following documents in an attempt to further clarify
   and refine the security extensions in RFC 2535.  These security
   extensions consist of a set of new resource record types and
   modifications to the existing DNS protocol [RFC1035].  The new
   records and protocol modifications are not fully described in this
   document, but in a family of documents that is described in section
   8.  The threat model DNS security was 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
   4 respectively.  Lastly, the impacts DNS security will have on
   resolvers, zones, and servers are discussed in sections 5 through 7.

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

   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 [RFC2119].  It is also
   assumed the reader has some knowledge of the Domain Name System
   [RFC1035].

2.  Threat Model

   The Domain Name System (DNS) protocol has been the target of several
   well-publicized attacks since it's creation.  These attacks are
   centered on altering 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 of the DNS security extensions is to protect the integrity
   of DNS data and provide a means of source and data authentication.
   No effort has been made to protect against other forms of attack such
   as attacks against server implementations and denial of service.


3. Services Provided by 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 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 of the zone, it can authenticate signed zone
   data.  The data origin authentication key(s) are associated with the
   zone and not with the servers that store copies of the zone data.

   A resolver could learn a public key of a zone either by reading it
   from the DNS or by having it statically configured.  To reliably
   learn a public key by reading it from the DNS, the learned key itself
   must be signed with a key the resolver trusts.  New zone information
   is authenticated by forming a "chain of trust" from a newly learned
   zone back to a trusted (pre-configured or previously learned) zone
   key.  Therefore, the resolver must be configured with at least a
   public key that authenticates one zone as a starting point.  To
   establish this chain of trust, security aware servers attempt to send
   the signature(s) needed to authenticate 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 to
   the "on-the-wire" DNS protocol beyond the addition of the signature
   resource type (SIG record) and the key resource type (KEY record)
   needed for key distribution.  Existing resolver and caching server
   implementations can support this service so long as they can support
   the new resource record types.


3.2 Key Distribution

   A resource record format is defined to associate public keys with DNS
   names.  This permits the DNS to be used as a public key distribution
   mechanism in support of DNS security itself and other protocols.
   Security aware resolvers can query for a zone's or other entities'
   public key when establishing a chain of trust.

   The syntax of a KEY resource record (RR) is described in a separate
   document [proto ref].  It includes identifiers for 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 sign existing
   RRsets in a zone.  The problem of sending negative responses with the



Massey, Rose                                                    [Page 3]


INTERNET-DRAFT       DNSSEC Intro. and Requirements            June 2001


   same level of authentication and integrity requires the use of the
   Non-existence (NXT) record type.  The NXT record allows a negative
   reply (either for name or type non-existence) to be authenticated the
   same way other DNS replies.  NXT records exist to cover the gaps in
   the canonical representation of a zone namespace.  Each NXT record is
   signed and authenticated the same way as any other RRset in the DNS.


3.4  Transaction Security

   The data origin authentication service described above protects
   retrieved resource records and the non-existence of resource records
   but provides no protection for complete DNS messages, including zone
   transfers and dynamic updates.

   DNS message can be authenticated by including a special signature RR
   at the end of the request, either a Transaction SIG (TSIG) or SIG[0]
   [Proto doc ref].  A Transaction signature included at the end of a
   response can be used to verify the integrity of the DNS message.
   Authenticating requests serves no function in older DNS servers and
   requests with a non-empty additional information section may produce
   error returns or be ignored. Unlike the SIG RR discussed above,
   transaction security involves the individual host machines in the DNS
   message transaction, so the cryptographic keys used in with
   transaction security are associated with individual systems and not
   DNS zones.

   In addition to the ability to use transaction signatures, there is
   additional support for the use of key agreement protocols to support
   transaction security using symmetric encryption keys.  This service
   uses the transaction key (TKEY) 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
   for each algorithm.


4. What Services Are Not Provided

   It is part of the design philosophy of the DNS that the data in it is
   public and that the DNS gives 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 has been made to provide for any confidentiality for
   queries or responses.

   Denial of service is not protected against.



Massey, Rose                                                    [Page 4]


INTERNET-DRAFT       DNSSEC Intro. and Requirements            June 2001


   The use of SIGs in a zone and/or 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
   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 known secure public key.  This might require
   additional queries to intermediate DNS zones for necessary keys and
   signatures.  It is assumed that a security aware resolver will be
   pre-configured with at least one public key to aid in this.

   The stub resolver found in many host systems 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 to secure the final message passing
   between a stub resolver and a primary recursive DNS server.  It is a
   matter of local security policy.

   It is necessary for a security aware resolver only communicate with
   security aware servers.  If an unsecure server or an unsecure zone is
   part of the DNS chain, the resolver cannot insure security.  If a
   security aware resolver must rely on an unsecure server (or unsigned
   zone), it is not possible for the resolver to verify DNS responses,
   and should rely on local policy when trusting responses.


6. Zone Considerations

   A secure zone will have several differences from an unsecure zone.  A
   secure zone will have additional security records (SIG, KEY, and NXT
   records) added to the zone data.  It is possible that the security
   records are added before the zone is loaded by a server.  In this
   case, the server must generate the signatures and NXT records before
   loading the zone.  Also, zone information is only valid and
   considered secure for a definable time period.  The SIG records that
   accompany zone data have a defined inception and expiration times.
   These times establish a validity period for the signatures and the
   zone data the signatures covers.


7.  Server Considerations

   A security aware server must be capable of performing the following



Massey, Rose                                                    [Page 5]


INTERNET-DRAFT       DNSSEC Intro. and Requirements            June 2001


   additional operations, in addition to the normal operations of a DNS
   zone server described in [RFC1035]:

   A security aware server should make all attempts to include necessary
   security related records in DNS responses.  This includes all
   necessary signatures and public key records, as DNS message space
   permits.

   A caching security aware server must also take the signatures
   validation period into consideration when determining the Time-To-
   Live (TTL) of cached data.

   A security aware server should have a means of employing transaction
   security such as transactions 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 administration access to a security aware server falls under the
   category 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 into five main groups
   as depicted in Figure 1.  All of these documents in turn are under
   the larger umbrella group of DNS base protocol documents.


8.1  DNS Security Document Roadmap


                    +--------------------------------+
                    |                                |
                    |    Base DNS Protocol Docs.     |
                    |   [RFC1035, RFC2181, etc.]     |
                    |                                |
                    +--------------------------------+
                                    |
                                    |
                              +-----------+          +-------------+
                              |  DNSSEC   |          |  New        |
                              | protocol  |<-------->|  Security   |
                              | documents |          |  Uses       |
                              +-----------+          +-------------+
                                    |



Massey, Rose                                                    [Page 6]


INTERNET-DRAFT       DNSSEC Intro. and Requirements            June 2001


                                    |
                     +------------------------------+
                     |                              |
                     |                              |
               +------------+               +---------------+
               |  DS        |               |               |
               |  Algorithm |               |  Transaction  |
               |  Impl.     |               |  Impl.        |
               |            |               |               |
               +------------+               +---------------+
                     Figure 1  DNSSEC Document Roadmap


8.2 Categories of DNS Security Documents

   The "DNSSEC protocol" document set refers to the document that makes
   up the groundwork for adding security to the DNS protocol [protocol
   doc ref].

   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.

   The "Transactions" document set refers to the group of documents that
   deal with the message transaction sequence of security-related DNS
   operations.  Message transaction schemes to support DNSSEC operation
   fall under this group, 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 and
   individual user public keys (PGP, e-mail, etc.)


9. 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 and source
   authentication and integrity through the use of 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.




Massey, Rose                                                    [Page 7]


INTERNET-DRAFT       DNSSEC Intro. and Requirements            June 2001


   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.


10. Acknowledgements

   This document was created from the input and ideas of several members
   of the DNS Extensions WG.  The authors would like to acknowledge the
   following people 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 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 and
   Specifications", STD 13, RFC 1035, November 1987.

   [RFC2181] Elz, R. 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                                                    [Page 8]


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



Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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."







Massey, Rose                                                    [Page 9]