Commit 365ca350 authored by Mark Andrews's avatar Mark Andrews
Browse files

new draft

parent 7ec0f55f
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]
......@@ -7,7 +7,7 @@ Expires August 2003 February 2003
Domain Name System (DNS) Case Insensitivity Clarification
------ ---- ------ ----- ---- ------------- -------------
<draft-ietf-dnsext-insensitive-01.txt>
<draft-ietf-dnsext-insensitive-02.txt>
Donald E. Eastlake 3rd
......@@ -46,7 +46,7 @@ Abstract
Copyright (C) 2003 The Internet Society. All Rights Reserved.
......@@ -63,8 +63,8 @@ INTERNET-DRAFT DNS Case Insensitivity
Acknowledgements
The contributions to this document of Rob Austein, Olafur
Gudmundsson, Daniel J. Anderson, Alan Barrett, and Andrew Main are
gratefully acknowledged.
Gudmundsson, Daniel J. Anderson, Alan Barrett, Dana, Andrew Main, and
Scott Seligman are gratefully acknowledged.
......@@ -194,7 +194,7 @@ INTERNET-DRAFT DNS Case Insensitivity
preceding them with a back-slash. This is the most commonly used
technique for protecting back slash ("\") and period ("."). However,
it is advisable to avoid using this on other than printing ASCII
characters.
characters to avoid implementation difficulties.
......@@ -283,7 +283,7 @@ INTERNET-DRAFT DNS Case Insensitivity
3.2 Extended Label Type Case Insensitivity Considerations
DNS was extended by [RFC 2671] to have additional label type numbers
available. (The only such type defined so far it the BINARY type [RFC
available. (The only such type defined so far is the BINARY type [RFC
D. Eastlake 3rd [Page 5]
......@@ -333,8 +333,8 @@ INTERNET-DRAFT DNS Case Insensitivity
[STD 13]. DNS Dynamic update has been added as a source of DNS data
[RFC 2136, 3007]. When a node in the DNS name tree is created by such
input, no case conversion is done and the case of ASCII labels is
preserved if they are for nodes being creted. However, no change is
made in the name label on nodes that already exist is the DNS data
preserved if they are for nodes being created. However, no change is
made in the name label on nodes that already exist in the DNS data
being augmented or updated. It is quite common for higher level nodes
to already exist.
......@@ -351,11 +351,11 @@ INTERNET-DRAFT DNS Case Insensitivity
this case can easily result is obtaining data with "xyz.BAR.example".
The same considerations apply inputting multiple data records with
owner names differing only in case. From the example above, if an "A"
record is stored under owner name "xyz.BAR.example" and then a second
"A" record under "XYZ.BAR.example", the second will be stored at the
node with the first (lower case initial label) name.
The same considerations apply when inputting multiple data records
with owner names differing only in case. From the example above, if
an "A" record is stored under owner name "xyz.BAR.example" and then a
second "A" record under "XYZ.BAR.example", the second will be stored
at the node with the first (lower case initial label) name.
Note that the order of insertion into a server database of the DNS
name tree nodes that appear in a Master File is not defined so that
......@@ -369,7 +369,7 @@ INTERNET-DRAFT DNS Case Insensitivity
There is one additional instance of note, which reflects the general
rules that output case reflects input case unless there is
conflicting capitalization in the DNS database or the output case is
hidden by name compression. This is when a query matches a wild card
hidden by name compression. This is when a query matches a wildcard
in the DNS database at a server. In that case, the answer SHOULD
reflect the input case of the label or labels that matched the
wildcard unless they are replaced by an indirect label which MAY
......@@ -542,7 +542,7 @@ Expiration and File Name
This draft expires August 2003.
Its file name is draft-ietf-dnsext-insensitive-01.txt.
Its file name is draft-ietf-dnsext-insensitive-02.txt.
......
This diff is collapsed.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment