rfc2065.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,439 行 · 第 1/5 页

Network Working Group                                   D. Eastlake, 3rd
Request for Comments: 2065                                     CyberCash
Updates: 1034, 1035                                           C. Kaufman
Category: Standards Track                                           Iris
                                                            January 1997


                 Domain Name System Security Extensions

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   The Domain Name System (DNS) has become a critical operational part
   of the Internet infrastructure yet it has no strong security
   mechanisms to assure data integrity or authentication.  Extensions to
   the DNS are described that provide these services to security aware
   resolvers or applications through the use of cryptographic digital
   signatures.  These digital signatures are included in secured zones
   as resource records.  Security can still be provided even through
   non-security aware DNS servers in many cases.

   The extensions also provide for the storage of authenticated public
   keys in the DNS.  This storage of keys can support general public key
   distribution service as well as DNS security.  The stored keys enable
   security aware resolvers to learn the authenticating key of zones in
   addition to those for which they are initially configured.  Keys
   associated with DNS names can be retrieved to support other
   protocols.  Provision is made for a variety of key types and
   algorithms.

   In addition, the security extensions provide for the optional
   authentication of DNS protocol transactions.












Eastlake & Kaufman          Standards Track                     [Page 1]

RFC 2065                DNS Security Extensions             January 1997


Acknowledgments

   The significant contributions of the following persons (in alphabetic
   order) to this document are gratefully acknowledged:

           Harald T. Alvestrand
           Madelyn Badger
           Scott Bradner
           Matt Crawford
           James M. Galvin
           Olafur Gudmundsson
           Edie Gunter
           Sandy Murphy
           Masataka Ohta
           Michael A. Patton
           Jeffrey I. Schiller

Table of Contents

   1. Overview of Contents....................................3
   2.  Overview of the DNS Extensions.........................4
   2.1 Services Not Provided..................................4
   2.2 Key Distribution.......................................5
   2.3 Data Origin Authentication and Integrity...............5
   2.3.1 The SIG Resource Record..............................6
   2.3.2 Authenticating Name and Type Non-existence...........7
   2.3.3 Special Considerations With Time-to-Live.............7
   2.3.4 Special Considerations at Delegation Points..........7
   2.3.5 Special Considerations with CNAME RRs................8
   2.3.6 Signers Other Than The Zone..........................8
   2.4 DNS Transaction and Request Authentication.............8
   3. The KEY Resource Record.................................9
   3.1 KEY RDATA format......................................10
   3.2 Object Types, DNS Names, and Keys.....................10
   3.3 The KEY RR Flag Field.................................11
   3.4 The Protocol Octet....................................13
   3.5 The KEY Algorithm Number and the MD5/RSA Algorithm....13
   3.6 Interaction of Flags, Algorithm, and Protocol Bytes...14
   3.7 KEY RRs in the Construction of Responses..............15
   3.8 File Representation of KEY RRs........................16
   4. The SIG Resource Record................................16
   4.1 SIG RDATA Format......................................17
   4.1.1 Signature Data......................................19
   4.1.2 MD5/RSA Algorithm Signature Calculation.............20
   4.1.3 Zone Transfer (AXFR) SIG............................21
   4.1.4 Transaction and Request SIGs........................22
   4.2 SIG RRs in the Construction of Responses..............23
   4.3 Processing Responses and SIG RRs......................24



Eastlake & Kaufman          Standards Track                     [Page 2]

RFC 2065                DNS Security Extensions             January 1997


   4.4 Signature Expiration, TTLs, and Validity..............24
   4.5 File Representation of SIG RRs........................25
   5. Non-existent Names and Types...........................26
   5.1 The NXT Resource Record...............................26
   5.2 NXT RDATA Format......................................27
   5.3 Example...............................................28
   5.4 Interaction of NXT RRs and Wildcard RRs...............28
   5.5 Blocking NXT Pseudo-Zone Transfers....................29
   5.6 Special Considerations at Delegation Points...........29
   6. The AD and CD Bits and How to Resolve Securely.........30
   6.1 The AD and CD Header Bits.............................30
   6.2 Boot File Format......................................32
   6.3 Chaining Through Zones................................32
   6.4 Secure Time...........................................33
   7. Operational Considerations.............................33
   7.1 Key Size Considerations...............................34
   7.2 Key Storage...........................................34
   7.3 Key Generation........................................35
   7.4 Key Lifetimes.........................................35
   7.5 Signature Lifetime....................................36
   7.6 Root..................................................36
   8. Conformance............................................36
   8.1 Server Conformance....................................36
   8.2 Resolver Conformance..................................37
   9. Security Considerations................................37
   References................................................38
   Authors' Addresses........................................39
   Appendix: Base 64 Encoding................................40

