[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: linux-ipsec: Decrypting ID payload in Main Mode w/shared secrets
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@network-alchemy.com]
> Sent: Wednesday, April 28, 1999 1:39 PM
> To: hugh@mimosa.com
> Cc: John Gilmore; linux-ipsec@clinet.fi; Hugo Krawczyk;
> ipsec@lists.tislabs.com
> Subject: Re: linux-ipsec: Decrypting ID payload in Main Mode w/shared
> secrets
>
---- snip ----
> I'm also a bit confused about the problem using ID_KEY_ID.
> As described
> by John Gilmore:
>
> This proposed solution permits eavesdroppers to determine
> that the same
> person (the same opaque blob) is connecting from a variety
> of places,
> even if they don't know the "identity" of that person.
>
> That would require large scale traffic analysis to derive
> this information
> and I'm not sure what use can be made of it-- that some
> opaque blob (the same
> person) is connecting from a variety of places. If that's
> scary in your
> environment than why isn't an active attack against "open
> secret" scary?
> Yes, the Quick Mode exchange would break down but now this
> attacker knows
> who (the actual identity, not just "the same opaque blob")
> and where. If
> I was running a hit squad that would be valuable
> intelligence; knowing that
> an opaque blob is running around connecting from various POPs
> would not.
---- Snip ---
You could take this further ... you should be able to easily develop a new
protocol (or a new exchange, config exchange, whatever) that could modify
the ID once the session has been authenticated. Assumming this exchange is
encrypted, you could use a different ID every time . If a given
implementation did not support the change request, you could go on using the
old one. Backwards compatibility and works too... I'm probably missing some
giant hole here :)
Paul Kierstead
TimeStep Corporation
mailto:pmkierst@timestep.com http:\\www.timestep.com