Access-challenge timeout on IOS

2013-07-04 Thread Franks Andy (RLZ) IT Systems Engineer
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Access-challenge timeout on IOS

2013-07-04 Thread Phil Mayers

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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Access-challenge timeout on IOS

2013-07-04 Thread A . L . M . Buxey
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Access-challenge timeout on IOS

2013-07-04 Thread David Mitton

Quoting Phil Mayers p.may...@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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Access-challenge timeout on IOS

2013-07-04 Thread Phil Mayers

On 04/07/13 14:34, David Mitton wrote:

Quoting Phil Mayers p.may...@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


RE: Access-challenge timeout on IOS

2013-07-04 Thread Franks Andy (RLZ) IT Systems Engineer
I'll give it a go. Thanks for the information guys. The cisco attribute
list says
Session-Timeout : Sets the maximum number of seconds of service to be
provided to the user before the session terminates. This attribute value
becomes the per-user absolute timeout.
Not that helpful, and why I discarded it as an option which might be
useful. Let's see..
Thanks
andy

-Original Message-
From:
freeradius-users-bounces+andy.franks=sath.nhs...@lists.freeradius.org
[mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk@lists.freeradiu
s.org] On Behalf Of Phil Mayers
Sent: 04 July 2013 15:28
To: freeradius-users@lists.freeradius.org
Subject: Re: Access-challenge timeout on IOS

On 04/07/13 14:34, David Mitton wrote:
 Quoting Phil Mayers p.may...@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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Access-challenge timeout on IOS

2013-07-04 Thread David Mitton

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.may...@imperial.ac.uk:


On 04/07/13 14:34, David Mitton wrote:

Quoting Phil Mayers p.may...@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


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Access-challenge timeout on IOS

2013-07-04 Thread Arran Cudbard-Bell

On 4 Jul 2013, at 22:32, David Mitton da...@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.cudba...@freeradius.org
FreeRADIUS Development Team

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html