Authenticating Remote Users
Gilbert Held In the movie "The Longest Day," paratroopers are shown dropping into Nazi occupied France on the eve of the invasion. These American paratroopers were supplied with clickers and instructions that if a paratrooper heard a suspicious sound, which in the dark could be friend or foe, he was to click once. If the other party was a friend, he would respond with a double click, alleviating the potential for separated American troops firing upon one another. In one suspenseful scene, a paratrooper waiting behind a hedgerow clicked his clicker once. Unfortunately, a German soldier on the other side slide his rifle bolt backward and forward to chamber a round, producing a double clicking sound, which resulted in the American soldier going forward from his hiding position to an unanticipated fate. The use of a clicker represents a rather primitive method of authentication. And, as the American soldier found out, a simple authentication process can lead to unexpected results. Although poor authentication may not kill you or your organization, an improper authentication technique can provide a mechanism for hackers to exploit. This in turn can result in unauthorized persons gaining access to your organization's computational facilities. Thus, a well-thought out and appropriately planned authentication technique is a security mechanism that verifies the identity of remote users and should be considered in your organization's security plan. Evolution The earliest type of authentication employed with computers was based upon the association of a password with a user ID. Remote users accessing a computer are commonly prompted to enter their user ID. If a valid user ID is entered, the user is then prompted to enter a password. If the password is valid, the remote user obtains access to the computer. Although the user ID/password method of authentication is still the most common method for identifying remote users, it has several weaknesses that are easily exploited. First, it is quite common for people to use acronyms, birthdates, or names of persons, places, and objects as passwords. Doing so enables hackers to literally run the contents of an electronic dictionary against a user ID in an attempt to break into a computer system. Thus, several third party vendors now offer programs for NetWare, Windows NT, UNIX, and other operating systems that prohibit the use of passwords based upon common names, digit sequences, and dictionary entries. Some of these programs require passwords consisting of alphanumeric characters. This dramatically increases the number of combinations a hacker must try on a brute force attempt to illegally gain access to a system. A second problem associated with user ID/password authentication is the fact that, although told not to, users commonly tape their passwords to their computers. While a person outside the organization may never get beyond the guard desk, it is relatively easy for a disgruntled employee to make a list of such exposed ID/password combinations before leaving the organization. If the company has remote access services, that employee can then easily login and wreak havoc. A third problem associated with this method is the fact that passwords are many times transmitted in the clear. This means that a hacker with access to a sniffer and your wide area network, dial-in line, or LAN can read user ID/password combinations as they flow over any type of network. In fact, if you use Microsoft's Windows NT and configure that operating system to enable FTP, you will be warned that passwords are transmitted in the clear. Based upon the limitations associated with User/Password authentication, a variety of techniques were developed to enhance the process. Such techniques range from a modem dial-back telephone call to verify the telephone number of an authorized user to a variety of biometrics designed to measure unique characteristics such as fingerprints, voice, retina, or even body odor. While biometric authentication in most cases represents technology for the next millennium due to its present cost and relatively large error rate, there are other techniques that enhance the authentication of remote users. These techniques are the focus of this article. PAP versus CHAP One version of the user ID/password combination is more formally referred to as the Password Authentication Protocol (PAP) and is used for Point-to-Point Protocol (PPP) based remote access. Under PAP, a table of passwords resides on a server in encrypted form. The user ID and password are transmitted to the server, which encrypts the password received using the same algorithm used to encrypt the passwords in the database. If the encrypted version of the transmitted password matches the entry in the database, the user is authenticated. PAP results in passwords being transmitted in an unencrypted or clear text, making its composition susceptible to monitoring. Thus, a second basic authentication technique is supported for PPP-based remote access. That technique is the Challenge Handshake Authentication Protocol (CHAP). The main feature of CHAP is the ability to perform authentication without transmitting passwords in the clear. To accomplish this, a server transmits a random key to the dial-in client upon the client's access attempt. Here the random key can be viewed as the challenge. The dial-in client uses the key to encrypt its password, transmitting the encrypted password to the server. Upon receipt of the password, the server will look up the user ID in its database and retrieve the user's password. The server then encrypts the password, using the same key previously transmitted to the client, and compares the result. If the two passwords match, the remote client is authenticated. Figure 1 provides a general comparison of PAP and CHAP. Although CHAP provides security against line monitoring, it also has a few weaknesses. First, of course, it cannot detect an unauthorized person who either guesses or knows a user's password and uses it to access a computer. Second, the password database on the server must be in plain text form to enable the server to validate client requests. Thus, the password database becomes highly vulnerable, and in fact a point of attack by many hackers. Multiple Factor Authentication The limitations of PAP, CHAP, and other user ID/password authentication methods resulted in the development of what I refer to as multiple-factor authentication techniques. Such techniques use two or more elements to verify the authentication of a remote user. A common example of a multiple-factor authentication method is the manner by which we get money from an ATM machine. In addition to using our bank credit or debit card, we must also enter our Personal Identification Number (PIN). Over the past 20 years a variety of multiple-factor authorization techniques have been developed for remote access. Those techniques range in scope from telephone number verification to the use of different types of hardware and software tokens. Dial-Back Dial-back represents one of the oldest methods of multiple-factor authentication techniques developed. Under this technique, a remote user dials the server and enters a top level user ID/password combination. In actuality the remote user may never access the server, because dial-back can be achieved either through the use of programmable security modems or via software on the server. Once the user ID/password is verified, the user's connection is terminated, either by the dial-in modem or by the server. The modem or server then searches its database and retrieves a telephone number associated with the validated user, which is then used to dial-back the remote user. The remote user then enters their server's user ID/password to gain access to the system. Although dial-back provides an excellent mechanism for verifying the location of a user dialing in from a branch office or home, it is difficult, if not impossible, to use this authentication method to support persons on travel status. In addition, dial-back involves a second telephone call which can result in an increase in communications cost. While dial-back still represents a popular multiple factor method of authentication, its use has been gradually superseded by hardware and software token-based authentication methods. Token-based Authentication Token-based authentication comes in many forms. Perhaps the most popular method involves the use of a credit card-sized token generator, which uses an algorithm to generate a new random sequence of digits on a periodic basis, typically every minute. The token generators provided to personnel are identified on an authentication server, which can be a program operating as a process on a server or on a dedicated authentication server. When a remote user attempts to access the corporate server, they are first pointed to the authentication process or authentication server. The remote user is then prompted to enter their PIN number or a similar identifier and the current token displayed on their generator card. The identifier is used by the server to execute a token generation algorithm. The same algorithm is also used on the token generator card previously given to the remote user. If the token generated by the server matches the token transmitted by the remote user, the user is authenticated. Since the token changes every minute, the server is normally programmed to generate both the prior and current token and to compare both to the token transmitted by the remote user. This technique alleviates the situation where a remote user might transmit a token that becomes obsolete upon arrival at the server. One implementation of smart card technology is the Security Dynamics Secure ID product. Several firewall vendors now support the use of Secure ID for authentication of connections. In comparing the use of hardware-based token generation to dial-back, the former represents a much wider solution for authentication as it supports any type of remote access. Software Authentication The use of Web clients and servers has become as ubiquitous as telephone operations. Although we normally do not think twice about giving out our credit card number over the phone, we are usually hesitant to do so online. One effort to improve Web security is represented by the incorporation of Secure Sockets Layer (SSL) and client-side certificates, which are supported by Microsoft's Internet Information Server, Netscape's Enterprise Server, and other Web server programs. The SSL protocol is a complex process that occurs between client and server to determine the parameters used in an encrypted session. During the initial handshake, the server, if configured to require client certificates, will require the client to authenticate itself. The client will transmit a certificate to the server that contains the client's public key, which will then be used for encrypting subsequent transmission. To verify or authenticate the identity of the client, the certificate must be signed by a recognized third-party certificate authority such as VeriSign. However, you can also purchase a certificate-issuing software program from several vendors. A digital certificate can contain such information as a user's public key, name, and electronic mail address. The certificate is generated using a person's private key and can be used to sign electronic documents. The primary function of a digital certificate is to verify that a public key belongs to a particular user. Thus, the use of a digital certificate is intended to prevent a person from using a phony key to impersonate another person. Depending upon the contents of a client certificate, it is possible to use the certificate for more than authentication. For example, specific data can be incorporated within a certificate to define user rights and permissions. Thus, client certificates not only provide a more secure method of user authentication than user ID/password combinations, but can also be used to define other levels of security. Kerberos No discussion of authentication techniques would be complete without mentioning a secret key authentication system developed at MIT approximately 10 years ago. The Kerberos system, named after the three-headed dog from Greek mythology, was intended to consist of three components designed to authenticate requests for network resources - authentication, accounting, and auditing. Although the development goal included accounting and auditing, these were never implemented. Under Kerberos authentication, a designated network site (referred to as a Kerberos server) provides a centralized facility that authenticates users to servers and servers to users. When a user logs onto a workstation and requests access to a server, a Kerberos client operating on a workstation transmits a request to a Kerberos subsystem referred to as the Kerberos Authentication Server (KAS). This request is called a ticket-granting ticket, since the KAS response will be used to request a service-granting ticket. This request for a ticket-granting ticket occurs once per logon session. The client request includes the user ID and the ticket-granting server ID, where the ticket-granting server represents a second subsystem of the Kerberos server. Upon receipt of the request for a ticket-granting ticket, the authentication server verifies the user's rights by checking the received user ID against its database. Next, the authentication server creates a ticket-granting ticket and session key, which are encrypted based upon the user's stored password. The ticket-granting ticket and session key are returned to the client, which then prompts the user for a password. That password is used to decrypt the received ticket generating ticket and session key, which are used to request a service-granting ticket from a subsystem of the Kerberos server. This new request is encrypted at the client and decrypted at the ticket-granting server. The ticket-granting server verifies the request and creates a ticket for the requested server, which is transmitted back to the client. That ticket is also encrypted, preventing it from being altered by the client or someone who might copy it off the network. Once the client receives the ticket, an authentication request can be sent to the desired server. That request consists of the client's ID and the just-received ticket. The server decrypts the ticket and verifies that the user ID in the ticket matches the unencrypted user ID in the authentication request. If they match, the server considers the user to be authenticated and grants access to the requested service. There are two popular versions of Kerberos. Kerberos Version 4 uses the 56-bit key Data Encryption Standard (DES) and includes an 8-bit ticket life, which is expressed in units of five minutes, resulting in a maximum ticket life of 1280 minutes. Under Kerberos Version 5, which is specified in RFC 1510, ciphertext is tagged with an encryption type identifier that permits any encryption technique to be used. This permits Kerberos to be used in areas where export restrictions preclude the use of DES and allows organizations that have concerns about its strength to use other encryption techniques. Concerning ticket life, although 1280 minutes provides the better part of a day, it may not be sufficient for certain types of network-based applications, such as the televaulting of the contents of a server's database via a client, which could take a good portion of a weekend. Recognizing this, Kerberos Version 5 uses explicit ticket start and end times. Although Kerberos has gained a degree of popularity, it is not problem free and has a few limitations that can be significant for some organizations. The first limitation is the fact that the initial request for a ticket-granting ticket is not encrypted and thus can be exploited. A second limitation is the fact that it is a client-server authentication method and does not support server-server authentication. In selecting an appropriate authentication technique, it is important to consider a variety of factors. Those factors should at a minimum include your organization's need for authentication, the use of other equipment to include router access lists and firewalls to bar unauthorized users, the locations from which remote users will establish connections to your servers, and your organization's budget. By considering these factors, you can select an appropriate authentication method to satisfy your organization's networking requirements and budgeting constraints. About the Author
Gilbert Held is an award-winning author and lecturer and is the author of more than 25 books and 250 technical articles. Some of his recent publications include Virtual LANs, Working with Network-Based Images, High Speed LAN Switching, LAN Performance 2ed., Ethernet Networks 2ed., The Complete Modem Reference 3ed., and Data and Image Compression 4ed., all published by John Wiley & Sons. Gil can be reached at 235-8068@mcimail.com.
|