MPPE in kernel?

What are the chances of getting MPPE (PPP encryption) into the 2.4.21 and/or 2.5.x kernels?

For 2.4.21, sha1 and arcfour code needs to be added, so I don't have too much hope :-) even though the code is trivial to integrate.

For 2.5.x, just the arcfour code is needed (since sha1 is already there). I've written a public domain implementation, which I'd be willing to relicense under GPL (although I don't see the point), but in any case the algorithm is easy and could be written by anyone.

In addition to the crypto, the mppe compressor module is required.

I'm not so concerned about getting any of that included though; what I really want is for the changes to ppp_generic.c to be included. It's not so much fun to have to maintain patches. The changes required are generic, don't require crypto, and are generally uneventful. Getting the crypto bits and the mppe compressor itself included would just be a bonus.

/fc

What about posting those changes for review? If they are clean and your arcfour implementation firts into the crypto API I guess it could go into 2.5. For 2.4.22 it sounds okay too if the 2.5ish crypto API goes in as Davem mentioned.

First, are there any patent issues that you are aware of?

The fundamental problem is that MPPE is misusing CCP (compression control protocol) for something for which it was never intended. The specific place where this is a problem is that the compression code in ppp_generic doesn't guarantee that it will never send a packet out uncompressed, but MPPE requires that. How do you get around that problem?

Regards,
Paul.

There are none for MPPE. It's just MPPC that has patent problems.

I have the compressor return a 3-valued return code (<0, 0, >0) instead of two-valued (>0, other). A negative value tells ppp_generic to drop the packet. 0 means the same as it does now--the compressor failed for some reason. (All current compressors always return 0 or >0, so the negative return is compatible.)

0 could also mean that CCP isn't up yet, but pppd userland doesn't allow NCP's to come up until CCP completes (iff trying to negotiate MPPE).

Note that ECP would have this same problem, it's addressed the same way.

/fc

Hmmm, and are you sure that nothing can cause CCP to go down? If it does then ppp_generic will send data uncompressed. What would happen if an attacker managed to insert a CCP terminate-request into the receive stream somehow?

I think the whole thing needs a careful audit. The idea that you fall back to sending and receiving uncompressed data if CCP goes down or a compressor fails is pretty fundamental to the CCP implementation in ppp_generic.

Paul.

When (if) CCP goes down, pppd shuts down LCP if MPPE was running. This could move into the kernel if you think it's better that way, but I think userland is ok.

static void
ccp_input(unit, p, len)
{
...

#ifdef MPPE
        if (ccp_gotoptions[unit].mppe) {
            error("MPPE disabled, closing LCP");
            lcp_close(unit, "MPPE disabled by peer");
        }

#endif
}

/fc

Not good enough - you have a window when the kernel will be transmitting unencrypted datagrams while pppd responds.

Look at the places in ppp_generic.c where the driver clears SC_COMP_RUN or SC_DECOMP_RUN - for example when it receives a CCP terminate-request or configure-request. You need to do something to make sure that the kernel never transmits data packets when SC_COMP_RUN is clear if you are doing MPPE. Similarly, if you are doing MPPE you probably need to discard received unencrypted data packets.

Paul.

Public domain is GPL compatible anyway so it doesnt matter if its "merely" public domain.

One issue is that there is no support in the crypto API yet for stream ciphers.

- James

James Morris
<[email protected]>

Doesn't need it, AFAICT. The caller keeps the state.

/fc

Well.. there's a very good reason to relicense under GPL, or BSD, or X11-style.

And that's to cover your ass from being sued.

If you release it as "public domain", you waive *all* rights to it, including:

1) The right to prohibit or control what people do with it, including taking it private and closed and making lots of money off it and basically ripping you off.

2) You can't attach a "hold harmless" clause to it. So if you put it in the public domain, since you don't have copyright on it anymore, you can't say "as a condition of copying, you promise not to sue me if this software turns your hair green".

The second is pretty important - although we all complain about large vendors disclaiming all responsibility and liability for their bugs, that's something you *REALLY* want to try to do if you're a open-source programmer....

Of course, IANAL, so consult one if you're worried. ;)

The code is trivial (compared to the effort required to use it in any larger application). I understand the value of this for the general case, though.

I thought public domain explicitly meant that you get what you pay for. Kind of like good samaritan laws. It'd be interesting to hear from any lawyers, are any on lkml?

/fc