draft-baba-dnsext-acl-reqts-01.txt [plain text]
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]