summaryrefslogtreecommitdiff
path: root/README.MSCHAP81
diff options
context:
space:
mode:
authorDavid F. Skoll <dfs@roaringpenguin.com>2002-03-05 15:14:06 +0000
committerDavid F. Skoll <dfs@roaringpenguin.com>2002-03-05 15:14:06 +0000
commitbcfa20820fc9ff3b25bcf62308e3e737c1897dc6 (patch)
treed9640a3481d36aa55608aee0dca99b72a0136947 /README.MSCHAP81
parent8ed456439d306257173fb0c74d77c4e3c472dfc6 (diff)
downloadppp-bcfa20820fc9ff3b25bcf62308e3e737c1897dc6.tar.gz
Patch from Frank Cusack to add support for MSCHAPv2.
Enhanced radiusclient to support INCLUDE lines in dictionary.
Diffstat (limited to 'README.MSCHAP81')
-rw-r--r--README.MSCHAP8165
1 files changed, 65 insertions, 0 deletions
diff --git a/README.MSCHAP81 b/README.MSCHAP81
new file mode 100644
index 0000000..1d415a9
--- /dev/null
+++ b/README.MSCHAP81
@@ -0,0 +1,65 @@
+PPP Support for Microsoft's CHAP-81
+===================================
+
+Frank Cusack frank@google.com
+
+Some text verbatim from README.MSCHAP80,
+by Eric Rosenquist, rosenqui@strataware.com
+
+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
+address 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:
+
+ <http://www.ietf.org/rfc/rfc2759.txt>
+
+
+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: 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).
+