<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Wireless Lan Controllers/Cisco Secure ACS-EAP-TLS Session Re in Network Access Control</title>
    <link>https://community.cisco.com/t5/network-access-control/wireless-lan-controllers-cisco-secure-acs-eap-tls-session/m-p/1267275#M343718</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;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. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Tue, 07 Jul 2009 15:11:07 GMT</pubDate>
    <dc:creator>htarra</dc:creator>
    <dc:date>2009-07-07T15:11:07Z</dc:date>
    <item>
      <title>Wireless Lan Controllers/Cisco Secure ACS-EAP-TLS Session Resumption t'out</title>
      <link>https://community.cisco.com/t5/network-access-control/wireless-lan-controllers-cisco-secure-acs-eap-tls-session/m-p/1267274#M343638</link>
      <description>&lt;P&gt;Hi Guys,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;With WLCs and ACSs there is the concept of session timeouts, where a use has to re-auth when useing eap-tls.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;What is the default EAP-TLS resumption timeout and is this server or client specific?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Pls see:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A class="jive-link-custom" href="http://www.faqs.org/rfcs/rfc5216.html" target="_blank"&gt;http://www.faqs.org/rfcs/rfc5216.html&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;section 2.1.2&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;2.1.2.  Session Resumption&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;   The purpose of the sessionId within the TLS protocol is to allow for&lt;/P&gt;&lt;P&gt;   improved efficiency in the case where a peer repeatedly attempts to&lt;/P&gt;&lt;P&gt;   authenticate to an EAP server within a short period of time.  While&lt;/P&gt;&lt;P&gt;   this model was developed for use with HTTP authentication, it also&lt;/P&gt;&lt;P&gt;   can be used to provide "fast reconnect" functionality as defined in&lt;/P&gt;&lt;P&gt;   Section 7.2.1 of [RFC3748].&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;   It is left up to the peer whether to attempt to continue a previous&lt;/P&gt;&lt;P&gt;   session, thus shortening the TLS conversation.  Typically, the peer's&lt;/P&gt;&lt;P&gt;   decision will be made based on the time elapsed since the previous&lt;/P&gt;&lt;P&gt;   authentication attempt to that EAP server.  Based on the sessionId&lt;/P&gt;&lt;P&gt;   chosen by the peer, and the time elapsed since the previous&lt;/P&gt;&lt;P&gt;   authentication, the EAP server will decide whether to allow the&lt;/P&gt;&lt;P&gt;   continuation or to choose a new session.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;   In the case where the EAP server and authenticator reside on the same&lt;/P&gt;&lt;P&gt;   device, the peer will only be able to continue sessions when&lt;/P&gt;&lt;P&gt;   connecting to the same authenticator.  Should the authenticators be&lt;/P&gt;&lt;P&gt;   set up in a rotary or round-robin, then it may not be possible for&lt;/P&gt;&lt;P&gt;   the peer to know in advance the authenticator to which it will be&lt;/P&gt;&lt;P&gt;   connecting, and therefore which sessionId to attempt to reuse.  As a&lt;/P&gt;&lt;P&gt;   result, it is likely that the continuation attempt will fail.  In the&lt;/P&gt;&lt;P&gt;   case where the EAP authentication is remoted, then continuation is&lt;/P&gt;&lt;P&gt;   much more likely to be successful, since multiple authenticators will&lt;/P&gt;&lt;P&gt;   utilize the same backend authentication server.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;   If the EAP server is resuming a previously established session, then&lt;/P&gt;&lt;P&gt;   it MUST include only a TLS change_cipher_spec message and a TLS&lt;/P&gt;&lt;P&gt;   finished handshake message after the server_hello message.  The&lt;/P&gt;&lt;P&gt;   finished message contains the EAP server's authentication response to&lt;/P&gt;&lt;P&gt;   the peer.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;   In the case where a previously established session is being resumed,&lt;/P&gt;&lt;P&gt;   and both sides authenticate successfully, the conversation will&lt;/P&gt;&lt;P&gt;   appear as follows:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;   Authenticating Peer     Authenticator&lt;/P&gt;&lt;P&gt;   -------------------     -------------&lt;/P&gt;&lt;P&gt;                           &amp;lt;- EAP-Request/&lt;/P&gt;&lt;P&gt;                           Identity&lt;/P&gt;&lt;P&gt;   EAP-Response/&lt;/P&gt;&lt;P&gt;   Identity (MyID) -&amp;gt;&lt;/P&gt;&lt;P&gt;                           &amp;lt;- EAP-Request/&lt;/P&gt;&lt;P&gt;                           EAP-Request/&lt;/P&gt;&lt;P&gt;                           EAP-Type=EAP-TLS&lt;/P&gt;&lt;P&gt;                           (TLS Start)&lt;/P&gt;&lt;P&gt;   EAP-Response/&lt;/P&gt;&lt;P&gt;   EAP-Type=EAP-TLS&lt;/P&gt;&lt;P&gt;   (TLS client_hello)-&amp;gt;&lt;/P&gt;&lt;P&gt;                           &amp;lt;- EAP-Request/&lt;/P&gt;&lt;P&gt;                           EAP-Type=EAP-TLS&lt;/P&gt;&lt;P&gt;                           (TLS server_hello,&lt;/P&gt;&lt;P&gt;                           TLS change_cipher_spec&lt;/P&gt;&lt;P&gt;                           TLS finished)&lt;/P&gt;&lt;P&gt;   EAP-Response/&lt;/P&gt;&lt;P&gt;   EAP-Type=EAP-TLS&lt;/P&gt;&lt;P&gt;   (TLS change_cipher_spec,&lt;/P&gt;&lt;P&gt;    TLS finished) -&amp;gt;&lt;/P&gt;&lt;P&gt;                           &amp;lt;- EAP-Success&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Many thx guys,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Ken&lt;/P&gt;</description>
      <pubDate>Sun, 10 Mar 2019 23:34:21 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/wireless-lan-controllers-cisco-secure-acs-eap-tls-session/m-p/1267274#M343638</guid>
      <dc:creator>kfarrington</dc:creator>
      <dc:date>2019-03-10T23:34:21Z</dc:date>
    </item>
    <item>
      <title>Re: Wireless Lan Controllers/Cisco Secure ACS-EAP-TLS Session Re</title>
      <link>https://community.cisco.com/t5/network-access-control/wireless-lan-controllers-cisco-secure-acs-eap-tls-session/m-p/1267275#M343718</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;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. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 07 Jul 2009 15:11:07 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/wireless-lan-controllers-cisco-secure-acs-eap-tls-session/m-p/1267275#M343718</guid>
      <dc:creator>htarra</dc:creator>
      <dc:date>2009-07-07T15:11:07Z</dc:date>
    </item>
  </channel>
</rss>

