[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]


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 99).

Figure 99: TTLS Server Certificate Sent to NAD

  1. The authentication server's certificate is used to establish a tunnel between the user and the server (Figure 100).

Figure 100: TTLS Tunnel Established

  1. 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 101).

Figure 101: 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, or token systems.

The routing of the inner authentication request is handled either by means of standard Steel-Belted Radius 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:

  1. Select Authentication Policies > EAP Methods to open the EAP Methods panel (Figure 102).

Figure 102: EAP Methods Panel

  1. Activate the Enable check box for the EAP-TTLS method.
  2. Select the EAP-TTLS entry and click the Edit button on the toolbar (or double-click the EAP-TTLS entry).

The Edit TTLS Authentication Method dialog (Figure 103) opens.


Figure 103: Edit TTLS Authentication Method Dialog
  1. Use the tabs in the Edit TTLS Authentication Method dialog to configure:

Each configuration task is described separately in the sections that follow.

Configuring Request Filters

Request filters affect the attributes of inner authentication requests. By default, Steel-Belted Radius Carrier does not use request filters.

NOTE: You must configure filters using the Filters panel before you can associate them with an authentication method. For information on configuring filters, refer to Chapter 13, "Setting up Filters" on page 175.


To configure request filtering for the EAP-TTLS protocol:

  1. Click the Request Filters tab in the Edit TTLS Authentication method dialog (Figure 104).

Figure 104: TTLS Request Filter Tab

  1. Optionally, activate the Transfer Outer Attribs to New check box and select the filter you want to use from the drop-down list.

This filter affects only a new inner authentication request.

  1. Optionally, activate the Transfer Outer Attribs to Continue check box and select the filter you want to use from the drop-down 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.

  1. Optionally, activate the Edit New check box and select the filter you want to use from the drop-down 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.

  1. Optionally, activate the Edit Continue check box and select the filter you want to use from the drop-down 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

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

To configure response filtering for the EAP-TTLS protocol:

  1. Click the Response Filters tab in the Edit TTLS Authentication method dialog (Figure 105).

Figure 105: TTLS Response Filters Tab

  1. Optionally, activate the Transfer Inner Attribs to Accept check box and select the filter you want to use from the drop-down list.

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

  1. Optionally, activate the Transfer Inner Attribs to Reject check box and select the filter you want to use from the drop-down 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 Client Certificate Validation

You use client certificate validation settings to specify how Steel-Belted Radius Carrier performs certificate revocation list (CRL) checking.

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

  1. Click the Client Certificate Validation tab in the Edit TTLS Authentication Method dialog (Figure 106).

Figure 106: TTLS Client Certificate Validation Tab

  1. Activate the Enable CRL Checking check box to enable CRL checking.
  2. If you want to require the client to provide a certificate as part of the TTLS exchange, activate the Require Client Certificate check box.

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


  3. 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.

  1. 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.

  1. Activate the Allow Missing CDP Attribute check box if you want Steel-Belted Radius 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.

  1. If you want to specify a CRL cache timeout period, activate the CRL Cache Timeout Period check box and enter the number of hours in the timeout period in the hours field.

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

  1. Enter the name of the LDAP server to use if the CDP contains a value that begins with the string //ldap:\\\ in the Default LDAP Server Name field.

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.

Configuring Session Resumption

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:

  1. Click the Session Resumption tab in the Edit TTLS Authentication Method dialog (Figure 107).

Figure 107: TTLS Session Resumption Tab

  1. 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.

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.

  1. Enter the value that you want 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. Enter the maximum number of seconds you want the client to be able to reauthenticate using the TTLS session resumption feature in the Resumption Limit field.

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. (See the Best Practice Using the Resumption Limit Option Effectively.)

Configuring Inner Authentication Settings

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:

  1. Click the Inner Authentication tab in the Edit TTLS Authentication Method dialog (Figure 108).

Figure 108: TTLS Inner Authentication Tab

  1. 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 network access device.

  1. 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.

Configuring Advanced Server Settings

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:

  1. Click the Advanced Server Settings tab in the Edit TTLS Authentication Method dialog (Figure 109).

Figure 109: TTLS Advanced Server Settings Tab

  1. 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-4096. This value affects the number of RADIUS challenge/response round-trips required to conclude the TLS exchange. A value of 1400 may result in 6 round-trips, while a value of 500 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.

  1. Enter the maximum number of seconds you want for the EAP authentication sequence in the Max Transaction Time field.

If the authentication sequence takes longer than this setting, the user authentication is aborted.

  1. Enable 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.

Enable this option 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.

  1. 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.

  1. Enter the TLS cipher suites (in order of preference) that the server is to use in the Cipher Suites field.

These cipher suites are documented in RFC 2246, The TLS Protocol Version 1.

Default value is 0x16, 0x13, 0x66, 0x15, 0x12, 0x0a, 0x05, 0x04, 0x07, 0x09.


[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]