QUESTION & ANSWER

Crypto for VPNs: Questions and answers

By SearchSecurity 29 Mar 2002 | SearchSecurity

Digg This!     StumbleUpon     Del.icio.us

Why doesn't IPsec use the same encryption algorithm as SSL?
Phifer: SSL (Secure Sockets Layer) can be used with several encryption algorithms, but most common is the RC4 stream cipher. Stream ciphers depend upon endpoint synchronization and work best over reliable connections, like HTTP over TCP. However, stream ciphers are not particularly well-suited for use in lossy networks, a very common environment for IP. Instead, it is better to encrypt IP with a block cipher algorithm like 3DES, CAST-128, RC5, IDEA, or Blowfish. ESP uses these algorithms in cipher block chaining (CBC) mode. To learn more, see RFC 2451 (http://www.ietf.org/rfc/rfc2451.txt).

Lisa Phifer

Why is IPsec security stronger than wireless LAN security?
Phifer: The IEEE 802.11:1997 standard for wireless LANs defined two security measures: shared key authentication and Wired Equivalent Privacy (WEP). These measures rely on group secrets that must be configured into every wireless client and access point.

Using WEP with static keys is like using IPsec without IKE (Internet Key Exchange). However, IPsec manual keys are configured per tunnel, while static WEP keys must be the same for all wireless stations. In practice, manual IPsec keys are rarely used; most IPsec tunnels are automatically keyed by IKE. Secret keys derived by IKE are much harder to compromise: They are more dynamic and have greater entropy. Each key is used for just one tunnel, often for just one hour. Static WEP keys are used by every wireless LAN station, often for weeks or months.

Furthermore, IPsec encryption algorithms operate securely in datagram networks. WEP uses RC4; this was not a particularly good choice for wireless. To withstand packet loss, an initialization vector must be carried in each WEP frame. Unfortunately, this IV is too short to prevent keystream reuse; reuse makes it possible for an attacker decode captured ciphertext. WEP also lacks IPsec's hashed message authentication code ?- wireless LANs can detect errors, but cannot prevent malicious modification. Finally, IKE public key authentication is much stronger than either group pre-shared secrets (sometimes used with IPsec) or WLAN shared key authentication.

What support does IPsec have for integration of AES, and how is performance affected?
Phifer: AES is the Advanced Encryption Standard approved by NIST as a replacement for DES. AES is the standard name for the Rijndael (Rain-doll) algorithm, selected from 15 top contenders in October, 2000. It is a symmetric-block cipher that can be used with 128, 192, and 256-bit keys. AES was chosen because it is both cryptographically strong and efficient to implement.

To use AES with IPsec, further specification is required to identify and negotiate the algorithm in IKE and apply the algorithm in ESP. This work is underway, documented in an Internet-Draft (currently http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-03.txt). See section 2.7 and the studies referenced there for information about AES performance and how it compares to algorithms used today with IPsec.

Our VPN clients use SecurID. Is that the same as IKE authentication?
Phifer: IKE and SecurID involve two very different kinds of authentication. IKE requires mutual authentication between peer security gateways, based on pre-shared secrets or public keys. SecurID supports two-factor user authentication, based on a hardware or software token. Companies often use SecurID to authenticate dial-up users: The user must present both his PIN (something he knows) and the value currently displayed on the SecurID token (something he has) to be granted access.

Some remote access VPN products let SecurID authentication be invoked during IPsec tunnel setup. One common implementation, XAUTH, follows IKE Phase 1 authentication with open-ended user authentication, then continues with IKE Phase 2. You might think that two authentications are better than one, that's not necessarily true. XAUTH is often used with an IKE group pre-shared secret -? doing so facilitates access by dynamically addressed clients, but prevents meaningful authentication of the security gateway. IETF standards remote access standards will provide other, more secure methods of integrating SecurID and other types of user authentication with IPsec VPNs.

What are Diffie-Hellman groups? Which DH Group should my VPN use?
Phifer: DH Groups 1 and 2 are Diffie-Hellman exchanges using the large prime numbers defined by RFC 2409. DH Group 1 uses a 768 bit modulus. DH Group 2 uses a 1024 bit modulus. The larger the modulus, the greater the entropy of the keys generated by the DH exchange. Additional groups are now being standardized, including longer modulus groups to be used with AES and elliptic curve groups to be used with handheld devices. In the absence of other factors, one should always use the DH Group with maximum entropy. To learn more about DH Group entropy and how to pair DH Groups with encryption algorithms, see http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-04.txt.

Explain HMAC a little more please?
Phifer: Hashed Message Authentication Codes (HMACs) are used by IPsec AH and ESP to provide data integrity and source authentication. HMACs are based on hash functions like MD5 and SHA1. These hash functions can be applied to any message to generate a digest -? a short, fixed-length summary of the message. When a hash function is combined with a secret key, this is a message authentication code (MAC). HMACs are a particular kind of MAC, specified by RFC 2104 (http://www.ietf.org/rfc/rfc2104.txt).

To generate an HMAC, the secret key is XOR'ed with an inner pad value, then hashed with message text -? this produces a keyed hash value. Next, the secret key is XOR'ed with an outer pad value, then hashed with the first hash value. This produces a second keyed hash that is carried within AH and ESP packets. The recipient uses the same algorithm, secret key, and message text to generate his own HMAC. He compares his HMAC to the HMAC carried in the arriving packet. If the two values match, the packet is considered authentic. If the two values differ, the packet is discarded because the message was either modified in transit or the HMAC was generated with the wrong key or algorithm (e.g., forged by a man-in-the-middle).

Can you explain about split tunneling? Is this a must in a VPN client?
Phifer: Split tunneling refers to VPN clients that can simultaneously exchange plaintext with public hosts and IPsec ciphertext with private hosts. IPsec selectors identify destinations that require encryption and authentication. VPN clients without split tunneling use a catch-all IPsec selector (0.0.0.0/0.0.0.0) to funnel all traffic over the IPsec tunnel. VPN clients with split tunneling can be configured with more specific IPsec selectors ? for example, only traffic to 192.168.0.0/255.255.255.0 goes over the IPsec tunnel. These clients can often be configured with several selectors, tunneling private traffic to the security gateway in front of each private network.

Split tunneling adds risk. A VPN client simultaneously connected to both the Internet and company network can inadvertently expose company resources ? for example, by making a corporate fileshare visible to outsiders. A seriously misconfigured or hacked client might even relay packets between the Internet and the company network. Without split tunneling, connecting the same PC at different times to the Internet, then to the company network introduces risk. Split tunneling only increases this risk.

Despite this, I strongly prefer a VPN client that supports multiple tunnels. A user without split tunneling may disable the client when he wants to connect to the Internet, then forget to re-enable it later. I would rather have a full-time VPN client that can support any security policy I decide to implement. In my view, the decision to permit or deny split tunneling should be made by your company, not by your IPsec vendor.

Is using the same VPN gateway for multiple VPNs a security issue? Can the separate recipients intercept each other's traffic?
Phifer: Except for entry-level SOHO boxes, most VPN products can support multiple tunnels. In a full-mesh VPN, each gateway has a tunnel to every other gateway. In a hub-and-spoke VPN, most gateways have just one tunnel (spoke) to a centrally-located gateway (the hub). Spokes may be able to reach each other by relaying traffic through the hub. Whether or not relaying is permitted is determined by security policy. Traffic from one spoke usually cannot reach another spoke unless the IPsec selectors at both the hub and spoke explicitly permit this. Configuration options vary by product.

What does Soft Lifetime and Hard Lifetime Mean and what are the actions taken specific to each? Are there any refreshment parameters that perform a similar function for manually-keyed IPsec?
Phifer: Each IPsec security association (SA) is associated with a lifetime. Lifetimes can be expressed in units of time or traffic. When an IPsec SA expires, IKE quick mode must be repeated to rekey the tunnel. When an IKE SA expires, IKE main or aggressive mode must be repeated to reauthenticate the peer and regenerate keying material.

A soft lifetime is merely a warning that the hard lifetime is about the expire. Reaching a hard lifetime actually disconnects the SA. Soft lifetimes give the IKE peers time to rekey the SA without disrupting communication before the hard lifetime is reached.

Manual IPsec requires the same static keys to be configured into each peer. These static keys remain in use forever -? or until someone updates both configurations. Products that do not support IKE occasionally support some other dynamic key exchange ? for example, SKIP. But this is rather unusual. Today, VPN products that support manual IPsec do so primarily for testing and to get around exceptional interoperability problems. If key refresh is needed, you should probably use IKE.

Tags: IPsec VPN Security,  VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT IPsec VPN Security Best Remote Access Products How to set up a split-tunnel VPN in Windows Vista What is the difference between a VPN and remote control? A short enterprise VPN deployment guide From the ground up: Creating secure WLANs Can S/MIME, XML and IPsec operate in one protocol layer? How to create a secure network through a shared Internet connection What firewall controls should be placed on the VPN? VoIP tools, attacks could increase threat Best practices for processing financial data through remote servers IPsec VPN Security Research

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary Internet Key Exchange  (SearchSecurity.com) network encryption  (SearchSecurity.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary