In a curse more deadly than making the cover of Sports Illustrated, public-key infrastructure (PKI) has been given product of the year status. It hasn't lived up to that billing yet, for several reasons, including cost, complexity as well as the lack of qualified resources and a critical mass of business drivers. But it seems clear that PKI will eventually live up to its advance publicity - someday. E-commerce, combined with governments' granting certificates and digital signatures full legal status, will force PKI to take center stage - but not without significant changes to other legacy systems and practices.
Yet even while PKI seeks to solve big business problems, enterprises are implementing PKIs as a practical way to solve a technology problem - managing virtual private network (VPN) connections.
VPNs are beginning to standardize on the IP Security (IPSec) protocol. IPSec is the RFC standard to provide encrypted communications over TCP/IP. In order to provide compatibility with existing TCP/IP networks, fields in a packet such as source and destination addresses, packet type and checksum, pass in clear text. However, the data portion is encrypted.
Earlier competitive challenges to IPSec, such as Microsoft's Point-to-Point Tunneling Protocol and Cisco's Layer 2 Tunneling Protocol, have shown that they simply do not measure up. The forthcoming Windows 2000 includes IPSec. The protocol is already supported in all major firewalls and many routers.
A critical aspect of IPSec is how keys are exchanged to authenticate each endpoint of the encrypted tunnel. The protocol for doing this is called Internet Key Exchange (IKE), and supports manually entering preshared keys into both hosts, by the newly standardized Secure DNS and by a PKI Certificate Authority. Many network managers would perhaps prefer to use Secure DNS for VPN authentication were it two years more mature, but VPN vendor support is more prevalent for PKI, and it is the method gaining much attention. Just as manually configuring networking devices from scratch gave way to centralizing configuration with boot images and TFTP servers, manually configuring shared secrets on every router and firewall is giving way to central management via a Certificate Authority (CA).
To manually configure a shared secret, you access each VPN device's console, use the appropriate command to configure the ISAKMP key, and enter the mutually agreed upon password plus the IP address for the adjacent endpoint. This is very quick and simple - until your router engineer quits and goes to work for your dreaded competitor. There is no central way to make the changes, and it becomes apparent to you that manually configuring IKE provides easy setup but zero management.
Configuring VPN devices to authenticate via a Certificate Authority is actually more work up front. However, it provides a scalable, centrally managed solution to revoking and reassigning the certificates used to create a trusted connection. To do this successfully, you need to follow several steps:
* Implement your PKI. When stripped bare of the need to integrate into line-of-business applications or direct-to-user interfaces, building a CA Server becomes much simpler. VPN vendors are recognizing this, and are even beginning to include a turnkey PKI in some product offerings, usually an OEM version of a major directory provider, such as Entrust.
* Generate key pairs at the VPN device. Depending upon your implementation, you will either generate two key pairs, one for encryption and one for signing/authentication, or one key pair for both.
* Identify the CA Server to the VPN device. This involves configuring the host name of the CA Server, the enrollment URL and downloading the CA Server's own certificate.
* Enroll the VPN device with the CA Server. An enrollment command will precede the CA administrator issuing the certificate for this device, and will usually be tied to passphrase to allow certificate revocation. While registering a user or device and issuing certificates are often separate in an enterprise PKI, these functions will likely be combined on a single CA Server that is designed for a VPN.
After these steps, you can continue on and configure the IPSec access control list and actually start to get data flowing over the connection. While many organizations cannot justify the business need for an enterprise PKI solution, or stumble over the costs and complexity, a vertically oriented PKI intended to ease management of VPN devices has much lower technology and cost barriers.
A turnkey PKI can be a boon to VPNs and the PKI market itself. It may be an overstatement to call it PKI's killer app, but the simpler any product becomes, the closer it is to killer application status.
RELATED LINKS
SecurityPortal.com PKI white papers
Checkpoint Certificate Manager for VPN-1
Cisco introduction to IPSec (Chapter 5, IKE configuration)
PKI interoperability tests postponed at Interop
Network World, 09/06/99
Public keys
Network World, 05/10/99
Archive of Network World on Security newsletters
Network World Security Alert will keep you up to date on the latest security holes and patches, with daily updates from key vendors, security organizations and Network World reporters. See the latest dispatches from the security here.
