337 lines
12 KiB
Plaintext
337 lines
12 KiB
Plaintext
|
||
|
||
|
||
|
||
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]
|