Ignore machine-check MSRs

[freebsd-src/fkvm-freebsd.git] / contrib / bind9 / doc / draft / draft-baba-dnsext-acl-reqts-01.txt

Internet-Draft                                                   T. Baba
Expires: March 11, 2004                                         NTT Data
                                                      September 11, 2003


         Requirements for Access Control in Domain Name Systems
                   draft-baba-dnsext-acl-reqts-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

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

   Distribution of this memo is unlimited.

   This Internet-Draft will expire on March 11, 2004.

Abstract

   This document describes the requirements for access control
   mechanisms in the Domain Name System (DNS), which authenticate
   clients and then allow or deny access to resource records in the
   zone according to the access control list (ACL).

1. Introduction

   The Domain Name System (DNS) is a hierarchical, distributed, highly
   available database used for bi-directional mapping between domain
   names and IP addresses, for email routing, and for other information
   [RFC1034, 1035].  DNS security extensions (DNSSEC) have been defined
   to authenticate the data in DNS and provide key distribution services
   using SIG, KEY, and NXT resource records (RRs) [RFC2535].



Baba                     Expires March 11, 2004                 [Page 1]
\f
Internet-Draft       DNS Access Control Requirements      September 2003


   At the 28th IETF Meeting in Houston in 1993, DNS security design team
   started a discussion about DNSSEC and agreed to accept the assumption
   that "DNS data is public".  Accordingly, confidentiality for queries
   or responses is not provided by DNSSEC, nor are any sort of access
   control lists or other means to differentiate inquirers.  However,
   about ten years has passed, access control in DNS has been more
   important than before.  Currently, new RRs are proposed to add new
   functionality to DNS such as ENUM [RFC2916].  Such new RRs may
   contain private information.  Thus, DNS access control will be
   needed.

   Furthermore, with DNS access control mechanism, access from
   unauthorized clients can be blocked when they perform DNS name
   resolution.  Thus, for example, Denial of Service (DoS) attacks
   against a server used by a closed user group can be prevented using
   this mechanism if IP address of the server is not revealed by other
   sources.

   This document describes the requirements for access control
   mechanisms in DNS.

2. Terminology

   AC-aware client
      This is the client that understands the DNS access control
      extensions. This client may be an end host which has a stub
      resolver, or a cashing/recursive name server which has a
      full-service resolver.

   AC-aware server
      This is the authoritative name server that understands the DNS
      access control extensions.

   ACE
      An Access Control Entry.  This is the smallest unit of access
      control policy.  It grants or denies a given set of access
      rights to a set of principals.  An ACE is a component of an ACL,
      which is associated with a resource.

   ACL
      An Access Control List.  This contains all of the access control
      policies which are directly associated with a particular
      resource.  These policies are expressed as ACEs.

   Client
      A program or host which issues DNS requests and accepts its
      responses. A client may be an end host or a cashing/recursive name
      server.



Baba                     Expires March 11, 2004                 [Page 2]
\f
Internet-Draft       DNS Access Control Requirements      September 2003


   RRset
      All resource records (RRs) having the same NAME, CLASS and TYPE
      are called a Resource Record Set (RRset).

3. Requirements

   This section describes the requirements for access control in DNS.

3.1 Authentication

3.1.1 Client Authentication Mechanism

   The AC-aware server must identify AC-aware clients based on IP
   address and/or domain name (user ID or host name), and must
   authenticate them using strong authentication mechanism such as
   digital signature or message authentication code (MAC).

   SIG(0) RR [RFC2931] contains a domain name associated with sender's
   public key in its signer's name field, and TSIG RR [RFC2845] also
   contains a domain name associated with shared secret key in its key
   name field.  Each of these domain names can be a host name or a user
   name, and can be used as a sender's identifier for access control.
   Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for
   message authentication.  These mechanisms can be used to authenticate
   AC-aware clients.

   Server authentication may be also provided.

3.1.2 End-to-End Authentication

   In current DNS model, caching/recursive name servers are deployed
   between end hosts and authoritative name servers.  Although
   authoritative servers can authenticate caching/recursive name servers
   using SIG(0) or TSIG, they cannot authenticate end hosts behind them.
   For end-to-end authentication, the mechanism for an end host to
   discover the target authoritative name server and directly access to
   it bypassing caching/recursive name servers is needed.  For example,
   an end host can get the IP addresses of the authoritative name
   servers by retrieving NS RRs for the zone via local caching/recursive
   name server.

   In many enterprise networks, however, there are firewalls that block
   all DNS packets other than those going to/from the particular
   caching/recursive servers.  To deal with this problem, one can
   implement packet forwarding function on the caching/recursive servers
   and enable end-to-end authentication via the caching/recursive
   servers.




