Authentication Methods
The main authentication methods considered are username and password, S/Key, token card and server, Password Authentication Protocol (PAP), and Challenge Handshake Authentication Protocol (CHAP) authentication. Each is covered in the following sections.
Username and Password Authentication
The most common user authentication method is the use of usernames and passwords. Username/password combination methods range from weak to strong in authentication power. Simple authentication methods use a database of usernames and passwords, whereas more complex methods use one-time passwords. Consider each of the methods shown in Figure 4-2, from the weakest at the bottom of the figure to the strongest at the top. Stronger authentication methods are better able to resist attempts to gain unauthorized access. Weaker methods are often easier to use and administer, and stronger methods are often harder to use and administer. Simple authentication methods use a database of usernames and passwords, and more complex methods use one-time passwords.
){kind=link}
Figure 4-2 Authentication Methods and Ease of Use
The authentication methods outlined in Figure 4-2 are as follows:
No username or password—Some system administrators and users opt to not use the username/password capabilities of their network access systems. This is obviously the least-secure option. A network intruder only has to discover the access method to gain access to the networked system.
Username/password (static)—Stays the same until changed by the system administrator or user. Susceptible to playback attacks and password-cracking programs.
Username/password (aging)—Expires after a set time (usually 30 to 60 days) and must be reset, usually by the user, before network access is granted. Susceptible to playback attacks and password cracking but to a lesser degree than static username/password pairs.
S/Key one-time passwords (OTP)—An OTP method generating multiple passwords typically used for terminal logins. In S/Key, a secret passphrase is used to generate the first password, and each successive password is generated from the previous one by encrypting it. A list of accessible passwords is generated by S/Key server software and is distributed to users.
One-time passwords (OTP)—A stronger method, providing the most secure username/password method. Most OTP systems are based on a secret passphrase, which is used to generate a list of passwords. These passphrases are good for only one login and therefore are not useful to anyone who manages to eavesdrop and capture the passphrase. S/Key is an OTP method typically used for terminal logins.
Token cards/soft tokens—Based on something you have (for example, a token card) and something you know (for example, a token card personal identification number [PIN]). Token cards are typically small electronic devices about the size and complexity of a credit card-size calculator. There are many token card vendors, and each has its own token card server. The PIN is entered into the card, which generates a secure password. A token server receives and validates the password. The password interplay usually consists of a remote client computer, a network access server, and a security server running token security software.
You should choose and implement an authentication method based on the guidelines established in your network security policy. The policy should specify the desired balance between strength of security and ease of use.
Figure 4-3 shows an example of dialup access using usernames and password authentication. On the client end, Windows NT Dialup Networking prompts the dialup user for a username and password (as shown in Figure 4-4), which is sent over communication lines using TCP/IP and PPP to a remote network access server or a security server for authentication. Windows 95, Windows 98, and Windows 2000 operating systems have a similar authentication window.
){kind=link}
){kind=link}
Figure 4-3 A Remote Client Sending a Username and Password to a Network Access Server for Authentication
Figure 4-4 The Windows NT Dialup Access Username and Password Authentication Dialog Box
The remote user enters a username and password in the User name and Password fields and clicks the OK button to initiate a dialup connection.
After the user enters the username and password and clicks the OK button, Windows NT Dialup Networking transmits the username and password, over communication lines using TCP/IP and PPP, to a remote network access server or a security server for authentication, as shown in Figure 4-3.
Authentication of usernames and passwords is commonly used with secure Internet applications. For example, some Cisco Connection Online (CCO) applications require a user to be registered and to possess a username and password assigned by CCO. When the user accesses a secure CCO application using a Web browser, the application causes the Web browser to display a window requesting a username and password similar to that shown in Figure 4-4. The username and password may be validated using a AAA security server.
S/Key Authentication
Remote logins are vulnerable to network intruders using eavesdropping techniques to obtain the usernames and passwords. Intruders can use captured information in a replay attack to gain unauthorized access to the target system. The S/Key one-time password system was designed by Bellcore and others as a way to create passwords that can be safely sent over remote connections, thereby countering eavesdropping and replay attacks. With S/Key, only the one-time password crosses the network. The one-time password is a hash of the user's secret password, so the secret password never crosses the network, and the hashed one-time password is never used again.
Where S/Key Got Its Name
After searching available RFCs and publications to find the meaning of the name S/Key with no success, I decided to ask Neil Haller, one of the original developers of S/Key and coauthor of several S/Key RFCs. Here is his reply: "I made up the name. It was originally called something else, but we discovered that name was trademarked. Then came a lengthy search for a name that we could trademark. S/Key came from desperation, trying many alternatives. I suppose the words 'secure' and 'key' were in my mind."
A strong advantage of S/Key is that it protects against eavesdroppers without modification of remote client software, and it imposes little inconvenience on the users. Because S/Key is easy to integrate, many security-sensitive networks use it as their password security system. The S/Key client and host do not store any secret information. If either element is compromised, a network intruder cannot obtain secret passwords.
The S/Key system consists of three main parts, as shown in Figure 4-5: the remote client system that the user is using to gain remote access, S/Key client software installed on the remote client system that generates one-time passwords for the remote user, and S/Key host software running on the remote security server.
){kind=link}
Figure 4-5 S/Key Authentication System Components: Remote Client, S/Key Client Software, and S/Key Host
S/Key Client Software
The S/Key client software that is usually installed on the remote system (also known as a password generator) generates a one-time password. When a one-time password is needed, the user enters a secret password into the S/Key client user interface. The S/Key client runs a one-way hashing algorithm using the secret password entered by the user and a seed value sent by the S/Key host to create the one-time password. S/Key uses either MD4 or MD5, which are one-way hashing algorithms, to create the one-time passwords. Each one-time password generated by S/Key consists of six short words. S/Key clients can have a command-line interface or a graphical user interface. An example of an S/Key password generated via a command-line interface is BONE YANK ROW RING WHOA TRUE. Figure 4-6 shows an example of the user interface of an S/Key password generator, the keyapp.exe program for Windows 95 systems.
){kind=link}
Figure 4-6 The S/Key Client keyapp.exe User Interface
keyapp.exe has a graphical user interface that allows the user to enter the secret password, compute a one-time password, copy the password to the clipboard, and then paste the password into an authentication screen (such as Windows Dialup Networking) for the remote login. The authentication software on the remote client sends the one-time password in cleartext over the network to the S/Key host, which validates the one-time password. After the one-time password has been used, it is no longer useful to an eavesdropper. Some S/Key password generators create a list of one-time passwords that can be printed and manually entered into the authentication screen when needed.
S/Key Hosts
The S/Key host receives an authentication request from the S/Key client and sends a challenge/response with S/Key parameters that include a sequence number and a seed value used by the client hash algorithm. The S/Key client then sends the one-time password to the S/Key host. The S/Key host receives the one-time password and validates it by running the hash algorithm against it and comparing the hashed output with the previously received one-time password. If the values match, the user request is approved, and the received one-time password is stored in a file. The S/Key client and server keep track of the number of one-time passwords generated by decrementing a sequence number so that the user must reinitialize the S/Key calculator with a new secret password when the sequence number reaches 0. The CiscoSecure ACS for UNIX security server supports S/Key authentication.
An S/Key User Example
Consider an example of how a user named Sally uses S/Key from a remote UNIX system (with a command-line interface), through a network access server, to CiscoSecure ACS:
Sally identifies herself to the network access server in response to a standard prompt for authentication:
User Access Verification Username: sally s/key 98 agst2359 Password:
CiscoSecure ACS issues a challenge that includes a sequence number of 98 for the one-time password expected and a seed value of agst2359. The values are displayed to Sally by the network access server.
Sally enters 98 and agst2359 into her S/Key calculator program, called key, at the UNIX prompt. The secret password is any string of at least 10 alphanumeric characters generated by Sally, for Sally, and known only by Sally, as follows:
% key 98 agst2359 Enter secret password: secret_password The S/Key calculator creates a one-time password, as follows: ANNE JEAN MILK SHAW LARK NEST
Sally now returns to her interaction with the network access server. She enters the S/Key password and is authenticated, as follows:
Password: ANNE JEAN MILK SHAW LARK NEST
The next time Sally attempts network access, she will be prompted for the one-time password sequence number 97. The sequence number is one less than what was used for the previous authentication. When the sequence number reaches 0, Sally will not be able to log on without reinitializing the S/Key calculator with a new secret password.
Token Cards and Servers
Another one-time password authentication method that adds a new layer of security is accomplished with a token card and a token server. Each token card, about the size of a credit card, is programmed to a specific user, and each user has a unique PIN that can generate a password keyed strictly to the corresponding card. The password is then entered into the password field during a remote authentication.
The use of the token card requires the user to possess a token card or soft token software and to know a password to enable the token. This is called "something you have and something you know." This represents one of the highest commercially available security methods of authentication. One-time password authentication takes place between the specified token server with a token card database and the remote client's authentication software.
Token Card and Server Operation
Token card and server systems consist of a remote client PC, a token card, a network access server, and a token server. Token cards and servers generally work as follows:
The user generates a one-time password with the token card, using a security algorithm.
The user enters the one-time password into the authentication screen generated by the remote client (in this example, the Windows Dialup Networking screen).
The remote client sends the one-time password to the token server via the network and a remote access server.
The token server uses the same algorithm to verify that the password is correct and authenticates the remote user.
Token Card and Server Methods
Two token card and server methods are commonly used:
Time-based—In this system, the token card contains a cryptographic key and generates a password (or token) through the use of a PIN entered by the user. The password is entered into the remote client, which sends it to the token server. The password is loosely synchronized in time to the token server. The server compares the token received to a token generated internally. If they match, the user is authenticated and allowed access.
Challenge/response—In this system, the token card stores a cryptographic key. The token server generates a random string of digits and sends it to the remote client that is trying to access the network. The remote user enters the random string, and the token card computes a cryptographic function using the stored key and random string. The result is sent back to the token server, which has also computed the function. If the results match, the user is authenticated.
Token cards are now implemented in software for installation on the remote client. SofToken, which generates single-use passwords without the associated cost of a hardware token, is one example of software token cards.
Cisco Token Card and Server Support
Cisco supports authentication from the following four token-card servers within CiscoSecure ACS software:
CRYPTOCard RB-1 from CRYPTOCard Corporation
SecurID ACE/Server from RSA Security, Inc.
SafeWord from Secure Computing Corporation, which uses the DES Gold Card token card and the SafeWord SofToken software token card
Axent Technologies token server in CiscoSecure ACS 2.4 for Windows NT
See the "References" section of this chapter for more information about these servers.
PAP and CHAP Authentication
An important component of dialup access security is support for authentication accomplished with PAP and CHAP. The following sections look at the relative strengths of PAP and CHAP. We will examine how PAP and CHAP authentication operates. We will also consider Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), an extension to CHAP.
PPP is a standard encapsulation protocol for the transport of different network layer protocols (including, but not limited to, IP) across serial, point-to-point links such as the PSTN or ISDN. PPP enables authentication between remote clients and servers using either PAP or CHAP.
NOTE
PPP was designed to overcome the limitations of SLIP and to meet the need for an encapsulation protocol for serial lines based on Internet standards. PPP enhancements include encryption, error control, dynamic IP addressing, multiple protocol support, and connection negotiation and authentication.
Cisco network access servers are configured to perform authentication using the aaa authentication commands, which are covered in Chapters 5 and 6.
PAP Authentication Over PPP
PAP authentication, which uses PPP, provides a simple way for the remote client to establish its identity: a two-way handshake (see Figure 4-7). The handshake is done only after initial PPP link establishment. After the link establishment phase is complete, a username/password pair is repeatedly sent by the peer to the authenticator until authentication is acknowledged or the connection is terminated. Here are the messages exchanged during PAP authentication:
){kind=link}
The remote client establishes the dialup link.
The remote client tells the network access server that it is running PPP.
The network access server, configured to use PAP, notifies the remote client to use PAP in this session.
The remote client sends the username and password in PAP format.
The network access server compares the username and password to that stored in its database and accepts or rejects the username and password entered.
Figure 4-7 The Steps in PAP Authentication Over PPP
PAP is not a strong authentication method. The username and password are sent in cleartext across the link. A protocol analyzer could be used to easily capture the password in an eavesdropping attack. PAP offers no protection from playback or repeated trial-and-error attacks. The peer is in control of the frequency and timing of the attempts. PAP provides a level of security similar to the usual user login at the remote host.
Usually PAP is used if it is the only authentication method supported by the client, when a plaintext password must be available to simulate a login at a remote host, or where the communication links are secure. CHAP is the preferred authentication method. Most vendor equipment and software support PAP, enabling greater interoperability between them.
CHAP Authentication Over PPP
CHAP is a stronger authentication method than PAP because the user's actual password never crosses the communications channel. CHAP uses a three-way handshake to verify the identity of the peer. The handshake is done upon initial link establishment, and it may be repeated periodically thereafter to ensure the identity of the peer. The CHAP initiation sequence and three-way handshake occur as follows and as illustrated in Figure 4-8:
){kind=link}
The PPP link is established after dialup. The network access server is configured to support PPP and CHAP.
The network access server tells the remote client to use CHAP.
The remote client responds with an OK.
The three-way handshake occurs as follows:
The network access server sends a challenge message to the remote client.
The remote client replies with a one-way hash value.
The network access server processes the received hash value. If it matches the station's own calculation, authentication is acknowledged. Passwords are not sent over the link.
CHAP periodically verifies the identity of the remote client by using a three-way handshake. The network access server sends a challenge message to the remote node. The remote node responds with a value calculated using a one-way hash function (typically MD5). The network access server checks the response against its own calculation of the expected hash value. If the values match, the authentication is acknowledged. Otherwise, the connection is terminated immediately.
Figure 4-8 CHAP Authentication Steps Over PPP
CHAP provides protection against playback attack through the use of a variable challenge value that is unique and unpredictable. The use of repeated challenges is intended to limit the time of exposure to any single attack. The network access server (or a security server such as CiscoSecure TACACS+) is in control of the frequency and timing of the challenges. A major advantage of the constantly changing challenge string is that eavesdropping cannot be used to capture the challenge value and replay it back later in order to gain unauthorized access to the network because the value constantly changes. CHAP is preferable to PAP for authentication. One problem with CHAP has been that it was not supported in Windows NT authentication systems. Windows NT now supports the Microsoft version of CHAP, MS-CHAP.
CHAP authentication depends on a "secret" known only to the authenticator and the remote client. The secret is not sent over the link. Although the authentication is only one-way, by negotiating CHAP in both directions, the same secret set may easily be used for mutual authentication.
CHAP requires that the secret be available in plaintext form. Irreversibly encrypted password databases that are commonly available (such as the Windows NT SAM hive, the NT password database) cannot be used.
Most vendor efforts have been focused on enabling and improving authentication methods, particularly password access technologies. Improvements to authorization and accounting methods are being made more slowly.
MS-CHAP Authentication
MS-CHAP is the Microsoft version of CHAP, an extension of CHAP described in RFC 1994. MS-CHAP enables PPP authentication between a PC using Microsoft Windows 95, Windows 98, Windows NT, or Windows 2000 and a network access server. PPP authentication using MS-CHAP can be used with or without AAA security services.
MS-CHAP differs from standard CHAP in the following ways:
MS-CHAP is enabled while the remote client and the network access server negotiate PPP parameters after link establishment.
The MS-CHAP Response packet is in a format designed for compatibility with Microsoft's Windows NT 3.5, 3.51, and 4.0 and Windows 95 networking products.
MS-CHAP lets the network security server (authenticator) control retry and password-changing mechanisms. MS-CHAP allows the remote client to change the MS-CHAP password.
MS-CHAP defines a set of reason-for-failure codes returned to the remote client by the network access server.
Cisco routers support MS-CHAP in Cisco IOS Release 11.3 and later releases with the ppp authentication ms-chap command.
Cisco routers support double authentication for PPP in Cisco IOS Release 11.3 and later. With double authentication, the remote host is authenticated with PAP or CHAP, and then the user is authenticated for remote access, potentially with one-time passwords such as token card passwords, which are not supported by CHAP. See the "Enabling Double Authentication" section in the Cisco IOS Security Configuration Guide, Release 12.0, for more information about double authentication.