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

RE: IPSEC Security Gateways & NAT


If you pre-comp a set of prime numbers for DH-key exchange...
These can use only one time and they are consumed faster then you can come
up new ones.
This is the DOS idea that keep the IPSec responder so busy (meaninglessly)
that 
no time for other meaningful activities.
Recycling prime numbers for DH-key exchange is a implementation mistake???

The CR process requires pending on a state that waits for server search
through the 
chains of servers to come up CRL (and it grows longer along the time).  
It is a classical eavesdropping. 

The preshared key (pass-phrase) can auth the peer with much less cost and
stateless.

If someone can inscribe the first pair of DH-key exchange with CHAP(or
others),
it seems can remove some random DOS attack. 
This will complement the DH-Key exchange's weakness of 
unknowing the peer is "DOS attacker".

Regards,

--- David




-----Original Message-----
From: Dan Harkins [mailto:dharkins@lounge.org]
Sent: Thursday, June 14, 2001 12:04 AM
To: Chen, David
Cc: ipsec@lists.tislabs.com
Subject: 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.
Follow-Ups: