Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

EAP-TTLS Authentication Protocol

EAP-TTLS (Tunneled Transport Layer Security) is designed to provide authentication that is as strong as EAP-TLS, but it does not require that each user be issued a certificate. Instead, only the authentication servers are issued certificates. User authentication is performed by password, but the password credentials are transported in a securely encrypted tunnel established based upon the server certificates.

  1. After the authentication server determines that the user has made an authentication request, it sends its certificate to the user’s system (Figure 102).

    Figure 102: TTLS Server Certificate Sent to NAD

    TTLS Server Certificate Sent to NAD
  2. The authentication server’s certificate is used to establish a tunnel between the user and the server (Figure 103).

    Figure 103: TTLS Tunnel Established

    TTLS Tunnel Established
  3. After the tunnel is established, credentials can be exchanged safely between the server and the user because tunnels encrypt all data in a secure fashion. This stage is called inner authentication (Figure 104).

    Figure 104: TTLS Inner Authentication

    TTLS Inner Authentication

With EAP-TTLS, you do not need to create a new infrastructure of user certificates. User authentication is performed against the same security database that is already in use on the corporate LAN; for example, SQL or LDAP databases.

The routing of the inner authentication request is handled either by means of standard SBR Carrier authentication request routing, or by means of a directed realm. If your EAP-TTLS tunnel ends at a dedicated server, and you want all the inner authentication requests to be performed by other servers, use standard request routing so the proxy realm target can be determined in a standard fashion (that is, the decoration of the username revealed by inner authentication). If your EAP-TTLS tunnel and inner authentication are handled by the same server, you can use a directed realm to specify which authentication methods handle the inner authentication.

Configuring EAP-TTLS as an EAP Authentication Method

To configure EAP-TTLS using the Web GUI:

  1. Select RADIUS Configuration > Authentication Policies > EAP Methods.

    The EAP Methods List page (Figure 92) appears.

  2. Select EAP-TTLS.

    The Selected EAP Method: EAP-TTLS pane (Figure 105) appears.

    Figure 105: Selected EAP Method: EAP-TTLS Pane

    Selected
EAP Method: EAP-TTLS Pane
  3. Select the Enable EAP-TTLS Method check box to enable the EAP-TTLS method.

    Note: You can also enable the EAP-TTLS method by using the EAP Methods List page. In the EAP Methods List page, click the Status column of the EAP-TTLS entry, select the appeared check box, and click Apply.

  4. Configure client certificate validation for the EAP-TTLS protocol. For more information about configuring client certificate validation, see Configuring Client Certificate Validation—EAP-TTLS.
  5. Configure request filters for the EAP-TTLS protocol. For more information about configuring request filters, see Configuring Request Filters—EAP-TTLS.
  6. Configure response filters for the EAP-TTLS protocol. For more information about configuring response filters, see Configuring Response Filters—EAP-TTLS.
  7. Configure session resumption for the EAP-TTLS protocol. For more information about configuring session resumption, see Configuring Session Resumption—EAP-TTLS.
  8. Configure inner authentication for the EAP-TTLS protocol. For more information about configuring inner authentication, see Configuring Inner Authentication Settings—EAP-TTLS.
  9. Configure advanced server settings for the EAP-TTLS protocol. For more information about configuring advanced server settings, see Configuring Advanced Server Settings—EAP-TTLS.
  10. Click Save to save the configuration.

Configuring Client Certificate Validation—EAP-TTLS

You use client certificate validation settings to specify how SBR Carrier performs CRL checking.

To configure client certificate validation for the EAP-TTLS protocol using the Web GUI:

  1. In the Selected EAP Method: EAP-TTLS pane, click the Client Certificate Validation tab (Figure 106).

    Figure 106: EAP-TTLS—Client Certificate Validation

    EAP-TTLS—Client
