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
On Mon, May 12, 2003 at 04:59:29AM -0700, Frank Cusack wrote:
> 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.
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.
Frank Cusack writes:
> What are the chances of getting MPPE (PPP encryption) into the 2.4.21
> and/or 2.5.x kernels?
First, are there any patent issues that you are aware of?
> 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.
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.
On Mon, May 12, 2003 at 10:36:29PM +1000, Paul Mackerras wrote:
> Frank Cusack writes:
>
> > What are the chances of getting MPPE (PPP encryption) into the 2.4.21
> > and/or 2.5.x kernels?
>
> First, are there any patent issues that you are aware of?
There are none for MPPE. It's just MPPC that has patent problems.
> 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?
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
Frank Cusack writes:
> 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).
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.
On Llu, 2003-05-12 at 12:59, Frank Cusack wrote:
> 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.
Public domain is GPL compatible anyway so it doesnt matter if its
"merely" public domain.
On Mon, 12 May 2003 04:59:29 PDT, Frank Cusack <[email protected]> said:
> 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
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. ;)
On Mon, 12 May 2003, Frank Cusack wrote:
> 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.
One issue is that there is no support in the crypto API yet for stream
ciphers.
- James
--
James Morris
<[email protected]>
On Tue, May 13, 2003 at 12:59:19AM +1000, James Morris wrote:
> On Mon, 12 May 2003, Frank Cusack wrote:
>
> > 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.
>
> One issue is that there is no support in the crypto API yet for stream
> ciphers.
Doesn't need it, AFAICT. The caller keeps the state.
/fc
On Mon, May 12, 2003 at 11:07:20PM +1000, Paul Mackerras wrote:
> Frank Cusack writes:
>
> > 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).
>
> 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?
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
On Mon, May 12, 2003 at 11:04:14AM -0400, [email protected] wrote:
> On Mon, 12 May 2003 04:59:29 PDT, Frank Cusack <[email protected]> said:
> > 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
>
> 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.
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.
> 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".
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
Frank Cusack writes:
> When (if) CCP goes down, pppd shuts down LCP if MPPE was running.
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.