[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Retransmits in traffic count?
I feel I need to make one more comment on this subject, since I don't think
we reached a sensible conclusion. (Dan's conclusion thus far was "Although I
wasn't too serious about removing the KB lifetype this statement of utility
should be enough to end this rediculous thread.") I want to point out that
there are, in fact, some important uses for KB lifetimes on IKE SAs.
First, let me say that I didn't intend to start an argument about the value
of KB lifetimes for IKE. I simply suggested to Tim (offline) that it didn't
make sense to count retransmits against the SA lifetime. Tim posed the
question to the list and the reaction was mixed.
Then Dan started a tangential thread about whether KB lifetimes were useful.
I said they were. My reasoning here was by extrapolation, but the argument
got bogged down in the details. The two questions that I don't feel Dan made
any attempt to answer are the following:
1. If IKE packets are not sensitive enough to warrant strong protection then
why do we encrypt them at all?
2. If notifies for KB lifetimes are not important then why do we send
notifies for time-based expiry?
As I said, this was just argument by extrapolation. If we do X then why
wouldn't we do Y? The answer could be that we should do Y or possibly that
we don't really need to do X.
-----------------------
My feeling on (1) is that IKE packets are worth protecting. They contain
some sensitive information (identities, nonces) and some not so senstitive
stuff (SA proposals). The identities are worth protecting in their own
right. The nonces are worth encrypting because they seed the QM keymat (and
if you're doing PFS then the KE is worth protecting because it makes it just
that much harder to crack the QM DH when the whole exchange is encrypted).
As for SKEYID_a, cracking it doesn't provide a lot of information towards
SKEYID_d. They are related, but not in any way that can forseeably be
exploited (to the best of my knowledge). On the other hand, while an
attacker who had access to SKEYID_e and SKEYID_a couldn't read any IPSec
traffic, they could still play havoc with your network by frivolously
negotiating and deleting SAs.
Dan doesn't see this as much of a threat: "To note how rediculous this is,
if [Dan's conditions for SKEYID_e being broken] happened then why would the
"attacker" want to _increase_ the renegotiation of the IPSec SAs. Given the
incredibly low volume of IKE traffic to IPSec traffic for a given flow it
would make more sense that the "attacker" would use his advance in
cryptanalysis to attack the IPSec traffic."
My concern is that the intruder will attack the weakest link in the chain of
security. If we make IKE traffic easier to crack than IPSec traffic then the
intruder may very well focus on what they can get rather than what they
really want. Plus, I don't think it is fair to assume that breaking an IKE
SA would require ciphertext-only cryptanalysis, since a large percentage of
the data (SA proposals, etc.) is both easily guessable and highly consistent
across exchanges.
It is relatively difficult to screw around with the traffic on an IPSec SA
(of course it depends on the other aspects of network security -- firewalls,
locks on the door, etc.), but it is much easier to screw with an IKE SA. For
example, could an attacker force one of the nodes to generate encrypted info
mode traffic on an IKE SA? Probably. Would this attack be detected by the
system? Maybe, maybe not.
-----------------------
Don't get me wrong -- I am all for defining a third expiry constraint like
the one you mentioned. But as I see it, there are three factors that
contribute to the gradual degradation of an IKE SA's security:
1. Time.
2. The number of phase 2s which have keymat based on SKEYID_d.
3. Traffic on the IKE SA.
In many situations, these three factors are highly correlated. As so often
happens, we have to resort to traffic analysis:
For example, a sgw on a 100 mb link with relatively even traffic density
proposing the same set of security descriptors with other peers who have
similar configurations. In this situation, phase 2 rekeys occur at regular
time intervals and the size of the QM negotiation packets are always the
same size (and I imagine that one could make the same assumption about
config mode exchanges). In this case, a time-based SA expiry is sufficient
(assuming, yet again, that the attacker doesn't force the negotiation of
extra phase 2 SAs).
There are other situations where this traffic pattern does not make sense.
Imagine a more diverse S/WAN -- one where much of the traffic is sent on a
fast 100 mb connection, but some of the traffic is on a 56k modem link.
Also, some of the SA proposal payloads are large and others are small. Now,
the three determining factors have become decoupled and it is much harder to
set a simple time-based expiry. An expiry based only on 1 & 2 or only on 1 &
3 might be practical, since you can only decouple 2 & 3 so far (unless the
attacker can force the generation of info modes, which I think is possible),
but it is still theoretically unsound.
-----------------------
My feeling on (2) is that notifies for expiry constraints aren't
particularly useful, but if we support them then we should at least be
consistent. I was hoping that someone would suggest a reason why these
notifies are important (because I can't think of a good one) -- perhaps for
auditing purposes or maybe to negotiate an intelligent jitter condition to
avoid rekey collisions.
Besides, it doesn't seem to do much harm to send expiry constraints that the
other side doesn't understand (since, as we have already discussed, pretty
much everyone discards them without using them). But apparently it does do
damage to some vendors' implementations if we remove constraints that
already exist. As far as I can tell, this should be a MAY clause in the spec
(which it probably already is, but I can't be bothered to look it up).
Andrew
_______________________________________________
Beauty without truth is insubstantial.
Truth without beauty is unbearable.
Follow-Ups: