Re: [RADIATOR] random EAP authentication errors since 4.17
Hi Heikki, just read the patches changelog, the EAP related things sound good! I'll get back to you when I got a change to update our 802.1x Radius servers to it. Thanks, Alex On 2017-04-20 10:26, Heikki Vatiainen wrote: On 24.1.2017 14.58, Hartmaier Alexander wrote: On 2017-01-24 12:57, Heikki Vatiainen wrote: I think we'll need to think about an interface for this. This discussion has been useful to understanding the custom use cases, so rather than moving it, I' say it's better to provide a documented call or similar to do this. That would be great! Can you name a timeframe how soon you would have a patch for us to decide if we implement the current solution or wait for the documented one? Getting back to this: The current Radiator 4.17 patch set includes eaptls_resume_post_auth_hook.pl in goodies that shows how to customise authentication results. What the sample hook shows should be more simple and better way to do what we discussed earlier. It also does away the need to know about how internals that could change in the future. The example shows how to work with non-resumed and resumed TLS sessions. There's no need to call any of the Net::SSLeay methods since the context now has the necessary information about how and if the resumption was done. Thanks, Heikki *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* 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. *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* ___ radiator mailing list radiator@lists.open.com.au http://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] random EAP authentication errors since 4.17
On 2017-01-24 12:57, Heikki Vatiainen wrote: On 24.1.2017 13.39, Hartmaier Alexander wrote: Could you move the storage of reply attributes into the resume context to a point after PostAuthHook is called so this isn't required? I think we'll need to think about an interface for this. This discussion has been useful to understanding the custom use cases, so rather than moving it, I' say it's better to provide a documented call or similar to do this. That would be great! Can you name a timeframe how soon you would have a patch for us to decide if we implement the current solution or wait for the documented one? 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. Ah, sorry, I read EAP-TLS twice. 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. I trace 4 log would be best. If you create one, just send it to me directly since the list does now allow large attachments. We had no duplicate error since about four hours, but I'll enable debug logging to file so we have it next time it occurs. 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? It's not calculated but an estimate that was based on watching how it worked with different certificate chains. It's a good idea to get this documented. Note that the difference between PEAP max fragment size (1300) and inner EAP-TLS max fragment size (1200) is 100, not 50. Would you suggest to decrease the inner value even more or keep the difference of 100 and decrease both? What happens when Radiator builds a reply packet with 1300 bytes EAP-Message and some other radius reply attributes and the udp packets gets larger than the server interface MTU (1500 in our case)? Is it possible that it gets silently dropped? Thanks, Heikki Is anyone else on the list using PEAP-TLS anywhere and can share her/his findings? 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. *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* ___ radiator mailing list radiator@lists.open.com.au http://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] random EAP authentication errors since 4.17
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
Re: [RADIATOR] random EAP authentication errors since 4.17
Hi,
we still have an issue with session resumption where the EAP context
doesn't contain the custom variables we've stored in the
EAPTLS_CertificateVerifyHook of the initial, non-resumed, authentication.
How does EAPContextTimeout, which has been reduced from 1000 to 120
seconds in version 4.17, interact with EAPTLS_SessionResumptionLimit
which defaults to 43200 seconds (12 hours) which we have explictly
configured to this value?
If I've interpreted the code and OpenSSL docs correctly, OpenSSL would
keep the data required for a successful session resumption for
EAPTLS_SessionResumptionLimit (12 hours).
If a client sends a session id it would look up the session and find it
if < EAPTLS_SessionResumptionLimit but Radiator would have thrown away
its context because of > EAPContextTimeout and not return any reply
attributes in the accept reply.
We've increased EAPContextTimeout to the same 43200 seconds as
EAPTLS_SessionResumptionLimit which seems to have fixed the issue.
If you can confirm that our analysis is correct please add something
like this to the docs of EAPContextTimeout:
If the Radiator context timeout for the EAP session is shorter than the
OpenSSL session timeout (EAPTLS_SessionResumptionLimit) a session
resumption will succeed at the OpenSSL level but Radiator will create a
new context which doesn't include any custom data nor the initial Radius
reply attributes.
I'd also suggest to add a warning log message to Radius::Context::get if
a context can't be found and a new one is returned.
Thanks, Alex
On 2016-12-19 10:23, Hartmaier Alexander wrote:
On 2016-12-16 12:40, Heikki Vatiainen wrote:
On 16.12.2016 11.46, Hartmaier Alexander wrote:
Sadly the sh** didn't stop there, OpenSSL segfaults when
Net::SSLeay::session_reused gets passed an undefined value:
For Net::SSLeay this is just a pass through call to OpenSSL's
respective function. I think the caller is responsible for not handing
undef/NULL as the argument.
For this reason I'd say this is not a candiate for a ticket against
Net::SSLeay and is not something that neither Net::SSLeay or OpenSSL
needs to handle.
I agree with your view regarding Net::SSLeay but not on OpenSSL,
function args should always be validated.
Is Mike (author of Net::SSLeay) still working for you? I haven't opened
a RT for the module as I'm not sure if this should be handled at the
Perl XS layer or in OpenSSL.
Mike is still maintainer for Net::SSLeay, but he is not with us
anymore. About the ticket, as I mentioned above, I think we need to do
the null check inside Radiator hook.
As a workaround I'll check for exists $p->{EAPContext} && exists
$p->{EAPContext}->{ssl} before calling the function. This was enough
for
MAC bypass auths (non-EAP) but expired certs crashed Radiator again
today.
I'd add && $p->{EAPContext}->{ssl} to the checks too. What likely
happens now is that the hash key 'ssl' exists but the value for the
key is undef. I'd say this is caused by the code that runs when the
expiration was noticed.
Already done that last week ;) Seems to be stable so far.
Would you advise to use Radius::TLS::contextSessionCheckReuse
instead of
Net::SSLeay::session_reused directly?
I think what could be done in this function is to set something like
$context->{eap_tls_session_resumed} to the value returned by
Net::SSLeay::session_reused or implement the resume counter which I
mentioned earlier. I would not call this function from a hook since
its purpose is to check if the session was resumed or not and do
what's appropriate based on resumption and configured resumption
settings.
We'd prefer to have a special variable we can use for logging instead of
having to do the determination ourselves.
Please advise a safe way of determining and logging EAP session
resumption, we seem to stumble from one pitfall to another ourselves.
I'd say the above extra check allow session_reused() to work for now
until we add the extras/helpers mentioned above and the earlier
messages.
Ok, thanks!
Thanks for your patience,
Heikki
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
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.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] random EAP authentication errors since 4.17
On 2016-12-16 12:40, Heikki Vatiainen wrote:
On 16.12.2016 11.46, Hartmaier Alexander wrote:
Sadly the sh** didn't stop there, OpenSSL segfaults when
Net::SSLeay::session_reused gets passed an undefined value:
For Net::SSLeay this is just a pass through call to OpenSSL's
respective function. I think the caller is responsible for not handing
undef/NULL as the argument.
For this reason I'd say this is not a candiate for a ticket against
Net::SSLeay and is not something that neither Net::SSLeay or OpenSSL
needs to handle.
I agree with your view regarding Net::SSLeay but not on OpenSSL,
function args should always be validated.
Is Mike (author of Net::SSLeay) still working for you? I haven't opened
a RT for the module as I'm not sure if this should be handled at the
Perl XS layer or in OpenSSL.
Mike is still maintainer for Net::SSLeay, but he is not with us
anymore. About the ticket, as I mentioned above, I think we need to do
the null check inside Radiator hook.
As a workaround I'll check for exists $p->{EAPContext} && exists
$p->{EAPContext}->{ssl} before calling the function. This was enough for
MAC bypass auths (non-EAP) but expired certs crashed Radiator again
today.
I'd add && $p->{EAPContext}->{ssl} to the checks too. What likely
happens now is that the hash key 'ssl' exists but the value for the
key is undef. I'd say this is caused by the code that runs when the
expiration was noticed.
Already done that last week ;) Seems to be stable so far.
Would you advise to use Radius::TLS::contextSessionCheckReuse instead of
Net::SSLeay::session_reused directly?
I think what could be done in this function is to set something like
$context->{eap_tls_session_resumed} to the value returned by
Net::SSLeay::session_reused or implement the resume counter which I
mentioned earlier. I would not call this function from a hook since
its purpose is to check if the session was resumed or not and do
what's appropriate based on resumption and configured resumption
settings.
We'd prefer to have a special variable we can use for logging instead of
having to do the determination ourselves.
Please advise a safe way of determining and logging EAP session
resumption, we seem to stumble from one pitfall to another ourselves.
I'd say the above extra check allow session_reused() to work for now
until we add the extras/helpers mentioned above and the earlier messages.
Ok, thanks!
Thanks for your patience,
Heikki
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
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.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] random EAP authentication errors since 4.17
On 16.12.2016 11.46, Hartmaier Alexander wrote:
Sadly the sh** didn't stop there, OpenSSL segfaults when
Net::SSLeay::session_reused gets passed an undefined value:
For Net::SSLeay this is just a pass through call to OpenSSL's respective
function. I think the caller is responsible for not handing undef/NULL
as the argument.
For this reason I'd say this is not a candiate for a ticket against
Net::SSLeay and is not something that neither Net::SSLeay or OpenSSL
needs to handle.
Is Mike (author of Net::SSLeay) still working for you? I haven't opened
a RT for the module as I'm not sure if this should be handled at the
Perl XS layer or in OpenSSL.
Mike is still maintainer for Net::SSLeay, but he is not with us anymore.
About the ticket, as I mentioned above, I think we need to do the null
check inside Radiator hook.
As a workaround I'll check for exists $p->{EAPContext} && exists
$p->{EAPContext}->{ssl} before calling the function. This was enough for
MAC bypass auths (non-EAP) but expired certs crashed Radiator again today.
I'd add && $p->{EAPContext}->{ssl} to the checks too. What likely
happens now is that the hash key 'ssl' exists but the value for the key
is undef. I'd say this is caused by the code that runs when the
expiration was noticed.
Would you advise to use Radius::TLS::contextSessionCheckReuse instead of
Net::SSLeay::session_reused directly?
I think what could be done in this function is to set something like
$context->{eap_tls_session_resumed} to the value returned by
Net::SSLeay::session_reused or implement the resume counter which I
mentioned earlier. I would not call this function from a hook since its
purpose is to check if the session was resumed or not and do what's
appropriate based on resumption and configured resumption settings.
Please advise a safe way of determining and logging EAP session
resumption, we seem to stumble from one pitfall to another ourselves.
I'd say the above extra check allow session_reused() to work for now
until we add the extras/helpers mentioned above and the earlier messages.
Thanks for your patience,
Heikki
--
Heikki Vatiainen
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] random EAP authentication errors since 4.17
On 2016-12-15 13:46, Heikki Vatiainen wrote:
On 15.12.2016 14.04, Hartmaier Alexander wrote:
If you get context from $p, it does not matter if, for example,
EAP_UseState was enabled or note. It's easier and more reliable to get
it from $p.
I've removed EAP_UseState from our config since everything works as
before. Can the nested auth of PEAP-TLS cause this in conjunction with
the state ID generation?
I'd say in your case the call to get EAP worked fine because it simply
returned the context that was retrieved earlier. In other words, it
did the same as getting the context with $p->{EAPContext}.
Our PostAuthHook already has this at the very top since the beginning.
Is this the correct way to check?
my $p = ${$_[0]};
my $rp = ${$_[1]};
my $result = $_[2];
my $reason = $_[3];
return
unless $$result == $main::ACCEPT;
Yes. This looks fine. The reason you are given a reference to result
is that you can also change it in case you need to modify the result
with your hook.
Yes, we already have several $$reason assignments ;)
Yes, but it only points to EAP.pm which didn't change much since 4.16.
How should they be persisted after writing to $context?
I hope this is clarified below. Now when I look at the notes, I can
see that a mentioned of eap_save_resume_context and
eap_recover_resume_context could have been included.
So basically write to and read from
$context->{eap_resume_context}->{foo} instead of $context->{foo}?
As this doesn't use an accessor method I'd like it at least documented
somewhere so we can be sure it doesn't break without notice on one of
the next updates.
Yes, that's correct. eap_resume_context points to the context that is
saved across resumed sessions. You are correct that there are no
accessors yet. These would be among the helpers for hooks that I wrote
about earlier.
Sadly the sh** didn't stop there, OpenSSL segfaults when
Net::SSLeay::session_reused gets passed an undefined value:
gdb --args perl -E 'use Net::SSLeay; my $foo = {foo => bar};
Net::SSLeay::session_reused($foo->{EAPContext}->{ssl});'
Is Mike (author of Net::SSLeay) still working for you? I haven't opened
a RT for the module as I'm not sure if this should be handled at the
Perl XS layer or in OpenSSL.
BTW this happens on Debian stable (8) 64bit with all packages updated,
OpenSSL 1.0.1t-1+deb8u5.
As a workaround I'll check for exists $p->{EAPContext} && exists
$p->{EAPContext}->{ssl} before calling the function. This was enough for
MAC bypass auths (non-EAP) but expired certs crashed Radiator again today.
Would you advise to use Radius::TLS::contextSessionCheckReuse instead of
Net::SSLeay::session_reused directly?
EAP_25.pm line 219 is the only place where Net::SSLeay::session_reused
is called directly outside of Radius::TLS::contextSessionCheckReuse.
Please advise a safe way of determining and logging EAP session
resumption, we seem to stumble from one pitfall to another ourselves.
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.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] random EAP authentication errors since 4.17
On 15.12.2016 14.04, Hartmaier Alexander wrote:
If you get context from $p, it does not matter if, for example,
EAP_UseState was enabled or note. It's easier and more reliable to get
it from $p.
I've removed EAP_UseState from our config since everything works as
before. Can the nested auth of PEAP-TLS cause this in conjunction with
the state ID generation?
I'd say in your case the call to get EAP worked fine because it simply
returned the context that was retrieved earlier. In other words, it did
the same as getting the context with $p->{EAPContext}.
Our PostAuthHook already has this at the very top since the beginning.
Is this the correct way to check?
my $p = ${$_[0]};
my $rp = ${$_[1]};
my $result = $_[2];
my $reason = $_[3];
return
unless $$result == $main::ACCEPT;
Yes. This looks fine. The reason you are given a reference to result is
that you can also change it in case you need to modify the result with
your hook.
Yes, but it only points to EAP.pm which didn't change much since 4.16.
How should they be persisted after writing to $context?
I hope this is clarified below. Now when I look at the notes, I can see
that a mentioned of eap_save_resume_context and
eap_recover_resume_context could have been included.
So basically write to and read from
$context->{eap_resume_context}->{foo} instead of $context->{foo}?
As this doesn't use an accessor method I'd like it at least documented
somewhere so we can be sure it doesn't break without notice on one of
the next updates.
Yes, that's correct. eap_resume_context points to the context that is
saved across resumed sessions. You are correct that there are no
accessors yet. These would be among the helpers for hooks that I wrote
about earlier.
--
Heikki Vatiainen
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] random EAP authentication errors since 4.17
On 12.12.2016 17.45, Hartmaier Alexander wrote:
please respond how to:
Hello Alex, I'll reply to your previous messages about these, but I'll
add quick notes below. Sometimes time just flies, I'm sorry for the slow
response.
- log auth vs. session resumption
- handle session resumption in PostAuthHooks
For these, you can currently check
Net::SSLeay::session_reused($context->{ssl}); are you wrote before. I'll
have an alternative too I have thought for this.
- if the last_reply_attrs don't include the attributes added by a
PostAuthHook
More about this in its own message. These attributes are from tunnelled
EAP's inner authentication. If you need to add, for example, VLAN
attributes with a Hook, we can see how to do that.
- usability of FarmSize with PEAP-TLS when enabling EAP_UseState
EAP_UseState does not change this. It's the TLS state that lives within
the SSL library that ties one TLS based EAP authentication session to
one instance making it problematic with FarmSize (multiple instances).
Thanks,
Heikki
--
Heikki Vatiainen
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
