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 PROTECTED]> M2P 2A8 jabber: [EMAIL PROTECTED] +1 416 646 3304 x4110 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
