Passwords

All multiuser computer systems have some form of login identification (or username) and some sort of password. This has been the basis for authentication on computers since multiuser computer systems came into existence. All authentication mechanisms in FireWall-1 rely on some sort of username and password, the credentials by which a user proves to the firewall who he or she is. Before proceeding, let's briefly discuss passwords.

To date, the vast majority of authentication is done with a static password. Most users, when left to their own devices, choose very simple passwords that are easy to guess. Even if a complicated password is chosen, the password, as it is being typed, can easily be picked off the wire with a packet sniffer. For these reasons, static passwords are not recommended. The risks these pass words create are somewhat mitigated by encrypting the passwords as part of the data stream (e.g., as part of SSH or HTTPS). However, most applications do not use encryption. Also, there is no point to encryption if the password is easy to guess.

One-time password (OTP) schemes were developed to solve these problems. They require a different password each time the user authenticates. Even though the network may be subject to packet tracing and may be able to see the entire challenge/response session, no information is divulged, so a hacker cannot pretend to be a particular user. OTP schemes use a secret key along with a cryptographic hash function. As long as the secret key is not divulged, the scheme is not compromised.

Passwords, regardless of whether or not they are OTPs or static passwords, can be managed a number of different ways, some inside FireWall-1 and others on external authentication servers.

FireWall-1 Password

FireWall-1 Password is a simple, static password that is maintained internally by FireWall-1. The password can be up to eight characters in length. No additional software is needed to use FireWall-1 Password. FireWall-1 Passwords are static, so use outside of a test environment is not recommended.

OS Password

FireWall-1 can use the login and password information stored in the operating system of the firewall for authentication. You are limited to what the specific operating system allows in terms of usernames and passwords (the latter are usually static passwords of limited length). No additional software is needed to use OS Password.

NOTE!

OS Password is not supported on IPSO.

S/Key

S/Key is an OTP system that uses an MD4 or MD5 cryptographic hash function. It uses three values: a password number, a seed value (usually the same as the username), and a secret key. The password number and the seed value are transmitted in the clear as the challenge. The challenge, along with the secret key, is typed into an S/Key generator that resides on the user's local system. The S/Key generator then outputs a response to the challenge, which users type in to authenticate themselves. S/Key generators are widely available on the Internet free of charge.

Given the challenge and the response, it is impossible to determine what future responses need to be without knowing the secret key used to generate the S/Key chain. However, if you choose an easy-to-guess secret key, your login can easily be compromised. It is important to choose a secret key that is difficult to guess. As of version 4.1, FireWall-1 requires a secret key of at least ten characters to try to enforce a difficult-to-guess secret key.

When you log on and use S/Key, you are given a challenge such as:

SKEY CHALLENGE: 98 username

The number is the password number, which decrements after each successful login. The seed (in this case username) always stays the same. You type this information into an S/Key generator along with your secret key. This generates an OTP, which you then use as the response.

On a UNIX platform, the interaction with an S/Key generator looks something like this:

$ key 98 username
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: test123
CUFF IRIS ELK JEFF ROSY GAG

On a Windows platform, the interaction with an S/Key generator might look similar to Figure 8.1.

S/Key can be used natively in FireWall-1 without having to purchase additional software. S/Key generators, and where to obtain them, for Windows and UNIX platforms are listed in Appendix G.

As of FireWall-1 NG with Application Intelligence (FP4), S/Key is no longer a supported authentication scheme. One major reason for this is that S/Key does not work where the firewalls are in a High Availability configuration. S/Key is also not widely used in corporate environments.

SecurID

SecurID uses a hardware token with a value that changes every minute or so. The card is synchronized with an ACE/Server, which validates the authentication attempt. So long as you do not lose this card, your authentication will be secure.

When you are prompted for authentication, you will be given a passcode prompt. Depending on the type of SecurID card you have, you will either type in a PIN (four to eight alphanumeric digits in length) followed by the six-digit number currently displayed on your SecurID card, or you will enter the PIN on your SecurID card, press the diamond key, and type in the number displayed on the SecurID card. Because the SecurID card and ACE/Server are in sync, the ACE/Server knows what the SecurID card should read at any given moment.

Using SecurID involves purchasing both the ACE/Server (which runs on UNIX or Windows NT workstations) and SecurID keys. The hardware keys expire after a period of time. Figure 8.2 shows a sample SecurID token.

Defender

Defender (formerly Axent Pathways Defender) is also a hardware token?based solution. You use a numeric keypad on the hardware key to punch in a challenge and a user-definable PIN, which gives you a response. The hardware key is programmed with an ID that is also specified on the Defender Authentication Server. This key is tied to a specific login ID and cannot be used with anyone else's login ID.

When you log in, you are prompted with a challenge (a number). You enter this number along with your PIN into the hardware key. This generates your response, which you then type into the computer.

As of FireWall-1 NG FP3, Defender is no longer a supported authentication scheme. Based on my personal experience, this is not a widely used authentication scheme. For as long as I've been supporting FireWall-1 (since 1996), only one customer has asked me about this authentication scheme. In any case, Defender has a RADIUS-compatible mode, which can be used with FireWall-1.

Remote Access Dial-In User Service (RADIUS)

Originally developed by Livingston (now a part of Lucent), RADIUS is an authentication server usually used by those providing dial-up access for authentication. RADIUS can theoretically support any sort of password scheme, whether static or OTP. A wide variety of other authentication servers (SecurID, Defender, and others) also implement a RADIUS-compatible mode to make it easy for other applications to tie in, thus making RADIUS support rather ubiquitous. Some RADIUS servers can also be used to provide authentication via an OS-level password (e.g., a Windows NT/2000 domain password). It is often far easier and more secure to use RADIUS to authenticate against a Windows NT domain than to use actual Microsoft protocols to do it.

Terminal Access Controller Access Control System (TACACS/TACACS+)

TACACS provides access control for routers, network access servers, and other networked computing devices via one or more centralized servers. BBN Technologies originally developed TACACS for use on MILNET. Cisco has built upon and enhanced TACACS. The original TACACS is no longer supported by Cisco. A newer version, called TACACS+, provides several enhancements to the original protocol, including the use of TCP (instead of UDP) and separation of functions (authentication, authorization, and accounting).

Lightweight Directory Access Protocol (LDAP)

LDAP Directories are becoming popular in midsize to large enterprises as a way to centrally store and manage information about people, places, and things. FireWall-1 allows you to use information stored in an LDAP server as well as store data specific to FireWall-1 there. This allows you to use existing LDAP tools and SmartDashboard/Policy Editor to manage users. All authentication schemes previously mentioned can be used with users defined in an LDAP server in addition to the password that is stored in each LDAP record (typically a fixed password). You also have further flexibility insofar as groups can be defined in terms of existing hierarchies that may already exist in your LDAP Directory. Users can also be defined in terms of templates. All an administrator has to do is change the template to change the attributes of all the users who use that template. LDAP requires the purchase of additional licenses in FireWall-1 in order to make use of it; you must also have an LDAP server.