Home > Articles > Cisco Network Technology > General Networking > Examining Cisco AAA Security Technology

Examining Cisco AAA Security Technology

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Feb 22, 2002.

Chapter Description

This chapter examines Cisco AAA security technology, including authentication, authorization, and accounting methods, and AAA security servers.

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.

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.

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.

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.

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:

  1. 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
  2. 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.

  3. 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:
  4. Sally now returns to her interaction with the network access server. She enters the S/Key password and is authenticated, as follows:

  5. 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:

  1. The user generates a one-time password with the token card, using a security algorithm.

  2. The user enters the one-time password into the authentication screen generated by the remote client (in this example, the Windows Dialup Networking screen).

  3. The remote client sends the one-time password to the token server via the network and a remote access server.

  4. 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.


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:

  1. The remote client establishes the dialup link.

  2. The remote client tells the network access server that it is running PPP.

  3. The network access server, configured to use PAP, notifies the remote client to use PAP in this session.

  4. The remote client sends the username and password in PAP format.

  5. 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:

  1. The PPP link is established after dialup. The network access server is configured to support PPP and CHAP.

  2. The network access server tells the remote client to use CHAP.

  3. The remote client responds with an OK.

  4. The three-way handshake occurs as follows:

    1. The network access server sends a challenge message to the remote client.

    2. The remote client replies with a one-way hash value.

    3. 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.

3. Authorization Methods | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020