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]