Access-challenge timeout on IOS
Hi, I'm experimenting with a system involving an access-challenge to a NAS. It works fine with FR so far on, say, the cisco ipsec vpn client, which waits a long time until timing out waiting for user input. I'd like to also discover how other NAS's behave using this and have found the timeout on a particular cisco 1131 access point to be quite short. Does anyone know if there's a radius attribute I can send that will extend this timeout, or an internal setting that will change the default on the ap? Session-timeout and Idle-timeout are attributes mentioned by the cisco docs but neither of these seem to be what I'm after. Thanks Andy
On 04/07/13 11:00, Franks Andy (RLZ) IT Systems Engineer wrote:
Hi,
I’m experimenting with a system involving an access-challenge to a NAS. It works fine with FR so far on, say, the cisco ipsec vpn client, which waits a long time until timing out waiting for user input. I’d like to also discoverhowother NAS’s behave using this and have found the timeout on a particular cisco 1131 access point to be quite short.
Does anyone know if there’s a radius attribute I can send that will
Not as far as I know.
extend this timeout, or an internal setting that will change the default on the ap?
Maybe. This usually depends on link-layer timers, e.g. EAPOL timeouts, IPSec/IKE timeouts, etc. rather than anything radius-related.
Session-timeout and Idle-timeout are attributes mentioned by the cisco docs but neither of these seem to be what I’m after.
Neither are relevant; they're for established sessions, not timeouts in *establishing* one.
Quoting Phil Mayers <p.mayers@imperial.ac.uk>:
On 04/07/13 11:00, Franks Andy (RLZ) IT Systems Engineer wrote:
Hi, ....
Session-timeout and Idle-timeout are attributes mentioned by the cisco docs but neither of these seem to be what I'm after.
Neither are relevant; they're for established sessions, not timeouts in *establishing* one. - Actually, that is incorrect Session-Timeout _is_ used to control the authentication timeout, when in the initial AccReq. I'd quote the RFC, but I'm not at home. The *-Timeouts in the Acc-Accept control the session.
Some models/versions of Cisco APs cause me no end of grief getting timeouts long enough for users to enter their RSA token values. They use it to abort the session, when they should just retry. Dave.
On 04/07/13 14:34, David Mitton wrote:
Quoting Phil Mayers <p.mayers@imperial.ac.uk>:
On 04/07/13 11:00, Franks Andy (RLZ) IT Systems Engineer wrote:
Hi, ....
Session-timeout and Idle-timeout are attributes mentioned by the cisco docs but neither of these seem to be what I'm after.
Neither are relevant; they're for established sessions, not timeouts in *establishing* one. - Actually, that is incorrect Session-Timeout _is_ used to control the authentication timeout, when in the initial AccReq. I'd quote the RFC, but I'm not at home. The *-Timeouts in the Acc-Accept control the session.
Hmm, so it does; 5.27 of 2865 and 2.3.2 of 2869. However - does any equipment actually *honour* this? Also, I note the wording is very loose indeed - no MUST.
Oh for sure... I used Cisco 1200s @ RSA and the Windows EAP interfaces I was always fighting with the system timing out the authentication before a user would time in a token code. This frequently takes a minute or more, because people have to get their token, often they wait for the code to change, so they have a minute to read it, then type it in... On Windows 7, we had more problems, so I decided to explore some not well understood options of the EAP interface. Their was on option that supposed to take 60 seconds (so their Tech support told me) I tried it. It failed so quickly my head was spinning. I got out Wireshark and traced the protocol. When this option was selected, the MS EAP/RADIUS client sent an Session-Timeout value of 6! That AP killed the session faster than you could type a character. Removing the option, the value Windows sends is 60. If you google hard you will find that some versions of Cisco APs have a command line option to ignore the attribute and allow you to specify your own value. Mine honored the command, but did not have it in the Management GUI. I believe the "new" Windows EAPhost API now allows the EAP developer to set this value. But there are other 1 minute timers hardwired into the Windows EAP interface that I had to work around. Dave. Quoting Phil Mayers <p.mayers@imperial.ac.uk>:
On 04/07/13 14:34, David Mitton wrote:
Quoting Phil Mayers <p.mayers@imperial.ac.uk>:
On 04/07/13 11:00, Franks Andy (RLZ) IT Systems Engineer wrote:
Hi, ....
Session-timeout and Idle-timeout are attributes mentioned by the cisco docs but neither of these seem to be what I'm after.
Neither are relevant; they're for established sessions, not timeouts in *establishing* one. - Actually, that is incorrect Session-Timeout _is_ used to control the authentication timeout, when in the initial AccReq. I'd quote the RFC, but I'm not at home. The *-Timeouts in the Acc-Accept control the session.
Hmm, so it does; 5.27 of 2865 and 2.3.2 of 2869.
However - does any equipment actually *honour* this? Also, I note the wording is very loose indeed - no MUST. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 4 Jul 2013, at 22:32, David Mitton <david@mitton.com> wrote:
Oh for sure... I used Cisco 1200s @ RSA and the Windows EAP interfaces
I was always fighting with the system timing out the authentication before a user would time in a token code. This frequently takes a minute or more, because people have to get their token, often they wait for the code to change, so they have a minute to read it, then type it in...
On Windows 7, we had more problems, so I decided to explore some not well understood options of the EAP interface. Their was on option that supposed to take 60 seconds (so their Tech support told me) I tried it.
It failed so quickly my head was spinning. I got out Wireshark and traced the protocol. When this option was selected, the MS EAP/RADIUS client sent an Session-Timeout value of 6! That AP killed the session faster than you could type a character. Removing the option, the value Windows sends is 60.
If you google hard you will find that some versions of Cisco APs have a command line option to ignore the attribute and allow you to specify your own value. Mine honored the command, but did not have it in the Management GUI.
I believe the "new" Windows EAPhost API now allows the EAP developer to set this value. But there are other 1 minute timers hardwired into the Windows EAP interface that I had to work around.
Lower levels will time out authentication way before you hit the one minute mark. 15 seconds is the default on most NAS, and then you'll have to tune FreeRADIUS so it doesn't clear out it's EAP session cache. Just don't use this stuff for 802.1X. Web portals fine, email fine, just not anything to do with EAP, it won't work well. Most devices have support for client certificates, use those instead, they're just as easy to revoke as tokens, and you'll piss the end user off a hell of a lot less. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Hi,
waits a long time until timing out waiting for user input. I'd like to also discover how other NAS's behave using this and have found the timeout on a particular cisco 1131 access point to be quite short.
most NAS devices have configurable options for their RADIUS/EAP timers. note that you will need to adjust RADIUS server too - as the server also has its own timeout/clear-up timers
Session-timeout and Idle-timeout are attributes mentioned by the cisco docs but neither of these seem to be what I'm after.
they control the end clients, not the RADIUS clients (the NAS) alan
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Arran Cudbard-Bell -
David Mitton -
Franks Andy (RLZ) IT Systems Engineer -
Phil Mayers