IKE resource exhaustion at 2 to 10 packets per second

2006-07-27 Thread William Allen Simpson

http://www.nta-monitor.com/posts/2006/07/cisco-concentrator-dos.html

The vulnerability allows an attacker to exhaust the IKE resources on a
remote VPN concentrator by starting new IKE sessions faster than the
concentrator expires them from its queue. By doing this, the attacker
fills up the concentrator's queue, which prevents it from handling valid
IKE requests.

The exploit involves sending IKE Phase-1 packets containing an
acceptable transform. It is not necessary to have valid credentials in
order to exploit this vulnerability, as the problem occurs before the
authentication stage. The vulnerability affects both Main Mode and
Aggressive Mode, and both normal IKE over UDP and Cisco proprietary
TCP-encapsulated IKE.

In order to exploit the vulnerability, the attacker needs to send IKE
packets at a rate which exceeds the Concentrator's IKE session expiry
rate. Tests show that the target concentrator starts to be affected at a
rate of 2 packets per second, and is becomes unusable at 10 packets per
second. As a minimal Main Mode packet with a single transform is 112
bytes long, 10 packets per second corresponds to a data rate of slightly
less than 9,000 bits per second.

...

The vulnerability was first discovered on 4th July 2005, and was reported
to Cisco's security team (PSIRT) the same day. Cisco responded on 9th
August 2005, but no further progress has been made, over a year after
finding the flaw.



Gosh and golly gee, how could this vulnerability slip past them without
anybody noticing?

... other than the person posting an internet-draft that the IESG refused
to publish as an RFC, that was instead published in ;login: December 1999.

... that attack threat was mentioned in the design principles of Photuris
circa 1995, that the IESG also refused to publish until after the
NSA-originated and approved IKE/ISAKMP protocol.

It's particularly amusing that Photuris was overwhelmingly approved in a
straw poll conducted by John Gilmore at the 36th IETF in Montreal, 1996,
but Cisco issued a press release that they had chosen the NSA-designed
protocol instead.  Protocol adoption by press release, such a good choice.

They just had the 66th IETF in Montreal a week ago.  Full circle.

Anybody ready to order Photuris from your vendors?




-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Crypto to defend chip IP: snake oil or good idea?

2006-07-27 Thread Anne Lynn Wheeler

a related article (that also mentions certicom crypto):

How Secure Is That Device?  As device software joins the larger world,
security becomes ever more vital
http://dso.com/news/showArticle.jhtml?articleID=191501076

and some general comments in another thread
http://www.garlic.com/~lynn/2006o.html#2 the more things change, the 
more things stay the same




-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Crypto to defend chip IP: snake oil or good idea?

2006-07-27 Thread Thor Lancelot Simon
On Tue, Jul 25, 2006 at 03:49:11PM -0600, Anne  Lynn Wheeler wrote:
 Perry E. Metzger wrote:
 EE Times is carrying the following story:
 
 http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=190900759
 
 It is about attempts to use cryptography to protect chip designs from
 untrustworthy fabrication facilities, including a technology from
 Certicom.
 

 http://www.garlic.com/~lynn/x959.html#aads
 
 which basically puts keygen and minimal number of other circuits in the 
 chip. keygen is executed as part of standard initial power-on/test ... 
 before the chips are sliced and diced from the wafer.

So, you sign the public key the chip generated, and inject the _signed_
key back into the chip, then package and ship it.  This is how the SDK
for IBM's crypto processors determines that it is talking to the genuine
IBM product.  It is a good idea, and it also leaves the chip set up for
you with a preloaded master secret (its private key) for encrypting other
keys for reuse in insecure environments, which is really handy.

But do we really think that general-purpose CPUs or DSPs are going to
be packaged in the kind of enclosure IBM uses to protect the private keys
inside its cryptographic modules?

Thor

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]