[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Clogging attacks on SKIP
>From amir@watson.ibm.com Wed Dec 14 05:47:17 1994
>
>In Ashar's response I found two different issues which we should clarify.
>I'll dedicate this note to the first, which is: can we assume in SKIP that
>the receiver can pre-compute all Kij pairs. It apprears to me that's what
>Ashar suggests:
>
>> First, let me mention that the pair keys Kij always (conceptually)
>> exist, and can be precomputed *prior* to any communication attempt.
>>
>
>I think this is not reasonable for many applications. In particular, it
>is not reasonable for the `firewall' application where a firewall of an
>organization is the endpoint of (some) tunnels leading to the organization,
>a scenario which the group has decided we must support (see Paul's note).
>The number of potential Kij's is simply too large (practically unbounded).
We have to be clear what firewall scenario we are talking about.
If we are talking about firewall-to-firewall, then the number of Kijs
is proportional to the square of the number of firewalls, *not* the
square of the number of endpoints on either side of them. This is
usually a small number even with sites having thousands of endpoints,
because it is related to the number of sites, not the number of
machines in those sites.
Second, the end-node to firewall, a scenario used to access organizations
from either home or some public network is limited to the number of
machines coming in over the public networks using that one particular
access point. This cannot be a very large number, because there is
a practical limit to what a particular firewall machine can support
in terms of simultaneous independent transactions, and in most cases
is also bounded for these practical reasons.
So, I disagree with your contention that the Kijs become unbounded
for the firewall scenario.
>> This can be done by following a prioritized list using the per node
>> ACL (which you always need, because otherwise there is no need to
>> authenticate).
>
>Allow me to disagree: you don't always need an ACL (certainly not an `explicit
>ACL' - even when ACL is needed, many times one can have `wildcards' to specify
>large groups). For example, some firewalls may have a policy to allow all
>communication in, except for some blacklisted, but also log the event (and
>use the authentication to maintain the blacklist). Others may allow all
>communication from any machine belonging to specific trading partners or
>to all internal machines. While these examples are dramatic for the firewall
>scenario, they apply almost as well to `regular' hosts.
An ACL always exists, whether it is wildcarded or expressed in
"not allowed" terms. What I was trying to say is that if everyone
is allowed, there is no point to authenticate the access.
>> Note that this sort of precomputation cannot be performed
>> using traditional (non-SKIP) interactive schemes, because there
>> are no shared secrets prior to communication.
>
>Again I must disagree. The pre-computation involves also getting the
>(certified or otherwise authenticated) public keys. This is just the same
>as the initial communication (and computation) of any other scheme for
>long-lived keys.
I must also disagree with your contention. This is *not* the same
as the initial communication to compute session or master keys using
traditional techniques, because precomputing SKIP master keys doesn't even
require the machines for which master keys are being computed to be connected
to the network or to be online. All that is required are the remote
certificates, which may be obtained from a local cache, a local directory
server etc.
This is a very practical matter, because in firewall scenarios,
end node machines (residing in e.g. homes) dont have to be powered
up for this computation to occur, nor do expensive telephone/ISDN/etc.
calls have to made to the home to establish these keys.
Ashar.
Follow-Ups: