Re: [RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

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

[Heikki Vatiainen]

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

--
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

[Hartmaier Alexander]

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

[Heikki Vatiainen]

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.



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.



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.


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

Re: [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 pro

Re: [RADIATOR] random EAP authentication errors since 4.17

[Heikki Vatiainen]

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.



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'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.



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.


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/

Re: [RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

Hi Heikki,


On 2017-01-23 14:35, Heikki Vatiainen wrote:

On 20.1.2017 11.33, Hartmaier Alexander wrote:


Can you confirm that Radiator stores the information saved by
eap_save_resume_context for the same duration as OpenSSL is told to
do so?
In Radius/TLS.pm line 818 it looks like EAPTLS_SessionResumptionLimit is
used to set this timeout too.


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.



Can you please write up how we should persist our custom data set in the
EAPTLS_CertificateVerifyHook and retrieve it in the PostAuth hook?
I suggest defining and documenting one key that is persisted and
restored by eap_save_resume_context / eap_recover_resume_context which
can then be used by hooks to store data in.


I have attached a short PostAuthHook that does this. During the full
auth, the hook stores a custom value from EAPContext so that it is
available when TLS resume is done. When a TLS resume is done, it
copies the value from resume data to EAPContext. This allows you to
always access your custom value when the hook has run. You may want to
add more error checks, etc. but it should work as a sample.

The hook can be configured as PostAuthHook for an AuthBy or a Handler.
In addition to this, for a demo, use this for
EAPTLS_CertificateVerifyHook:

EAPTLS_CertificateVerifyHook sub {my $p = $_[5]; \
   $p->{EAPContext}->{hvn_test} = 'hvn_test set in
CertificateVerifyHook. Time: '. time(); \
   return $_[0];}

The verify hook sets a custom value that the PostAuthHook stores and
restores as needed. The timestamp is there to show how the value stays
the same once it's set during the full authentication.


Is $p->{EAPContext}->{eap_resume_context} already available in a
EAPTLS_CertificateVerifyHook or will data I'll write into it be
overwritten?


No, the resume context is created only when TLS has accepted a new
session. You need to store the values in EAPContext as you are already
doing.

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.



Also in a PostAuth hook when a session has been resumed?


Yes, as seen in the attached hook.


I've tried using $p->{EAPContext}->{eap_resume_context} instead of
$p->{EAPContext} for all custom variables but the reply attributes set
by our PostAuth hook aren't restored from the resume context as it
seems.
Is eap_save_resume_context called before the PostAuth hook is called?


It is, but you may want to see the hook to see if it works better in
your case.


What about my suggestion to add a warning to Radius::Context::get if a
context can't be found?
Does this make sense as Radiator has one per-auth context and one
per-resumeable session?


I'd say get() does what it's now expected. In other words, it will
return the existing value or create a new context. Note that there is
also find() that returns the existing value, if any, and does not
reset the timeout. But in any case, the caller needs to see if it got
anything and act accordingly.

To summarize, your suggested solution is:
- store custom variables in $p->{EAPContext} in EAPTLS_CertificateVerifyHook
- 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.
- 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?
- 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?



Just saw that the last paragraph in 4.22.77. PostAuthHook is duplicate.


I have made a ticket about this, thanks!
Heikki


Our findings from Friday and yesterday where that only PEAP-TLS fails,
EAP-TLS works fine.
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 (

Re: [RADIATOR] random EAP authentication errors since 4.17

[Heikki Vatiainen]

On 20.1.2017 11.33, Hartmaier Alexander wrote:


Can you confirm that Radiator stores the information saved by
eap_save_resume_context for the same duration as OpenSSL is told to do so?
In Radius/TLS.pm line 818 it looks like EAPTLS_SessionResumptionLimit is
used to set this timeout too.


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.



Can you please write up how we should persist our custom data set in the
EAPTLS_CertificateVerifyHook and retrieve it in the PostAuth hook?
I suggest defining and documenting one key that is persisted and
restored by eap_save_resume_context / eap_recover_resume_context which
can then be used by hooks to store data in.


I have attached a short PostAuthHook that does this. During the full 
auth, the hook stores a custom value from EAPContext so that it is 
available when TLS resume is done. When a TLS resume is done, it copies 
the value from resume data to EAPContext. This allows you to always 
access your custom value when the hook has run. You may want to add more 
error checks, etc. but it should work as a sample.


The hook can be configured as PostAuthHook for an AuthBy or a Handler. 
In addition to this, for a demo, use this for EAPTLS_CertificateVerifyHook:


EAPTLS_CertificateVerifyHook sub {my $p = $_[5]; \
   $p->{EAPContext}->{hvn_test} = 'hvn_test set in 
CertificateVerifyHook. Time: '. time(); \

   return $_[0];}

The verify hook sets a custom value that the PostAuthHook stores and 
restores as needed. The timestamp is there to show how the value stays 
the same once it's set during the full authentication.



Is $p->{EAPContext}->{eap_resume_context} already available in a
EAPTLS_CertificateVerifyHook or will data I'll write into it be
overwritten?


No, the resume context is created only when TLS has accepted a new 
session. You need to store the values in EAPContext as you are already 
doing.



Also in a PostAuth hook when a session has been resumed?


Yes, as seen in the attached hook.


I've tried using $p->{EAPContext}->{eap_resume_context} instead of
$p->{EAPContext} for all custom variables but the reply attributes set
by our PostAuth hook aren't restored from the resume context as it seems.
Is eap_save_resume_context called before the PostAuth hook is called?


It is, but you may want to see the hook to see if it works better in 
your case.



What about my suggestion to add a warning to Radius::Context::get if a
context can't be found?
Does this make sense as Radiator has one per-auth context and one
per-resumeable session?


I'd say get() does what it's now expected. In other words, it will 
return the existing value or create a new context. Note that there is 
also find() that returns the existing value, if any, and does not reset 
the timeout. But in any case, the caller needs to see if it got anything 
and act accordingly.



Just saw that the last paragraph in 4.22.77. PostAuthHook is duplicate.


I have made a ticket about this, 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.
sub {
my $p = ${$_[0]};
my $result = ${$_[2]};

my $context = $p->{EAPContext};
return unless ($result == $main::ACCEPT &&
		   $context->{ssl});

unless ($context->{eap_resume_context})
{
	# Should not happen
	main::log($main::LOG_ERR, "PostAuthHook: No eap_resume_context", $p);
	return;
}

my $custom_val;
my $reused = Net::SSLeay::session_reused($context->{ssl});
if ($reused)
{
	# TLS session resumed. Get our custom value from the
	# previously saved resume data and store it in EAP context
	$custom_val = $context->{eap_resume_context}->{hvn_test};
	$context->{hvn_test} = $custom_val;
}
else
{
	# Full authentication. Need to store the custom value for
	# later. Get it from EAP context where it was saved by
	# EAPTLS_CertificateVerifyHook
	$custom_val = $context->{hvn_test};
	$context->{eap_resume_context}->{hvn_test} = $custom_val;
}

# The custom value always present in EAP context
main::log($main::LOG_DEBUG, "PostAuthHook: reused: $reused custom_val: $context->{hvn_test}", $p);

return;
}
___
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

[Hartmaier Alexander]

On 2017-01-19 16:30, Heikki Vatiainen wrote:

On 19.1.2017 13.00, Hartmaier Alexander wrote:


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.


I hope I can clarify this. Please note that EAP context is aimed at
for short term storage only, as described below.


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?


EAPContextTimeout is for EAP authentication only. It sets the timeout
for the client to respond and continue the ongoing EAP authentication.

EAPTLS_SessionResumptionLimit is for OpenSSL as you have correctly
understood below.


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).


Yes.


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.


Correct partly. Radiator can throw away the EAP current context once
the authentication has finished. However, it will store information
required for session resumption. This information is stored and
retrieved by the functions in EAP.pm. For example, the reply
attributes, among other information, is stored by
eap_save_resume_context().

In other words, the information required across resumed sessions has
its own storage that is separate from the EAP authentication context.
When a session is resumed successfully, the saved information is
copied in EAP context so that hooks etc. can continue to use it as
they have done with earlier releases.

Can you confirm that Radiator stores the information saved by
eap_save_resume_context for the same duration as OpenSSL is told to do so?
In Radius/TLS.pm line 818 it looks like EAPTLS_SessionResumptionLimit is
used to set this timeout too.



We've increased EAPContextTimeout to the same 43200 seconds as
EAPTLS_SessionResumptionLimit which seems to have fixed the issue.


This will keep the EAP context around so that the custom values you
save in EAP context are always available. This works even if you don't
save the custom values to resume storage similar to how EAP.pm
eap_save_resume_context() does. What you are doing is much like how
things were working before the separate storage saved by
eap_save_resume_context() was introduced.

What Radiator saves by default with the above function is the
information it needs. This includes, for example, the reply attributes
and information about inner authentication user names for PEAP and
such. It does not include any custom information since it's now known
what it might be.

What you would need to save and recover from the resume_context is
your custom information. As was discussed in the previous messages,
there's no interface to do it yet, but I can see that it is needed.

Although both timeouts are now identical we still have issues with a
much lower amount of clients than before where the OpenSSL session
resumption works, but $p->{EAPContext} in the PostAuth hook doesn't
contain any of the custom variables.

As previously asked it should be sufficient to skip any PostAuth
processing at the beginning of a PostAuth hook using this code as
Radiator has saved the reply attributes from the initial full
authentication ifself:
return
if exists $context->{ssl} &&
Net::SSLeay::session_reused($context->{ssl});

exists $context->{ssl} is required because SSL_session_reused in OpenSSL
1.0.2 segfaults when given an invalid pointer (undefined at the Perl level).

This would however lose the custom variables used for logging.

Can you please write up how we should persist our custom data set in the
EAPTLS_CertificateVerifyHook and retrieve it in the PostAuth hook?
I suggest defining and documenting one key that is persisted and
restored by eap_save_resume_context / eap_recover_resume_context which
can then be used by hooks to store data in.

Is $p->{EAPContext}->{eap_resume_context} already available in a
EAPTLS_CertificateVerifyHook or will data I'll write into it be overwritten?
Also in a PostAuth hook when a session has been resumed?

I've tried using $p->{EAPContext}->{eap_resume_context} instead of
$p->{EAPContext} for all custom variables but the reply attributes set
by our PostAuth hook aren't restored from the resume context as it seems.
Is eap_save_resume_context called before the PostAuth hook is called?



If you can confirm that our analysis is correct please add something
like this to the docs of EAPContextTimeout:


I think we need to include information that describes how to save
custom information in case, for example, customisati

Re: [RADIATOR] random EAP authentication errors since 4.17

[Heikki Vatiainen]

On 19.1.2017 13.00, Hartmaier Alexander wrote:


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.


I hope I can clarify this. Please note that EAP context is aimed at for 
short term storage only, as described below.



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?


EAPContextTimeout is for EAP authentication only. It sets the timeout 
for the client to respond and continue the ongoing EAP authentication.


EAPTLS_SessionResumptionLimit is for OpenSSL as you have correctly 
understood below.



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).


Yes.


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.


Correct partly. Radiator can throw away the EAP current context once the 
authentication has finished. However, it will store information required 
for session resumption. This information is stored and retrieved by the 
functions in EAP.pm. For example, the reply attributes, among other 
information, is stored by eap_save_resume_context().


In other words, the information required across resumed sessions has its 
own storage that is separate from the EAP authentication context. When a 
session is resumed successfully, the saved information is copied in EAP 
context so that hooks etc. can continue to use it as they have done with 
earlier releases.



We've increased EAPContextTimeout to the same 43200 seconds as
EAPTLS_SessionResumptionLimit which seems to have fixed the issue.


This will keep the EAP context around so that the custom values you save 
in EAP context are always available. This works even if you don't save 
the custom values to resume storage similar to how EAP.pm 
eap_save_resume_context() does. What you are doing is much like how 
things were working before the separate storage saved by 
eap_save_resume_context() was introduced.


What Radiator saves by default with the above function is the 
information it needs. This includes, for example, the reply attributes 
and information about inner authentication user names for PEAP and such. 
It does not include any custom information since it's now known what it 
might be.


What you would need to save and recover from the resume_context is your 
custom information. As was discussed in the previous messages, there's 
no interface to do it yet, but I can see that it is needed.



If you can confirm that our analysis is correct please add something
like this to the docs of EAPContextTimeout:


I think we need to include information that describes how to save custom 
information in case, for example, customisation done by hooks requires 
it. That is, document the interface that needs to be implemented for 
saving the custom data.


What you have described below would be for cases when EAP_UseState is 
not enabled. Even then the resumption is not allowed if Radiator does 
not know about the first full authentication.


When State attribute use is enabled, then the context lookup will also 
depend on the State attribute that is created for each EAP 
authentication exchange.



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.


Thanks again for your input on this.

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

Re: [RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

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

[Hartmaier Alexander]

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

[Heikki Vatiainen]

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

[Hartmaier Alexander]

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

[Heikki Vatiainen]

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

[Hartmaier Alexander]

On 2016-12-13 14:45, Heikki Vatiainen wrote:

On 13.12.2016 12.32, Hartmaier Alexander wrote:


I strongly advice to get context like this:
my $context = $p->{EAPContext};

Ok, I've changed our hooks to use this again like before, seems to not
make a difference both ways.


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?



Can you please add this to the reference guide?


Good idea. I think this discussion means we need to create an example
how to keep custom data that persists across resumed authentications.

Thanks!



The session_reused() call will tell this.

I've added logging and all resumed sessions are missing the reply
attributes we're adding with our hooks (mainly vlan id).
Does this check signal a successful resume or just the attempt to do so?


I am not sure if this has been strictly defined by the OpenSSL API. To
be sure, I would only check this after the TLS session has been
accepted. I'd check first that, for example, PostAuthHook result is
ACCEPT before continuing. Radiator only does this check for TLS
sessions that have been successfully established.

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;




It seems the reply attributes added by the hook code for the first,
non-resumed authentication aren't stored in the EAP context.
Please advise if it is required to do that manually or if this is a bug
in 4.17.


You need to do it manually. This is why it got a special mention in
the release history.

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?


What you could do is to write your custom attributes in the
resume_context when the authentication was successfully and
session_reused() indicates it was not a resumed. See
eap_save_resume_context in EAP.pm for an example.

The next time around when session_reused() indicates TLS did resume,
you can once again get the resume_context like above, but now just
verify the values are there and then use them.

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.


When the next Radiator release is done, see the change history for the
possible helpers that you could consider using in your hooks instead.
One of the helpers could be the resume count I wrote about earlier.


For now I'd use the session_reused() check with the Hook.

This works, but we're not sure if it means the resumption was successful
or attempted, see above.


As I mentioned above, I would only check this if the result indicates
authentication success.

What comes to reliably saving state information across server restarts
and reloads, that is not currently supported. Saving the resume
context required by Radiator is doable. SQL, Redis and similar could
be used for this. Storing and and reloading TLS library's TLS sessions
seems to be possible, from a quick look at the openssl docs. As a
downside, doing this would not still help with FarmSize without more
work there.

If you need to split load, maybe you could consider a front end proxy
that uses, for example, AuthBy HASHBALANCE to forward messages to a
number of workers where each worker is bound to its own port, as
opposed one port with FarmSize.

Thanks,
Heikki


Cheers, 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

[Heikki Vatiainen]

On 13.12.2016 12.32, Hartmaier Alexander wrote:


I strongly advice to get context like this:
my $context = $p->{EAPContext};

Ok, I've changed our hooks to use this again like before, seems to not
make a difference both ways.


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.



Can you please add this to the reference guide?


Good idea. I think this discussion means we need to create an example 
how to keep custom data that persists across resumed authentications.



The session_reused() call will tell this.

I've added logging and all resumed sessions are missing the reply
attributes we're adding with our hooks (mainly vlan id).
Does this check signal a successful resume or just the attempt to do so?


I am not sure if this has been strictly defined by the OpenSSL API. To 
be sure, I would only check this after the TLS session has been 
accepted. I'd check first that, for example, PostAuthHook result is 
ACCEPT before continuing. Radiator only does this check for TLS sessions 
that have been successfully established.



It seems the reply attributes added by the hook code for the first,
non-resumed authentication aren't stored in the EAP context.
Please advise if it is required to do that manually or if this is a bug
in 4.17.


You need to do it manually. This is why it got a special mention in the 
release history.


What you could do is to write your custom attributes in the 
resume_context when the authentication was successfully and 
session_reused() indicates it was not a resumed. See 
eap_save_resume_context in EAP.pm for an example.


The next time around when session_reused() indicates TLS did resume, you 
can once again get the resume_context like above, but now just verify 
the values are there and then use them.


When the next Radiator release is done, see the change history for the 
possible helpers that you could consider using in your hooks instead. 
One of the helpers could be the resume count I wrote about earlier.



For now I'd use the session_reused() check with the Hook.

This works, but we're not sure if it means the resumption was successful
or attempted, see above.


As I mentioned above, I would only check this if the result indicates 
authentication success.


What comes to reliably saving state information across server restarts 
and reloads, that is not currently supported. Saving the resume context 
required by Radiator is doable. SQL, Redis and similar could be used for 
this. Storing and and reloading TLS library's TLS sessions seems to be 
possible, from a quick look at the openssl docs. As a downside, doing 
this would not still help with FarmSize without more work there.


If you need to split load, maybe you could consider a front end proxy 
that uses, for example, AuthBy HASHBALANCE to forward messages to a 
number of workers where each worker is bound to its own port, as opposed 
one port with FarmSize.


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

Re: [RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

Answers below


On 2016-12-13 07:59, Heikki Vatiainen wrote:

On 1.12.2016 17.02, Hartmaier Alexander wrote:


We're fighting duplicate requests due to slow responses because of
PEAP-TLS many exchanged packets.

Is FarmSize still unusable when enabling EAP_UseState because the EAP
context data isn't shared between the forked childs?


This has not changed. EAP_UseState does not change this. Even if EAP 
context data kept by Radiator could be shared between children, 
there's still the TLS state that lives within the TLS library that can 
not be easily shared.



Can Gossip be used to share this state between the childs or the State
attribute to balance all requests of one EAP session always to the same
child?


Gossip, or some other method, could be used for sharing EAP context. 
However, the problem with TLS based EAP methods is the TLS state.



I've added this line to all PostAuthHooks and everything seems to work
as it should:

my $self = $p->{AuthBy};
my $context = $self->getEAPContext($p);


I strongly advice to get context like this:
my $context = $p->{EAPContext};
Ok, I've changed our hooks to use this again like before, seems to not 
make a difference both ways.

Can you please add this to the reference guide?



return
if Net::SSLeay::session_reused($context->{ssl});

As I currently don't log if an auth was an EAP auth or a session
resumption I can't tell if the session resumption works.


The session_reused() call will tell this.
I've added logging and all resumed sessions are missing the reply 
attributes we're adding with our hooks (mainly vlan id).

Does this check signal a successful resume or just the attempt to do so?

It seems the reply attributes added by the hook code for the first, 
non-resumed authentication aren't stored in the EAP context.
Please advise if it is required to do that manually or if this is a bug 
in 4.17.


Please note that as I wrote earlier, I'd consider EAP authentication 
that uses TLS session resumption as EAP authentication too.

Of course, just a different way.



Can you please advice how to log session resumption?


For now I'd use the session_reused() check with the Hook.
This works, but we're not sure if it means the resumption was successful 
or attempted, see above.


For help with hooks, I have thought about the following: Add a resume 
counter in EAP context. If resume support is off, the counter would 
always have undefined value. When resume support is enabled, the 
counter would be initialised to 0 and incremented for each resume. 
This would allow you to simply check 'if 
($context->{eap_tls_resume_count})' to see if a TLS resume was done.


This counter could also be used to enforce policies, for example, an 
upper for how many times (not just for how long) a session can be 
resumed. This could also be something that can be logged in 
authentication log for example for statistics.


When the resume happens and information that needs to be kept over 
resumed sessions is recovered, a hook can be added to do any local 
processing that might be required to recover custom information used 
by the current configuration. In addition to this, a user specific 
opaque value (could be a simple scalar or reference, for example) can 
be copied over by the code. The user hooks could then use this as they 
wish.


In short: we can enhance the support for storing configuration 
specific data in the resume information and can add a counter that can 
be used to detect resumption with hooks.
As far as I've understood I'd need to save and resume any additional 
data I'm adding to the EAP context, how to do that?
Is it possible to persist that through server restarts or are reloads 
the only workaround?
SystemD doesn't support reload as far as I know, can this be accomplised 
by sending a signal to the radiator process in a user friendly way?




Thanks,
Heikki


Thanks, Alex


On 2016-11-30 18:09, Hartmaier Alexander wrote:

On 2016-11-30 17:45, Heikki Vatiainen wrote:

On 30.11.2016 18.02, Hartmaier Alexander wrote:


Let me clarify our setup:
EAPTLS_CertificateVerifyHook parses the cert issuer and subject and
populates
$context->{customer} = $customer;

[cut]

Thanks, this clarifies the situation. You need to save information
across resumed authentications.


I assume that the PostAuthHook is also run for resumed sessions but
EAPTLS_CertificateVerifyHook isn't which leads to the lack of the
$context contents and thus the failure of the PostAuthHook.


Correct. Certificate verification runs only during full TLS handshake.
Handler's PostAuthHook runs always when Handler is finishing its work.
It does not matter if the TLS handshake within an AuthBy was full or
resumed.

I'll get back to you about how to save custom information across
resumed authentications. For more about what is saved now, see EAP.pm
and eap_save_resume_context and its counterpart just below. When
thinking about possible options would a hook work for you? Another
possibly might be to au

Re: [RADIATOR] random EAP authentication errors since 4.17

[Heikki Vatiainen]

On 1.12.2016 17.02, Hartmaier Alexander wrote:


We're fighting duplicate requests due to slow responses because of
PEAP-TLS many exchanged packets.

Is FarmSize still unusable when enabling EAP_UseState because the EAP
context data isn't shared between the forked childs?


This has not changed. EAP_UseState does not change this. Even if EAP 
context data kept by Radiator could be shared between children, there's 
still the TLS state that lives within the TLS library that can not be 
easily shared.



Can Gossip be used to share this state between the childs or the State
attribute to balance all requests of one EAP session always to the same
child?


Gossip, or some other method, could be used for sharing EAP context. 
However, the problem with TLS based EAP methods is the TLS state.



I've added this line to all PostAuthHooks and everything seems to work
as it should:

my $self = $p->{AuthBy};
my $context = $self->getEAPContext($p);


I strongly advice to get context like this:
my $context = $p->{EAPContext};


return
if Net::SSLeay::session_reused($context->{ssl});

As I currently don't log if an auth was an EAP auth or a session
resumption I can't tell if the session resumption works.


The session_reused() call will tell this.

Please note that as I wrote earlier, I'd consider EAP authentication 
that uses TLS session resumption as EAP authentication too.



Can you please advice how to log session resumption?


For now I'd use the session_reused() check with the Hook.

For help with hooks, I have thought about the following: Add a resume 
counter in EAP context. If resume support is off, the counter would 
always have undefined value. When resume support is enabled, the counter 
would be initialised to 0 and incremented for each resume. This would 
allow you to simply check 'if ($context->{eap_tls_resume_count})' to see 
if a TLS resume was done.


This counter could also be used to enforce policies, for example, an 
upper for how many times (not just for how long) a session can be 
resumed. This could also be something that can be logged in 
authentication log for example for statistics.


When the resume happens and information that needs to be kept over 
resumed sessions is recovered, a hook can be added to do any local 
processing that might be required to recover custom information used by 
the current configuration. In addition to this, a user specific opaque 
value (could be a simple scalar or reference, for example) can be copied 
over by the code. The user hooks could then use this as they wish.


In short: we can enhance the support for storing configuration specific 
data in the resume information and can add a counter that can be used to 
detect resumption with hooks.


Thanks,
Heikki


Thanks, Alex


On 2016-11-30 18:09, Hartmaier Alexander wrote:

On 2016-11-30 17:45, Heikki Vatiainen wrote:

On 30.11.2016 18.02, Hartmaier Alexander wrote:


Let me clarify our setup:
EAPTLS_CertificateVerifyHook parses the cert issuer and subject and
populates
$context->{customer} = $customer;

[cut]

Thanks, this clarifies the situation. You need to save information
across resumed authentications.


I assume that the PostAuthHook is also run for resumed sessions but
EAPTLS_CertificateVerifyHook isn't which leads to the lack of the
$context contents and thus the failure of the PostAuthHook.


Correct. Certificate verification runs only during full TLS handshake.
Handler's PostAuthHook runs always when Handler is finishing its work.
It does not matter if the TLS handshake within an AuthBy was full or
resumed.

I'll get back to you about how to save custom information across
resumed authentications. For more about what is saved now, see EAP.pm
and eap_save_resume_context and its counterpart just below. When
thinking about possible options would a hook work for you? Another
possibly might be to automatically save suitably named context
variables, for example $context->{custom_info} would be automatically
saved and restored.

The reason for this change was to allow the user of State attribute
with EAP authentication and more clearly separate information that is
needed during one EAP authentication dialog from information that
needs to be kept across resumed authentications.

Thanks,
Heikki


Correct me if I'm wrong but can a resumed session every be not accepted?
As it means that a successful auth has happened before.
Should a PostAuth hook, or some of the other hooks, be run at all in
this case?
It might make sense to differenciate between an authentication and a
resumption.

As the 'last_reply_attrs' are already stored in the context it might be
the easiest option to either use a different hook instead of PostAuth,
continue using PostAuth if you decide to not call PostAuth for resumed
'auths' or detect the resumption in the Hook and just bail out of it at
the very beginning.


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*

T-Systems Austria GesmbH Rennweg 97-99

Re: [RADIATOR] random EAP authentication errors since 4.17

[Heikki Vatiainen]

On 30.11.2016 19.09, Hartmaier Alexander wrote:


Correct me if I'm wrong but can a resumed session every be not accepted?


It's possible. EAP-TLS can check if the user is still available in the 
user database or has their account been, for example, removed.


PEAP requires the server and client to share a single handshake over the 
resumed TLS tunnel before the PEAP authentication is fully accepted by 
the both peers. This could be thought of one sort of authentication.


In other words, TLS resume tells that the peers can resume a previously 
created session. On the EAP and Radius layer I'd consider a TLS resumed 
EAP-TLS, PEAP, etc. just a quicker way to authenticate where some things 
were skipped since they were already done, for example inner 
authentication, certificate checks.



As it means that a successful auth has happened before.
Should a PostAuth hook, or some of the other hooks, be run at all in
this case?


I think the hooks and other processing should be called the same as with 
non-resumed authentication. There could be, for example, an AuthBy GROUP 
where PEAP authby runs first and then another authby does possibly 
authorisation. This next authby may not care if PEAP did a full or 
resumed authentication but it needs to run always.



It might make sense to differenciate between an authentication and a
resumption.


This can be made available for hooks. What you can already do is to 
check Net::SSLeay::session_reused(). More about this in another reply.



As the 'last_reply_attrs' are already stored in the context it might be
the easiest option to either use a different hook instead of PostAuth,
continue using PostAuth if you decide to not call PostAuth for resumed
'auths' or detect the resumption in the Hook and just bail out of it at
the very beginning.


Detecting resumption in a Hook could be the best option here. If the 
hook needs to behave differently, then it can do so.


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

Re: [RADIATOR] random EAP authentication errors since 4.17

[Heikki Vatiainen]

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

Re: [RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

Hi,

please respond how to:

- log auth vs. session resumption

- handle session resumption in PostAuthHooks

- if the last_reply_attrs don't include the attributes added by a 
PostAuthHook


- usability of FarmSize with PEAP-TLS when enabling EAP_UseState


Thanks, Alex


On 2016-12-01 16:02, Hartmaier Alexander wrote:

Hi,

We're fighting duplicate requests due to slow responses because of 
PEAP-TLS many exchanged packets.


Is FarmSize still unusable when enabling EAP_UseState because the EAP 
context data isn't shared between the forked childs?


Can Gossip be used to share this state between the childs or the State 
attribute to balance all requests of one EAP session always to the 
same child?



I've added this line to all PostAuthHooks and everything seems to work 
as it should:


my $self = $p->{AuthBy};
my $context = $self->getEAPContext($p);

return
if Net::SSLeay::session_reused($context->{ssl});

As I currently don't log if an auth was an EAP auth or a session 
resumption I can't tell if the session resumption works.


Can you please advice how to log session resumption?

Thanks, Alex


On 2016-11-30 18:09, Hartmaier Alexander wrote:

On 2016-11-30 17:45, Heikki Vatiainen wrote:

On 30.11.2016 18.02, Hartmaier Alexander wrote:


Let me clarify our setup:
EAPTLS_CertificateVerifyHook parses the cert issuer and subject and
populates
$context->{customer} = $customer;

[cut]

Thanks, this clarifies the situation. You need to save information
across resumed authentications.


I assume that the PostAuthHook is also run for resumed sessions but
EAPTLS_CertificateVerifyHook isn't which leads to the lack of the
$context contents and thus the failure of the PostAuthHook.


Correct. Certificate verification runs only during full TLS handshake.
Handler's PostAuthHook runs always when Handler is finishing its work.
It does not matter if the TLS handshake within an AuthBy was full or
resumed.

I'll get back to you about how to save custom information across
resumed authentications. For more about what is saved now, see EAP.pm
and eap_save_resume_context and its counterpart just below. When
thinking about possible options would a hook work for you? Another
possibly might be to automatically save suitably named context
variables, for example $context->{custom_info} would be automatically
saved and restored.

The reason for this change was to allow the user of State attribute
with EAP authentication and more clearly separate information that is
needed during one EAP authentication dialog from information that
needs to be kept across resumed authentications.

Thanks,
Heikki


Correct me if I'm wrong but can a resumed session every be not accepted?
As it means that a successful auth has happened before.
Should a PostAuth hook, or some of the other hooks, be run at all in
this case?
It might make sense to differenciate between an authentication and a
resumption.

As the 'last_reply_attrs' are already stored in the context it might be
the easiest option to either use a different hook instead of PostAuth,
continue using PostAuth if you decide to not call PostAuth for resumed
'auths' or detect the resumption in the Hook and just bail out of it at
the very beginning.


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* 


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


___
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

[Hartmaier Alexander]

Hi,

We're fighting duplicate requests due to slow responses because of 
PEAP-TLS many exchanged packets.


Is FarmSize still unusable when enabling EAP_UseState because the EAP 
context data isn't shared between the forked childs?


Can Gossip be used to share this state between the childs or the State 
attribute to balance all requests of one EAP session always to the same 
child?



I've added this line to all PostAuthHooks and everything seems to work 
as it should:


my $self = $p->{AuthBy};
my $context = $self->getEAPContext($p);

return
if Net::SSLeay::session_reused($context->{ssl});

As I currently don't log if an auth was an EAP auth or a session 
resumption I can't tell if the session resumption works.


Can you please advice how to log session resumption?

Thanks, Alex


On 2016-11-30 18:09, Hartmaier Alexander wrote:

On 2016-11-30 17:45, Heikki Vatiainen wrote:

On 30.11.2016 18.02, Hartmaier Alexander wrote:


Let me clarify our setup:
EAPTLS_CertificateVerifyHook parses the cert issuer and subject and
populates
$context->{customer} = $customer;

[cut]

Thanks, this clarifies the situation. You need to save information
across resumed authentications.


I assume that the PostAuthHook is also run for resumed sessions but
EAPTLS_CertificateVerifyHook isn't which leads to the lack of the
$context contents and thus the failure of the PostAuthHook.


Correct. Certificate verification runs only during full TLS handshake.
Handler's PostAuthHook runs always when Handler is finishing its work.
It does not matter if the TLS handshake within an AuthBy was full or
resumed.

I'll get back to you about how to save custom information across
resumed authentications. For more about what is saved now, see EAP.pm
and eap_save_resume_context and its counterpart just below. When
thinking about possible options would a hook work for you? Another
possibly might be to automatically save suitably named context
variables, for example $context->{custom_info} would be automatically
saved and restored.

The reason for this change was to allow the user of State attribute
with EAP authentication and more clearly separate information that is
needed during one EAP authentication dialog from information that
needs to be kept across resumed authentications.

Thanks,
Heikki


Correct me if I'm wrong but can a resumed session every be not accepted?
As it means that a successful auth has happened before.
Should a PostAuth hook, or some of the other hooks, be run at all in
this case?
It might make sense to differenciate between an authentication and a
resumption.

As the 'last_reply_attrs' are already stored in the context it might be
the easiest option to either use a different hook instead of PostAuth,
continue using PostAuth if you decide to not call PostAuth for resumed
'auths' or detect the resumption in the Hook and just bail out of it at
the very beginning.


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* 


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

[Heikki Vatiainen]

On 30.11.2016 16.34, Petr Adamec wrote:


I have probably the same problem. It sounds like

https://lists.open.com.au/pipermail/radiator/2015-August/020360.html

My solution is to downgrade to 4.16


Hello Petr,

can you see if 'EAPTLS_SessionContextId %u%1' parameter I wrote about 
yesterday would help with the errors you see? If you can do that, please 
let us know if it helps.


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

Re: [RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

On 2016-11-30 17:45, Heikki Vatiainen wrote:

On 30.11.2016 18.02, Hartmaier Alexander wrote:


Let me clarify our setup:
EAPTLS_CertificateVerifyHook parses the cert issuer and subject and
populates
$context->{customer} = $customer;

[cut]

Thanks, this clarifies the situation. You need to save information
across resumed authentications.


I assume that the PostAuthHook is also run for resumed sessions but
EAPTLS_CertificateVerifyHook isn't which leads to the lack of the
$context contents and thus the failure of the PostAuthHook.


Correct. Certificate verification runs only during full TLS handshake.
Handler's PostAuthHook runs always when Handler is finishing its work.
It does not matter if the TLS handshake within an AuthBy was full or
resumed.

I'll get back to you about how to save custom information across
resumed authentications. For more about what is saved now, see EAP.pm
and eap_save_resume_context and its counterpart just below. When
thinking about possible options would a hook work for you? Another
possibly might be to automatically save suitably named context
variables, for example $context->{custom_info} would be automatically
saved and restored.

The reason for this change was to allow the user of State attribute
with EAP authentication and more clearly separate information that is
needed during one EAP authentication dialog from information that
needs to be kept across resumed authentications.

Thanks,
Heikki


Correct me if I'm wrong but can a resumed session every be not accepted?
As it means that a successful auth has happened before.
Should a PostAuth hook, or some of the other hooks, be run at all in
this case?
It might make sense to differenciate between an authentication and a
resumption.

As the 'last_reply_attrs' are already stored in the context it might be
the easiest option to either use a different hook instead of PostAuth,
continue using PostAuth if you decide to not call PostAuth for resumed
'auths' or detect the resumption in the Hook and just bail out of it at
the very beginning.


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
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

[Heikki Vatiainen]

On 30.11.2016 18.02, Hartmaier Alexander wrote:


Let me clarify our setup:
EAPTLS_CertificateVerifyHook parses the cert issuer and subject and
populates
$context->{customer} = $customer;

[cut]

Thanks, this clarifies the situation. You need to save information 
across resumed authentications.



I assume that the PostAuthHook is also run for resumed sessions but
EAPTLS_CertificateVerifyHook isn't which leads to the lack of the
$context contents and thus the failure of the PostAuthHook.


Correct. Certificate verification runs only during full TLS handshake. 
Handler's PostAuthHook runs always when Handler is finishing its work. 
It does not matter if the TLS handshake within an AuthBy was full or 
resumed.


I'll get back to you about how to save custom information across resumed 
authentications. For more about what is saved now, see EAP.pm and 
eap_save_resume_context and its counterpart just below. When thinking 
about possible options would a hook work for you? Another possibly might 
be to automatically save suitably named context variables, for example 
$context->{custom_info} would be automatically saved and restored.


The reason for this change was to allow the user of State attribute with 
EAP authentication and more clearly separate information that is needed 
during one EAP authentication dialog from information that needs to be 
kept across resumed authentications.


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

Re: [RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

On 2016-11-30 16:35, Heikki Vatiainen wrote:

On 30.11.2016 17.21, Hartmaier Alexander wrote:


we only do machine cert authentication. Can I log the SessionContextId
for debugging purposes to really make sure it's not the issue?


This defaults to Handler. In other words, if a full authentication was
processed by Handler A, the resumption will only work with Handler A.
If Handler B is selected, full authentication is done. If this
happens, it is not an error but a normal full authentication.

I do understand the inner workings, thanks.



This also happens for smartphones, mainly Apple and Android.


Do you have log messages about errors?

Let me clarify our setup:
EAPTLS_CertificateVerifyHook parses the cert issuer and subject and
populates
$context->{customer} = $customer;
$context->{ca_name} = $ca_name;
$context->{cert_usage} = $cert_usage;
$context->{cert_subject} = $subject; # for logging only
$context->{cert_issuer} = $cert_issuer; # for loggin only

PostAuthHooks use $context->{customer} and $context->{cert_usage} to
allow/deny wired/wireless access assign VLAN ID/restrict SSIDs.
The error messages that started getting logged after the 4.17 update are
our custom reject reasons:
$$reason = "certificate usage '$cert_usage' not for DIRECT, subject: "
.  $context->{cert_subject} . ", issuer: " . $context->{cert_issuer};


I wonder if the reduced EAPContextTimeout from 1000 to 120 seconds might
cause this when roaming from access-point to access-point?


This should only matter when it takes more than 120 seconds for the
client to respond after Radiator sends RADIUS Access-Challenge to get
the client to continue the ongoing EAP authentication. Once the
authentication has finished, this context is not required any longer.

The information required for resume is kept longer. See
EAPTLS_SessionResumptionLimit that defaults of 12 hours.

https://www.open.com.au/radiator/ref/EAPTLS_SessionResumptionLimit.html

I assume that the PostAuthHook is also run for resumed sessions but
EAPTLS_CertificateVerifyHook isn't which leads to the lack of the
$context contents and thus the failure of the PostAuthHook.


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

[Heikki Vatiainen]

On 30.11.2016 17.21, Hartmaier Alexander wrote:


we only do machine cert authentication. Can I log the SessionContextId
for debugging purposes to really make sure it's not the issue?


This defaults to Handler. In other words, if a full authentication was 
processed by Handler A, the resumption will only work with Handler A. If 
Handler B is selected, full authentication is done. If this happens, it 
is not an error but a normal full authentication.



This also happens for smartphones, mainly Apple and Android.


Do you have log messages about errors?


I wonder if the reduced EAPContextTimeout from 1000 to 120 seconds might
cause this when roaming from access-point to access-point?


This should only matter when it takes more than 120 seconds for the 
client to respond after Radiator sends RADIUS Access-Challenge to get 
the client to continue the ongoing EAP authentication. Once the 
authentication has finished, this context is not required any longer.


The information required for resume is kept longer. See 
EAPTLS_SessionResumptionLimit that defaults of 12 hours.


https://www.open.com.au/radiator/ref/EAPTLS_SessionResumptionLimit.html

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

Re: [RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

Hi Heikki,

we only do machine cert authentication. Can I log the SessionContextId
for debugging purposes to really make sure it's not the issue?

This also happens for smartphones, mainly Apple and Android.

I wonder if the reduced EAPContextTimeout from 1000 to 120 seconds might
cause this when roaming from access-point to access-point?

Best regards, Alex


On 2016-11-30 16:12, Heikki Vatiainen wrote:

On 30.11.2016 16.27, Hartmaier Alexander wrote:


we have random EAP authentication errors since the upgrade to 4.17.
I figured it might have something to do with the EAP session resumption
changes in 4.17.


For tweaking resumption behaviour, can you try adding the parameter
shown below to EAPTLS_ settings?

I have been looking at this, and my suspicion is that when Windows has
been configured to try both machine and username authentication, it
uses the same TLS session for the both. This may cause confusion for
it when a session resumption succeeds as machine while the session was
first successful for username authentication. What Radiator sees is a
successful resumption and proceeds as usually.

In 4.17 you can further restrict the context for which the resumption
is considered. So please add the original username to the context to
use host/ prefix for creating a separate context for machine vs
username authentication.

EAPTLS_SessionContextId %u%1

The above adds original User-Name to the resumption context which will
create separate resumption context when the username changes.

This parameter goes to AuthBy that handles the outer EAP
authentication (certicates, etc.).

For more:
https://open.com.au/radiator/ref/EAPTLS_SessionContextId_AuthByxx.html


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

[Hartmaier Alexander]

Hi Petr,

not sure was the problem only started after upgrading to 4.17 which 
hasn't been release in 2015 when you reported your issue.


Best regards, Alex


On 2016-11-30 15:34, Petr Adamec wrote:

Hi,

I have probably the same problem. It sounds like

https://lists.open.com.au/pipermail/radiator/2015-August/020360.html

My solution is to downgrade to 4.16

Best regards

Petr Adamec

Dne 30.11.2016 v 15:27 Hartmaier Alexander napsal(a):

Hi,
we have random EAP authentication errors since the upgrade to 4.17.
I figured it might have something to do with the EAP session resumption
changes in 4.17.

The release notes only mentions to look at EAP.pm regarding required
hook code changes. I guess one should now use $self->getEAPContext($p)
instead of $p->{EAPContext} directly.

The problem is that $self isn't passed to any hook!

I couldn't find an example in the goodies either.

Please advice how to resolve this.

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


___
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

[Heikki Vatiainen]

On 30.11.2016 16.27, Hartmaier Alexander wrote:


we have random EAP authentication errors since the upgrade to 4.17.
I figured it might have something to do with the EAP session resumption
changes in 4.17.


For tweaking resumption behaviour, can you try adding the parameter 
shown below to EAPTLS_ settings?


I have been looking at this, and my suspicion is that when Windows has 
been configured to try both machine and username authentication, it uses 
the same TLS session for the both. This may cause confusion for it when 
a session resumption succeeds as machine while the session was first 
successful for username authentication. What Radiator sees is a 
successful resumption and proceeds as usually.


In 4.17 you can further restrict the context for which the resumption is 
considered. So please add the original username to the context to use 
host/ prefix for creating a separate context for machine vs username 
authentication.


EAPTLS_SessionContextId %u%1

The above adds original User-Name to the resumption context which will 
create separate resumption context when the username changes.


This parameter goes to AuthBy that handles the outer EAP authentication 
(certicates, etc.).


For more:
https://open.com.au/radiator/ref/EAPTLS_SessionContextId_AuthByxx.html

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

Re: [RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

Hi,

thanks for the quick response!

In the meantime I tried the new EAP_UseState,  didn't fix the problem
but also didn't have any negative effect. Do you recommend to already
use it?

Disabling EAP session resumption seems to have fixed the issue
(EAPTLS_SessionResumption 0).


On 2016-11-30 15:38, Tuure Vartiainen wrote:

Hello,


On 30 Nov 2016, at 16:27, Hartmaier Alexander 
 wrote:

we have random EAP authentication errors since the upgrade to 4.17.
I figured it might have something to do with the EAP session resumption
changes in 4.17.


interesting, could you please send a trace 5 debug log for few authentication
errors?

I would have to force the errors again by reenabling EAP session
resumption which I'd rather like not to do.



The release notes only mentions to look at EAP.pm regarding required
hook code changes. I guess one should now use $self->getEAPContext($p)
instead of $p->{EAPContext} directly.

The problem is that $self isn't passed to any hook!

I couldn't find an example in the goodies either.

Please advice how to resolve this.


you can call it

$p->{AuthBy}->getEAPContext($p)

but the function is only available when processing $p which has EAP-Message AVP.

So it should be safe to use it in EAP specific hooks like
EAPTLS_CertificateVerifyHook and PostAuthHook in Handler that check for
TunnelledByPEAP=1?

I've changed:

my $context =  $p->{EAPContext};

to:

my $self = $p->{AuthBy};
my $context = ($main::config->{EAP_UseState})
? $self->getEAPContextState($p, $code, $type)
: $self->getEAPContext($p);

as seen in EAP.pm. Should I always call getEAPContext instead? If the
above is required I'd advice to add a method doing that to EAP.pm.
The problem with getEAPContextState is that I don't have $code and $type
in my hook.




BR

Best regards, 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

[Tuure Vartiainen]

Hello,

> On 30 Nov 2016, at 16:27, Hartmaier Alexander 
>  wrote:
> 
> we have random EAP authentication errors since the upgrade to 4.17.
> I figured it might have something to do with the EAP session resumption
> changes in 4.17.
> 

interesting, could you please send a trace 5 debug log for few authentication 
errors?

> The release notes only mentions to look at EAP.pm regarding required
> hook code changes. I guess one should now use $self->getEAPContext($p)
> instead of $p->{EAPContext} directly.
> 
> The problem is that $self isn't passed to any hook!
> 
> I couldn't find an example in the goodies either.
> 
> Please advice how to resolve this.
> 

you can call it

$p->{AuthBy}->getEAPContext($p)

but the function is only available when processing $p which has EAP-Message AVP.


BR
-- 
Tuure Vartiainen 

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

[Petr Adamec]

Hi,

I have probably the same problem. It sounds like

https://lists.open.com.au/pipermail/radiator/2015-August/020360.html

My solution is to downgrade to 4.16

Best regards

Petr Adamec

Dne 30.11.2016 v 15:27 Hartmaier Alexander napsal(a):
> Hi,
> we have random EAP authentication errors since the upgrade to 4.17.
> I figured it might have something to do with the EAP session resumption
> changes in 4.17.
> 
> The release notes only mentions to look at EAP.pm regarding required
> hook code changes. I guess one should now use $self->getEAPContext($p)
> instead of $p->{EAPContext} directly.
> 
> The problem is that $self isn't passed to any hook!
> 
> I couldn't find an example in the goodies either.
> 
> Please advice how to resolve this.
> 
> 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

___
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator

[RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

Hi,
we have random EAP authentication errors since the upgrade to 4.17.
I figured it might have something to do with the EAP session resumption
changes in 4.17.

The release notes only mentions to look at EAP.pm regarding required
hook code changes. I guess one should now use $self->getEAPContext($p)
instead of $p->{EAPContext} directly.

The problem is that $self isn't passed to any hook!

I couldn't find an example in the goodies either.

Please advice how to resolve this.

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