Baba                     Expires March 11, 2004                 [Page 3]
\f
Internet-Draft       DNS Access Control Requirements      September 2003


3.1.3 Authentication Key Retrieval

   Keys which are used to authenticate clients should be able to be
   automatically retrieved.  The KEY RR is used to store a public key
   for a zone or a host that is associated with a domain name.  SIG(0)
   RR uses a public key in KEY RR for verifying the signature.  If
   DNSSEC is available, the KEY RR would be protected by the SIG RR.
   KEY RR or newly defined RR can be used to automatic key retrieval.

3.2 Confidentiality

3.2.1 Data Encryption

   To avoid disclosure to eavesdroppers, the response containing the
   RRsets which are restricted to access from particular users should be
   encrypted.  Currently, no encryption mechanism is specified in DNS.
   Therefore, new RRs should be defined for DNS message encryption.
   Instead, IPsec [RFC2401] can be used to provide confidentiality if
   name server and resolver can set up security associations dynamically
   using IPsec API [IPSECAPI] when encryption is required.

   In case encryption is applied, entire DNS message including DNS
   header should be encrypted to hide information including error code.

   Query encryption may be also provided for hiding query information.

3.2.2 Key Exchange

   If DNS message encryption is provided, automatic key exchange
   mechanism should be also provided.  [RFC2930] specifies a TKEY RR
   that can be used to establish and delete shared secret keys used by
   TSIG between a client and a server.  With minor extensions, TKEY can
   be used to establish shared secret keys used for message encryption.

3.2.3 Caching

   The RRset that is restricted to access from particular users must not
   be cached.  To avoid caching, the TTL of the RR that is restricted to
   access should be set to zero during transit.

3.3 Access Control

3.3.1 Granularity of Access Control

   Control of access on a per-user/per-host granularity must be
   supported.  Control of access to individual RRset (not just the
   entire zone) must be also supported.  However, SOA, NS, SIG, NXT,
   KEY, and DS RRs must be publicly accessible to avoid unexpected
   results.
   

Baba                     Expires March 11, 2004                 [Page 4]
\f
Internet-Draft       DNS Access Control Requirements      September 2003


3.3.2 ACL Representation

   Access Control List (ACL) format must be standardized so that both
   the primary and secondary AC-aware servers can recognize the same
   ACL.  Although ACL may appear in or out of zone data, it must be
   transferred to the secondary AC-aware server with associated zone
   data.  It is a good idea to contain ACL in zone data, because ACL can
   be transferred with zone data using existing zone transfer mechanisms
   automatically.  However, ACL must not be published except for
   authorized secondary master servers.
   
   In zone data master files, ACL should be specified using TXT RRs or
   newly defined RRs.  In each access control entry (ACE), authorized
   entities (host or user) must be described using domain name (host
   name, user name, or IP address in in-addr.arpa/ip6.arpa format).
   There may be other access control attributes such as access time.

   It must be possible to create publicly readable entries, which may be
   read even by unauthenticated clients.

3.3.3 Zone/ACL Transfer

   As mentioned above, ACL should be transferred from a primary AC-aware
   server to a secondary AC-aware server with associated zone data.
   When an AC-aware server receives a zone/ACL transfer request, the
   server must authenticate the client, and should encrypt the zone
   data and associated ACL during transfer.

3.4 Backward/co-existence Compatibility

   Any new protocols to be defined for access control in DNS must be
   backward compatible with existing DNS protocol.  AC-aware servers
   must be able to process normal DNS query without authentication, and
   must respond if retrieving RRset is publicly accessible.
   
   Modifications to root/gTLD/ccTLD name servers are not allowed.

4. Security Considerations

   This document discusses the requirements for access control
   mechanisms in DNS.

5. Acknowledgements

   This work is funded by the Telecommunications Advancement
   Organization of Japan (TAO).

   The author would like to thank the members of the NTT DATA network
   security team for their important contribution to this work.


Baba                     Expires March 11, 2004                 [Page 5]
\f
Internet-Draft       DNS Access Control Requirements      September 2003


6. References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
              "Secret Key Transaction Authentication for DNS (TSIG)", 
              RFC 2845, May 2000.

   [RFC2916]  Faltstrom, P., "E.164 number and DNS", RFC 2916,
              September 2000.

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

   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
              (SIG(0)s)", RFC 2931, September 2000.

   [IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API",
              draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in
              Progress.


Author's Address

   Tatsuya Baba
   NTT Data Corporation
   Research and Development Headquarters
   Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku,
   Tokyo 104-0033, Japan
   
   Tel: +81 3 3523 8081
   Fax: +81 3 3523 8090
   Email: babatt@nttdata.co.jp








Baba                     Expires March 11, 2004                 [Page 6]