[ppp]ppp支持mschap2

ppp老家：

---------------------------------------------start------------------------------
Q: Explain about PAP and CHAP?

A: PAP stands for the Password Authentication Protocol. With this protocol, the "client" (the machine that needs to authenticate itself) sends its name and a password, in clear text, to the "server". The server returns a message indicating whether the name and password are valid.

CHAP stands for the Challenge Handshake Authentication Protocol. It is designed to address some of the deficiencies and vulnerabilities of PAP. Like PAP, it is based on the client and server having a shared secret, but the secret is never passed in clear text over the link. Instead, the server sends a "challenge" - an arbitrary string of bytes, and the client must prove it knows the shared secret by generating a hash value from the challenge combined with the shared secret, and sending the hash value back to the server. The server also generates the hash value and compares it with the value received from the client.

At a practical level, CHAP can be slightly easier to configure than PAP because the server sends its name with the challenge. Thus, when finding the appropriate secret in the secrets file, the client knows the server's name. In contrast, with PAP, the client has to find its password (i.e. the shared secret) before it has received anything from the server. Thus, it may be necessary to use the `remotename' option to pppd when using PAP authentication so that it can select the appropriate secret from /etc/ppp/pap-secrets.

Microsoft also has a variant of CHAP which uses a different hashing arrangement from normal CHAP. There is a client-side implementation of Microsoft's CHAP in ppp-2.3; see README.MSCHAP80.

-------------------------------------------end---------------------------------------------------------

PPP Support for Microsoft's CHAP-81
===================================

Frank Cusack        [e-mail]

Some text verbatim from README.MSCHAP80,
by Eric Rosenquist, [e-mail]

INTRODUCTION

First, please read README.MSCHAP80; almost everything there applies here.
MS-CHAP was basically devised by Microsoft because rather than store
plaintext passwords, they (Microsoft) store the md4 hash of passwords.
It provides no advantage over standard CHAP, since the hash is used
as plaintext-equivalent.  (Well, the Change-Password packet is arguably
an advantage.)  It does introduce a significant weakness if the LM hash
is used.  Additionally, the format of the failure packet potentially
gives information to an attacker.  The weakness of the LM hash is partly
addressed in RFC 2433, which deprecates its use.

MS-CHAPv2 adds 2 benefits to MS-CHAP.  (1) The LM hash is no longer
used.  (2) Mutual authentication is required.  Note that the mutual
authentication in MS-CHAPv2 is different than the case where both PPP
peers require authentication from the other; the former proves that
the server has access to the client's password, the latter proves that
the server has access to a secret which the client also has -- which
may or may not be the same as the client's password (but should not be
the same, per RFC 1994).  Whether this provides any actual benefit is
outside the scope of this document.  The details of MS-CHAPv2 can be
found in the document:

    <


BUILDING THE PPPD

In addition to the requirements for MS-CHAP, MS-CHAPv2 uses the SHA-1
hash algorithm.  A public domain implementation is provided with pppd.


TROUBLESHOOTING

Assuming that everything else has been configured correctly for PPP and
CHAP, the MS-CHAPv2-specific problems you're likely to encounter are mostly
related to your Windows NT account and its settings.  A Microsoft server
returns error codes in its CHAP response.  The following are extracted from
RFC 2759:

 646 ERROR_RESTRICTED_LOGON_HOURS
 647 ERROR_ACCT_DISABLED
 648 ERROR_PASSWD_EXPIRED
 649 ERROR_NO_DIALIN_PERMISSION
 691 ERROR_AUTHENTICATION_FAILURE
 709 ERROR_CHANGING_PASSWORD

You'll see these in your pppd log as a line similar to:

   Remote message: E=649 No dialin permission

Previously, pppd would log this as:

   Remote message: E=649 R=0

Now, the text message is logged (both for MS-CHAP and MS-CHAPv2).



补充：、
hat was new in ppp-2.4.2. ************************** * The CHAP code has been rewritten. Pppd now has support for MS-CHAP V1 and V2 authentication, both as server and client. The new CHAP code is cleaner than the old code and avoids some copyright problems that existed in the old code. * MPPE (Microsoft Point-to-Point Encryption) support has been added, although the current implementation shouldn't be considered completely secure. (There is no assurance that the current code won't ever transmit an unencrypted packet.) * James Carlson's implementation of the Extensible Authentication Protocol (EAP) has been added. * Support for the Encryption Control Protocol (ECP) has been added. * Some new plug-ins have been included: - A plug-in for kernel-mode PPPoE (PPP over Ethernet) - A plug-in for supplying the PAP password over a pipe from another process - A plug-in for authenticating using a Radius server. * Updates and bug-fixes for the Solaris port. * The CBCP (Call Back Control Protocol) code has been updated. There are new options `remotenumber' and `allow-number'. * Extra hooks for plugins to use have been added. * There is now a `maxoctets' option, which causes pppd to terminate the link once the number of bytes passed on the link exceeds a given value. * There are now options to control whether pppd can use the IPCP IP-Address and IP-Addresses options: `ipcp-no-address' and `ipcp-no-addresses'. * Fixed several bugs, including potential buffer overflows in chat.