Re: [lwip-users] PPP MPPE "Optional" Support

[Sylvain Rochet]

Hi Greg,


On Wed, Aug 10, 2016 at 11:30:14PM +0000, Greg Smith wrote:
> Hello.
>
> I have some devices in the field that have all PPP authentication 
> turned off for PPP.  Now that lwIP supports MSCHAPv2 and MPPE (in the 
> 2.0.0 betas), I'd like to enable those features on my devices to 
> encrypt the traffic.  But I also need to support older units that are 
> running older lwIP versions and don't have authentication support.
> 
> If I ppp_set_auth(, PPPAUTHTYPE_ANY,,) in my startup code, I can get 
> peers to connect with both no authentication and MSCHAPv2 
> successfully.  (Yea!)

Yes, but it only works because MSCHAPv2 is tried first. Anyway using 
PPPAUTHTYPE_ANY have security considerations to take into account, it 
mostly renders authentication useless, this is just to say it for future 
readers, I'm sure you already know that :)


> However, if I then try ppp_set_mppe(pppPcb, PPP_MPPE_ENABLE | 
> PPP_MPPE_REFUSE_128); (with or without the REFUSE flag), my clients 
> with no authentication fail because MPPE is "required".  (LwIP 
> responds with "MPPE required, but MS-CHAP[v2] auth not performed.".)
> 
> I'd like to make it so MPPE is only required if MSCHAPv2 negotiates.  
> (Alternately, don't require MPPE if no authentication is negotiated, 
> but require it (and fail) if any other form is negotiated.)  Is there 
> a way to do this?  Or is that behavior completely unsupported?

You are right, this is currently not supported. The problem here is that 
allowing no encryption if the peer does not support encryption while 
encryption is enabled makes it vulnerable to a downgrade attack[1] up to 
using clear text.

Maybe I could add a flag to MPPE configuration to allow it, something 
like PPP_MPPE_ALLOW_CLEARTEXT, with a huge warning about the security 
implication because it makes MPPE close to useless.


> I've thought about using PPP_NOTIFY_PHASE in some way, but I haven't 
> explored that yet.  Would that be viable (even if clunky) to manually 
> do ppp_set_mppe after MSCHAPv2 negotiates?  Or is even that poor 
> practice to change LCP options in the middle of the negotiation?

I'm pretty sure this idea is actually working :-)

As long as ppp_set_mppe is called inside the lwIP thread for !NO_SYS 
systems, I see no reason it couldn't work. Note you have to clear MPPE 
flags after authentication phase and before CCP, else MSCHAPv2 is not 
going to prepare keys for MPPE.


MPPE is clearly misdesigned, this is huge hack between MSCHAPv2 and CCP… 
it breaks all the PPP basic design about auth and control protocol 
isolation from each other. There is worse, the way keys are generated 
can't have more entropy than the chosen password because keys are only 
derived from the password hash, and it gets even worse because 
transformations done on the hash to make it "more" random actually 
reduce its entropy to a weak 56-bit key, that was designed back in the 
day were Microsoft knew nothing about encryption and they did it wrong. 
By the way, it can only uses the RC4 cipher, which is considered weak 
today.[2][3][4]

It was enough for what I needed though, this is why I added it, I only 
wanted to prevent anyone from sending valid command packets to our 
equipment just by knowing its IP address. If someone breaks encryption 
and send the packet which we avoided being received, then we will 
"Actually, I'm not even mad, that's amazing" [5] :-)


Sylvain


[1] https://en.wikipedia.org/wiki/Downgrade_attack
[2] 
http://security.stackexchange.com/questions/45509/are-there-any-known-vulnerabilities-in-pptp-vpns-when-configured-properly
[3] 
http://superuser.com/questions/171277/mppe-forcing-strong-passwords-enough-to-make-pptp-secure
[4] 
https://www.schneier.com/academic/archives/1999/09/cryptanalysis_of_mic_1.html
    ( abstract: https://www.schneier.com/academic/pptp/ )
[5] 
http://s2.quickmeme.com/img/34/34bde2c7eac4b12fec8ebfad5b806f0f5c12f2f7493fd40ca2e01f5d6c84901e.jpg

signature.asc
Description: Digital signature