[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPSEC Security Gateways & NAT

  There is no requirement to generate a prime number per exchange and
the cost of checking a CRL should pale in comparison to computing a
Diffie-Hellman. 

  Nothing computationally expensive is done until two messages are 
received from the same peer with the 2nd containing the responder's 
cookie. There is a DOS concern, though, since a responder will create 
state upon receipt of the 1st message from the initiator. If we wanted to 
address that we could add a stateless "cookie request" option ala Oakley 
and Photuris. But that would make things more complex....

  Dan.

On Wed, 13 Jun 2001 15:24:59 EDT you wrote
> Dan,
> Preshared key seem more effective against DOS attack 
> comparing to "generating prime number" or "check certificate revocation"?
> Regards,
> --- David
> 
> 
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]
> 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.
References: