[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSEC Security Gateways & NAT (3 issues)
The reason the SKEYID derivations differ is because Hugo stated that he did
not think DH alone was strong enough for key agreement. The last time this
issue came up, Hugo suggested changing the key derivation to:
SKEYID_e = prf(hash(Ni_b | Nr_b), g^xy | CKY-I | CKY-R | 2)
(although he also stated that he still prefers the exiting definition.)
As for removing preshared key mode, here's a good quote from Ari from the
last time this was discussed:
What's the point of removing a feature that:
- is the most interoperable authentication mode in existance
- makes possible the smallest memory footprint implementation possible
- is the most resistant to DoS attacks
???
Yes, it's not really usable in large scale, but that's beside the point.
As for identity protection, we have several identity protection techniques
which all have vulnerabilities. You can use main mode, which is vulnerable
to an active attack. Or you can send a hash of the certificate with the
encryted nonces authentication method, which is vulnerable to a tracking
attack. Or you can use ID_KEY_ID, which is also vulnerable to a tracking
attack. The hybrid/crack approach solves the problem of protecting the
initiator's id, which is usually the important one.
I suggest that those who are ultra-paranoid about tracking attacks get
together and design a protocol for using one-time tokens in the ID_KEY_ID.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins
> Sent: Wednesday, June 13, 2001 3:03 PM
> To: Derek Atkins
> Cc: Chen, David; 'jshukla'; ipsec@lists.tislabs.com
> Subject: Re: IPSEC Security Gateways & NAT
>
>
> On 13 Jun 2001 12:24:28 EDT you wrote
> >
> > I agree that it is a problem that the IKE ID is tied to the
> source and
> > destinatin IP address. Currently, however, the __ONLY__
> time there is
> > this particular problem is when using pre-shared static keys for
> > authentication. Well, first, I would suggest people not use
> > pre-shared static keys. That suggestion notwithstanding,
> wouldn't it
> > be better if this problem was fixed completely, so that pre-shared
> > static keys are _NOT_ tied to the IP Source Address?
>
> The reason it was done that way is that there was a desire to
> force the
> keys to contain something known only by the peers (which is
> why signature
> mode was described as "the least secure"). There was also a
> requirement
> for identity protection. Those two combined to give us what
> we have today.
> You need to get the pre-shared secret to use to derive a key
> to protect
> the identity which is used to find the pre-shared key. That
> wouldn't work
> so the key is bound to all you can know at that time-- the IP address.
> Actually, using ID_KEYID identity and Aggressive Mode can
> give you identity
> protection (since the keyid can be any opaque blob) with
> pre-shared keys
> but that's really not an elegant solution.
>
> Provided that the Diffie-Hellman is authenticated I guess we could say
> that the resultant secret is something known only by the parties to
> the exchange and therefore having g^xy (and not the pre-shared key) is
> good enough. But I'm not a cryptographer and I didn't come up with the
> key derivation.
>
> I'm all for simplifying and unifying SKEYID generation. Are there any
> comments on this proposal? Hugo, are you out there?
>
> Dan.
>
>
Follow-Ups:
References: