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