[9fans] ppp question

[9fans] ppp question

[rod]

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