How to implement certificate based authentication?

[hbaerten]

Hi,

imagine a network consisting of multiple remote sites (connected to Internet with a dynamic IP address) setting up a vpn to a central site.

The central site wishes to allow only connections coming from "authorised" devices, i.e. remote vpnrouters rolled out by the central office.

Using a wildcard pre-shared key for the ISAKMP authentication is the simplest option, but since the key is stored in plaintext and the device will be located at an untrusted (customer) site, this is a relatively large security risk.

So the logical step would seem to move towards certificate based authentication. However, I'm not sure how to picture this resulting in stronger authentication without implying too much overhead.

The way I see it, you have to make your CA (or RA) publicly accessible on the internet. But that means anyone can send a cert request, so the enrollment procedure must include some form of human intervention to validate the request, right? This makes the whole process of enrollment and especially auto-renewal of certs quite cumbersome, in fact this is not really "auto"-renewal at all...

So is there another way of setting this up, without too much overhead, yet still assuring that only authorised devices can connect?

tia

Herbert

[jsivulka]

Yes, there is human intervention while validating certificate requests and issuing them. However, the important point is that this is necessary only once, ie when getting the certificate initially. Each time a new device is added, you would need to get a certificate for the new device only. You will not have to change or enter new passwords on each of the existing sites to enable them to authenticate to the new device.

[hbaerten]

I see, but since we would use a wildcard pre-shared key (i.e. the same key on all devices) this also only requires adding the key to a new device only.

So the only advantage I see of using certs is the longer key length and the fact that the key is not revealed when doing a "sh run".

The disadvantage would be the manual intervention not only during initial enrollment but also during renewal.

Except, as I suggested in another reply, if the ca used for renewals does auto-approval and is only accessible through the vpn (i.e. only from devices that already have a valid cert)?

tnx

Herbert

[jasobrown]

Depending on your Cert Server setup you can have it auto approve the cert (not a good idea). The problem that I see here is the age old issue of Security vs Convenience.

What devices are you using that have the pre-shared key in clear text?

[hbaerten]

Well, I was thinking of installing the first certificate "manually" before shipping the device to the remote site; then have it renew its certificate (daily? monthly? annualy?) using a cert server that is accessible only through the vpn, and is configured to auto-approves renewals.

In that case manual intervention would only be needed for a new customer, and in (a hopefully rare) case an auto-renewal fails.

The devices we intend to use are Cisco 836 routers.

Apart from the auto versus manual enrollment, would you consider this setup as secure?

Won't it still be possible for example for a malicious person with physical access to a decive, to somehow "clone" the device (I have never heard of anyone or anything doing this but I imagine it is not impossible) thereby simply copying the keys and the certificate. With that identical copy he can then connect to the central site disguised as a legitimate user... ?

But then I guess the only solution would be to use some kind of TRD to store the key.

Anyway thanks already for your input so far!

Herbert

[Jan Wachsmuth]

There are some new IOS features in 12.2T like Certificate Autoenrollment http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/ftautoen.htm, but also features like encrypted pre-shared keys http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123t/123t_2/gt_epsk.htm.

It´s now (12.2(15)T http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/ft_key.htm) also possible to export private key and certificate, so a router may be cloned with either pre-shared keys or certificates.

Certificates have a little more overhead, but are more secure. Imagine, one of your routers gets lost or the pre-shared key/certificate/private key was discovered by a former employee or hacker. With certificates you can simply revoke the certificate of that router and use a Certificate Revocation List CRL, but with pre-shared keys you need to change the pre-shared key in every configuration. Especially when you have a large number of routers or VPN software clients I prefer certificates. When the number is small, then pre-shared keys are easier to implement.

[hbaerten]

I knew about autoenrollment, the point was that it still requires human intervention on the CA to approve the enrollment.

Encrypting pre-shared keys looks interesting, thanks for the tip.

The ability to revoke a certain certificate without having to update all other routers is a definite advantage, thanks for pointing that out.

But I guess the remaining question is: how do I prevent cloning of a router?