2.5.0 and 2.4.9 interoperability issue (MPPE key miscalculation when using radius to authenticate) #453
Comments
|
server side log: (Fatal signal 11 described in #454) Client side log: The Protocol-Reject approximately co-incides with the ping command I ran to get traffic on the link. Could be related to GRE. encapsulation/decapsulation but afaik that's handled in-kernel. I've got a few theories, pending on how accurately we can reproduce on l2tp (which I was told we can but I'm no longer convinced), looks like this could be a crypto key issue for MPPE possibly. Possibly in collaboration with radius authentication. More work required. Downgrading the server ONLY works, ie, 2.4.9 on the server then everything works as expected, client can be either 2.4.9 OR 2.5.0. Will get confirmation on L2TP situation as soon as possible. |
|
@enaess, @paulusmack: What do you think? |
|
This somehow relates to radius authentication, if I use /etc/ppp/chap-secrets to authenticate the client everything works as expected. |
|
@paulusmack, @enaess, @tisj, @jjkeijser, @Sander80, @EasyNetDev, @rustylife, @sthibaul: What do you think? |
|
Impossible to tell for sure without adding debug statements to the code, but the whole |
|
Yeah, my hunch would likely be in the configuration of wrong mppe keys for decryption / encryption in this case. When I did this refactoring, I had no way to test radius code paths. Probably, my fault and also a regression. Should be fixed before 2.5.1 goes out the door IMO |
|
How can I configure using radius authentication with PPP @jkroonza ? |
|
@enaess do you have a static IP I can permit you to send radius from? The ppp configuration side is fairly easy (extracts as needed, tried to trim this down, we also use radattr.so): options file: ppp radius only sends one of NAS-Identifier (and usually gets it wrong) or NAS-IP-Address, we want both, so the above generally gets it right. Don't recall why we needed/wanted map-to-ifname, but it changed something that ended up being more in line with some other major setup which also auths against our radius servers. radius-lns.conf Note that a.b.c.d we use 127.0.0.1 which runs into freeradius that can load balance against a set of remote radius servers, or in some cases, authenticate locally, and a few other options. server-secrets: and dictionary-uls: Don't see anything there that you specifically need for auth, so you can just point directly at /etc/ppp/radius/dictionary. The above I think we merely have so that radattr will place more sensible name=value pairs in the radattr file, so for this bug I highly doubt this is relevant. I can definitely provide you with remote access to send to one of our dev servers where radius is being run if that would help, alternatively also happy to dig into the code myself, if you perhaps have some ideas of where it MAY be going wrong I can certainly add debug code to those paths - just been away on holiday until today for a little over a week, and probably going to be playing a bit of catch-up this week. |
|
At this stage, it seems that in my specific use-case at least, the radius.c module is invoking the mppe_set_keys directly, and not via one of the two chap() mechanisms, this calculation function has been heavily refactored, so I currently believe the problem to reside in that function in radius.c - I'm just wondering if there isn't perhaps a way to simply defer this calculation to mppe.c and invoke one of the two chap setters rather? Incidentally, there is a possible problem here in mppe.c in that they key length is assumed to be the same for send-and receive (makes logical sense). So I don't believe this to be a major issue. |
|
When generating the key material for decrypting the second half of the MPPE key material the refactor in commit 4cb90c1 () changed the key material from MD5(Secret + Crypt) to MD5(Secret + Crypt + Salt) ... I did a bit of a refactor to not nest as deep as well as to output more sensible errors in case of failures, if this full refactor isn't desired I'm willing to go back and perform a minimum change fix rather ... but this full change is how I found the issue. |
block. During he refactor in commit 4cb90c1 the key material used to decrypt the second-half of the encrypted block was accidentally updated from: MD5(radius_secret + crypt[0..15]); to: MD5(radius_secret + crypt[0..15] + salt) Which would obviously mismatch. This also refactors back into what I believe to be a more readable block with lower nesting and more comprehensive error reporting. Closes: ppp-project#453 Signed-off-by: Jaco Kroon <jaco@uls.co.za>
jkroonza
changed the title
…463) During he refactor in commit 4cb90c1 the key material used to decrypt the second-half of the encrypted block was accidentally updated from: MD5(radius_secret + crypt[0..15]); to: MD5(radius_secret + crypt[0..15] + salt) Which would obviously mismatch. This also refactors back into what I believe to be a more readable block with lower nesting and more comprehensive error reporting. Closes: #453 Signed-off-by: Jaco Kroon <jaco@uls.co.za>
Connecting using pptp as well as l2tp (less so on l2tp) gives lots of problems.
Debugging still to be done, just want to get this raised and logged in case someone else has run into and fixed this, or such that we can collaborate on the debug effort. Will post debug logs as soon as possible.
Problems are always with 2.5.0 on the "server" side, and 2.4.9 or windows built-in on the client. This leads me to believe that the problem resides on the server side of 2.5.0.
When connecting using 2.5.0 from the "client" side all seems fine.
2.4.9 outputs messages like "Protocol-Reject for unsupported protocol 'RTP IPHC Compressed TCP' (0x63)"
The text was updated successfully, but these errors were encountered: