Case Study for Layer 3 Authentication and Encryption

IPSec tunneling protocol is based on the IPSec Security Protocol feature, which is framework of open standards developed by the Internet Engineering Task Force (IETF). IPSec provides data confidentiality, data integrity, and data authentication between participating peers. IPSec provides these security services at the IP layer; it uses IKE to handle negotiation of protocols and algorithms based on local policy and to generate the encryption and authentication keys to be used by IPSec. IPSec can be used to protect one or more data flows between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.

In IPSec tunnel mode, the remote users' VPN Clients encrypt the entire original IP datagrams. These encryptions become the payload in new IP packets. The VPN Clients initiate IPSec tunnels with a network device, such as a Cisco IOS router or a Cisco Secure PIX Firewall (gateway). The gateway acts as an IPSec proxy, performing encryption on behalf of all the hosts. The VPN Clients encrypt packets and forward them along the IPSec tunnel. The gateway decrypts the original IP datagrams and forwards them to their destination.

The major advantage of IPSec tunnel mode is that the end systems do not need to be modified to receive the benefits of IPSec. IPSec tunnel mode also protects against traffic analysis; with IPSec tunnel mode an attacker can only determine the tunnel endpoints and not the true source and destination of the tunneled packets, even if they are the same as the tunnel endpoints.

• The extranet partner purchases, configures and maintains the PC and the VPN Client software.

• The remote users, telecommuters and remote offices all obtain equipment from the enterprise.

• The enterprise network administrator purchases, configures, and maintains the VPN Client software, the remote access PCs on which the VPN Client software is to be installed, the home gateway, a public web server, and the private corporate server.

The manual configuration feature addresses the enterprise requirement to allow for a more secure method of assigning IP addresses to a small number of VPN Clients by assigning static internal IP addresses. A static IP address is a unique IP address that is assigned to a client for an extended period of time, to be used by only that client.

Without the manual configuration feature, it is difficult for the gateway to authenticate a VPN Client with an IP address dynamically-assigned through an ISP. A local ISP assigns the VPN Client a routable IP address from its pool. The VPN Client creates an encrypted tunnel to the gateway. The tunnel source IP address, which is the IP address of the client as the IPSec peer, matches the original source IP address, which is the IP address assigned to the client by the ISP for communications with the ISP. Because both source IP addresses match, the gateway cannot determine which source IP address belongs to the trusted peer.

For an enterprise with a small number of VPN Clients, manual configuration is a simple method of assigning internal corporate IP addresses to each remote VPN Client, making it easier to set up IPSec policy on each VPN Client. IKE Mode Configuration is the alternative to manually configuring internal IP addresses on each remote access VPN Client.

For a large number of VPN Clients, manual configuration is not a very secure method. The IP address on the VPN Client is static, and remains configured on the VPN Client even when a remote user is not logged on. The static IP address or IKE security parameters on the VPN Client can be viewed, then used by an untrusting party. The untrusting party can masquerade as the remote user. For this reason, manual configuration is less secure than IKE Mode Configuration in that it is more sensitive to IP spoofing attacks. Should an attacker get access to the IKE security parameters on a VPN Client, that attacker can masquerade as the remote user authorized to connect to the corporate network.

For a large number of VPN Clients, manual configuration is also not very scalable because each VPN Client must be manually configured. Each time the network grows, configuring and maintaining additional VPN Clients can be time-consuming and complex. Each time the gateway is reconfigured to permit access to more VPN Clients, each VPN Client has to be reconfigured to match the new gateway configuration.

To prevent attacks, the following instructions should be a part of your enterprise security policy:

• The gateway administrator must manually configure each client. Each time a VPN Client is added to the network, the gateway administrator must configure another access-list global configuration command on the gateway to permit traffic from that static IP address on the VPN Client. Also, the gateway administrator must ensure all traffic destined for the VPN Clients' subnet is routed back to the gateway to be encrypted, using the crypto map local-address global configuration command with interface loopback0. A loopback interface is a virtual interface that is always up and allows routing protocols to stay up even if the physical interface is down.

• On the gateway, the gateway administrator must configure an access-list rule matching each VPN Client IP address because of the source proxy definitions--which are IP addresses instead of subnets--on the VPN Clients.

• The gateway administrator must ensure all traffic destined for the VPN Clients' IP address pool on the enterprise subnet is routed back to the gateway for encryption, because the gateway does not automatically route to the VPN Clients. To do this, the gateway administrator must define a static route between the gateway and all VPN Clients.

The alternative to static IP addressing with manual configuration is dynamic IP addressing with IKE Mode Configuration.

The IKE Mode Configuration feature addresses the enterprise requirement to issue scalable, dynamic IP addresses to one or more clients by configuring scalable IPSec policy on the gateway. A dynamic IP address is an IP address that is temporarily assigned as part of a login session, to be returned to an IP pool at the end of the session. IKE Mode Configuration is a gateway-initiated IKE negotiation that occurs between IKE phase 1 and IKE phase 2. The gateway assigns a dynamic IP address to the VPN Clients, replacing any current IP address configuration on the VPN Clients. IKE Mode Configuration secures the connection between the VPN Clients and ISPs with an IPSec tunnel, and allows for dynamic IP addressing of VPN Clients from the gateway. With IKE Mode Configuration, you can download IP addresses (and other network level configuration, such as your IPSec policy) to VPN Clients as part of an IKE negotiation. The gateway administrator can add VPN Clients to the network without having to reconfigure the gateway or the VPN clients.

Without the IKE Mode Configuration feature, it is difficult for the gateway to administer scalable IPSec policy on many VPN Clients. A new IPSec policy is required for each VPN Client because each has a dynamic IP address, each dynamic IP address is assigned by the VPN Client's local ISP, and each of these dynamic IP addresses will not be within the enterprise subnet's IP address range.

When a remote user wants to connect to an corporate gateway, the remote user's VPN Client must first establish a point-to-point (PPP) connection to the ISP's NAS (network access server). The NAS authenticates the PPP connection. Then, the VPN Client initiates ISAKMP SA with the untrusted peer at the gateway. After the ISAKMP SA is created and authenticated, the gateway initiates IKE Mode Configuration with the VPN Client. After the VPN Client receives the dynamic IP address from the gateway, the VPN Client loads the IPSec SA from the gateway.

For corporations with large numbers of VPN Clients, IKE Mode Configuration is a scalable approach to assigning dynamic IP addresses and administering IPSec policy for VPNs between multiple remote access VPN clients and corporate networks. Gateway administrators do not have to manually configure each VPN Client, because no VPN Client configuration is required. With IKE Mode Configuration, the gateway can set up a scalable IPSec policy for a very large set of VPN Clients, replacing pre-existing IP addresses on VPN Clients with dynamic IP addresses within the IP range of the corporate subnet.

IKE Mode Configuration uses dynamic IP addressing, which is more secure than manual configuration with static IP addressing. The IPSec policy set up on the gateway uses dynamic crypto maps. With IKE Mode Configuration, each time a remote user forms a tunnel to the gateway using a VPN Client, a new IP address from within the corporate subnet's IP address pool is assigned to the VPN Client. Also, unlike manual configuration, IKE Mode Configuration does not rely on an access list because the gateway administrator can easily define the local address pool on the gateway. In addition, the gateway automatically defines a static route to the VPN Clients and inserts the static route into the routing table during IKE Mode Configuration. When all IKE and IPSec negotiations are completed, IKE Mode Configuration automatically removes the dynamic IP address, returns it to the corporate subnet's IP address pool, and removes the static route.

The alternative to dynamic IP addressing with IKE Mode Configuration is static IP addressing with manual configuration.

The pre-shared key feature addresses the enterprise requirement to allow for one or more clients to use individual shared secrets to authenticate encrypted tunnels to a gateway using IKE. The Diffie-Hellman key exchange combines public and private keys to create a shared secret to be used for authentication between IPSec peers. The shared secret can be shared between two or more peers. At each participating peer, you would specify a shared secret as part of an IKE policy. Distribution of this pre-shared key usually takes place through a secure out-of-band channel.

Note   When using a pre-shared key, if one of the participating peers is not configured with the same pre-shared key, the IKE SA cannot be established. An IKE SA is a prerequisite to an IPSec SA. You must configure the pre-shared key at all peers.

The pre-shared key feature requires that each client has its own pre-shared key, which must match a pre-shared key configured on the gateway for authentication. Use pre-shared keys for VPN Clients with static or dynamic IP addresses.

Pre-shared keys are commonly used in small networks of up to 10 clients. With pre-shared keys, there is no need to involve a CA for security.

To prevent attacks, the following instructions should be a part of your security policy:

• The gateway administrated must initially configure each client with a separate and distinct key for secure authentication.

• Each time another client or remote user is added, the gateway administrator must configure that client with a new key, and reconfigure the gateway to permit that new key.

• Each time a client or remote user is removed, the gateway administrator must reconfigure the gateway to deny the key that client used.

Without a method of client authentication, you cannot establish an encrypted tunnel between a client and gateway. Digital certification and wildcard pre-shared keys are alternatives to pre-shared keys. Both digital certification and wildcard pre-shared keys are more scalable than pre-shared keys.

The wildcard pre-shared key feature addresses the enterprise requirement to allow for one or more clients to use a shared secret to authenticate encrypted tunnels to a gateway. With a wildcard pre-shared key configured on a router, any peer using the same pre-shared key is a valid peer to the router.

The key that you configure on one peer is identical to the values assigned to prospective peers. With wildcard pre-shared keys, a peer is no longer a static IP address, but a subnet that is dynamically assigned by the router.

The wildcard pre-shared feature allows a group of clients with the same level of authentication to share a pre-shared key, which also must match a pre-shared key configured on the gateway for authentication. Use wildcard pre-shared keys for VPN Clients with static or dynamic IP addresses.

Because a group of VPN Clients with the same level of authentication share a key, the wildcard pre-shared key method scales better than pre-shared keys. Each time another VPN Client is added, that client only needs to be configured with the group key--no gateway reconfiguration is required. Each time a client is removed, the gateway and all VPN Clients must be reconfigured with a new group key to prevent attacks. The wildcard aspect of wildcard pre-shared keys means that any IPSec peer with the pre-shared key can access the enterprise network, regardless of the IPSec peer's IP address assignment.

The wildcard pre-shared key feature is vulnerable to IP spoofing, specifically the man-in-the-middle attack. An attacker can potentially redirect all traffic between the IPSec peers to go through an IKE proxy. If an attacker knows the pre-shared key and can redirect all traffic between the IPSec peers to go through an IKE proxy, the attacker can read and modify the IPSec-protected data without detection.

To prevent attacks to one or more parties using wildcard pre-shared key(s), the following instructions should be a part of your enterprise security policy:

• The gateway administrator must initially configure each client with the group key for secure authentication.

• For different groups of remote users requiring varying levels of authorization, the gateway administrator must use a distinctly different key for each peer. The gateway administrator must configure a key for each level of trust, and assign the correct keys to the correct parties.

• Each time another client or remote user is added to a group, the gateway administrator or remote user must configure that client with the pre-existing group key.

• Each time a client or remote user is removed from a group, the gateway administrator must reconfigure the gateway for a new group key. The remote user whose client is removed becomes an untrusted peer. The remaining trusted remote users must reconfigure their clients for a new key. The gateway administrator should distribute the new group key and instructions to remote users through a secure channel.

Without a method of client authentication, you cannot establish an encrypted tunnel between a client and gateway. Digital certification and pre-shared keys are alternatives to wildcard pre-shared keys.

The digital certification feature addresses the enterprise requirement to allow one or more clients to use digital certificates to authenticate encrypted tunnels to a gateway. Digital certification is supported on the Cisco Secure VPN Client in certification authority (CA) and Registration Authority (RA) modes.

Simple Certificate Enrollment Protocol (SCEP) is a certificate enrollment protocol based on common and well understood PKCS #10/7 standards using HTTP transport methods. SCEP provides a standard way to enroll network devices with a CA, as well as to lookup and retrieve CRL information from LDAP or HTTP methods. Version 1.1 of the VPN Client supports the Registration Authority (RA) mode for SCEP enrollment. RA SCEP is currently supported by the Entrust and Microsoft CAs.

Note   See to the latest release notes of your specific version of the VPN Client and networking devices for CA support.

The digital certification feature requires that each IPSec peer has its own digital certificate, which is issued and validated by the certification authority (CA). To authenticate itself to the gateway, the client sends a certificate that performs public key cryptography with the gateway. Each peer's certificate encapsulates that peer's public key, each certificate is authenticated by the CA, and all participating IPSec peers recognize the CA as an authenticating authority. This is called IKE with an RSA signature.

Essentially, the steps to signing on with a CA are as follows:

1. The VPN Client must generate a public/private key pair for the CA to sign. The VPN Client first signs outbound data with its private key. Then, the CA uses the VPN Client's public key to validate that this data was originated by the VPN Client.

2. The VPN Client requests the CA's public key. Only after the VPN Client has the CA's public key can the VPN Client validate data coming from the CA.

3. The VPN Client sends an enrollment request to the CA. The CA ties the VPN Client's personal certificate to its public key, then signs the personal certificate.

4. The VPN Client accepts the signed personal certificate. The VPN Client validates this certificate by decrypting the signed personal certificate with its private key.

Because each VPN Client and each router has its own digital certificate and authentication is handled by the CA, a network is more scalable and provides a more secure authentication with digital certificates than with pre-shared keys or wildcard pre-shared keys. With digital certification, you can configure unlimited numbers of VPN Clients without having to change the gateway configuration.

To prevent attacks to one or more parties using digital certification, the following instructions should be a part of your enterprise security policy:

• An IPSec peer can send its own certificate for multiple IPSec sessions with multiple IPSec peers.

• When an IPSec peer's certificate expires periodically, the gateway administrator must obtain new digital certificates from the CAs, and reconfigure the devices with these new digital certificates.

• The gateway administrator must ensure that all digital certificates obtained are interoperable with all the devices in the network.

Without a method of client authentication, you cannot establish an encrypted tunnel between a client and gateway. Digital certification and pre-shared keys are the alternative to wildcard pre-shared keys.