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]
|