Internet DRAFT - draft-baba-dnsext-acl-reqts

draft-baba-dnsext-acl-reqts




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



         Requirements for Access Control in Domain Name Systems
                   draft-baba-dnsext-acl-reqts-02.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 September 30, 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 September 30, 2004               [Page 1]
Internet-Draft       DNS Access Control Requirements          March 2004



   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 September 30, 2004               [Page 2]
Internet-Draft       DNS Access Control Requirements          March 2004



   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.


   It is noted that if TSIG is used, secret keys for MAC authentication 
   should be shared between AC-aware server and AC-aware client in 
   advance.


   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.








Baba                   Expires September 30, 2004               [Page 3]
Internet-Draft       DNS Access Control Requirements          March 2004



   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
   which forwards DNS messages with SIG(0) RR or TSIG RR to the AC-aware
   server without making any changes, and enable end-to-end
   authentication via the caching/recursive servers.


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 proposed 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 using secret key algorithms,
   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.




Baba                   Expires September 30, 2004               [Page 4]
Internet-Draft       DNS Access Control Requirements          March 2004



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.


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 at the same time.  It is good 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 described 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.


   Sample ACL formats in zone data are shown below:


   1) In case of using TXT RR for specifying permitted users:


      www       IN      A       10.0.0.52
                IN      TXT     "ACL A haruka@example.com"
                IN      TXT     "ACL A *@example.net"
                IN      AAAA    4321:0:1:2:3:4:567:89ab
                IN      TXT     "ACL AAAA haruka@example.com"
                IN      TXT     "ACL AAAA *@example.net"


   2) In case of using newly defined RR (for example, ACL RR)
      for specifying permitted users:


      www       IN      A       10.0.0.52
                IN      ACL     A haruka@example.com
                IN      ACL     A  *@example.net
                IN      AAAA    4321:0:1:2:3:4:567:89ab
                IN      ACL     AAAA haruka@example.com
                IN      ACL     AAAA *@example.net





Baba                   Expires September 30, 2004               [Page 5]
Internet-Draft       DNS Access Control Requirements          March 2004



   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 September 30, 2004               [Page 6]
Internet-Draft       DNS Access Control Requirements          March 2004



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 8082
   Fax: +81 3 3523 8092
   Email: babatt@nttdata.co.jp








Baba                   Expires September 30, 2004               [Page 7]