Certificate problem between 3.0.11 and 3.1.x

[Matthew Newton]

On Fri, Mar 18, 2016 at 12:02:40PM +0000, Matthew Newton wrote:
> On Fri, Mar 18, 2016 at 09:23:20AM +0000, Scott Armitage wrote:
> > Alan Buxey and myself have spent some time and believe we have tracked down the commit which broke EAP:
> > 
> > commit 8a7f6e330f45439d333f61dde7ee0982ebcc2a29
> > Author: Arran Cudbard-Bell <a.cudbardb at freeradius.org>
> > Date:   Sun Dec 6 00:34:21 2015 -0500
> > 
> >     Add additional debugging so we can track TLS fragments sent
> 
> Hmm. If that's the case, then the bug is probably to do with the
> length included flag and the length of the packet.

Close. Think I may have found it. Have found the differences,
anyway.

First confusing thing is the FreeRADIUS is only printing out the
first EAP-Message attribute in the debug output, hence the lengths
before looked wrong (e.g. showing length 1000, but only having 247
or so bytes in the response). This is just because the other three
EAP-Message attributes aren't being printed.

Testing here with eapol_test shows that they are being returned
correctly and this is only a debug output issue.

The new code, for fragmented packets, is arguably more correct.

In 8a7f6e330f^, in my test here, I have

  Challenge 1: length 1004, flags L+M
  Challenge 2: length 1000, flags M
  Challenge 3: length 726

Total length 2730, all verified OK (correct lengths in packets
etc) as far as I can tell.

In 8a7f6e330f (with the patch) for the same request/config I get:

  Challenge 1: length 1000, flags L+M
  Challenge 2: length 1000, flags M
  Challenge 3: length 730

So it's not going over the MTU, which is better.

However...

The key difference seems to be that in packets that do *not* need
fragmenting, the L flag and length are now included, whereas in
8a7f6e330f^ they are not.

This seems fine in the PEAP negotiation stage, but fails on the
first packet after PEAP goes into its inner tunnel.

My hypothesis would be a supplicant bug that sees the Length flag
set so erroneously expects more packets, but that should not be
the case because M was not set. It certainly works fine in
eapol_test both pre- and post-8a7f6e330f, so it seems down to the
way the particular supplicant processes the reply.

draft-josefsson-pppext-eap-tls-eap-02 is silent on this matter it
seems. L and M MUST be set for the start of fragments, L to set
the length of the whole amount of data. But there is no mention of
whether L on its own (for a non-fragmented packet), without M, is
banned. Certainly the supplicant seems to send data this way to
the server, and other packets are sent like this back to the
supplicant, hence guessing this change in behaviour is just
hitting one particular Windows supplicant in the wrong places.

Cheers,

Matthew


-- 
Matthew Newton, Ph.D. <mcn4 at le.ac.uk>

Systems Specialist, Infrastructure Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>