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

RE: Retransmits in traffic count?



Look at it this way. You are not denying that increased traffic on an Isakmp
SA will theoretically make it easier to break, you are just saying that if
it does get broken then who cares? In that case, why do we bother encrypting
the last few messages of Main Mode? And why do we even bother with phase 1
rekeying?

Obviously we are placing some value in the protection of encrypted Isakmp SA
data. And maybe we are concerned that there will eventually be a viable
attack on SKEYID_d. When building a security system, you generally decide
that you're either going to protect a given piece of data or you're not. You
don't say that this data is only a little bit sensitive so let's just make a
half-hearted attempt to protect it.

Probably the majority of attacks we are concerned about are brute force
attacks that are facilitated more by time than by traffic. But we can't be
sure that no one in the future is going to come up with an attack that is
greatly facilitated by increased traffic. If an attacker can find a loophole
in the user's security system that allows them to continually force the
renegotiation of IPSec SAs then they can artificially increase the traffic
count on the Isakmp SA, thus giving themselves a lot more encrypted traffic
to work with. 

If we have Kb-based expiry then this kind of attack doesn't work. The Isakmp
SA gets renegotiated continually and this hopefully sets off alarm bells in
the network monitoring department somewhere.

Whether or not Kb-based expiry needs to be in the spec, well that's a bit
different issue. Presumably, there is some value in informing the other
party of the expiry constraints, or why do we support the notify for
time-based expiry? (I'm just extrapolating here.) Probably some
implementations want to know when to anticipate a rekey, and if so then they
should be able to do so regardless of the expiration constraints.

Andrew
_______________________________________________
 Beauty without truth is insubstantial.
 Truth without beauty is unbearable.


> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM]
> Sent: Thursday, August 05, 1999 4:49 PM
> To: Andrew Krywaniuk
> Cc: Tim Jenkins; ipsec@lists.tislabs.com
> Subject: Re: Retransmits in traffic count? 
> 
> 
> On Thu, 05 Aug 1999 16:06:58 EDT you wrote
> > Ahh, the wonderous diversity of a technical mailing list. 
> On one hand,
> > you've got people complaining that a simple protocol like 
> IKE-Config is too
> > risky simply because it adds complexity to your state 
> machine (even though
> > there are no real plausible attacks). And now you've got 
> people arguing that
> > Kb expiry of an IKE SA is useless simply because the 
> attacks (which are easy
> > to envision) are too esoteric.
> 
> I don't know what technical mailing list you've been reading 
> but welcome
> to IPSec. No one was arguing about anything called IKE-Config 
> (perhaps you
> mean ISAKMP-Config) it was XAUTH that's the risky protocol. 
> And I never said
> an attack against SKEYID_d was too esoteric.
> 
> > We're in the security business. We're supposed to be (at 
> least a little bit)
> > paranoid. If people didn't care about identity protection 
> then why would
> > they be using main mode? 
> 
> Because Main Mode has much richer negotiation capabilities 
> (that is, if
> you actually parse the attributes and use the values in negotiation).
> 
> >                          Organizations like the military 
> collect and analyze
> > statistical data such as who is talking to who.
> 
> The data to collect is the IPSec protected data since that will tell a
> whole lot more than just knowing the ID payloads used in IKE. 
> And removing
> the KB lifetype value from the protocol will not make the life of the
> military (or any other bogyman you can think of) easier. 
> 
> > Deprecating features (especially a locally enforced feature 
> like this one),
> > simply because a few parties can't see any use for thm, isn't what a
> > standards-determining organization is supposed to be about. 
> Our customers
> > expect us to be forward-thinking; if we don't plan for an 
> attack, simply
> > because we can't think of how to exploit it off the top of 
> our heads, then
> > how can we be forward-thinking?
> 
> Had I not added KB lifetime to IKE in the first place I 
> seriously doubt
> you would be demanding it today. And this topic was brought 
> up 2 months
> ago by a well-respected member of this WG and no one said anything.
> 
> If KB lifetime is a locally enforced feature (as you say) 
> which is not 
> negotiated (and if the attribute appears in an offer it's 
> ignored in favor 
> of the locally configured value) then it is not part of the 
> protocol. If 
> the protocol removes the KB lifetime attribute and/or re-uses 
> the lifetype 
> value for a lifetype that actually makes sense it will not 
> have any effect 
> on implementations which happen to have this locally enforced 
> value. You
> could have other locally enforced rules (like an idle timer 
> which auto-
> matically deletes SAs if they have not been used in X 
> seconds/minutes/hours) 
> which you may want to have knobs to give your customers but 
> that too is not
> part of the protocol.
> 
> The only people arguing for KB lifetype in phase 1 are the ones that,
> admittedly, don't use the value in negotiation. That's pretty funny.
> 
>   Dan.
> 


Follow-Ups: