Republished with permission from
WatchGuard Technologies, Inc.
Security Parameters for Site-to-Site VPNs
by David M. Piscitello, President, Core Competence, Inc.
IP-based Virtual Private Networks (VPNs) provide authenticated, encrypted tunnels between branch and corporate offices. The Internet Key Exchange protocol (IKE) and IP Security (IPsec) standards identify many options for end point authentication, data privacy, and message integrity. While these options provide enormous flexibility and broad international application, not all network administrators understand them thoroughly. The result: the most common problems in deploying VPNs, especially in multi-vendor deployments, arise from mismatched configurations. You should always strive to deploy the most secure VPN tunnels possible. To support you in that goal, this article will help you understand the important IKE and IPsec parameters, and what choices you should make.
IKE is commonly used to authenticate VPN tunnel end points (for example, a Firebox and a RapidStream Security Appliance) and to negotiate security parameters for a "management" tunnel. Once the IKE management tunnel is established, you've got a secure channel over which you can create IPsec tunnels for secure data transfer between trusted networks, protected by the tunnel end points. This configuration is known as site to site. Here's a quick synopsis of what IKE accomplishes for you:
1. Negotiates the policy and keys that will be used to protect communications between IPsec end points (IKE peers); the result of this negotiation is called the Phase 1 Security Association, or SA.
2. Performs end point authentication between IKE peers.
3. Negotiates the policies and keys that will be used to protect an IPsec Security Association (also known as a Phase 2 SA). These SAs are used to securely transfer IP data.
End Point Authentication
Before you allow hosts at your site to communicate with hosts at the remote site, you perform end point authentication to verify the identity of an IKE peer (an IPsec capable firewall, router, or security appliance). This is similar to how your browser verifies a Web server's digital certificate when you use SSL to make an electronic purchase. The difference here is that with IKE, each party verifies the identity of the peer on the other end (symmetric authentication).
What is "identity" in this context? Usually, in site-to-site IPsec VPNs, it's the IP address of the external interface of your security appliance. Alternatively, you can also use the fully qualified domain name (FQDN) associated with this IP address. Choose FQDN only when an end point has a dynamically assigned IP address.
To authenticate end points, you must select an authentication type. The most commonly used authentication for IKE is pre-shared keys. As the name suggests, both end points must be configured with the same value. How you do this is a non-strenuous exercise left to your creativity; however, you should apply strong password policies. Digital certificates provide stronger authentication. While I recommend you use this method whenever it's available, begin with pre-shared keys, then deploy digital certificates later, so you can deal with IKE and IPsec debugging separately from certificate deployment issues.
IKE Security Association Parameters
IKE standards specify two modes of key exchange, Main and Aggressive. Main mode uses a six-message exchange, and protects (hides) the end point identities. It is the more secure of the two, and is commonly used in site-to-site deployments. However, you must use Aggressive mode if you are using FQDN and pre-shared keys. (Main mode with pre-shared keys requires an IP address identity.)
A Diffie-Hellman (DH) exchange is a method IKE peers use to obtain the same keying material for encryption and authentication without ever exchanging the entirety of any keying material. (Keying material refers to very large random numbers used as the base number and the exponentiation factor in cryptography.) You'll need to specify the Diffie-Hellman (DH) Group to be used in this exchange: this is essentially a large prime number p and generator number g that support the mathematics used to generate keying material. IKE peers must agree upon a DH Group to perform the DH Exchange. The default Diffie-Hellman group (1) is sufficient for DES encryption. Groups two and above provide greater security for 3DES.
You must choose the symmetric encryption algorithm that will protect IKE Phase 2 exchanges. When you encrypt IKE message data, you apply an encryption algorithm and a shared session key (derived during the DH exchange) to transform an original message from plain text into a ciphertext. Only the holder of the same key as the encrypting system can decrypt this message (thus, the terms shared secret or symmetric key encryption). The IKE standard allows many different encryption methods, but the most commonly used are DES and 3DES. Note that 3DES is not "three times" stronger than DES. "Triple" refers to the number of times a given 64-bit input is encrypted, each time with a different key. The result is generally believed to be 256 times more difficult to crack.
Message Authentication. A hash or message digest is a mathematical transformation that takes an arbitrary length message, and derives a small, fixed length value with the following unique property: if someone alters your message, it's computationally unlikely that it would hash into the same value you computed on the original message. A hash does not assure message integrity; however, a signed hash (or hashed message authentication code) does. When using pre-shared keys, each IKE party computes a hash on its Identity information and includes that hash in an encrypted message to its remote peer. The key used for authentication is derived from the shared key and keying material created during the Diffie-Hellman exchange. When the IKE peer receives this message, it decrypts the message, then computes its own value of the hash, using the same shared key; if the value proves to be "mutually obtainable," the integrity of the message serves to authenticate the exchange. Thereafter, all management messages exchanged during Phase 2 are protected by a hashed message authentication code. Of the choices available, Secure Hash Algorithm (SHA1) is considered more secure than Message Digest (MD5) because SHA1 uses a longer key (160 bit, compared to MD5's 128-bit key).
One of the many things cryptanalysts worry about is a key compromise. Once an attacker learns a key, he can decrypt any message he's previously captured. Since computing power still increases commensurate to Moore's Law, brute force cracking of encrypted messages is a potential threat. The longer you use a key, the greater the probability that the key can be compromised, so IKE uses symmetric keys that can be refreshed by repeating a DH exchange as frequently as you believe necessary to protect your IKE (and IPsec). All IKE and IPsec implementations provide a method for requiring key refresh, measured as elapsed time or maximum number of kilobytes of transferred data, or both.
A second concern IKE and IPsec address is an attacker's ability to crack one SA key, and use something learned from this key to more readily crack subsequent SA keys. When configuring IKE and IPsec, always select Perfect Forward Secrecy (PFS) to assure that compromise of a single key has the property of containment (only the data encrypted from this key are compromised).
IKE and IPsec security parameters are alIKE…
Many of the IKE parameters apply to IPsec, with the same recommendations. The same algorithms and keys for symmetric encryption and message integrity, PFS, and key refresh are negotiated for IPsec (Phase 2) SAs under the protection of the IKE "management" (Phase 1) SA. The vast majority of IPsec deployments use Tunnel Mode, which also provides you with the maximum flexibility if you use network or port address translation. You must also choose whether to use the Authentication Header, which only provides message integrity, or the Encapsulating Security Payload, which provides message integrity, plus confidentiality through encryption. Note that your IPsec SA's DH Group can only be as strong as your IKE SA's DH Group; for example, if you did not choose PFS for IKE, you cannot choose it for IPsec. Typically, IPsec SA lifetimes are shorter than IKE SA lifetimes. When an IPsec SA expires, the IKE SA is used to refresh the IPsec SA keys. When the IKE SA expires, the gateways start from scratch by repeating IKE Phase 1 again.
IKE automates authentication, key exchange, and key refresh, and should always be used when both gateways support it. If a security appliance doesn't support IKE, you can manually configure keying material used by IPsec SAs, but you sacrifice endpoint authentication, and key refresh is not automatic.
Vendors use different terminology. I've described the IKE security parameters using terminology from the standards, but beware that vendors don't use these terms consistently, even across their own products. Master the standards jargon and you'll stand a good chance of fielding intelligible responses from VPN mail lists, FAQs, and peers who have already tamed the VPN monster. ##
Copyright© 2002, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.
Copyright © 1996 - 2002
WatchGuard Technologies, Inc. All rights reserved.