07-01-2009 10:03 AM - edited 03-10-2019 04:34 PM
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:
http://www.faqs.org/rfcs/rfc5216.html
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
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS change_cipher_spec
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished) ->
<- EAP-Success
Many thx guys,
Ken
07-07-2009 08:11 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide