Three-part encryption technique Security

91 The international version of AltaVista Tunnel uses a 56-bit RC4 key, as U.S. export laws prohibit the export of higher forms of encryption technology. By necessity, 56-bit keys are less secure and can be cracked by a determined snooper. The tunnel recognizes and compensates for the differences between domestic and international keys, which allows users to log in to the virtual private network from one country to another. The AV Tunnel 98 also supports 40-bit encryption keys if required.

6.1.2.2 Support for an emerging security standard

RSA has recently begun development of the Secure Wide Area Network SWAN standard, which is based on IPSec. Though AltaVistas security methods were developed by AltaVista, they are committed to supporting the emerging standard once it has been finalized. They will likewise continue to support their proprietary security methods as well. No announcements for IPSec support were apparent for AV Tunnel 98.

6.1.2.3 Support for Security Dynamics SecureID

You can get even more secure authentication by using the AltaVista Tunnel 98s support for Security Dynamics SecureID authentication tokens. By generating random access codes every 60 seconds, SecureID tokens provide a further line of defense against persons trying to gain unauthorized access to the secure private LAN. The Extranet server actually acts as a client for the ACESERVER, the guts of the SecureID system.

6.1.3 Flexibility

The AltaVista Tunnel 98 works with many types of conventional firewalls. The LANs firewall is configured as a generic relay, which automatically forwards all traffic addressed to the tunnel port on the firewall to a unique port on the tunnel server. The unique tunnel port and the generic relay configuration not only hide the physical IP address of the tunnel server, but also log all attempts to connect to the tunnel network at both the firewall and the tunnel server. Other firewall configuration options for IP tunnels may be found in Chapter 9 .

6.2 AltaVista Tunnel Limitations

While it includes a full-featured tunnel setup, the AltaVista Tunnel still has a few limitations that may render it inappropriate for some enterprises needing a virtual private network.

6.2.1 Platform Limitations

Given its limited support of platforms, AltaVista Tunnel is definitely not the answer for the enterprise with a mix of operating systems. AltaVista has released a Telecommuter client package for the MacOS, though there is no mention of this release on their tunnel web site. However, a demo copy of the Mac Telecommuter Client software is available for download at the AltaVista Tunnel 98 site listed at the beginning of this chapter. No versions have been announced for flavors of Unix other than Digital Unix, and AltaVista has gone so far as to drop support for both BSDOS and FreeBSD in this revision of their software. 92

6.2.2 Security Drawbacks of User Authentication

Though the security features are one of the most powerful aspects of the AltaVista Tunnel, user-based authentication still poses some security concerns. In order to provide the flexibility to log in from anywhere, the product removes one of the most common types of authentication normally used by VPNs: checking the incoming IP address. Network administrators, already burdened with users losing or compromising passwords to the system, must stress extra care in protecting generated keys, tunnel user group names, and passwords; these are the only factors by which AltaVista Tunnel verifies its connections. As stated, the AltaVista Tunnel Extranet server should be closely managed as a highly trusted system, because compromising a tunnel key negates the purpose of the virtual private network in the first place.

6.3 How the AltaVista Tunnel Works

Each AltaVista Tunnel network consists of two sides, the inbound and outbound, both connected to the Internet in some fashion. The inbound side is the private network, which consists of some number of hosts and an AltaVista Extranet server. The outbound side can be either a single computer or another LAN. In the first case, the user would run the AltaVista Telecommuter client, and in the second, the remote LAN would have an Extranet server of its own to manage inbound or outbound tunnel traffic by hosts on its network. The Extranet server on the inbound side always manages authentication, dynamic IP assignment, and the routing of tunnel traffic for incoming connections. A simple VPN might consist of three individual users connected to the Internet via three separate ISPs. Each user is running a Telecommuter client, and has access to the tunnel group through the remote LANs Extranet server. Users have unique physical IP addresses on their respective ISPs networks. The tunnel server and hosts on the remote LAN are likewise assigned physical IP addresses. On the tunnel server, a range of virtual IP addresses is available for assignment to incoming tunnel connections. Each tunnel receives two virtual IP addresses: one for the client end and one for the server end. Tunnel traffic destined for the virtual private network is first routed, via the tunnel client software, from the clients physical IP address to its virtual IP address. This virtual IP address points to the tunnel servers virtual IP address for that connection, which, in turn, is routed to an internal host on the local networks physical IP range. In this way, the remote clients act as if they were nodes on the local network. When a remote user initiates a tunnel session with the tunnel server, an encrypted connection request is sent, which, once relayed through the firewall, is authenticated against the tunnel servers list of authorized clients. Once the request is granted, the tunnel server issues a response encrypted with the clients public key. The client decrypts this message using its own private key, and then the two exchange parts of a session key. These parts are combined to form a secret session key, which is regenerated every 30 to 1,440 minutes of the connection. The AltaVista Tunnel 98 software on both ends is installed as a separate network protocol, and is routed to a piece of software called a pseudo-adapter. The virtual IP address assigned for the tunnel connection is attached to this pseudo-adapter through which all tunnel traffic is