Virtual Private Networks

We Need a Public Key Infrastructure

Many of today's virtual private networks (VPNs) are limited by their simple security systems. We discuss some of the changes that will be necessary in order to build massive, secure VPNs.

Lisa Phifer
VP Core Competence, Inc.

Many of today's virtual private networks (VPNs) exist without the support of a public key infrastructure (PKI). VPN endpoints — be they security gateways or clients — authenticate each other when establishing IPsec tunnels. At its simplest, this can be accomplished by configuring the same shared secret — essentially a pair-wise password — at both tunnel endpoints. This rudimentary approach works fine on a small scale, but becomes unwieldy in larger VPNs, especially large remote access VPNs with hundreds or thousands of clients.

Think of a small, cozy club where all members are known to each other because they've met before. It isn't hard to learn and remember names and faces in a small group. But a club with more than a few dozen members probably needs membership cards. A club officer issues membership cards. New members prove who they are when they obtain the card and can thereafter present the card for admission to members-only events. With this kind of infrastructure, two complete strangers can recognize each other as club members simply because they trust the membership cards.

Similarly, tunnel endpoint authentication can be based on digital certificates — essentially electronic membership cards for large VPNs. So why isn't every IPsec VPN using digital certificates today? Because large scale deployment requires not only certificates, but infrastructure: a trusted authority to issue certificates, a secure way to create and distribute them, and a readily-accessible means to validate their authenticity. This, in a nutshell, is PKI.

What Are Public Keys and What Are They Used For?
To understand the challenge behind PKI, we need to know a little bit about public key cryptography. This system is based upon key pairs that are mathematically related such that if one key is used to encrypt a message, only the other key can decrypt it, and vice versa. We can make one key in the pair public: give it to everyone we know, even post it on the web. If someone wants to send us a confidential message — perhaps someone we've never met — they encrypt the message with our public key. Because we've kept the other key private, only we can successfully decrypt the message.

These key pairs are also used to authenticate messages. The sender creates a message hash — a short version of the original message — with an algorithm like MD5. He encrypts the hash with his private key and sends it along with the original message. The recipient decrypts the hash with the sender's public key, rehashes the original message, and compares the two. If the hashes match, the recipient knows that the message wasn't modified in transit and must have originated from the holder of the private key. This kind of encrypted hash is known as a digital signature.

But recall that we need more than a signature — we need an electronic membership card. This is where certificates come in. A digital certificate binds the name of a person or device to a key pair, much like a membership card binds a member's name to his signature or photo. To ensure the certificate is authentic, we typically have it issued — and signed — by a third party that we trust. For digital certificates, the trusted signer is known as a Certification Authority (CA).

How IPsec VPNs Use Digital Certificates
When IPsec tunnels are created, the endpoints can authenticate each other with digital certificates. For example, security gateway X identifies itself and digitally signs a message with its private key. Security gateway Y obtains the digital certificate issued to X and uses the contained public key to verify the signature is authentic. That is, security gateway X must really be X because it generated a signature that could only have been generated using the private key associated with X's certificate.

Why are digital certificates more scalable than shared secrets? We no longer need to issue a unique pair of secrets for every pair of VPN devices. Each device has just one digital certificate. And we no longer have to reconfigure all other devices every time we add a new device to our VPN. Instead, we make certificates available to every device through a public directory — for example, using the Lightweight Directory Access Protocol (LDAP). Furthermore, if we want to join two VPNs, we can leverage existing certificates by having the issuers — two CAs — cross-certify each other. This is analogous to accepting passports issued by other countries as proof of identity.

Like passports, certificates have a specified validity period and can be revoked by the issuer when necessary. Present the signature associated with a non-existent, expired, or revoked certificate and you won't be successfully authenticated — at least that's the objective. Revocation can be a bit tricky if the authenticator doesn't check with the issuing CA. Even if the authenticator consults a list of revoked certificates (a CRL), the list may be obsolete. Do we issue the CRL weekly? Daily? Hourly? The answer is a matter of security policy and practice.

goto page 2: PKI Components