Workshops

Plugging Holes With Remote Authentication

by Dan Backman and Christopher Smith

The first of its generation, TACACS was developed by the Internet service provider BBN Planet Corp. and adopted by Cisco Systems. So far, it's the only remote authentication protocol standardized by the Internet Engineering Task Force (IETF) in RFCs 927 and 1492. TACACS was a simple protocol, limited to simple user name and password lookups. It evolved into an extended protocol, dubbed XTACACS, which includes support for limited accounting and adds more intelligence on the server side. The latest generation of the TACACS line is TACACS+. It was developed by Cisco to incorporate increased security features such as secure communication over the network (protecting passwords) and to improve access control and accounting.

RADIUS was spearheaded by Livingston Enterprises and, like TACACS+, is designed to offer improved security as well as versatile access control and accounting features. Unlike TACACS+, which is supported only by Cisco, RADIUS has been submitted to the IETF with the intention of providing a versatile standard for dial-up authentication. Also, Livingston has made the RADIUS code available to other vendors, including Ascend, making it widely supported in the r emote-access market.

Sliding on the Hip Waders We tested RADIUS and XTACACS servers on a Sun Microsystems' SPARCstation 2 and a SPARCstation 10 running SunSoft Solaris 2.5. To represent XTACA CS, we chose xtacacsd 4.0, a server derived from Cisco's own code and available via anonymous FTP at ftp://ftp.navya. com/pub/vikas. On the RADIUS side, we used Ascend's RADIUS server to support the Ascend MAX 1800. We were unable to use Cisco's own XTACACS server because it is not supported and does not compile under Solaris 2.5. Cisco could not provide us with a remote-access server or a copy of its CiscoSecure software, and we could not find support for TACACS+ elsewhere.

Since authentication is a low overhead protocol, we found that it requires little horsepower. In fact, Syracuse University supports more than 20,000 users and more than 200 dial-up accounts on a single Sun SPARCstation IPC using XTACACS to access its NIS account database. Both the xtacacsd and Ascend's RADIUS server were slightly tricky to compile, install and configure, but once they were up and running, they provided seamless authentication services. We queried all authentication requests to the Unix account database (/etc/passwd) to test the three-tier authentication model.

Likewise, access to NIS is provided in the same format and is supported by both XTACACS and RADIUS. Additionally, both use an encryption system to hide user names and passwords in transit.

Finally, a distinctive feature that we found useful in the three-tier architecture is the ability to use shell scripting to provide an additional level of security. Both XTACACS and RADIUS let you create access privileges and security intelligence customized to your security model.

Our testing showed that Shiva's LANRover/E Plus and Ascend's MAX 1800 provided nearly seamless examples of XTACACS and RADIUS support. Since these authentication protocols, if supported, are largely independent of the actual remote-access hardware, it is important to note that Ascend's BRI ISDN dial-u ps imposed no additional authentication headaches.

As an example of XTACACS support, we duplicated Syracuse University's scenario in our lab by setting up a Shiva LANRover/E Plus to authentica te against our XTACACS access server. We were pleasantly surprised by the ease of installation and simplicity in connecting the two components. Once the XTACACS server was configured, the Shiva LANRover/E Plus merely needed to be made aware of the IP address of the

XTACACS server, and away it went. We were so impressed with this setup that we converted our in-house authentication system to an XTACACS-Shiva model. The advantage that we have gained from our upgrade to XTACACS is that we now manage our production accounts from one Unix user database. In version 4.0, Shiva also supports RADIUS as an authentication protocol.

RADIUS support was well-illustrated by Ascend's MAX 1800 remote-access device. We found that although the MAX 1800 supports simple user name and password through standard TACACS queries against our XTACACS server, RADIUS offers a much more powerful access-control and accounting system. Using RADIUS, a more complex set of configuration information is passed with each successful authentic ation. For instance, RADIUS lets you define whether the connection is granted access to a "framed protocol," such as SLIP or PPP, or whether the user is automatically routed to a predefined telnet session. It also can include detailed configuration information such as an IP address and subnet mask.

Since RADIUS is designed to be an open standard, there is more room for device-specific configuration. Much like the Simple Network Management Protocol (SNMP) that defines management information bases (MIBs), or databases of specific variables, RADIUS defines dictionaries that can house a vendor's proprietary configuration information. For example, Ascend's RADIUS server includes its own dictionary that can be used for extended functions such as Multilink PPP for utilizing both "B" channels of an ISDN Basic Rate Interface ( BRI) circuit simultaneously. RADIUS' dictionary support is modular, letting a single RADIUS server serve a variety of devices.

RADIUS servers are available from several sources, including Livingston and Ascend, and third-party vendors, such as CryptoCard, which offers a Windows NT-based RADIUS server using an Open Database Connectivity (ODBC)-compliant database to store account information. Also available is a Kerberos-enabled RADIUS server from Merit, which allows dial-up authentication against a cross-platform enterprisewide authentication systems.

If your security needs are small or if access control isn't at the top of your priority list, simple solutions such as RAS for Windows NT, NetWare Connect or the addition of a remote-access server that authenticates against your existing NOS user database are simple to install. However, if your access-control needs are a bit more complex, a three-tier authentication system such as those that use TACACS or RADIUS will offer you the capability to implement a full-scale authentication system that will keep your network from springing security leaks.

Dan Backman can be reached at dbackman@nwc.com. Christopher Smith is a network consultant wo rking at Syracuse University. He can be reached at chsmith@syr.edu.

Token-Based Security Systems

If you need security that is tighter than the solutions discussed in this workshop, look at token-based security solutions such as AssureNet Pathways' Defender, Enigma Logic's SafeWord and Security Dynamics' SecurID. These token-based authentication systems use a credit card-sized device that generates a one-time password for every login a user attempts, eliminating the need for users to remember dial-up passwords. Remember, however, that such systems introduce support questions and are wo rthless if they cannot be integrated into existing dial-up authentication systems.

Token-based solutions use protocols that either communicate directly with remote-access servers or can be incorporated into a three-tier authentication system using a Remote Authentication Dial-In User Service (RADIUS) or an Extended Terminal Access Control Access System (XTACACS) server as a broker between the two systems. Both xtacacsd 4.0 and Ascend Communications' RADIUS server support SecurID and SafeWord. Ascend's RADIUS also supports Defender. In the remote-access server arena, Microcom's LANexpress 4000, Ascend's MAX 1800 and Shiva Corp.'s LANRover/E Plus support SecureID. Additionally, Shiva's latest OS update supports Enigma Logic.