[RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

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,
thanks!
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.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*