Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)       9  TCP/IP Network Interface Layer (OSI Data Link Layer) Protocols            9  TCP/IP Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP)                 9  Point-to-Point Protocol (PPP)                      9  PPP Core Protocols: Link Control, Network Control and Authentication

PPP Network Control Protocols (IPCP, IPXCP, NBFCP and others) 1 2 3 PPP Feature Protocols

Challenge Handshake Authentication Protocol (CHAP)

The most important difference between PAP and CHAP is that CHAP doesn't transmit the password across the link. Now you may be wondering—if that's the case, how is the password verified? Well, think of it this way. PAP works by the initiator telling the authenticator “here's the password I know, see if it matches yours”. CHAP does this by having each of the devices use the password to perform a cryptographic computation and then check if they each get the same result. If they do, they know they have the same password.

In CHAP, a basic LCP link is set up between the initiator (calling client) and authenticator (generally the server that is deciding whether to grant authentication). The authenticator then takes charge of the authentication process, using a technique called a three-way handshake. This is a fairly common general authentication procedure; the same basic technique is used, for example, in IEEE 802.11 Shared Key Authentication.

The three-way handshake steps are as follows (and as illustrated in Figure 30):

1. Challenge: The authenticator generates a frame called a Challenge and sends it to the initiator. This frame contains a simple text message (sometimes called the challenge text). The message has no inherent special meaning so it doesn't matter if anyone intercepts it. The important thing is that after receipt of the Challenge both devices have the same challenge message.
   
   
2. Response: The initiator uses its password (or some other shared “secret” that the authenticators also knows) to encrypt the challenge text. It then sends the encrypted challenge text as a Response back to the authenticator.
   
   
3. Success or Failure: The authenticator performs the same encryption on the challenge text that the initiator did. If the authenticator gets the same result that the initiator sent it in the Response, the authenticator knows that the initiator had the right password when it did its encryption, so the authenticator sends back a Success message. Otherwise, it sends a Failure message.
   

   Figure 30: PPP Challenge Handshake Authentication Protocol (CHAP) Authentication

   CHAP uses a three-way handshake beginning with a Challenge from the authenticating device (usually the remote server accessed by a host). This message is encrypted and returned to the authenticating device, which checks to see if the device trying to authenticate used the correct password (or other “shared secret”).

   
   

You can see the beauty of this: it verifies that the two devices have the same “shared secret” but doesn't require that the secret be sent over the link. The Response is calculated based on the password, but the content of the Response is encrypted and thus, much harder to derive the password from. CHAP also provides protection against replay attacks, where an unauthorized user captures a message and tries to send it again later on. This is done by changing an identifier in each message and varying the challenge text. Also, in CHAP the server controls the authentication process, not the client that is initiating the link.

CHAP itself is not perfect, but it's a heck of a lot closer to perfection than PAP is. In fact, the IETF made a rather strong statement in this regard when it revised the original RFC describing PAP and CHAP, and included only CHAP in the new standard. Despite this, PAP is still used in some applications, because it is simple. And well, some folks think they are smarter than Einstein. J Seriously though, PAP can be fine in situations where security is not a big deal, but CHAP is much better and still not really that complicated.

PPP Network Control Protocols (IPCP, IPXCP, NBFCP and others) 1 2 3 PPP Feature Protocols