[pptp-server] pptpd questions/info newbie...

[Steve Langasek]

Hi Charlie,

On Sun, 7 Oct 2001, Charlie Brady wrote:

> > I'm not the original poster, but I've just yesterday finished patching the
> > Debian/woody ppp package to include mppe support (no smb-stripdomain yet).  I
> > can make this package available for download, but I'd first like to check w/
> > Michael Beattie about getting it included in the next official package
> > release.  Does anyone know of reasons why this mppe patch should not be
> > included in the upstream releases as well (e.g., crypto laws or patent
> > concerns)?

> I know that Paul Mackerras was concerned about crypto laws, but things
> have changed (who knows for how long).

#include <IANAL.h>

MPPE is an encryption algorithm, and as such is regulated under US export law.
As Open Source software, it is also covered by the TSU exemption of the EAR
740.13, which means it can be exported from the US without an export license
so long as the source code is made publically available and the government is
notified prior to the export.

The MSCHAPv2 patch, OTOH, has licensing problems as described in my previous
message.  I know that Linux pppd includes a fair amount of source that is not
covered under the GPL, and some of it may not even be covered by licenses that
are compatible with the GPL; however, because it is the original authors of
pppd who are doing this, there's an implicit license exception being granted.
In the case of the third-party MSCHAP patch, no such permission can be
assumed, and MSCHAP-enabled binaries should not be distributed until someone
secures the appropriate permissions from Paul (et al., if appropriate).

>From a crypto perspective, MSCHAPv2 doesn't pose any problems; there's no
general-purpose (reversible) encryption involved, only message digesting, and
it happens to be the same message digesting algorithm that Microsoft was
selling internationally for years with NT under the old export laws.

I'm cc:ing Paul on this message in case he wants to comment on the licensing
issue.  Hopefully this is a current email for him, it's the one listed on the
freshmeat ppp page.

Again (repeating for Paul's benefit), I'm currently trying to spec out some
chap hooks for pppd because we have an application that requires all
authentication requests (including MSCHAPv2) to be sent against a RADIUS
server; so if this sort of approach would be more palatable than including
MSCHAPv2 directly in the upstream ppp release, perhaps that would be an
option.

> Before we get the patches more widely distributed, I'd like to change the
> mppe-modified pppd to kernel interface so that the modified pppd will work
> with a standard ppp.o module. It doesn't at the moment because an oversize
> parameter block is used to pass encryption keys into the kernel for the
> mppe module to use. This is done via the ioctl handler of the ppp module.

> My idea is to change the interface so that only a pointer is passed, which
> will fit within the standard limit of 32 bytes. The mppe module would then
> upload the keys using copy from user to kernel space. We would then
> distribute the mppe modified pppd along with the mppe module, but use the
> standard ppp module.

> Care to help me develop and test this change, Steve?

I think I would be amenable to that.  Since my employer is in this for the
long haul, the more of this stuff I can commoditize, the better. :)

Steve Langasek
postmodern programmer