Wireless Lan Controllers/Cisco Secure ACS-EAP-TLS Session Resumption t'out

Unanswered Question
Jul 1st, 2009

Hi Guys,

With WLCs and ACSs there is the concept of session timeouts, where a use has to re-auth when useing eap-tls.

What is the default EAP-TLS resumption timeout and is this server or client specific?

Pls see:


section 2.1.2

2.1.2. Session Resumption

The purpose of the sessionId within the TLS protocol is to allow for

improved efficiency in the case where a peer repeatedly attempts to

authenticate to an EAP server within a short period of time. While

this model was developed for use with HTTP authentication, it also

can be used to provide "fast reconnect" functionality as defined in

Section 7.2.1 of [RFC3748].

It is left up to the peer whether to attempt to continue a previous

session, thus shortening the TLS conversation. Typically, the peer's

decision will be made based on the time elapsed since the previous

authentication attempt to that EAP server. Based on the sessionId

chosen by the peer, and the time elapsed since the previous

authentication, the EAP server will decide whether to allow the

continuation or to choose a new session.

In the case where the EAP server and authenticator reside on the same

device, the peer will only be able to continue sessions when

connecting to the same authenticator. Should the authenticators be

set up in a rotary or round-robin, then it may not be possible for

the peer to know in advance the authenticator to which it will be

connecting, and therefore which sessionId to attempt to reuse. As a

result, it is likely that the continuation attempt will fail. In the

case where the EAP authentication is remoted, then continuation is

much more likely to be successful, since multiple authenticators will

utilize the same backend authentication server.

If the EAP server is resuming a previously established session, then

it MUST include only a TLS change_cipher_spec message and a TLS

finished handshake message after the server_hello message. The

finished message contains the EAP server's authentication response to

the peer.

In the case where a previously established session is being resumed,

and both sides authenticate successfully, the conversation will

appear as follows:

Authenticating Peer Authenticator

------------------- -------------

<- EAP-Request/



Identity (MyID) ->

<- EAP-Request/



(TLS Start)



(TLS client_hello)->

<- EAP-Request/


(TLS server_hello,

TLS change_cipher_spec

TLS finished)



(TLS change_cipher_spec,

TLS finished) ->

<- EAP-Success

Many thx guys,


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
htarra Tue, 07/07/2009 - 08:11

I think the default EAP-TLS session timeout is zero sec. Enter the maximum number of seconds you want the client to remain connected to the network access device before having to reauthenticate in the Session TImeout field. If you enter a number greater than 0, the lesser of this value and the remaining resumption limit is sent in a Session-Limit attribute to the RADIUS client on the RADIUS Access-Accept response.

If you enter 0, a Session-Limit attribute is not generated directly. A 0 does not prevent the authentication methods that perform secondary authorization from providing a value.

Entering a value such as 600 (10 minutes) does not necessarily cause a full reauthentication to occur every 10 minutes. You can configure the resumption limit to make most reauthentications fast and computationally efficient.


This Discussion