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


This section explains the following:

Reauthentication Cache

Instead of doing a full authentication for cryptographically complex processes, session keys can be established and made to persist, and a simpler reauthentication can take place instead. This requires between 200 and 2400 bytes of data per session (which mostly, in the SSR, varies due to stored attribute value pairs) to be stored on both the client and the server. Reauthentication caching optimizes the amount of CPU utilization required and is not a required functionality for any use case. Certain use cases may not see any benefits.

TLS resumption is currently handled on a per-server basis. The cryptographic material is stored on one local SBRC. To perform reauthentication, the source of the previous transaction must be routable (using load balancers or similar, see Load Balancing on RADIUS Front-End Applications and Downstream Proxy Devices for more information) to the correct target SBRC.

TTLS resumption, especially in the roaming WiMAX use case, can be propagated to the SSR, so that multiple servers can handle the reauthentication. The tradeoff is that heavy cryptography work is not done at the expense of another insert into the SSR for upwards of 2400 bytes of data, plus the read in a future attempted reauthentication. In cases of high throughput, where the performance of the SSR is the bottleneck, turning off reauthentication caching might allow you to scale more linearly (no longer limited by SSR transaction rates) by adding front-end applications.

Cipher Suites and Key Sizing

The derivation of keying material for a tunnel is completed based on functions of the key (client and server keys for TLS or server certificate for TTLS) by using a set of cryptographic operations called a cipher suite. The default SBRC cipher suite cryptography is estimated on the strength of the suites and occurs in the order listed in Table 15.

Table 15: Cipher Suite

Cipher Suite

Cipher Suite Code





























The performance of the above algorithms is loosely related to their relative security, in the order shown in Table 15. RADIUS will always attempt to use the highest security cipher suite for which it is configured and that the client can also utilize. Removing the lower cipher suites increases the relative security of your system. Removing the higher cipher suites can result in a significant performance boost.

In the Diffie-Hellman Ephemeral (DHE)-based cipher suites, the temporary keys derived by the client and server are thrown away after the session is completed, providing perfect forward security—nothing directly derived from the server certificate is sent over the wire. However, using DHE keys is expensive and requires the creation of large relative prime numbers. Using the settings of DHE-based suites, the key generation is modified by the number of DHE prime bits of the field in which to search, which is the number of bits to look for in a relatively prime number on which to base the session keys.

Cipher Suite Scaling

A few index values reproduced in Chapter 7 for the M3000 2.53 GHz should scale linearly with total CPU GHz. The relative cryptographic costs will be commensurate between TLS and TTLS. With the default 1024 DHE bits using 0x39, the default cipher suite includes accounting to SSR but not reauthentication caching.

Reducing the Number of Round Trips

SBRC can be configured to use a larger TLS fragment length per RADIUS transaction. Determine the expected length of the non-RADIUS attributes (with some buffer) in an authentication transaction and subtract that from 4000 (the maximum size of a RADIUS transaction). Set the TLS fragment length towards that length, preferably as a number evenly divisible by 255 (maximum RADIUS AVP length). The default of 1020 is intentionally short to emphasize operative safety in cases where many long AVPs might be sent from NAS equipment; 2040 may be a better value for many purposes.

Certificate Management

The cryptographic keys of a TLS-based or TTLS-based server have a strong impact on the amount of work each server must process. A cryptographically secure system is one that has no known breaks or limitations on how long it would take to deconstruct the entire system (for example, in Triple-DES the key field is 2^168, but an attack reduces that complexity to 2^112, and because of that, cryptographers consider Triple-DES to be “broken”—although not completely so). Keys in such a secure system are cryptographically secure when the amount of time in which they are in use is less than the amount of time it would take to break the key using optimized brute force methods. One way of optimizing the CPU utilization is to generate shorter keys for the server certificate, and change them more often. If you have never changed your server certificates, then decreasing their size and changing them once a year may be both a security and performance improvement.

To give an appropriate reference point, in 2007 it was reported that by using a special number field sieve (filter), the equivalent operation of breaking a single 700-bit RSA key was executed on 400 computers over 11 months.

Multiple TLS/TTLS-Only Front-End Applications

In cases using highly cryptographically secure algorithms and keys, running multiple standalone versions of SBRC, outside of use cases requiring cluster resumption, using TLS with secondary authentication to a cluster front-end application, or using TTLS inner-auth to a cluster front-end application provides linear scaling with hardware. Whether TLS or TTLS--since it all depends on CPU and scales well through higher end, massive multiple-CPU hardware--faster CPU is generally better than more CPU, GHz for GHz, but more total CPU among cores will always be a benefit to this case.

Modified: 2016-11-15