Test Certificates?

[Robert Moskowitz]

At 08:39 PM 12/23/2000 -0500, Ryan McBride wrote:
>On Sat, Dec 23, 2000 at 04:55:08PM -0800, Christopher S. Gripp wrote:
>
> > Ryan McBride wrote:
> >
> > > They're not necessarily more secure than using fixed keys - they're
> > > one way to handle the problem of key management, but the're definately
> > > not a panacea.
> >
> > Well, the reason they are more "secure" is due to the key length.  It is
> > essentially a MUCH larger static key.

First Verisign maintains a test CA for certs.  https://testdrive.verisign.com

Now one very strong advantage of certificate based IPsec (well, actually
IKE) is the removal of the IP address from the policy database.  That is,
you gain support for mobile clients.  Yes, there is Aggresive Mode, but
there are plenty of security concerns there.  Better to go with Main Mode
and RSA sig.

The strength of the IPsec security has little to do with the strength of
the key used for IKE.  Rather the Group negotiated in IKE. The crypto gays
and gals love to debate, but basically Group1 is ok for up to 80 bit
keys.  After that you should be using at least Group 2.  I would have to
check again but even IKE's security is not dependent on the 'key
size'  after all, the typical use of the RSA key in the cert is ONLY for a
signing operation.  IKE and IPsec are tricky and lead to wrong guesses on
where their weakness are.

>That's only if you are using weak static keys... Any IPSec
>implementation that does not permit static keys with entropy greater
>than or equal to the key length of the cipher I would consider broken.

Are their many implementations that use static keys as defined in RFC
2401???  I think not.  Most use session keying controled by IKE with
'pre-shared secrets'.  These secrets are a form of identity.  But when you
use pre-shared secrets you have to use IP addresses for Main Mode identity,
ie no mobility (static gateways or hosts).  Aggresive mode 'fixes' this at
a price.  BTW, the Certicom Pilot (meaning the PDA) demo I saw at N+I was
using Aggresive mode.

>There are drawbacks to using certificate based authentication - people
>often overestimate the security provided by a PKI. Unless the
>transmission of CA certificates is done with care to ensure
>authenticity, man-in-the-middle attacks become a real threat. The
>recent release of dsniff 2.3 which makes available "point-and-click"
>man-in-the-middle attacks against SSH and SSL is a hint of the tools
>that will soon be publicly available to attack IPSec.

Not even close to the same attack model.  If you use RSA encrypt mode, you
are strongly protected against man-in-the middle.  If you are running your
own CA and maintain it offline, leaving only the repostory online, you can
pretty much run clean.  You see, SSL depend on at the time of connection
verification of keys.  SSH when it gets loaded (which with the win version
can happen at the strangest times, it seems).  But with IKE, you are
pre-storing certificate info that will be checked.  Only if the CA is
comprimised MIGHT there be concern (the bad guy first has to figure out
what is in your policy database.  He can't figure that out by looking at
Main Mode packets.

G-d, I HATE this protocol.  Too much to keep straight.

>There _is_ an advantage in letting your machine generate random keys
>for you, but users of IPSec should be doing this anyways (or flipping
>a coin) to generate static keys. There is no point in using robust 128
>bit key encryption algorithms if your key is "bob", or even "7:3O -
>mAn, @m 1 3v3r hunGry!".

Provided that the software is really generating good random nubers.  But it
better have for the IPsec IV (if you are using a CBC crypto)....


Robert Moskowitz
Senior Technical Director
ICSA Labs, a division of the TruSecure Corporation
	(248) 968-9809
Fax:	(248) 968-2824
rgm at icsa.net

There's no limit to what can be accomplished
if it doesn't matter who gets the credit

VPN is sponsored by SecurityFocus.COM