Certificate Validation
  2. Select the Enable CRL Checking check box to enable CRL checking.
  3. If you want to require the client to provide a certificate as part of the TTLS exchange, select the Require Client Certificate check box.

    Note: To validate client certificates, enable both the Enable CRL Checking and Require Client Certificate check boxes.

  4. In the Retrieval Timeout field, enter the number of seconds you want EAP-TTLS to wait for a CRL checking transaction to complete, when the CRL check involves a CRL retrieval.

    When CRL retrieval takes longer than the specified time, the user's authentication request results in a reject.

  5. Enter the number of seconds during which a CRL is still considered acceptable after it has expired in the Expiration Grace Period field.

    EAP-TTLS always attempts to retrieve a new CRL when it is presented with a certificate chain and it finds an expired CRL in its cache.

    • If you enter 0 (strict expiration mode), EAP-TTLS does not accept a CRL that has expired.
    • If you enter a value greater than 0 (lax expiration mode), EAP-TTLS considers the expired CRL as an acceptable stand-in from the time the CRL expires to the time the grace period ends.
  6. Select the Allow Missing CDP Attribute check box if you want SBR Carrier to accept a non-root certificate that does not have a CDP attribute.

    Without a CDP attribute, EAP-TTLS cannot retrieve a CRL and cannot perform a revocation check on the certificate.

    • If you select the Allow Missing CDP Attribute check box, EAP-TTLS accepts such certificates and skips CRL checking for them.
    • If you clear the Allow Missing CDP Attribute check box, EAP-TTLS does not accept a CRL with a missing CDP attribute.
  7. If you want to specify a CRL cache timeout period, select the CRL Cache Timeout Period check box and enter the number of hours in the CRL Cache Timeout Period field.
    • If you do not enable this setting, the CRL is refreshed whenever it expires.
    • If you enable this setting and enter 0, SBR Carrier always regards the CRL in the cache as expired and downloads a new CRL every time it receives a client certificate request.
    • If you enable this setting and enter a number greater than 0, the CRL begins to expire when the age of the CRL in the cache exceeds the number of hours specified in this field or when the scheduled CRL expiration time occurs, whichever comes first.

    After a CRL has expired (because its scheduled expiration time has passed or because the CRL cache has timed out), SBR Carrier uses the expiration grace period to determine whether to use the current CRL.

  8. In the Default LDAP Server Name field, enter the name of the LDAP server to use if the CDP contains a value that begins with the string //ldap:\\\.

    CDPs generated by some CAs do not include the identity of the LDAP server. If you expect to encounter certificates with this style CDP, specify the name of the LDAP server that contains the CRLs.

    If you do not specify a server name and such certificates are encountered, the CRL retrieval fails.

  9. If you want the EAP-TTLS plug-in to add four attributes to the outer request before the secondary authorization check is performed, select the Include Certificate Info check box.

    When the Include Certificate Info check box is selected, SBR Carrier adds the following attributes to the request:

    • The Funk-Peer-Cert-Subject attribute contains the value of the Subject attribute in the client certificate.
    • The Funk-Peer-Cert-Principal attribute contains the value of the principal name (Subject Alternate Name or Other Name) attribute of the client certificate.
    • The Funk-Peer-Cert-Issuer attribute contains the value of the Issuer attribute in the client certificate.
    • The Funk-Peer-Cert-Hash attribute contains a hexadecimal ASCII representation of the SHA1 hash of the client certificate.

    If these attributes are to be used in the inner authentication, they must be transferred from the outer request by using a filter (see Configuring Request Filters—EAP-TTLS). These attributes are ignored if the authentication method that performs the authentication check does not use them. The attributes are available in Realm Selection for EAP-TTLS inner authentication, and proxy filtering from EAP-TTLS inner authentication.

    Special-purpose VSAs carry the certificate information and must be filtered into the inner authentication method in order to be made available for validation. For example, these lines could be added to the ttls transfer filter:

    Allow Funk-Peer-Cert-Subject
    Allow Funk-Peer-Cert-Principal
    Allow Funk-Peer-Cert-Hash
    Allow Funk-Peer-Cert-Issuer

Configuring Request Filters—EAP-TTLS

Request filters affect the attributes of inner authentication requests. By default, SBR Carrier does not use request filters.

Note: You must configure filters before you can associate them with an authentication method. For information about configuring filters, refer to Setting Up Filters.

To configure request filtering for the EAP-TTLS protocol using the Web GUI:

  1. In the Selected EAP Method: EAP-TTLS pane, click the Request Filters tab (Figure 107).

    Figure 107: EAP-TTLS—Request Filters

    EAP-TTLS—Request
