[pptp-server] Bug in PPPD CCP Negotiation/change_key bug

[Jordan Mendelson]

(I'm not on this mailing list, so please reply to me directly)

Hello all,

After three hours of attempting to get a MacOS X version of PPTP to work
(based on FreeBSD's userspace ppp which is terribly difficult to find the
source for without a FBSD machine), I finally figured out what was wrong.

In FreeBSD's MPPE implementation both the input and output sides have two
different states with different coherency counts and separate options
including stateless/stateful.

Unfortunately, it appears that the Linux PPPD daemon will happily negotiate
stateful MPPE outbound and stateless MPPE inbound (may have that reversed.)
This obviously causes a problem because when trying to communicate with the
FreeBSD ppp daemon as it changes it's key for only one side of the
connection every packet whereas the Linux end flips both keys.

I finally was able to the world from my MacOS X machine using 128 bit
encryption and MSCHAPv2 through my Linux box when I changed ppd's
ccp_reqci() function to always NAK packets with p[2] (stateless
specification) set to 0.

I'd submit a patch however, this is not the correct way to fix this problem.
As I'm unfamiliar with the official PPTP spec (and PPP in general), I do not
know whether FreeBSD's ppp daemon is doing it the correct way. It is
certainly wasting more CPU than the Linux ppp daemon (since it has two sets
of state, it seems to flip both sets of keys independently), but if the spec
says they can be negotiated separately.. well I'm not sure what to do.

It will be necessary to fix this if anyone wants to connect a FreeBSD, MacOS
X or NetBSD machine to a Linux box. I'm not sure what other platforms this
might affect... But if it's part of the spec, there is a good chance that
other vendors might do the exact same thing.

Again, please tack my address onto the CC list as I'm not on this list. I'm
going to sleep now.


Jordan