[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bellovin's and Ahar's attacks
Steve, I have a question. This question is based on the assumption that a
conversation (whether through TCP or UDP) should be equally protected on
both directions.
For TCP, I think the assumption implies there must be a specific key
(or a pair of keys) for each connection. This means this key becomes
part of the connection state. I discussed this with Perry during last
IETF. I think I know how to do it.
What I don't understand is how to do the same thing for UDP, or any
state-less protocol. How does a receiver knows which key to use when
sending a response to a received message if the receiver is talking to
multiple parties through the same port ?
Regards, Pau-Chen
> > I am somewhat uncomfortable with your proposition :
> >
> > > I
> > > suggest that once we've done that, per-session (or per-user) keys are not
> > > required as long as we re-key frequently. The re-keying defeats Rogoway's
> > > attack as effectively as per-session keying.
> >
> > It assumes that an intruder cannot quickly capture and replay traffic. If he
> > is doing this manually, then this is probably a safe assumption. However, in
> > high value applications, there is no reason to believe an intruder will not
> > spend the resources to write a program that detects a potentially valuable
> > stream of target traffic, coordinates with an end system program and
> > replay's it according to Phil's and Ashar's suggestion.
>
> A lot depends on our assumptions. For TCP, it's probably feasible, so
> long as rekeying occurs more frequently than the TIMEWAIT period. For
> UDP, there's no mandatory dead time in the protocol. I strongly suspect
> that we absolutely must use very rapid key changes, though -- per user
> (though with AH+ESP for some services), per packet (a la SKIP), or per
> socket. Nothing less seems to guard adequately against both replay attacks
> and the CBC cut-and-paste attack that I outlined.
Follow-Ups:
References: