[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (IPng) problems with SKIP
>From: Steve Bellovin <smb@research.att.com>
Steve,
Thanks for the comments. I will respond to some of your other points
later, but I'll address these first.
(Incidentally, I am responding to ipng as well, but this discussion
might be more appropriate for ipsec, since this doesn't relate
to encapsulation formats).
>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.
You are correct about the possibility of denial-of-service (d-o-s)
attacks on stream ciphers with byte counters. Our implementation at
the moment does some things to prevent this sort of attack.
In particular it keeps track of current offsets, and has a
notion of what reasonable offset differences can be, even given
out-of-order arrival of packets. This doesn't completely
eliminate all possible d-o-s but can help, in that wildly
different counter values are ignored.
However, this really isn't a SKIP issue per se. The issue is generic
to how one does stream ciphers at the IP layer. The same issues
would apply to any other key-mgmt scheme that would use a stream
cipher of the RC4 variety.
Also, this doesn't mean that because of the possibility of d-o-s
attacks, one shouldn't use this mode of operation, because
there may be environments where confidentiality and performance
are greater considerations than d-o-s. All environments don't
suffer from the same threat possibilities.
> 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.
The issue you raise, (essentially a known key attack) has
been raised in the past on ipsec by Hugo. At the last IETF
meeting, I presented a zero-message way of updating the SKIP
master key (Kij) that eliminates this attack. Essentially
the master key becomes a function of a counter (that
is communicated in the packet) that only runs forward.
(This modification was also discussed on the ipsec list
soon after the IETF meeting, under the subject zero-message
master key update.)
If a session key is ever compromised, (but the master key
is not) it cannot be replayed because the attacker will
not know the encryption of Kp under the current Kij. The IETF
presentation slides explained how the counter can be
implemented as a function of time units since the more
recent of I or J's certificate.
Since the counter never runs backwards, it isn't possible
to reuse past compromised keys. With this modification,
there are no known-key attacks on SKIP that I am aware
of.
Incidentally, the type of attack you cite (known key attack), applies
to Photuris as well. Compromise of a session's secret DH exponent
allows the party that connected to later impersonate the party
whose session exponent was compromised. I have described this
in the past, although there hasn't yet been agreement
on the correct way to fix this.
The SKIP draft hasn't yet been updated to reflect the master key
update mechanism that I described above, and I am working on
updating the draft.
> 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.
I believe that this situation is not applicable to the DEC
scheme, because keys are not established by sending them encrypted
in the per node master key. A key-negotiation protocol is employed
to establish the session key, so if the key-negotiation protocol
doesn't suffer from key playback weaknesses, neither will the
DEC scheme. (Charlie Kaufmann can correct me if am wrong).
Regards,
Ashar.