10.2 USER AUTHENTICATION AND AUTHORIZATION

Team-Fly

As mentioned in Section 10.1, one of the key functionalities of an application-level gateway or proxy server is user authentication and authorization. In Section 6.1, we overviewed and briefly discussed several user authentication schemes that can be used by an application-level gateway or proxy server. For example, HTTP version 1.1 specifies a Basic authentication mechanism in which the client sends the user-name and password in the clear (i.e., in Base-64 encoded form) to the HTTP proxy server [1]. Contrary to that, a more sophisticated and more secure Digest authentication mechanism is specified in [2]. Following this specification, a one-way hash is computed from the username, the password, a challenge provided by the proxy server, and some additional information. The resulting authentication mechanism is more secure because user passwords are never transmitted in the clear.

In general, there are several user authentication and authorization schemes that an application-level gateway or proxy server could implement and use:

The simplest scheme is notably to have a proxy server hold a pair of lists of client IP addresses that are allowed to connect inbound (first list) or outbound (second list). Obviously, this scheme is not very secure, since IP spoofing is possible and can be used to spoof authorized IP addresses to get intranet or Internet access.
Another scheme is to have a client (or user) and a proxy server share a secret, such as a password. When the client connects to the proxy server, the server requests the secret, and the client has to provide it. If the secret is transmitted in the clear, the resulting authentication scheme is weak (i.e., a passive attacker gets authentication information he or she can reuse to spoof a legitimate user). The HTTP Basic authentication mechanism is an example of a weak authentication scheme. In such a scheme, authorization is done implicitly, meaning that someone equipped with a shared secret is also authorized to gain intranet or Internet access.
A more secure scheme is to use strong authentication mechanisms to have users authenticate to a proxy server, and to handle authorization accordingly. In this case, it is no longer possible for a user to simply spoof the IP address of another user's authorized client machine to get Internet access. Examples of strong authentication mechanisms include HTTP Digest authentication as mentioned earlier, as well as one-time password and challenge-response mechanisms.

In practice, the firewall policy must define the authentication and authorization schemes that must be used in either direction and for each service. Many policies use the simplest scheme mentioned above for outbound connections and a strong authentication scheme for inbound connections.

In either case, the application-level gateway or proxy server must have access to some reference information it can use to verify whether the authentication information provided by a client (or user) is valid and legitimate (e.g., a one-way hash value of a user password or the public key certificate of a user). The reference information can be stored either locally or remotely. For obvious reasons, the second approach is preferable since it makes it possible to aggregate security information and functions for several firewall systems and network access servers (NAS) at a single point. Typically, a standardized protocol is used to retrieve the reference information from a centralized security server. There are currently two competing protocol proposals:

Livingston Enterprises, Inc., has developed and implemented a protocol called Remote Authentication Dial-In User Service (RADIUS) [3].^[1] In short, the RADIUS protocol can be used to carry authentication, authorization, and configuration information between an NAS that desires to authenticate its users and a shared authentication or security server. Livingston Enterprises, Inc., also has made publicly and freely available corresponding RADIUS security server software. A companion protocol that can be used to carry accounting information between an NAS and a shared authentication or security server server is specified in [4].
The terminal access controller access control system (TACACS) was originally developed by BBN under ARPA funding in the early 1980s. It was used to authenticate users to terminal access computers on the ARPANET. Later, Cisco Systems developed, implemented, and deployed a family of protocols that are based on TACACS [5]. While the TACACS and extended TACACS (XTACACS) protocols are no longer in use, TACACS+ is a protocol in current use. Refer to the Cisco manuals for the corresponding TACACS, XTACACS, and TACACS+ commands.

Both protocols (RADIUS and the protocol family for the TACACS derivates) are widely supported by commercial firewall systems and network access servers. They are not further addressed in this book.

There also are some alternative proposals to handle user authentication reference information. For example, some time ago, Ravi Ganesan implemented an application gateway that uses the Kerberos^[2] system to authenticate connection requests [6]. Once the application gateway has satisfied itself about the identity of the requesting user, it establishes a corresponding connection to the destination server.

After having successfully authenticated and authorized the client (or user), the proxy server sets up a secondary TCP connection to the requested application server. From the user's point of view, a secondary authentication may now be required and actually take place, since the application server may want to authenticate and authorize the client (or user) as well. This secondary authentication step is beyond the scope of the firewall. If the user is successfully authenticated and authorized, the application server usually starts serving the request.

^[1]As of this writing, the RADIUS protocol has reached the status of a Draft Standard.

^[2]We address the Kerberos system in Section 16.2, when we talk about authentication and key distribution systems.

Team-Fly