337 lines
11 KiB
Plaintext
337 lines
11 KiB
Plaintext
|
|
|
|
|
|
|
|
Internet-Draft T. Baba
|
|
Expires: August 4, 2003 NTT Data
|
|
February 4, 2003
|
|
|
|
|
|
Requirements for Access Control in Domain Name Systems
|
|
draft-baba-dnsext-acl-reqts-00.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 August 4, 2003.
|
|
|
|
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 August 4, 2003 [Page 1]
|
|
|
|
Internet-Draft DNS Access Control Requirements February 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. 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.
|
|
|
|
RRset
|
|
All resource records (RRs) having the same NAME, CLASS and TYPE
|
|
are called a Resource Record Set (RRset).
|
|
|
|
|
|
|
|
|
|
Baba Expires August 4, 2003 [Page 2]
|
|
|
|
Internet-Draft DNS Access Control Requirements February 2003
|
|
|
|
|
|
3. Requirements
|
|
|
|
This section describes the requirements for access control in DNS.
|
|
|
|
3.1 Authentication
|
|
|
|
3.1.1 Client Identifier / 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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Baba Expires August 4, 2003 [Page 3]
|
|
|
|
Internet-Draft DNS Access Control Requirements February 2003
|
|
|
|
|
|
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. Although IPsec can be used to encrypt DNS packets, it
|
|
authenticates a peer based on IP address. Currently, no encryption
|
|
mechanism is specified in DNS. Therefore, new RRs must be defined
|
|
for DNS message encryption. In case encryption is applied, entire
|
|
DNS message including DNS header must be encrypted to hide
|
|
information including error code.
|
|
|
|
Query encryption may be also provided.
|
|
|
|
3.2.2 Key Exchange
|
|
|
|
If DNS message encryption is provided, automatic key exchange
|
|
mechanism must 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 August 4, 2003 [Page 4]
|
|
|
|
Internet-Draft DNS Access Control Requirements February 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 August 4, 2003 [Page 5]
|
|
|
|
Internet-Draft DNS Access Control Requirements February 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.
|
|
|
|
[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.
|
|
|
|
[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.
|
|
|
|
|
|
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 August 4, 2003 [Page 6]
|