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.
PPP Authentication Protocols: Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP)
(Page 3 of 3)
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 wonderingif 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.
CHAP Authentication Procedure
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):
Benefits of CHAP
- 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.
- 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.
- 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
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.
Key Concept: PPP supports two authentication protocols: PAP and CHAP. PAP is a simple request/reply authentication protocol that is widely considered to be inadequate since it sends the user name and password in clear text and provides little protection against many security concerns. CHAP uses a three-way handshake procedure and is preferred over PAP in most implementations.
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.
|If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!|
Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.