Kerberos Overview
The Kerberos protocol was designed by the Massachusetts Institute of Technology to provide strong authentication for client/server applications by using secret-key cryptography. Kerberos keeps a database of its clients and their private keys. The private key is a large number known only to Kerberos and the client it belongs to. In the case that the client is a user, it is an encrypted password.
Network services requiring authentication register with Kerberos, as do clients wanting to use those services. The private keys are negotiated at registration.
Because Kerberos knows these private keys, it can create messages that convince one client that another is really who it claims to be. Kerberos also generates temporary private keys, called session keys, which are given to two clients and no one else. A session key can be used to encrypt messages between two parties.
Kerberos provides three distinct levels of protection. The application programmer determines which is appropriate, according to the requirements of the application. For example, some applications require only that authenticity be established at the initiation of a network connection and can assume that further messages from a given network address originate from the authenticated party.
Other applications require authentication of each message, but do not care whether the content of the message is disclosed. For these, Kerberos provides safe messages. Yet a higher level of security is provided by private messages, where each message is not only authenticated but also encrypted.
Private messages are used, for example, by the Kerberos server itself for sending passwords over the network.
You can find more information on Kerberos at http://web.mit.edu/kerberos/www/.
PAP and CHAP Authentication
Traditionally, remote users dial in to an access server to initiate a PPP session. PPP is the standard encapsulation protocol for the transport of different network protocols across ISDN, serial, or Public Switched Telephone Network (PSTN) connections.
PPP currently supports two authentication protocols: PAP and CHAP. Both are specified in RFC 1334 and are supported on synchronous and asynchronous interfaces. Authentication via PAP or CHAP is
Data integrity The entire TACACS+ packet is encrypted in MD5.
Only the user password is encrypted.
Accounting Limited. Extensive.
Table 6-3 Features of TACACS+ and RADIUS Protocols (Continued)
Functionality TACACS+ RADIUS
equivalent to typing in a username and password when prompted by the server. CHAP is considered to be more secure because the remote user’s password is never sent across the connection.
PAP
Password Authentication Protocol (PAP) involves a two-way handshake where the username and password are sent across the link in clear text. When PAP is enabled, the remote client attempting to connect to the access server is required to send an authentication request. If the username and password specified in the authentication request are accepted, the access server sends an authenti-cation acknowledgment. Figure 6-3 shows the two-handshake process of PAP.
Figure 6-3 Two-Handshake Process of PAP
An example of a PAP authentication on a NAS follows:
Router(config-if)# ppp authentication pap
PAP provides no protection from playback and password attacks. A protocol analyzer could easily capture the password. Although a lot of vendors support PAP, CHAP is the preferred method of authentication because it is more secure.
CHAP
Challenge Handshake Authentication Protocol (CHAP) is a more secure authentication method than PAP because the password is never sent over the wire. CHAP periodically verifies the identity of the peer using a three-way handshake. This is done upon initial link establishment and may be repeated any time after the link has been established. Figure 6-4 shows the three-way handshake of CHAP.
Figure 6-4 Three-Way Handshake of CHAP
Dial-Up User NAS
Username, Password
Accept/Reject
Dial-Up User NAS
Challenge
Accept/Reject Response
PAP and CHAP Authentication 111
After the link establishment phase is complete, the access server sends a “challenge” message to the remote peer. The remote peer responds with a value calculated using a “one-way hash” function (typically MD5). The access server checks the response against its own calculation of the expected hash value. If the values match, the authentication is acknowledged.
CHAP provides protection against playback attacks through the use of an incrementally changing identifier and a variable challenge value. The use of repeated challenges is intended to limit the time of exposure to any single attack. The access server is in control of the frequency and timing of the challenges.
MS-CHAP
Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) is the Microsoft version of CHAP and is an extension of RFC 1994. Like the standard version of CHAP, MS-CHAP is used for PPP authentication; in this case, authentication occurs between a PC using Microsoft Windows NT or Microsoft Windows 95 and a Cisco router or access server acting as a NAS.
MS-CHAP differs from the standard CHAP as follows:
■ MS-CHAP is enabled by negotiating CHAP algorithm 0x80 in LCP option 3, Authentication Protocol.
■ The MS-CHAP response packet is in a format designed to be compatible with Microsoft Windows. This format does not require the authenticator to store a clear or reversibly encrypted password.
■ MS-CHAP provides an authenticator-controlled authentication retry mechanism.
■ MS-CHAP provides an authenticator-controlled change-password mechanism.
■ MS-CHAP defines a set of reason-for-failure codes returned in the failure packet’s Message field.
Foundation Summary
The “Foundation Summary” section of each chapter lists the most important facts from the chapter.
Although this section does not list every fact from the chapter that will be on your exam, a well-prepared candidate should at a minimum know all the details in each “Foundation Summary” before going to take the exam.
■ Authentication methods vary from strong to weak:
— One-time passwords using token cards
— One-time passwords using token cards
— The session key one-time password (OTP) systems
— Expiring or aging username and passwords
— Static username and password
— No username and password
■ TACACS+ separates authentication, authorization, and accounting services. RADIUS combines authentication and authorization but separates accounting services.
■ CHAP periodically verifies the identity of the peer using a three-way handshake.
■ PAP involves a two-way handshake where the username and password are sent across the link in clear text. PAP provides no protection from playback and password attacks.
Q&A 113
Q&A
As mentioned in the introduction, “How to Use This Book,” you have two choices for review questions. The questions that follow next give you a bigger challenge than the exam itself by using an open-ended question format. By reviewing now with this more difficult question format, you can exercise your memory better and prove your conceptual and factual knowledge of this chapter. The answers to these questions are found in the appendix.
For more practice with exam-like question formats, including questions using a router simulator and multiple choice questions, use the exam engine on the CD-ROM.
1. Which port is reserved TACACS+ use?
2. Why is PAP considered insecure compared to other authentication protocols such CHAP and MS-CHAP?
3. What type of encryption algorithm does CHAP uses during the three-way handshake?
4. Who developed and designed the Kerberos authentication protocol?
5. Give one difference between CHAP and MS-CHAP?
6. Which versions of the TACACS protocol in Cisco IOS Software have officially reached end-of-maintenance?
7. What command is used to disable the console password for a network access server?
8. Which two popular authentication methods does PPP support?
9. In the RADIUS security architecture, what is the network access server?
This chapter covers the following subjects:
■ AAA Overview
■ Configuring AAA Services
■ Troubleshooting AAA