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

RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing



I've had some thoughts about this.

Consider that rather than generate a 'get out of puzzle free' token that the
ISAKMP peers negotiate a shared secret authentication key.  Subsequent
negotiations could use this key in place of the much more expensive PKI base
authentication.  These temporary authentication keys could be cached and
wouldn't need to be held for every possible peer.

If there's a vulnerability here, then the token could be used to
authenticate the initial ISAKMP datagram(s) only and be used in addition to
the current authentication mechanisms.

This doesn't solve the initial connection issue, but it would help protect
established VPNs at rekeying time against attacks on their PK/memory
resources.

Chris

> -----Original Message-----
> From: Andrew Krywaniuk [mailto:akrywani@newbridge.com]
> Sent: 18 February 2000 17:32
> To: 'Paul Koning'
> Cc: ipsec@lists.tislabs.com
> Subject: RE: Future ISAKMP Denial of Service Vulnerablity Needs
> Addressing
> 
> 
> Hi Paul,
> 
> I don't know that it wouldn't be possible to use client 
> puzzles in a typical
> VPN.
> 
> There are certain differences between the typical usage of clients and
> gateways that might help to reduce load under common scenerios.
> 
> For example:
> 
> 1. There are typically more clients than gateways.
> 2. The gateways have fixed IPs but the clients do not.
> 3. The gateways are usually initiating to a limited set of 
> remote gateways
> that is known in advance (or can be detected at runtime).
> 
> Under these circumstances, the responder could avoid forcing 
> the gateway to
> solve multiple subsequent client puzzles by issuing him a 
> "get out of puzzle
> free" token after each phase 1 negotiation.
> 
> There are a limited number of known gateways, therefore these 
> tokens would
> only use up a small amount of stored state. And sending the 
> token during a
> phase 1 negotiation would absolve the initiator of the 
> puzzle-solving task.
> 
> Of course, this technique only works in the scenario I 
> describe, but that is
> a fairly common scenerio.
> 
> Note that this is quite similar to a method of active 
> identity protection
> that I described a few months ago.
> 
> Andrew


Follow-Ups: