Session resumption

[Paul Seward]

On 11 February 2016 at 09:44, Jonathan Gazeley <
Jonathan.Gazeley at bristol.ac.uk> wrote:

> We've upgraded our FreeRADIUS 2.2.x servers to FreeRADIUS 3.0.11 because
> it was about time. Since then, we're having a subtle problem with session
> resumption where in some cases, FreeRADIUS returns two Access-Accept
> packets, each with differing VLAN information which breaks the client. The
> double reply only occurs when EAP sessions have been resumed, but not with
> every resumed session.
> ...
> I hope today to capture enough debug information to be able to submit a
> detailed report to this list.
>

Further to my colleague Jonathans email from last week, we've now managed
to reproduce this issue reliably, using eapol_test.

Output of "radiusd -X" covering server startup and a failed test auth can
be found here
https://www.wireless.bris.ac.uk/software-archive/fr3-debug-20160215.txt as
it was too big to attach to this message.

our eapol_test.conf contains:
---
eapol_version=1
fast_reauth=1
network={
key_mgmt=WPA-EAP
eap=PEAP
identity="iser-linauth at bris.ac.uk"
anonymous_identity="anonymous at bris.ac.uk"
password="REDACTED"
ca_cert="/usr/lib64/nagios/plugins/wpa_supplicant/uob-net-ca.pem"
phase2="auth=MSCHAPV2"
priority=10
}
---

Our config uses Reply:User-Name to determine which vlan a user should go
in, and on a full (non-resumed) authentication, this works fine.

However, It appears that on a resumed session, the Reply:User-Name is blank
after the session details are pulled out of the cache - which is why our
VLAN selection logic fails to perform as expected.  Eg:

[Lines 4472 - 4475]
(13)       if (reply:User-Name =~
/(^[[:alpha:]]+[[:digit:]]+v@|^[[:alnum:]]+-[[:alnum:]]+@)/)
{
(13)       ERROR: Failed retrieving values required to evaluate condition
(13)       elsif (reply:User-Name =~
/(uob\\\\?)?([a-z0-9\\-\\.]+)(@bris(tol)?\\.ac\\.uk)/){
(13)       ERROR: Failed retrieving values required to evaluate condition

I'm hesitant to speculate about what's going on, but it looks to me like
the cache is being populated with the wrong value for
Reply:Stripped-User-Name - instead of being a stripped version of the
Reply:User-Name (from the inner) it's based on the anonymous outer identity.

[Lines 4315-4317]
(12) eap_peap: Adding cached attributes from session
bae26d00e8f00847e2e781985039e5f978cd8856e804b3c7ac6ce276e084f7d9
(12) eap_peap:   reply:User-Name := "iser-linauth at bristol.ac.uk"
(12) eap_peap:   reply:Stripped-User-Name = "anonymous"

I can confirm that turning off eap caching makes the symptoms problem go
away, although obviously there are implications to doing that.

Can anyone tell us what's going on, and how we can fix it?

-Paul
-- 
----------------------------------------------------------------------
Paul Seward,    Senior Systems Administrator,    University of Bristol
Paul.Seward at bristol.ac.uk  +44 (0)117 39 41148    GPG Key ID: E24DA8A2
GPG Fingerprint:    7210 4E4A B5FC 7D9C 39F8  5C3C 6759 3937 E24D A8A2