[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A fix for main mode with preshared keys
Dan,
----- Original Message -----
From: Dan Harkins <dharkins@network-alchemy.com>
To: <ipsec@lists.tislabs.com>
Sent: Monday, December 13, 1999 8:54 AM
Subject: 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?
I think the problem is to not require keys to be bound to an IP address
while using Main Mode. You solution doesn't solve this problem, while,
Hugo's does. And besides, Hugo's solution makes policy lookup in IKE
more uniform - you always rely only on ID payload content regardless of
IKE's mode of operation.
> Dan.
Regards,
Valera.
Follow-Ups:
References: