From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7b045aa42078b97aca226cb514e5fdb5@hemiola.co.uk> Date: Fri, 21 Oct 2011 20:37:50 +0100 From: rod@hemiola.co.uk To: 9fans@9fans.net MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] ppp question Topicbox-Message-UUID: 397737a6-ead7-11e9-9d60-3106f5b1d025 Can anyone help with this? Ppp doesn't authenticate in server mode. During the auth phase the plan9 ppp client sends the mschap response packet with the 24 byte "lan manager" field zeroed out. This is in line with the recommendation in rfc2433 which deprecated lm as being insecure. However, in authsrv.c both the lm and nt fields are checked as follows: > lmhash(hash, secret); > mschalresp(resp, hash, chal); > lmok = memcmp(resp, reply.LMresp, MSresplen) == 0; > nthash(hash, secret); > mschalresp(resp, hash, chal); > ntok = memcmp(resp, reply.NTresp, MSresplen) == 0; > dupe = memcmp(reply.LMresp, reply.NTresp, MSresplen) == 0; > > /* > * It is valid to send the same response in both the LM and NTLM > * fields provided one of them is correct, if neither matches, > * or the two fields are different and either fails to match, > * the whole sha-bang fails. > * > * This is an improvement in security as it allows clients who > * wish to do NTLM auth (which is insecure) not to send > * LM tokens (which is very insecure). > * > * Windows servers supports clients doing this also though > * windows clients don't seem to use the feature. > */ > if((!ntok && !lmok) || ((!ntok || !lmok) && !dupe)){ > replyerror("mschap-fail bad response %s/%s(%s) %d,%d,%d", In this case, dupe=0, lmok=0, ntok=1, so auth fails. This bit of code was added on 28/11/09. Prior to that only ntok was checked, which if course worked fine. I can't find any corroboration that the above comment and code is correct, but it's obviously there for a reason. I know it's probably obsolete stuff, but it seems a shame if old bits just crumble through natural wastage. Can anyone shed any light? -rod