Network Computingwww.networkcomputing.com

In main mode, two Oakley peers establish an SA for the purpose of performing secure communications. In quick mode, SAs are negotiated on behalf of IPSec or any other service that n eeds key material or parameter negotiation. For example, SSL (Secure Sockets Layer) 4.0 could use Oakley, which was designed specifically not to be tied to IPSec, instead of the SSL 3.0 key exchange mechanism for a much more secure session setup process.

DOI Needed ISAKMP/Oakley was not designed specifically for IPSec, so there is a domain of interpretation (DOI, pronounced "doey") that supplies the values for IPSec's use of ISAKMP/Oakley. Other protocols can use ISAKMP/Oakley by specifying their own DOIs. Currently, there is no other DOI, but this might change at the next IETF conference, or if a private developer like Netscape Communications Corp. decides to adopt the mechanism. For more information, see "The Internet Key Exchange (IKE)," available from the IP Security Protocol Working Group (ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-oakley-06.txt).

Main mode negotiates the encryption method, hash, authentication method and Diff ie-Hellman group. The D-H group (four are specified) determines the strength of the keying material. D-H Group 1 is strong enough for DES, while Groups 2 or 3 should be used for Triple DES. Because main mode might require six packets, in high-latency satellite connections for example, it might be better to use the stronger D-H group for DES. Then, the more lightweight quick mode exchanges can be done before a computational and data-packet-intensive main mode must be performed again.

When main mode establishes the Oakley SA, it creates a block of random bits referred to as the keying material. It also negotiates the Oakley lifetime; that is how long--based on time duration or data throughput--that the Oakley SA and its keying material is valid before another main-mode negotiation is required.

Quick mode is simpler than main mode and negotiates the actual IPSec SA in three data packets. It establishes this SA with replay protection and, through a simple exponentiation operation on the main-mode keying ma terial, produces the IPSec session keying material. Quick mode also negotiates the algorithms and lifetimes for IPSec.

These lifetimes determine how often, based on time or data, another quick-mode negotiation is required. Note that there are two different lifetimes. The main-mode lifetime controls the Oakley SA, and the quick-mode lifetime controls the IPSec SA. An example of how these lifetimes are commonly implemented might be setting the quick-mode lifetime at 15 minutes, or 10 MB, and the main mode at 1 hour, or 40 MB, when DES is being used for IPSec. These numbers would be increased for Triple DES or decreased for ARCFour (ARCFour uses a 40-bit key, compared to the 112-bit key of Triple DES). This approach balances the strength of the IPSec services against the strength

of the underlying cryptographic algorithm against the cost of ISAKMP/Oakley packet overhead.

The main-mode rekeying also can enforce session termination based on certificate revocation. End-point certificates are used only dur ing main mode. Thus, only during main mode will the exchange fail if one of the certificates has been revoked. The lifetime of main-mode- and quick-mode-negotiated keys may vary significantly based on the type of data and transactions that use the IPSec connection. Properly determining these lifetimes--weighing both the computational and network overhead versus the potential for data compromise--is the subject of some study.

The combined mechanisms of IPSec provide for very secure connections between networks as well as end stations. Vendors are implementing these standards, which will inevitably yield an environment where secure connections can be implemented across the Internet. IPSec will be a cornerstone upon which secure and private commerce and collaboration will exist on the Internet.

Robert Moskowitz is a senior technical director at the International Computer Security Association and a member of the Internet Architecture Board (IAB). He can be reached at rgm@htt-consult.com.