Fwd: eap-fast: using eap-fast-mschapv2 in anonymous tunnel
Hi Alan, On Sat, Sep 23, 2017 at 4:47 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 22, 2017, at 9:05 PM, Isaac Boukris <iboukris@gmail.com> wrote:
I've been trying to test eap-fast unauthenticated provisioning (RFC 5422), and was getting mschap errors, for which I think I found a fix - see attached patch (v3.0x).
With this patch, the mschap authentication stage succeeds using eapol_test and a tunnel-pac is provisioned (while the first eapol exchange ends with reject as allowed by the RFC, the subsequent authentication successes using the newly provisioned pac).
That looks good, thanks.
Thanks!
I also tried out the v4.0x branch but encountered some other issues. First had to add a cast to float when comparing with tls_max_version (inst->tls_conf->tls_max_version > (float) 1.1), as otherwise: float x = 1.1; if (x > 1.1) yields true for some reason.
Floats are notorious for that kind of thing...
To me this seem insane. See attached patch with some more casting, including the actual one, preventing tlsv1.1 with eap-fast, in rlm_eap_fast.c file.
Then however, I get a crash which I can't figure so far - logs with back-trace attached.
That's a straightforward infinite recursion. I've pushed a fix.
That stopped the crash. However eap-fast still fails for no obvious reason and sometimes the server exits on assertion fail - see attached log. Regards.
On Sep 23, 2017, at 7:40 AM, Isaac Boukris <iboukris@gmail.com> wrote:
That stopped the crash. However eap-fast still fails for no obvious reason and sometimes the server exits on assertion fail - see attached log.
I've pushed the patch, thanks. The reason EAP-FAST fails is odd... I suspect it's because the code was re-written a while ago and not properly tested. I've pushed one more fix which lets it go further. It now complains about (1) eap_fast - ERROR: PAC missing type TLV, sending alert to client And the client complains about: SSL: SSL3 alert: read (remote end reported an error):fatal:bad certificate Which is weird. Probably again due to the re-write. As for the assertion, that's odd. I don't see anything like that on my system. And the hope is that time is always increasing. Alan DeKok.
On Sep 23, 2017, at 7:40 AM, Isaac Boukris <iboukris@gmail.com> wrote:
That stopped the crash. However eap-fast still fails for no obvious reason
I've pushed some fixes. It should now work.
and sometimes the server exits on assertion fail - see attached log.
That one still confuses me. Alan DeKok.
On Sat, Sep 23, 2017 at 4:22 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 23, 2017, at 7:40 AM, Isaac Boukris <iboukris@gmail.com> wrote:
That stopped the crash. However eap-fast still fails for no obvious reason
I've pushed some fixes. It should now work.
and sometimes the server exits on assertion fail - see attached log.
That one still confuses me.
I'm still seeing failures, note that it's running on 32bit arch, which had led into strange bugs in the past. In server authenticated only flow (phase1="fast_provisioning=2") i get this consistently: phttps://filebin.ca/3bNwuiCQ3ddm In unauthenticated flow (phase1="fast_provisioning=1"), the first request causes the server to exit with: https://filebin.ca/3bNzY0BK89xv But that first request does provision the pac file, and so the subsequent request succeeds using the pac. However, when I run eapol_test repeatedly a few times, the server exits again with: https://filebin.ca/3bO0B1s5uUHY HTH
On Sep 23, 2017, at 10:16 AM, Isaac Boukris <iboukris@gmail.com> wrote:
I'm still seeing failures, note that it's running on 32bit arch, which had led into strange bugs in the past.
Ah... we do most of the testing on 64-bit, but it *should* work on 32-bit systems.
In server authenticated only flow (phase1="fast_provisioning=2") i get this consistently: phttps://filebin.ca/3bNwuiCQ3ddm
In unauthenticated flow (phase1="fast_provisioning=1"), the first request causes the server to exit with: https://filebin.ca/3bNzY0BK89xv
That looks like the same error. I'd need to see the full gdb output for more.
But that first request does provision the pac file, and so the subsequent request succeeds using the pac.
However, when I run eapol_test repeatedly a few times, the server exits again with: https://filebin.ca/3bO0B1s5uUHY
That assertion is just weird. It's asserting that time only goes forward, which it should... What OS are you using? Alan DeKok.
On Sat, Sep 23, 2017 at 6:54 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 23, 2017, at 10:16 AM, Isaac Boukris <iboukris@gmail.com> wrote:
In server authenticated only flow (phase1="fast_provisioning=2") i get this consistently: phttps://filebin.ca/3bNwuiCQ3ddm
In unauthenticated flow (phase1="fast_provisioning=1"), the first request causes the server to exit with: https://filebin.ca/3bNzY0BK89xv
That looks like the same error. I'd need to see the full gdb output for more.
Log with gdb backtrace at: https://filebin.net/i2qmyn0kvy3m0doi/v4_sigsegv.log
But that first request does provision the pac file, and so the subsequent request succeeds using the pac.
However, when I run eapol_test repeatedly a few times, the server exits again with: https://filebin.ca/3bO0B1s5uUHY
That assertion is just weird. It's asserting that time only goes forward, which it should...
What OS are you using?
Sorry, I haven't looked much into the error itself, I'll try to. I'm testing on a virtual machine, running Linux fedora, with libkqueue built from git source. $ uname -a Linux fedora 4.11.12-100.fc24.i686+PAE #1 SMP Fri Jul 21 17:51:58 UTC 2017 i686 i686 i386 GNU/Linux $ openssl version OpenSSL 1.0.2k-fips 26 Jan 2017 Thanks.
participants (2)
-
Alan DeKok -
Isaac Boukris