Subject: I-D regarding access control in DNS

From: Tatsuya Baba <[email-masked]>
Date: Thu, 06 Feb 2003 00:14:15 +0900

Hi all,

I wrote an I-D regarding access control in DNS.

   draft-baba-dnsext-acl-reqts-00.txt

I know that DNSSEC specification states "the DNS design philosophy calls
for all DNS data to be public."  However, I also know that there are
many people who would like to control access to DNS data.

Is there anyone who is interested in this area?

Any comments, questions, or corrections are appreciated.

Regards.

-- Tatsuya Baba

-------- Original Message --------
Subject: I-D ACTION:draft-baba-dnsext-acl-reqts-00.txt
Date: Wed, 05 Feb 2003 06:44:12 -0500
From: [email-masked]
Reply-To: [email-masked]
To: IETF-Announce: ;

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Requirements for Access Control in Domain Name Systems
	Author(s)	: T. Baba
	Filename	: draft-baba-dnsext-acl-reqts-00.txt
	Pages		: 6
	Date		: 2003-2-4
	
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).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-baba-dnsext-acl-reqts-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-baba-dnsext-acl-reqts-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-baba-dnsext-acl-reqts-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 5 Feb 2003 12:25:56 -0500

I don't know if this is something the WG should be looking at.  Besides
making a decision not to include confidentiality into the DNSSEC extensions
and I believe there are good reasons not too:

1.  Many DNS implementations have some sort of acl functionality built in.
It is also easier to do access control outside of the DNS protocol.
2. IPSec can be used to provide confidentiality at a lower level (hard to
imagine DNS would be the only network traffic that a network wants
encrypted).

minor problems
3.  New records will have to be introduced for the ACL (TXT RRs probably
won't do),
4.  new RCODEs would have to be introduced/redefined for security.  That
might affect backwards compatibility when older resolvers try to communicate
with a AC aware server.

I do not believe that the benefit of adding this functionality outweights
the cost and burden it would place on the DNS.  This benefit already exists
to some degree by other protocols and implementations.

Scott

---

From: Tatsuya Baba <[email-masked]>
Date: Mon, 10 Feb 2003 18:28:33 +0900

Scott, thank you for your comments.

> It is also easier to do access control outside of the DNS protocol.

Yes.
I know that BIND has access control functionality based on TSIG, but I
think that TSIG does not scale.
Moreover, BIND controls access based on entire zone (not indivisual
RRset).

But I don't know about other implementations.

> imagine DNS would be the only network traffic that a network wants

If the authoritative name server is also deployed in the network
protected by IPsec, this is the case.

IPsec can be used to provide confidentiality if resolver can control
IPsec policy and set up security associations between clients and
authoritative name servers when required.  But I think it is difficult.

> 3.  New records will have to be introduced for the ACL (TXT RRs probably

Yes. I think new RRs should be introduced.

> might affect backwards compatibility when older resolvers try to communicate

It might be, but I would like to avoid discussions about actual
protocols now.  I think this functionality should not affect existing
resolvers.

> to some degree by other protocols and implementations.

It is not required to introduce this functionaly on root/TLD servers.
Only those who want to control access to RRsets on their name servers
should introduce this functionality on their servers and their user's
clients.

To summarize draft,

1) client identification and authentication using SIG(0) (or TSIG)
2) direct communication between client and server
   (bypassing caching name server)
3) ACL in zone file using new RR (or TXT RR?)
4) DNS message encryption using new RR (or IPsec?)

Above (1) and (2) do not affect existing DNS protocol.
(3) and (4) require standard action, but if TXT RR and IPsec can be
used for this, no standard action is needed.

This draft is intended for starting point of discussions.
Any comments are appreciated.

-- Tatsuya Baba