Filters
  2. Optionally, select the Transfer Outer Attribs to New check box and select the filter you want to use from the Transfer Outer Attribs to New list.

    This filter affects only a new inner authentication request.

    • If this filter is specified, all attributes from the outer request are transferred to the inner request and this filter is applied. The transfer occurs and the filter is applied before any attributes specified in the inner authentication are added to the request.
    • If this filter is not specified, no attributes from the outer request are transferred to the inner request.
  3. Optionally, select the Transfer Outer Attribs to continue check box and select the filter you want to use from the Transfer Outer Attribs to continue list.

    This filter affects only a continued inner authentication request (rather than the first inner authentication request discussed in the previous step). If this filter is specified, all attributes from the outer request are transferred to the inner request and this filter is applied. The transfer occurs and the filter is applied before any attributes specified in the inner authentication are added to the request.

    If this filter is not specified, no attributes from the outer request are transferred to the inner request.

  4. Optionally, select the Edit New check box and select the filter you want to use from the Edit New list.

    This filter affects only a new inner authentication request. If this filter is specified, it is applied to the inner request that is the cumulative result of attributes transferred from the outer request (by the filter specified in Step 2) and attributes included in the inner authentication request sent through the tunnel by the client.

    If this filter is not specified, the request remains unaltered.

  5. Optionally, select the Edit Continue check box and select the filter you want to use from the Edit Continue list.

    This filter affects only a continued inner authentication request (rather than a new inner authentication request). If this filter is specified, it is applied to the inner request that is the cumulative result of attributes transferred from the outer request (by the filter specified in Step 3) and attributes included in the inner authentication request sent through the tunnel by the client.

    If this filter is not specified, the request remains unaltered.

Configuring Response Filters—EAP-TTLS

Response filters affect the attributes in the final response (Access-Accept or Access-Reject) returned to the originating NAD. By default, SBR Carrier does not use response filters.

To configure response filtering for the EAP-TTLS protocol using the Web GUI:

  1. In the Selected EAP Method: EAP-TTLS pane, click the Response Filters tab (Figure 108).

    Figure 108: EAP-TTLS—Response Filters

    EAP-TTLS—Response
Filters
  2. Optionally, select the Transfer Inner Attribs To Accept check box and select the filter you want to use from the Transfer Inner Attribs To Accept list.

    This filter affects only an outer Access-Accept response that is sent back to a NAD.

    • If this filter is specified, the filter is applied to the inner authentication response and all resulting attributes are transferred to the outer authentication response.
    • If this filter is not specified, no inner authentication response attributes are transferred to the outer authentication response.
  3. Optionally, select the Transfer Inner Attribs To Reject check box and select the filter you want to use from the Transfer Inner Attribs To Reject list.

    This filter affects only a continued inner authentication request (rather than the first inner authentication request). If this filter is specified, all attributes from the outer request are transferred to the inner request and this filter is applied. The transfer occurs and the filter is applied before any attributes specified in the inner authentication are added to the request.

    If this filter is not specified, no attributes from the outer request are transferred to the inner request.

Configuring Session Resumption—EAP-TTLS

You use session resumption settings to specify whether session resumption is permitted and under what circumstances session resumption is performed.

Note: For session resumption to work, the NAD must be configured to handle the Session-Timeout return list attribute, so that the NAD can notify the client to reauthenticate after the session timer has expired.

To configure session resumption for the EAP-TTLS protocol using the Web GUI:

  1. In the Selected EAP Method: EAP-TTLS pane, click the Session Resumption tab (Figure 109).

    Figure 109: EAP-TTLS—Session Resumption

    EAP-TTLS—Session
