diff options
Diffstat (limited to 'doc/draft/draft-baba-dnsext-acl-reqts-01.txt')
| -rw-r--r-- | doc/draft/draft-baba-dnsext-acl-reqts-01.txt | 336 |
1 files changed, 336 insertions, 0 deletions
diff --git a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt new file mode 100644 index 0000000..1030e57 --- /dev/null +++ b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt @@ -0,0 +1,336 @@ + + + + +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] + +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] + +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] + +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] + +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] + +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] |