Subject: RE: I-D regarding access control in DNS

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 5 Feb 2003 09:14:58 -0800

Attempting to move from a public protocol to a private one is difficult.

A particular problem that you would face is the fact that
implementations are likely to cache information and forward it in ways
that do not conform with the access control policy that you are
attempting to impose.

Furthermore DNS stacks are deep integrated into O/S layers so you have
the potential for lots of confusion if person A who is not authorized to
know X puts in a request before person B who is. 

This problem has hit the WebDav group which has been suggesting all
manner of unlikely solutions. The proposal 'don't try caching then'
falling on stony ground.

If you really want to do this you will also need privacy enhancements to
the DNS protocol. So you are going to end up requiring a key agreement.
So why not do a key agreement against a separate service, perform any
access control you might want to do at that point and then use a
cryptographic encapsulation?

That would appear to describe IPSEC.

Incidentally the lack of access control is one reason why it is not a
good idea to attempt to lard every possible lookup function into the
DNS. 

		Phill

> -----Original Message-----
> From: Tatsuya Baba [mailto:[email-masked]]
> Sent: Wednesday, February 05, 2003 10:14 AM
> To: [email-masked]
> Subject: I-D regarding access control in DNS
> 
> 
> 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: Tatsuya Baba <[email-masked]>
Date: Mon, 10 Feb 2003 18:22:16 +0900

Phillip, thank you for your comments.

> that do not conform with the access control policy that you are

I understand that there is a caching problem (section 3.2.3).

There might be implementations that cache RRs whose TTL is zero.

I think that direct communication between client and server, bypassing
caching name server, is needed.

> That would appear to describe IPSEC.

If IPsec is applicable for this, I think it is OK.
In this case, resolver must control IPsec policy.
For example, when AC-aware client accesses to an RRset on AC-aware
server, it should use IPsec. But when it accesses to an RRset on
normal name server, it should not use IPsec.

> good idea to attempt to lard every possible lookup function into the

AC-aware resolver usually behaves as a normal resolver.
When the host lookups RRs in access-controlled zones, it uses SIG(0) for
authentication.

-- Tatsuya Baba

--
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: Robert Elz <[email-masked]>
Date: Mon, 10 Feb 2003 18:06:08 +0700

Date:        Mon, 10 Feb 2003 18:22:16 +0900
    From:        Tatsuya Baba <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think that direct communication between client and server, bypassing
  | caching name server, is needed.

Aside from that defeating the whole purpose of DNS caching, anything
that were to require that is going to fail in the world as it is.

There are way too many nets that block all packets to/from port 53,
other than those going to/from the known DNS cache(s) to ever
reasonably expect random clients to be able to talk directly to DNS
servers.

Other nets silently redirect packets aimed at port 53 to a cache
instead of whatever IP address they were previously directed at.

kre

---

From: Roy Arends <[email-masked]>
Date: Mon, 10 Feb 2003 12:19:10 +0100 (CET)

> instead of whatever IP address they were previously directed at.

And for the rest of the nets that do not do the above, it would not scale.

Roy