The adage that time stands still for no man could hold true for VPNs, where a host of proposed standards will help make the technology more efficient and secure in the future.
Within the Internet Engineering Task Force (IETF), proposals abound for tinkering with the complex, multifaceted IP Security (IPSec) standards that spell out how to establish secure VPN connections over the Internet. These VPNs require ways for users to authenticate themselves, for traffic to be encrypted and for verifying that no one has tampered with traffic being received.
Perhaps the most anticipated standard proposal is called Just Fast Keying (JFK), which would replace Internet Key Exchange (IKE), the standard for negotiating VPN sessions and managing encryption keys that are used in each VPN session. (JFK is an acronym, but the name also stems from the fact that JFK succeeded Ike as U.S. president.) Some fear IKE is so complicated that it may be insecure.
While it is widely used among IPSec VPN vendor equipment, the IETF acknowledges IKE could have potential security flaws, at least in theory, even though no specific flaws have been exploited.
JFK would perform the same functions as IKE, but would be simpler, thereby opening it up to fewer threats. It is being developed by a group, many of whom work at AT&T Laboratories, but has not yet been publicly proposed. At the IETF meeting last summer, the group said it would have the technology ready sometime this year. Drafts of JFK are rumoured to be circulating, and it could be ready when the IETF meets in December in Salt Lake City.
Like IKE, JFK would orchestrate the exchange of encryption keys between VPN gear. Unlike IKE, it would do so with fewer messages. This streamlining could make access to busy VPN sites noticeably faster, says Paul Hoffman, director of the VPN Consortium that has been following JFK, and a Network World (U.S.) columnist.
Less sweeping than JFK, a proposal called pre-IKE credential (PIC) protocol would make it simpler for companies to adopt digital certificates, the only way to authenticate VPN remote access users that meets the IPSec standard. Letting corporations adopt digital certificates gradually can save them time and expense, up to US$180 per user, according to Gartner Inc. Rather than switch to digital certificates all at once, companies could keep their current authentication methods operational as they migrate users to digital certificates a few users at a time.
Use of digital certificates requires a public-key infrastructure (PKI) for exchanging the digital keys used to authenticate the certificates. Because implementing PKI is quite complex, it is easier to phase in the use of digital certificates gradually, leaving legacy, non-IPSec authentication methods such as Remote Authentication Dial-In User Service (RADIUS) and RSA Security Inc.’s SecurID tokens in place at the same time.
There are other schemes, such as extended authentication and hybrid authentication, besides PIC that VPN vendors already use, but they have stalled in the standards process. Part of the reason they are bogged down goes back to the controversy over IKE. Extended and hybrid authentication require changes to IKE; PIC does not.
As a practical matter, vendors are implementing and advocating ways to handle legacy authorization and digital certificates that intrude into IKE. For instance, Nokia Corp. supports an alternative technology called challenge/response authentication of cryptographic keys (CRACK). CRACK also allows using RADIUS servers and secure tokens for authentication while supporting digital certificates. But it injects itself as part of the IKE protocol, which makes it unacceptable to some VPN experts.
The PIC proposal has received comment from IETF members and could be moved out of an IETF working group soon, which would put it on the formal track toward becoming a standard.
While the IETF considers these suggestions, an encryption standard awaiting U.S. government approval will deliver a lightweight encryption algorithm for securing VPN links. Called Advanced Encryption Standard (AES), it encrypts data in one step as opposed to Triple-DES encryption, which takes three steps. Triple-DES encrypts using the Data Encryption Standard algorithm, re-encrypts it and then encrypts it again, eating up processor cycles.
AES is harder to break than Triple-DES, but in a practical sense Triple-DES is plenty secure. It would take 4.6 billion years to break it with a computer that is far faster than anything available today. AES would take even longer, according to the National Institute of Standards and Technology (NIST), which sets standards for the federal government in a range of areas.
But the more desirable characteristic of AES is the streamlined way it computes encryption keys, says Paul Serrano, a senior product development manager at NetScreen Technologies Inc., the first VPN vendor to support AES. This “computationally less-intensive algorithm” means devices with relatively weak processors can still use this strong encryption without forfeiting as much speed as Triple-DES would eat up.
Notably, handhelds, which have relatively weak processors, would benefit from AES, Serrano says.
NIST has designated an algorithm known as Rijndael (pronounced “rain doll”), after the names of its creators, as the winner of a competition to design AES. Once NIST approves it for use by federal agencies, it will become the official government AES standard. That status should encourage vendors to incorporate it in their products, Serrano says.
NetScreen acknowledges the AES capability will be used initially for interoperability testing with other vendors. As it comes into common use, NetScreen says it will make custom processors to speed AES encryption.
Separate from encryption, the IETF is also close to an agreement on a way for IPSec software clients to work with any IPSec VPN server even if the VPN traffic has to cross corporate firewalls. Firewalls perform network address translation (NAT) to shield private IP addresses from the Internet, but NAT also blocks IPSec connections. Individual vendors have worked around this, but a standard would make it easier to build corporate VPNs using equipment made by many vendors.
Two NAT proposals could come out of the IETF’s IPSec remote access working group next month, putting them on the formal track to standardization, says Hoffman, who is also the committee’s chairman. One proposal defines how clients and servers determine if there is a device in between them that is performing NAT. The other spells out how to get around the problem.
The latter proposal calls for wrapping up VPN traffic inside User Datagram Protocol (UDP) packets that can traverse NAT devices without being rejected by VPN equipment. These proposals might be finished in time for the December IETF meeting, Hoffman says.
While standards processes are often painfully slow, they are the established way to bring about improvements that will make VPN gear more efficient and interoperable.
