[RADIATOR] random EAP authentication errors since 4.17

Hartmaier Alexander alexander.hartmaier at t-systems.at
Tue Jan 24 11:39:05 UTC 2017

On 2017-01-24 12:11, Heikki Vatiainen wrote:
> On 24.1.2017 12.18, Hartmaier Alexander wrote:
>>> Yes, that's correct. The information saved for resume has the same
>>> lifetime. Also, if it happens that a session is resumed by TLS layer
>>> but Radiator has no information about the resumed session, the
>>> authentication will fail.
>> I can't confirm that behaviour. For us the (by OpenSSL) successfully
>> resumed session was accepted without any reply attributes leading to
>> clients not getting in the correct vlan. That's why I've assumed that
>> the resume context wasn't saved or restored correctly.
> I think I might know why you are not seeing the your reply attributes,
> please see below.
>> That explains why my change from $p->{EAPContext}->{hvn_test} to
>> $p->{EAPContext}->{eap_resume_context}->{hvn_test} in
>> EAPTLS_CertificateVerifyHook didn't work at all, Radiator overwrote
>> ->{eap_resume_context} without checking that it's already there assuming
>> noone fiddled with it in a hook.
> Correct. It only goes and fetches the information needed across
> resumes when TLS handshake has completed. The hook runs before that.
>> To summarize, your suggested solution is:
>> - store custom variables in $p->{EAPContext} in
>> EAPTLS_CertificateVerifyHook
> Yes. The context is available at that point. The saved resume
> information has not been fetched yet.
>> - move them from $p->{EAPContext} to
>> $p->{EAPContext}->{eap_resume_context} in a PostAuthHook which can be
>> both in the EAP enabled AuthBy or the Handler for full authentications
>> (non-resumed). This is something I've never tried.
> Yes, when you do this after full TLS handshake, the values will be
> available when resume happens.
>> - access the stored variables in $p->{EAPContext}->{eap_resume_context}
>> when resuming. Is there a need to copy them to $p->{EAPContext} if I
>> only need their values in the PostAuthHook?
> There's no need to copy them if it's ok for you to access them from
> eap_resume_context.
>> - set the reply attributes based on the variables. Here I'd unsure if I
>> only need to set them for full authentications, because Radiator
>> persists them $p->{EAPContext}->{eap_resume_context} automatically or if
>> I need to do that myself because PostAuthHook is after Radiator has done
>> that already?
> I think this might be the reason why you are not seeing the reply
> attributes. The attributes (last_reply_attrs) in resume context are
> not automatically updated if you add your own custom attributes in the
> reply, for example, in PostAuthHook.
> The attributes, last_reply_attrs, in resume context are the ones that
> the inner authentication returned during the full authentication. If
> you update those attributes with your custom reply attributes during
> the full authentication in PostAuthHook, then your custom attributes
> should be automatically added during resumption.
The radius reply attribute handling for session resumption is clear now,
Could you move the storage of reply attributes into the resume context
to a point after PostAuthHook is called so this isn't required?

>> Our findings from Friday and yesterday where that only PEAP-TLS fails,
>> EAP-TLS works fine.
> The latter is EAP-TTLS and the problem is PEAP/EAP-TLS?
We don't use EAP-TTLS, only PEAP-TLS and EAP-TLS. EAP-TLS works, also
resumption, PEAP-TLS doesn't.

>> We've disabled session resumption for all PEAP-TLS authentications, both
>> wired and wireless to work around the missing reply attributes on
>> resumption which lead to duplicate request errors.
>> I did a packet capture on the radius server and saw that the first
>> packet after the (PEAP) TLS tunnel establishment never gets replied by
>> radiator (radius packet id 57 in our capture) but it's retransmission by
>> the Cisco WLC after 5 seconds still gets logged as 'Duplicate request id
>> 57 received from ...'. Do you have any idea why this could be happening?
> Can't really say without logs. However, if it's related to fragment
> sizes, then the adjustment in Radiator does seems not to be enough. It
> uses value of 40 but as you wrote, you seem to be needing adjustment
> of 50.
What kind of logs do you need? I could mail you the packet capture as a
starting point, but we haven't had debugging enabled at that time, just
log level 3 where no sign of the mentioned request with id 57 can be seen.

>> Further as Radiator 4.13 changelog states that it handles
>> EAPTLS_MaxFragmentSize of the inner EAP method automatically we've
>> commented our inner EAPTLS_MaxFragmentSize 1200 which lead to a non
>> working auth for certificates from two of our three CAs.
>> We had issues when we onboarded that CA and had to reduce both the outer
>> PEAP as well as the inner EAP-TLS EAPTLS_MaxFragmentSize by 50 to get it
>> working.
>> May there be an edge case that some auths hang because of a too large
>> packet (for which no error is logged by Radiator) which leads to not
>> replied requests which IDs are still remembered as already received by
>> Radiator?
> That's a possibility since the adjustment is 40 which seems to be too
> little since you need 50. We probably need to update this value.
I see, please document this value in ref.pdf.
Which formula can be used to calculate this value?

> Thanks,
> Heikki
Thanks, Alex

T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.

More information about the radiator mailing list