Preshared keys - Any alternatives for "on the box" configs?

[kirkster]

Hello,

My second post.

I am using preshared keys on my customers at the moment. I do not want to get into the complexities of digital certifcates and authorities for a while yet. Are there any other techniques I can use for configuring the keys that allow me to do this on the routers (37xx) without going off to an external server? I have tried to read the docs on cco but I am finding this very confusing and complex.

I am a bit weary of this pre shared keys business. It looks a bit unscalable to me. Do preshared keys still use isakmp? I ask this since I have seen messages on this port with my analyser but can't think why if the keys are preshared.

I have ordered the Sadaat Malik book since I want to start studying this security a lot more.

Thanks,

Steve

[mostiguy]

Pre shared keys aren't scalable. PKI is a PITA. Choose your poison ;-)

The only alternative is rsa encrypted nonces, but only IOS supports them - PIXen and 3000 concentrators don't. I would tend to avoid using them for interoperability purposes - most everyone supports certs and preshared keys

You can use pre shared keys with isakmp - they are basically used to get the tunnel up, and then usage of Diffie Hellman to negotiate a new shared session key which is used for the lower of the two lifetimes (time in sec, or data traffic byte count) until another DH key is negotiated.

IMHO, setting up IPSec without ISAKMP is more laborious on cisco gear than using ISAKMP. And not using ISAKMP means no changing keys, no replay prevention, etc. Most cisco demo configs will show the use of isakmp - there is little reason not to use it.

[kirkster]

Thanks for that.

So let me clarify one point here. Even though I am using a preshared key - something simple like STEVE say, the routers still use isakmp to negotiate a another secret key? Also, using default settings, such a negotiated key will be changed after 86400 seconds? But if that is the case, this generated key is used locally and never sent across the wire?

This is what I do on most of my customers:

!

crypto isakmp policy 100

authentication preshare

group 2

encrypt 3des

!

crypto isakmp key STEVE address xx.xx.10.10

!

crypto ipsec transform-set MUM esp-sha-hmac esp-3des

!

crypto map VPN 100 ipsec-isakmp

set peer 10.10.10.10

match address SITE_ACCESS_LIST

set transform-set MUM

!

That's about it. When using an analyser, all I can see is the IPsec tunnel endpoints and the esp protocol in the output. The data is encrypted.

IS there anyway I can tighten this up or is this a perfectly valid config for a network of say 10 sites? I was looking at RSA myself, however, you don't recommend it?

Thanks for your kind help and assistance.

Steve

[mostiguy]

1. preshared keys, certs and rsa encrypted nonces are just authentication methods. They allow you to establish each others authenticity. DH is used to create keys used for bulk encryption. Enabling perfect forward secrecy will ensure that each DH key is unrelated to any other.

2. rsa nonces are just semi alone in the cisco world - only supported on IOS. That is my biggest concern with them.

3. across the wire - neither the shared secret key or DH keys should ever be sent across the wire - the beautry of DH is that it allows you to establish a shared secret in a hostile world.