Subject: [DNSOP] reverse-mapping-considerations proposed text change

From: Andrew Sullivan <[email-masked]>
Date: Tue, 24 Jul 2007 22:21:22 -0400

Dear colleagues,

Stephane Bortzmeyer pointed out to me this morning a problem in what
section 2.1 of the -04 draft says.  Here's how it reads now:

   Since the list of trusted hosts was a simple list of hostnames or
   addresses, an attacker could acquire access by intercepting the DNS
   query for a hostname, and replying with the IP address from which the
   attacker was making the rhosts authentication attempt.  (This was not
   the only weakness in the mechanism, but it is the most relevant to
   reverse mapping.)

This isn't quite right.  Some of the implementations, at least, merely
did a reverse lookup on the IP address connecting.  So all you had to
do was put the right hostname in the PTR record, and you could "be"
that trusted host.  RFC 1258 and RFC 1282 are actually silent on the
mechanism for host trusting, and talk about different implementations
having different features.  (That is consistent with my really limited
experience of rhosts authentication, which was already regarded as a
very bad idea by the time I started actually administering UNIX hosts.
What we put in the draft is all stuff I managed to suss out of old
manuals and paper -- ! -- documents.  So if people who used the rhosts
stuff want to speak up about some other details that are wrong, it'd
be very helpful.)

I propose the following replacement text:

   Since the list of trusted hosts was a simple list of hostnames or
   addresses, an attacker could acquire access either by by putting
   the target host name in the PTR record in the IN-ADDR zone for the
   attacking IP address; or, by intercepting the DNS query for a
   hostname, and replying with the IP address from which the attacker
   was making the rhosts authentication attempt.  Different
   implementations of the r* commands authenticated differently, but
   none of them actually checked for matching reverse data; the exact
   method of attack depended on the version of the r* commands being
   attacked and the configuration in use.  (This weakness was not the
   only one in the mechanism, but it is the most relevant to reverse
   mapping.)

While we were talking about this issue again this evening, Stephane
also kindly pointed out to me that the document uses the expression
"reverse query" when a more appropriate expression would be "query for
reverse data".  So the terminology section could be changed to clean
this up.  For instance

   The term "existing reverse data" means that a reverse query for Q
   results in a response other than Name Error.

would become

   The term "existing reverse data" means that a query for reverse
   data Q results in a response other than Name Error.

Does anyone object to making that change, while we're doing another
draft to fix the history?  By my count, there are three changes that
have to be made to address this (they'd all be changed in the same way
as the example above).

Many thanks to Stephane for his careful review.

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 24 Jul 2007 22:50:19 -0500

On Tue, Jul 24, 2007 at 10:21:22PM -0400,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 73 lines which said:

> the document uses the expression "reverse query" when a more
> appropriate expression would be "query for reverse data".  So the
> terminology section could be changed to clean this up.

The mathematically inclined readers may remark that (reverse o
reverse) is the identity (said in another way, reverse(reverse(x)) =
x) which is clearly not true of PTR and A requests :-) Many people
believe that PTR is the reverse of A and this erroneous assumption
generates a lot of trouble.

The only real reverse query in the DNS has been deprecated in RFC
3425.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 24 Jul 2007 22:50:19 -0500

---

From: [email-masked]
Date: Mon, 30 Jul 2007 10:33:06 +0100

> have to be made to address this (they'd all be changed in the same way

It is not really clear to me what Q is in the new text. I suggest removing 
the letter Q or being more explicit and saying something like

Starting from a given IPv4 address (probably the result of a query for an 
A RR), the term "existing reverse data" means that a query for 
<reversed-ip4-address>.in-addr.arpa. type PTR results in a response other 
than Name Error.

Starting from a given IPv6 address (probably the result of a query for an 
AAAA RR), the term "existing reverse data" means that a query for 
<reversed-ip6-address>.ip6.arpa. type PTR results in a response other than 
Name Error.

The term "matching reverse data" means that the query for existing reverse 
data resulted in a response containing a set of one or more names which, 
when each queried themselves in the forward zone for A or AAAA RRs (as 
appropriate) return one or more results, one of which corresponds to the 
original query.

John

====
John A Dickinson
Senior Researcher
Nominet UK
+44 (0) 1865 332344

---

From: [email-masked]
Date: Mon, 30 Jul 2007 10:33:06 +0100

John

====
John A Dickinson
Senior Researcher
Nominet UK
+44 (0) 1865 332344

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 Jul 2007 17:11:31 -0400

Hi,

On Mon, Jul 30, 2007 at 10:33:06AM +0100, [email-masked] wrote:

Thanks for the comment!

> appropriate) return one or more results, one of which corresponds to the 

I'd convert the last paragraph to present tense, but otherwise this
seems reasonable to me.

Presumably, to finish this off, 

    The term "missing reverse data" means that the query for existing
    reverse data as above results in a response for Name Error.

Does anyone object to this new formulation?

A

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 Jul 2007 17:11:31 -0400

Hi,

Thanks for the comment!

A