Fragments

Doing It Right in PKI-Enabled Cisco VPNs: Choosing and Protecting Keys

February 25th, 2009 | by Jan Bervar |

So you’d like to implement a Cisco IPsec VPN using RSA keys and certificates in a PKI to authenticate peers? I’m guessing that your reasons for this are (some of) the following:

• You understand that partially or fully meshed VPNs require a scalable peer-authentication method.
• You choose not to use pre-shared keys because you don’t have a good enough random-key generator (hint: get one here), and Cisco IOS should have a decent pseudorandom generator for RSA keys (at least, according to FIPS 140-2).
• You already have a PKI and would like to unify your authentication methods.
• You have some non-technical reasons for doing so.

This series of articles should help you to avoid some of the most important and often overlooked issues. Let’s start with the basics: the RSA keys themselves.

The first important step is to choose the correct key length for your public and private RSA keys. Today, going below 1536 bits could expose you to serious risks in upcoming years (look here for various recommendations), and Cisco IOS supports RSA keys only up to 2048 bits long. Therefore, choose 1536-bit or (better) 2048-bit keys, realizing that longer keys will be more demanding on routers during the initial Phase 1 IKE exchange.

The second important issue is private RSA key storage: will you store the private key inside the device’s NVRAM, or would you prefer external storage in a USB smart token? If you require more tamper resistance (more about this issue shortly), or if you want to be able to replace the router easily after a hardware failure (without re-enrolling it in the PKI), choose the smart token.

If you choose NVRAM storage, an important issue is whether to make the private key exportable. If your router will not be acting as a certificate authority, make the private key non-exportable as additional private-key protection. If the router will be acting as a CA, you’d better have a copy of your private key stored somewhere securely, so that you can restore your CA if the router fails.

A final important issue is how to protect the private RSA key. By default, the private key is stored in private NVRAM and could be accessed by someone hardware-probing router memory, or finding a bug in IOS that would allow private NVRAM disclosure. If you require stronger protection, but are willing to sacrifice ease of use, consider the following:

• Use the supported smart token with a PIN that unlocks the private key on it. The PIN can be entered manually through the CLI each time it’s needed (unlikely to be useful, except in extreme scenarios) or burned into the device’s configuration. (Be sure to disable password recovery if you choose this option!)
• Encrypt the private RSA key in private NVRAM with a passphrase, which requires unlocking the private key the first time it’s used after boot (logging onto the router and typing the passphrase). If you don’t have an operationally viable method, this option might not be useful.

In part 2 of this series, we’ll learn how to enroll a device into a PKI properly and how to devise a key rollover strategy.