1*a619718eSchristosPPP Support for Microsoft's CHAP-81 2*a619718eSchristos=================================== 3*a619718eSchristos 4*a619718eSchristosFrank Cusack frank@google.com 5*a619718eSchristos 6*a619718eSchristosSome text verbatim from README.MSCHAP80, 7*a619718eSchristosby Eric Rosenquist, rosenqui@strataware.com 8*a619718eSchristos 9*a619718eSchristosINTRODUCTION 10*a619718eSchristos 11*a619718eSchristosFirst, please read README.MSCHAP80; almost everything there applies here. 12*a619718eSchristosMS-CHAP was basically devised by Microsoft because rather than store 13*a619718eSchristosplaintext passwords, they (Microsoft) store the md4 hash of passwords. 14*a619718eSchristosIt provides no advantage over standard CHAP, since the hash is used 15*a619718eSchristosas plaintext-equivalent. (Well, the Change-Password packet is arguably 16*a619718eSchristosan advantage.) It does introduce a significant weakness if the LM hash 17*a619718eSchristosis used. Additionally, the format of the failure packet potentially 18*a619718eSchristosgives information to an attacker. The weakness of the LM hash is partly 19*a619718eSchristosaddressed in RFC 2433, which deprecates its use. 20*a619718eSchristos 21*a619718eSchristosMS-CHAPv2 adds 2 benefits to MS-CHAP. (1) The LM hash is no longer 22*a619718eSchristosused. (2) Mutual authentication is required. Note that the mutual 23*a619718eSchristosauthentication in MS-CHAPv2 is different than the case where both PPP 24*a619718eSchristospeers require authentication from the other; the former proves that 25*a619718eSchristosthe server has access to the client's password, the latter proves that 26*a619718eSchristosthe server has access to a secret which the client also has -- which 27*a619718eSchristosmay or may not be the same as the client's password (but should not be 28*a619718eSchristosthe same, per RFC 1994). Whether this provides any actual benefit is 29*a619718eSchristosoutside the scope of this document. The details of MS-CHAPv2 can be 30*a619718eSchristosfound in the document: 31*a619718eSchristos 32*a619718eSchristos <http://www.ietf.org/rfc/rfc2759.txt> 33*a619718eSchristos 34*a619718eSchristos 35*a619718eSchristosBUILDING THE PPPD 36*a619718eSchristos 37*a619718eSchristosIn addition to the requirements for MS-CHAP, MS-CHAPv2 uses the SHA-1 38*a619718eSchristoshash algorithm. A public domain implementation is provided with pppd. 39*a619718eSchristos 40*a619718eSchristos 41*a619718eSchristosTROUBLESHOOTING 42*a619718eSchristos 43*a619718eSchristosAssuming that everything else has been configured correctly for PPP and 44*a619718eSchristosCHAP, the MS-CHAPv2-specific problems you're likely to encounter are mostly 45*a619718eSchristosrelated to your Windows NT account and its settings. A Microsoft server 46*a619718eSchristosreturns error codes in its CHAP response. The following are extracted from 47*a619718eSchristosRFC 2759: 48*a619718eSchristos 49*a619718eSchristos 646 ERROR_RESTRICTED_LOGON_HOURS 50*a619718eSchristos 647 ERROR_ACCT_DISABLED 51*a619718eSchristos 648 ERROR_PASSWD_EXPIRED 52*a619718eSchristos 649 ERROR_NO_DIALIN_PERMISSION 53*a619718eSchristos 691 ERROR_AUTHENTICATION_FAILURE 54*a619718eSchristos 709 ERROR_CHANGING_PASSWORD 55*a619718eSchristos 56*a619718eSchristosYou'll see these in your pppd log as a line similar to: 57*a619718eSchristos 58*a619718eSchristos Remote message: E=649 No dialin permission 59*a619718eSchristos 60*a619718eSchristosPreviously, pppd would log this as: 61*a619718eSchristos 62*a619718eSchristos Remote message: E=649 R=0 63*a619718eSchristos 64*a619718eSchristosNow, the text message is logged (both for MS-CHAP and MS-CHAPv2). 65*a619718eSchristos 66