Resumption
  2. In the Session Timeout(In Seconds) field, enter the maximum number of seconds you want the client to remain connected to the NAD before having to reauthenticate.
    • If you enter 0, no Session-Limit attribute is generated. This does not prevent the authentication methods performing secondary authorization from providing a value for this attribute.
    • 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.

    Entering a value such as 600 seconds (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.

  3. Enter the value to be returned in a Termination-Action attribute in the Termination Action field.

    The Termination-Action attribute is a standard attribute supported by most access points and determines what happens when the session timeout is reached. Valid values are:

    • -1: Do not send the attribute; the default value. This does not prevent any authentication method that performs secondary authorization from providing a value for this attribute.
    • 0: Send the Termination-Action attribute with a value of 0, to terminate the session.
    • 1: Send the Termination-Action attribute with a value of 1, which forces reauthentication when the Session-Time expires.
  4. In the Resumption Limit(In Seconds) field, enter the maximum number of seconds you want the client to be able to reauthenticate using the TTLS session resumption feature.

    This type of reauthentication is fast and computationally efficient. It does, however, depend on previous authentications and is not as secure as a complete (computationally expensive) authentication. Specifying a value of 0 disables the session resumption feature.

    Best Practice: Using the Resumption Limit Option Effectively

    Two scenarios where the resumption limit can be used effectively:

    • In a wireless environment, the client is moving between access points. The resumption limit can be tuned to make the handover between access points smoother by not forcing a complete reauthorization that requires repeated verification of user information.

      When the new access point queries SBR Carrier, the server replies that the session ID is already valid. Because it is known to be good, repeating the inner authentication is not required, which saves some time. The access point acknowledges the reauthorization not required message and the session continues.

    • Another use for resumption limit occurs when the server ordinarily requires the client to reauthorize every 10 minutes or so, to ensure the client is still connected. Setting the resumption limit to 3600 seconds with a session timeout of 600 seconds means that the interval reauthorizations are fast and efficient, and a complete reauthorization is required just once an hour instead of every 10 minutes.

Configuring Inner Authentication Settings—EAP-TTLS

You use the inner authentication settings to specify the way in which the inner authentication step operates.

To configure inner authentication settings for the EAP-TTLS protocol using the Web GUI:

  1. In the Selected EAP Method: EAP-TTLS pane, click the Inner Authentication tab (Figure 110).

    Figure 110: EAP-TTLS—Inner Authentication

    EAP-TTLS—Inner
Authentication
  2. If you want requests to be routed based on the methods listed in the directed realm, enter the name of a directed realm in the Directed Realm field.

    Omitting this setting causes the inner authentication request to be handled like any other request received from a NAD.

  3. If you want requests to be processed by means of a realm selection script, enter the name of a script in the Realm Selection Script field.

    You must license the optional JavaScripting module to use realm selection scripts. For information about realm selection scripting, refer Creating Realm Selection Scripts.

Configuring Advanced Server Settings—EAP-TTLS

You use advanced server settings to specify the manner in which the inner authentication step operates.

To configure advanced server settings for the EAP-TTLS protocol using the Web GUI:

  1. In the Selected EAP Method: EAP-TTLS pane, click the Advanced Server Settings tab (Figure 111).

    Figure 111: EAP-TTLS—Advanced Server Settings

    EAP-TTLS—Advanced
Server Settings
  2. In the TLS Message Fragment Length field, enter the maximum length of the TLS message that may be generated during each iteration of the TLS exchange.

    Enter a number in the range 500 through 4096 bytes. This value affects the number of RADIUS challenge/response round-trips required to conclude the TLS exchange. A value of 1400 bytes may result in 6 round-trips, while a value of 500 bytes may result in 15 round-trips.

    Some access points may have problems with RADIUS responses or EAP messages that exceed the size of one Ethernet frame (1500 bytes including IP/UDP headers).

    The default length for TLS messages is 1020 bytes, which prevents the RADIUS challenge response (carried in a UDP packet) from exceeding one Ethernet frame.

  3. In the Max Transaction Time field, enter the maximum number of seconds you want for the EAP-TTLS authentication sequence to complete.
    • Enter a value in the range 1 through 3600 seconds. The default value is 120 seconds.
    • If the authentication sequence takes longer than this setting, user authentication is aborted.
  4. In the Challenge Timeout field, enter the number of seconds after which a challenge request times out.

    You can enter a value greater than or equal to 1 second, but this value must not exceed the value specified in the Max Transaction Time field. The default value is 30 seconds.

  5. Select the Return MPPE Keys check box to specify whether the TTLS authentication method includes RADIUS MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes in the final RADIUS Access-Accept response sent to the access point.

    Select this check box if the access point needs to key the WEP encryption. If the access point is authenticating only end users and WEP is not being used, you can clear this check box. Disable this option for WiMAX.

  6. Use the TLS Protocol Version list to specify the TLS protocol version on which the server expects the client to initiate the handshake process.

    Valid values are TLSv1, TLSv1.1, and TLSv1.2.

  7. Use the DH Prime Bits list to specify the number of bits in the prime number that the module uses for Diffie-Hellman exponentiation.

    Selecting a longer prime number makes the system less susceptible to certain types of attacks but requires more CPU processing to compute the Diffie-Hellman key agreement operation.

    Valid values are 512, 1024, 1536, 2048, 3072, and 4096 bits.

  8. In the Cipher Suites field, enter the TLS cipher suites (in order of preference) that the server is to use.

    These cipher suites are documented in RFC 2246, The TLS Protocol Version 1, RFC 4346, The TLS Protocol Version 1.1, and RFC 5246, The TLS Protocol Version 1.2.

    Default value is 0x003C,0x003D,0x0067,0x006B,0x0039,0x0038,
    0x0033,0x0035,0x002F,0x000a,0x0005,0x0004,0x0007
    .

    See Table 36 for the list of tested cipher suites and their TLS protocol versions.

Modified: 2017-09-27