 | Chapter 10 Authentication and Inbound Services |  |
| Chapter 10 Authentication and Inbound Services | |
There are two common freely available systems that allow you to avoid sending reusable passwords over the Internet. These are Kerberos and the authentication server portion of the TIS FWTK. The number of commercial authentication solutions is growing as well.
Kerberos was developed at MIT by Project Athena (the same folks who developed the X Window System). It is designed to provide authentication and encryption services through modified versions of standard clients and servers, e.g., Telnet clients and servers.
Kerberos provides strong authentication in a distributed environment, and it is widely available. Some vendors provide Kerberos support with their operating systems; MIT has freely available implementations for many versions of UNIX; and the code is freely available if you wish it to port it to an operating system that does not yet have an implementation.
Kerberos isn't an ideal solution, though. There are three major problems with it:
Kerberos requires custom client and server software. As with proxy systems, this limits your choice of client and server software. If the software you want to use doesn't support Kerberos, and if you can't modify it to support Kerberos (because the source code isn't available, or because you simply don't have the time or expertise required), you're out of luck, and you won't be able to use it. Unlike proxy systems, Kerberos does not let you use custom user procedures to make Kerberos work with arbitrary client/server software.
Kerberos tends to be difficult to set up and manage. Unless your operating-system vendor supports Kerberos (or you can find a third-party vendor who supports it for your platform), you'll have to obtain the Kerberos software and integrate it into your environment yourself. This is a nontrivial task, typically much more difficult than the integration work required for most other solutions outlined in this book. Once Kerberos is set up, management of it provides another ongoing challenge. Kerberos requires a dedicated, carefully secured server, which is accessible to all clients.
Kerberos doesn't scale up well beyond a single administrative domain (a single set of machines managed in common, which share user names and passwords). Each Kerberos realm (the Kerberos term for a single administrative domain) is independent. To do inter-realm authentication, the Kerberos servers in the two realms essentially have to trust each other, and have to share a key known only to each other. A separate key is required for each pair of realms that are going to do inter-realm authentication; as the number of realms involved increases, the number of keys required increases geometrically, to the point where it quickly becomes unmanageable.
Kerberos shows great promise for the future, particularly if more sites adopt the Distributed Computing Environment (DCE), which uses Kerberos as the basis of its security. It could very well become the de facto standard mechanism for authentication on the Internet sometime in the next decade or so. In order for that to happen, though, it will need wider support from developers and vendors, and easier setup and maintenance. Meanwhile, it will probably only be used within individual sites.
Right now, most sites don't have Kerberos clients available, so even if you install Kerberos versions of your servers, your users will not be able to log in from arbitrary other sites, because it requires modified software on both ends.
The authentication server in the TIS FWTK is another commonly used solution for authenticating users coming in from the Internet. The server implements a variety of authentication mechanisms, such as standard reusable passwords (not recommended), S/Key, Security Dynamics SecurID cards, and Digital Pathways SNK-004 cards. In addition, the server is modular and extensible, and is designed so that new authentication mechanisms can easily be integrated.
Traditionally, programs wishing to authenticate a user (such as the login program, or the ftpd daemon) have had to know how to authenticate a user; they have had to understand and implement whatever authentication method or methods were to be used. In a UNIX system, this means that these programs have to do all of the following to authenticate a user:
Prompt the user for a login name.
Look up that login name and obtain its encrypted password.
Prompt the user for a password.
Use the user-provided password and the first two characters from the encrypted password to encrypt a known string (eight bytes of nulls).
Check to see if the result of this encryption matches the encrypted password for the user.
If you want to add a second authentication mechanism (for example, the S/Key mechanism, which we discussed earlier), you have to modify all of these programs to understand this second mechanism as well as, or instead of, the standard UNIX password mechanism. And if you later want to add a third authentication mechanism (for example, support for the SecurID cards), you have to modify the programs yet again; and so it would go for each additional authentication mechanism. Each time you modify these programs, you're making them bigger and more complex, and increasing the chances that you've introduced some kind of bug that's going to result in a security problem. (This is a serious risk because these are very security-critical programs - they control access to your system.)
The TIS FWTK authentication server takes a different approach. With it, you modify all the authenticating programs (e.g., login, ftpd) once, to make them talk to the authentication server instead of doing the authentication themselves. All of the details of the authentication mechanism - e.g., what to prompt the user with, how to validate the user's response, etc. - are then handled by the authentication server. When you want to add or modify authentication methods, you do so by changing the authentication server (which is modular and designed to accommodate such changes), not by changing the individual authenticating programs.
A single authentication server can handle any number of client machines and programs, and any number of different authentication methods; different users within the same server can use different authentication methods. For example, some might use S/Key while some might use the Digital Pathways SNK-004 cards.
When a client program (such as login, or ftpd) wishes to authenticate someone using the TIS FWTK authentication server, it has to go through the following steps:
Prompt the user for a login name.
Contact the authentication server and tell it who is trying to log in.
Receive a response from the authentication server that tells it what to prompt the user with.
Display the prompt specified by the authentication server.
Collect the user's response and send it to the authentication server.
Receive either an OK or an error message from the authentication server.
Allow the user access (if OK) or display the error message.
This whole process is carried out with a single TCP connection between the client and the authentication server, so that the server knows it's talking to the same client and the client knows it's talking to the same server throughout the authentication process.
The authentication server consults its databases to determine how to authenticate that user and determines the appropriate prompt for the authentication mechanism for that user. For example:
If traditional passwords are being used as the authentication method, the prompt will be a simple "Password:" prompt.
If the authentication method is S/Key, the prompt will be the number of the key the user is to respond with.
If the authentication method is the Digital Pathways SKN-004 card, the prompt will be a randomly generated challenge number.
Figure 10.3 shows how the TIS FWTK authentication server works.
The TIS FWTK includes a number of programs (such as ftpd) that, in addition to other modifications and enhancements for security, have already been modified to use the authentication server. Converting an existing program to use the authentication server, rather than traditional UNIX passwords, is pretty straightforward. It typically involves only 20 or so lines of C code, examples of which are given in the toolkit.
The toolkit also includes some programs to support binary-only systems where you don't have the source to modify. For example, for systems in which you don't have the source code to the login program available for modification, the toolkit includes a program you can use as the user's shell (which is specified for each user in the /etc/passwd file) instead of one of the normal shells (e.g., /bin/csh or /bin/sh) This replacement shell authenticates the user with the authentication server, and, if the user passes, starts his real shell.
The major problem in running an authentication server is getting secure communication between the client and the server. An attacker who can convincingly pretend to be the authentication server can authenticate as anybody.
Some configurations may have additional problems; for example, using shell replacement can produce problems, because not all programs deal well with situations in which a user's shell environment variable and the entry for that user in the /etc/passwd file do not match.
Many commercial systems offering to do authentication are now on the market. In particular, "single sign-on" systems are a hot topic right now. These are systems that supposedly let a user log in once (presumably once each day), and then automatically log the user in to whatever other systems that user needs to access, without the user having to log in to each system individually.
There are a variety of issues you need to think about when you are considering a commercial solution; the primary considerations are availability, security, and cost.
This is a simple consideration. Is the system available for all the platforms and programs you need to use it for? Many systems address only certain types of machines (e.g., PCs or UNIX systems), and many handle only certain types of access (e.g., login but not FTP access).
This consideration is tougher to get a handle on. There are several things you need to think about. First, how hard is the system going to be to compromise? Second, if it is compromised, what implications does that have for the rest of your security?
Many of these commercial systems use proprietary algorithms that are not available for client or academic scrutiny. Unfortunately, there are a lot more ways to do these algorithms wrong than to do them right. Without an independent analysis of the system, you have to rely on the vendor's word that they got it right.
Other systems build their single sign-on capability on top of the standard UNIX .rhosts mechanisms used by the so-called Berkeley "r" commands (rsh, rlogin rcp, rdist, etc.). These commands are notoriously easy for an attacker to exploit because they create a web of trust among machines. (The weaknesses and vulnerabilities of these commands are discussed in Chapter 8.)
This consideration is almost always an issue. What will it cost to deploy this system in your environment to meet your needs? Some costs are one-time capital expenses; e.g., some systems require a dedicated piece of hardware, essentially a single-purpose PC, to generate the challenges and check the responses. Others are per-user expenses; for example, some systems require smart cards for all your users. Still others are licensing or support expenses. The systems are often priced depending on the number of users you'll support; systems to support more users obviously cost more.
The only commercial authentication system that is used extensively on the Internet is the SecurID system from Security Dynamics discussed earlier. A variety of commercial products, particularly terminal servers, support the system.[3]
[3] Apparently because of aggressive marketing and partnering by Security Dynamics, and not because of any inherent advantage of the product.
|  | |
| 10.3 Authentication Mechanisms |  | 10.5 Network-Level Encryption |