Authentication angst

Our Clear Choice Test expert discusses anxiety-raising issues around authentication.

Any SSL VPN deployment supporting more than a few dozen users will likely have links to external authentication servers, such as RADIUS or Lightweight Directory Access Protocol . Our test in this area measured how well each SSL VPN device worked with our five authentication servers and evaluated how well the vendors had integrated other functions - such as group retrieval for authorization purposes and method-specific security features, such as certificate revocation lists or password changing.

We started by looking at RADIUS servers. Every vendor but SonicWall passed this basic test. We ran into problems with SonicWall's SSL-VPN 2000, because you cannot control what port numbers it uses to query RADIUS servers. Because of confusion on the part of the RADIUS developers in the 1990s, half of the RADIUS servers run on one set of ports, and the other half run on the standardized ports. The choice of ports has been so unsettled for so long that many of the high-end servers will listen on both ports to maximize compatibility. SonicWall's SSL-VPN 2000 was the only product that wouldn't let us specify what port to query our RADIUS server on and, because of that, couldn't talk to our server.

The next step with RADIUS was to be sure that the devices could pull down group information from the RADIUS servers. Security and access-control policies in SSL VPNs are generally expressed in terms of groups, rather than individual users. With RADIUS, there is no standardized way to pull group information out of a RADIUS server, but there are some common industry practices. AEP, Fortinet and SonicWall all failed this test, because they don't allow you to pull group information out of RADIUS servers. We also ran into problems with Array's RADIUS implementation where the Array SPX-5000 would refuse to believe our RADIUS server when it said "no," and kept sending the same user authentication request repeatedly.

Our third RADIUS test was to point the SSL VPN devices over to our RSA Authentication Manager (formerly known as the ACE Server), a RADIUS server that handled RSA's SecurID tokens. You can talk to RSA's server using either its proprietary protocol or RADIUS, but most network managers elect to use RADIUS. However, there are a variety of special messages that the SecurID server will send back specific to the SecurID token. For example, the SecurID manager can force users to change their PIN, and so the SSL VPN devices had to handle these messages properly.

AEP and Array talked to the SecurID server directly, which means that their products were unable to pull group information from the server. Fortinet and SonicWall failed entirely, because neither product can handle SecurID properly, meaning that users will not be able to reliably log on with SecurID tokens.

Next, we moved onto authenticating users via LDAP servers. We had a very simple LDAP schema and didn't try and throw any product for a loop. However, we did run into a variety of both small and large problems. Two vendors that failed our test outright are Fortinet and SonicWall. With SonicWall, a user can be a member of just one group, something that is unrealistic in most SSL VPN deployments. Fortinet does not retrieve any group information out of LDAP, and we thought that it wouldn't work at all - until technical support suggested putting an IP address instead of a domain name in the GUI.

Most of the other problems we had with setting up LDAP were GUI-related. With Array, we ran into the first of several GUI bugs and had to drop into the command-line interface to get LDAP to operate properly - which it did, to the company's credit. We saw a similar problem with Caymas: A GUI bug meant that we had to switch platforms just to get the LDAP defined. Check Point's Connectra threw us for a loop by having the most undocumented and poorly designed LDAP configuration system. Rather than letting us tell it where to look, the product simply gave us choices of brands of LDAP servers. With a protocol analyzer, we were able to figure out what it wanted and changed our schema to accommodate its needs. Check Point engineers said there are files that can be manually edited to give better control, but they're not mentioned in the documentation.

We also discovered an elegant feature in the Juniper and Nokia implementations: the ability to use other LDAP information as part of the access-control decision (Nokia also lets you do this with information out of the RADIUS server). For example, you could use a field in your LDAP directory to restrict access if the number of bad password attempts was larger than 10.

Although we gave out straight pass/fail scores to all products (see chart), there were considerable differences in how each product handled LDAP. If you are planning a large deployment, it's critical to test the products against your actual LDAP directory and schema to check for interoperability.

Windows Active Directory poses a special problem for SSL VPN managers. Although Active Directory is accessible via LDAP, the variation in schema from one site to another makes this a nightmare for the SSL VPN manager who is not also an Active Directory guru. Even Active Directory gurus may not have a good knowledge of the underlying LDAP directory that their directory is based upon. For example, our Exchange Active Directory server users were included in a part of the LDAP tree that was completely different from the users on our Citrix Active Directory server. The solution to this, according to Microsoft, is to authenticate using Kerberos. AEP, F5, Juniper, Nokia and SonicWall all can talk directly to Active Directory. That's the preferred way to do it and will ease implementation. If an SSL VPN doesn't talk directly to Active Directory, but uses LDAP instead, it isn't a major issue but it is the kind of thing that can cost the network administrator hours or days of aggravation.

Our final test was to use digital certificates for authentication. Although PKI -based digital certificates are not a very popular authentication method, they can offer higher security than other common methods. In addition, because Microsoft Active Directory has the option of a (free) built-in PKI, all-Windows environments can issue digital certificates more easily than every before.

The big winners in this area were F5, Juniper, Nokia and Nortel, all of which started working right out of the box.

F5, Juniper and Nokia all also allow you to combine certificates with other authentication methods. AEP and SonicWall only allow you to use certificates as an additional mechanism, such as by combining a digital certificate with a username and password. Only Caymas didn't even try to get digital certificates working as an authentication mechanism.

We were unable to get Array and Fortinet to work with our certificates and certificate revocation list. A combination of balky software and inadequate documentation torpedoed our efforts.

Aventail also failed this test, unfortunately, because its product doesn't support certificate revocation list checking, a critical requirement for PKI deployment, although we had no problem authenticating with certificates. Check Point also took a while to get working, until someone deep in its engineering team told us that the product only supports one of the two common formats for revocation lists.

Digital certificates, although integral to SSL VPNs, caused problems in other places. AEP, Array, Caymas, Check Point, F5 and SonicWall were unable to generate proper certificate signing requests for their own digital certificates.

< Previous Test: Security policy/access control | Next test: Manageability >