[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
problems with SKIP
There appear to be some serious problems with the current SKIP
draft. Some of these seem to apply to the DEC scheme as well.
First, the stream cipher mode doesn't work well, and in particular
is not very general. The draft says that MI ``is simply the count
of bytes that have already been encrypted in key Kp'', and is 64
bits long. But using a counter only works if packets are in order;
arbitrary stream ciphers cannot be cranked backwards, though clearly
some can (such as DES in OFB mode). If the new counter is much
higher than the last one received, the receiving host may have to
turn the crank forward very far. This can lead to denial of service
attacks; an attacker can flood the recipient with many bogus packets
with wildly different byte counts. While there are some stream
ciphers for which neither of these objections apply -- say, encrypting
a byte counter with a block cipher to produce an XOR stream -- in
the general case the idea appears to be unworkable.
SKIP's in-band key negotiation makes it difficult to revoke a
compromised certificate. A host may have a cached copy of the old
certificate and to use when computing the long-term key Kij. But
such packets will be rejected by the recipient, since they won't
decrypt properly. Nor will either party know why, unless the
receiving machine sends a special bounce message any time decryption
fails, if that happens between the revocation time and the normal
expiration time of the certificate (and that period could be several
years, per the draft). Note the possibility here for a denial of
service attack on the the certificate directory: after a revocation,
the attacker sends lots of messages with forged source addresses
to some target. This causes the bounce messages, which in turn
would cause the nominal senders of the packets (who had received
the bounce messages) to query the directory server for a current
certificate.
It isn't clear how one side can force the use of different session
keys for each connection between a given pair of hosts. While it
can choose different session keys itself, there is no way for it
to tell the other side to do so. A number of attacks are possible
under these circumstances, especially if a stream cipher is used.
The most serious problem, though, is that SKIP makes it very
difficult to reject a compromised session key. Suppose that an I
have somehow obtained some session key, along with the encryption
of it using the long-term key Kij. This isn't impossible, as I
may have years to work on it. I can now send fraudulent packets,
using the address and Kij encryption from an original packet.
Since Kij will remain constant for a very long time, and since by
definition the receiving host has no input into the key generation
process, it has no way of detecting the forgery. Granted, the
attacker has no way of seeing the output from the target host, as
it will have its own session key, but as we've seen in the last
few weeks, one can quite easily launch certain attacks without ever
seeing any output.
I can think of a few ways to try to patch SKIP to get around this,
such as encrypting the current time with Kij, but the real problem
is much deeper: in an avowedly ``stateless'' scheme, the receiving
host has no part in the key generation, and hence can't forbid old
or bad keys.
This problem appears to affect the DEC scheme as well, though it
may be repairable there. With the DEC scheme (does it have a
name?), the key-encrypting key is private to the receiving host,
and thus can be changed at any time. If the generated session keys
all expire at the same time, and the KEK is changed at the same
instant, old session keys will fail. I would expect a bit of churn
for a few seconds on either side of the changeover time, but that
might be acceptable.
There are other minor problems with SKIP (cleartext algorithm identifiers,
a bit to indicate compression, etc., but the problems I've outlined
above seem to me to be very serious, and arguably fatal.
--Steve Bellovin