[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A fix for main mode with preshared keys
On Sun, 12 Dec 1999 21:22:27 PST francisco_corella@hp.com wrote
>
> When I said that the ID_KEY_ID solution only seems to work for keys shared
> between two parties, I was referring to ID_KEY_ID with your method for
> preventing traffic analysis. Without it, ID_KEY_ID seems like a weak
> mechanism for identity protection, especially given that the protocol
> includes a DH exchange that allows you to provide proper encryption for the
> identities.
Why is it weak? How can you invert a blob of bits into an identity? Which
frequent poster to the IPSec list does this blob of bits correspond to:
85e0a2896935d536891956d853b1243a371490f1
> The synchonization problem between two parties, when using the method for
> preventing traffic analysis, does not require a disk crash. It can also
> happen if there is a reboot due to a software error or power failure or
> anything else before the latest value of the key has been written out to
> secondary storage. This means that whenever there is an uncontrolled
> reboot, an operator will have to manually resynchronize *all* the preshared
> keys in case one of them has become out of sync.
Then don't rehash ID_KEY_ID and tell me who that blob of bits is. But, again,
this is not the type of problem that can be solved by a session establishment
and key exchange protocol, the "what if" game is endless.
> The redefinition of SKEYID_e described by Hugo solves the problem elegantly.
> If
> adopted, it would also clarify the IKE protocol by removing any need to rely
>on
> source IP addresses in IP packets for identification instead of relying on th
>e
> ID payload.
What problem? It would help if you could say exactly what you're trying to
solve. It started out as a way to not require keys to be bound to an IP
address. But that problem is solved. So what is it that you're trying to
solve now?
Dan.
Follow-Ups:
References: