[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: dnsop@cafax.se
cc: narten@us.ibm.com, <jinmei@isl.rdc.toshiba.co.jp>, <itojun@iijlab.net>
From: Pekka Savola <pekkas@netcore.fi>
Date: Fri, 28 Jun 2002 16:18:52 +0300 (EEST)
Sender: owner-dnsop@cafax.se
Subject: Comments on securiry of draft-ietf-dnsop-inaddr-required-03.txt

Hello,

I was referred to this draft as a reason why PTR (and subsequent name to 
PTR) lookups would not be useful as a part of authentication.

(The background is that arguably
draft-ietf-ipngwg-icmp-name-lookups-09.txt can be just as well be used for
reverse lookups as traditional DNS lookups in some contexts.)

First, it seems to me that this issue may not be entirely in scope of the 
draft.  I think it should either be removed, or discussed properly.

I'm saying is "discussed properly" because the only relevant parts seem to 
be:

Section 4:

    [...] The use
    of IN-ADDR, sometimes in conjunction with a lookup of the name
    resulting from the PTR record adds no real security, [...]

 and

Section 5:

    By recommending applications avoid using IN-ADDR as a security
    mechanism this document points out that this practice, despite its
    use by many applications, is an ineffective form of security. 
    Applications should use better mechanisms of authentication.  


This seems like a circular argument, at best, to me.


I'd gather that from security point of view, the reverse lookups are used 
for about three classes of purposes:

 1) as the only form of authentication (YUCK!!!!)
 2) as a partial (more or less strong hint, e.g. in addition to a 
password) authentication
 3) from statistics point-of-view (e.g. log file resolving; significant 
reverse record spooing can lead to interesting misunderstandings and even 
more, but are not really that security-critical; in this, only a PTR 
lookup is done so results don't really mean anything).

Software which performs reverse address check but does not check the 
result from forward tree can only be categorized as "crap" from security 
point-of-view.  The only acceptable group from above for this would be 3).

In some scenarios where only extremely weak form of identification is 
needed, I think that only PTR + resulting name lookups are enough.

In some scenarios where you need a stronger authentication, a PTR + 
resulting name lookup is a good _first_ step in authentication; naturally 
not the only one, but if that helps to hinder 99.99% of those portscanners 
or whatever, very good.

The main thing DNS lookup PTR+name lookups differ from ICMPv6 name lookups 
is that external entities administer the names.

If the attacker has access to your local network, as is the case with
ICMPv6 name lookups, sure -- they can do a lot of harm, as pointed out by
e.g. draft-kempf-ipng-netaccess-threats-00.txt.  But that's just one area
of application, and one might be able to counter these problems to some
extent even there.


So, in conclusion I think that either the recommendation about security 
of PTR(+Name) lookups should be extensively elaborated or removed from the 
draft.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords






Home | Date list | Subject list