The remaking of IPSec

Chicago

Call it IPSecond.

That's what IP security experts gathering this week at an Internet Engineering Task Force meeting are dubbing their work on the IP Security (IPSec) draft standard.

The reason: So many changes are being proposed to the original draft - such as new security features and a secure client package - that it will make early IPSec-compliant equipment obsolete. For users betting on IPSec as the primary means of authenticating and encrypting IP traffic, the question will be whether to buy now or wait for companies to propose new, improved "IPSecond" features.

IPSec defines encryption, authentication and key management routines for ensuring the privacy, integrity and authenticity of data as it traverses public IP networks.

At its core, IPSec is intended to let users identify each other over a network by swapping X.509 digital certificates - or some shared secret - in order to set up an encrypted IP tunnel.

"There are things we need to change, and some will be easy and some will be hard," says Bob Moskowitz, co-chair of the IETF IP Security Work Group. "Vendors are going to have to make changes to their existing equipment."

According to Moskowitz, one of the items the working group will look to accomplish is the addition of a new cryptographic algorithm to IPSec. At the meeting, IBM will propose adding a new authentication algorithm for faster data processing in the Internet Key Exchange (IKE). IKE supports RSA and the government's Digital Signature Standard.

Achieving faster processing becomes important when a gateway has to handle 1,000 connections at a time. The auto industry expects to see that level of traffic when using IPSec for security in the Automotive Network Exchange (ANX), Moskowitz notes.

The ANX is billed as the world's largest industrywide extranet; it is likely to link thousands of vendors and customers.

The harder IPSec change will be standardizing on an IPSec remote client. The goal of the IETF meeting is to define a client that can support IP address changes automatically, Moskowitz notes.

"If the user is dialing in and the ISP assigns an IP address, the IPSec gateway will need to know how to let randomly assigned addresses within this tunnel," Moskowitz says.

The IPSec working group wants to define a way to establish an encrypted session, in which the gateway will be able to assign an IP address to control where the remote user is allowed to go inside the intranet. This will mean having to change how the IPSec server now works.

Unfortunately, the IPSec working group is not in accord with another IETF group, called the IP Mobile working group, on exactly how this should be done. Another difficult item on this week's agenda will be redefining the core IKE protocol. Security experts recently uncovered a flaw related to the improper exposure of information, Moskowitz says.

And IKE, as it now exists, handles time-expiration of session keys in a way that could cause one gateway not to understand another.

In addition, when two IPSec servers fail to establish an encrypted session with each other, they can't exchange details on why the session failed.

The IPSec working group wants to remedy that oversight before the IPSec standard gets too far along.

Without a uniform IKE, there will be no IPSec interoperability unless users are willing to manually exchange keys - an impractical notion. n