1. Overview of Contents

   This document describes extensions of the Domain Name System (DNS)
   protocol to support DNS security and public key distribution.  It
   assumes that the reader is familiar with the Domain Name System,
   particularly as described in RFCs 1033, 1034, and 1035.

   Section 2 provides an overview of the extensions and the key
   distribution, data origin authentication, and transaction and request
   security they provide.

   Section 3 discusses the KEY resource record, its structure, use in
   DNS responses, and file representation.  These resource records
   represent the public keys of entities named in the DNS and are used
   for key distribution.







Eastlake & Kaufman          Standards Track                     [Page 3]

RFC 2065                DNS Security Extensions             January 1997


   Section 4 discusses the SIG digital signature resource record, its
   structure, use in DNS responses, and file representation.  These
   resource records are used to authenticate other resource records in
   the DNS and optionally to authenticate DNS transactions and requests.

   Section 5 discusses the NXT resource record and its use in DNS
   responses.  The NXT RR permits authenticated denial in the DNS of the
   existence of a name or of a particular type for an existing name.

   Section 6 discusses how a resolver can be configured with a starting
   key or keys and proceed to securely resolve DNS requests.
   Interactions between resolvers and servers are discussed for all
   combinations of security aware and security non-aware.  Two
   additional query header bits are defined for signaling between
   resolvers and servers.

   Section 7 reviews a variety of operational considerations including
   key generation, lifetime, and storage.

   Section 8 defines levels of conformance for resolvers and servers.

   Section 9 provides a few paragraphs on overall security
   considerations.

   An Appendix is provided that gives details of base 64 encoding which
   is used in the file representation of some RR's defined in this
   document.

2.  Overview of the DNS Extensions

   The Domain Name System (DNS) protocol security extensions provide
   three distinct services: key distribution as described in Section 2.2
   below, data origin authentication as described in Section 2.3 below,
   and transaction and request authentication, described in Section 2.4
   below.

   Special considerations related to "time to live", CNAMEs, and
   delegation points are also discussed in Section 2.3.

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




Eastlake & Kaufman          Standards Track                     [Page 4]

RFC 2065                DNS Security Extensions             January 1997


   In addition, no effort has been made to provide for any
   confidentiality for queries or responses.  (This service may be
   available via IPSEC [RFC 1825].)

2.2 Key Distribution

   Resource records (RRs) are defined to associate keys with DNS names.
   This permits the DNS to be used as a public key distribution
   mechanism in support of the DNS data origin authentication and other
   security services.

   The syntax of a KEY resource record (RR) is described in Section 3.
   It includes an algorithm identifier, the actual public key
   parameters, and a variety of flags including those indicating the
   type of entity the key is associated with and/or asserting that there
   is no key associated with that entity.

   Under conditions described in Section 3.7, security aware DNS servers
   will automatically attempt to return KEY resources as additional
   information, along with those resource records actually requested, to
   minimize the number of queries needed.

2.3 Data Origin Authentication and Integrity

   Authentication is provided by associating with resource records in
   the DNS cryptographically generated digital signatures.  Commonly,
   there will be a single private key that signs for an entire zone. If
   a security aware resolver reliably learns the public key of the zone,
   it can verify, for signed data read from that zone, that it was
   properly authorized and is reasonably current.  The expected
   implementation is for the zone private key to be kept off-line and
   used to re-sign all of the records in the zone periodically.

   This data origin authentication key belongs to the zone and not to
   the servers that store copies of the data.  That means compromise of
   a server or even all servers for a zone will not necessarily affect
   the degree of assurance that a resolver has that it can determine
   whether data is genuine.

   A resolver can learn the public key of a zone either by reading it
   from DNS or by having it staticly configured.  To reliably learn the
   public key by reading it from DNS, the key itself must be signed.
   Thus, to provide a reasonable degree of security, the resolver must
   be configured with at least the public key of one zone that it can
   use to authenticate signatures.  From there, it can securely read the
   public keys of other zones, if the intervening zones in the DNS tree
   are secure and their signed keys accessible.  (It is in principle
   more secure to have the resolver manually configured with the public



Eastlake & Kaufman          Standards Track                     [Page 5]

RFC 2065                DNS Security Extensions             January 1997


   keys of multiple zones, since then the compromise of a single zone
   would not permit the faking of information from other zones.  It is