802.1x authentication interval

  • 1
  • Question
  • Updated 3 years ago
We have class sets of iOS devices connected to a 802.1x SSID which uses Windows NPS server to authenticate the users.   The NPS authentication event gets passed through to our Web Proxy server to transparently authenticate the device.  

The problem is that the iOS devices dont leave the classroom, and so they seem to just sit there happily on the SSID all day and night and dont re-authenticate, and therefore our web proxy server session times out because it doesnt see a new NPS authentication event come through (the web session times out after 8 hours).

Is there a configuration which will make the device automatically re-auth after a certain period?    Currently the user will need to turn off their wifi and back on again so we can capture the Radius event.

Thanks in anticipation!
Chris
Photo of Chris

Chris

  • 4 Posts
  • 0 Reply Likes

Posted 3 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Chris,

You need to return two RADIUS attributes to get periodic re-authentication going.

These are the Session-Timeout and Termination-Action RADIUS attributes.

This is standards based behaviour for RADIUS with 802.1X and is defined in RFC 3580.

https://tools.ietf.org/html/rfc3580#section-3.17

Session-Timeout
   When sent along in an Access-Accept without a Termination-Action attribute or with a Termination-Action attribute set to Default, the Session-Timeout attribute specifies the maximum number of seconds of service provided prior to session termination.

   When sent in an Access-Accept along with a Termination-Action value of RADIUS-Request, the Session-Timeout attribute specifies the maximum number of seconds of service provided prior to re-authentication.  In this case, the Session-Timeout attribute is used to load the reAuthPeriod constant within the Reauthentication Timer state machine of 802.1X.  When sent with a Termination-Action value of RADIUS-Request, a Session-Timeout value of zero indicates the desire to perform another authentication (possibly of a different type) immediately after the first authentication has successfully completed.

   When sent in an Access-Challenge, this attribute represents the maximum number of seconds that an IEEE 802.1X Authenticator should wait for an EAP-Response before retransmitting.  In this case, the Session-Timeout attribute is used to load the suppTimeout constant within the backend state machine of IEEE 802.1X.

https://tools.ietf.org/html/rfc3580#section-3.19

Termination-Action
   This attribute indicates what action should be taken when the service is completed.  The value RADIUS-Request (1) indicates that re-authentication should occur on expiration of the Session-Time.  

For NPS, you configure these under the Constraints tab for the Session-Timeout and the Termination-Action under the Settings tab, Standard RADIUS Attributes:





It should be said that if your SSO integration worked properly, it would use RADIUS accounting information correctly so that this would be not be necessary. What you are doing is a potential workaround for a broken implementation. It may end up not working because of the reasons below. Who has suggested doing this?

Be mindful that you should not expect to see a Stop for the existing session and a subsequent Start when 802.1X re-authentication completes, just periodic Interim-Updates on the interval configured.

(Conversely, the only expectation here should be that you will see auth taking place again to the RADIUS server when re-authentication occurs. It is a separate, unrelated concern to accounting for the connection that stays up during the process.)

The Class attribute should be expected to change as the RADIUS server is likely to generate a new one and include this in the Access-Accept. You cannot track based on this attribute reliably therefore.

The Acct-Session-Id will remain constant, assuming that you do not observe a Stop and a Start when re-authentication occurs. This, however, is not constant across roams from one BSS to another so this cannot be used reliably.

A well designed SSO system will, therefore, track the session based on the Acct-Multi-Session-Id in RADIUS accounting information where one is sent by an AP.

For more information on this attribute, see:

https://tools.ietf.org/html/rfc3580#section-2.2

Conceptually:
  • Binding from Auth to Accounting is possible based on the Class attribute sent by the RADIUS server in the Access-Accept that kicks off the client's connection. (A system that integrates at the point of EAP termination can pierce anonymous EAP identity privacy.)
  • When accounting starts, the Acct-Session-Id and Acct-Multi-Session-Id becomes known as the Start will contain these as well as the Class attribute.
  • Based on Start, Interim-Update and Stop forms of Accounting-Request packets received, a SSO integration knows the duration of the client's connection. The client's DHCP-snooped IPv4 address is ascertained via the Framed-IP-Address attribute or a DHCP lease database is queried for the client's MAC address, contained in the Calling-Station-Id. (There's also Accounting-On and Accounting-Off on a per-NAS or per-BSS basis used to terminate all existing dependent sessions.)
To further complicate matters, there are some unresolved issues in HiveOS 6.6r1 that pertain to RADIUS-based session tracking. These are:

1) Acct-Multi-Session-Ids occasionally being missing from Accounting-Request packets that HiveOS sends. (There's a CFD open on this due to its breaking nature when it occurs and roaming from one BSS to another happens.)

2) Acct-Session-Ids not being constructed in a way that is guaranteed to be globally unique by HiveOS.
(There is a bug open on this.)

3) Acct-Multi-Session-Ids occasionally being constructed containing whitespace by HiveOS. Although technically allowed by the spec, this can trip up some systems that expect a UTF-8 encoded string without it containing whitespace.
(There is a bug open on this.)

Hope this helps! I suspect that you may also have to go back to the vendor responsible for your Web proxy and get them to fix bugs/design deficiencies their side. There is a lot of devil in the detail complexity here and it takes two to tango.

Happy to answer any questions! :)

Regards,

Nick
(Edited)
Photo of Chris

Chris

  • 4 Posts
  • 0 Reply Likes
Thank you Nick for your very helpful response.  I am going to do just that and go back to the vendor to ensure we have this design right.  I will let you know how it goes! :)

Many thanks
Chris
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I should mention that you could just return a Session-Timeout which will disassociate the client after the time elapses, or also with a Termination-Action of Default. This has the potential to tangibly disrupt service to an interactive user though. You would be relying on the client then attempting to associate again and in a timely manner - it is not akin to re-authentication. This will, however, definitely give you a Stop for the old and a Start for the new.

Personally, I would talk to your vendor to see how exactly they are session/connection tracking. Perhaps even point them to this thread...
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Chris,

No problem.

The other thing that I ought to mention, more complexity, is that HiveOS is documented as sending a Stop for the old session before a Start for the new session that is created when a roam occurs. (This is perfectly reasonable behaviour and is in line with what the RFC expects/requires: A new session is created when a roaming event occurs but the RFC doesn't specify the order that is expected and we should expect out-of-order receipt anyway.) 

This means that an SSO implementation that integrates with RADIUS must defer acting upon a Stop where there is an Acct-Multi-Session-Id present (dynamically generated, constant across sessions that share the same EAP authentication) for around 10 seconds to handle the case where a new session is started with the same Acct-Multi-Session-Id. 

The implication is that a SSO implementation must maintain an appropriate state table to know about related sessions that share an Acct-Multi-Session-Id to be correctly implemented.

The key point to take away from this is that a client's connection is conceptually constituted from a RADIUS accounting perspective of related sessions via the Acct-Multi-Session-Id. You may end up having one session only, but it should never be expected.

Slight slip, I should have therefore written above:

A well designed SSO system will, therefore, track the session connection over its constituent sessions based on the Acct-Multi-Session-Id in RADIUS accounting information where this attribute is sent by an AP.

Cheers,

Nick
(Edited)