[RADIATOR] Suggestion: Support of TLS Session Resumption based on tickets and not just session IDs

[Nadav Hod]

Hi Heikki,


According to:
https://technet.microsoft.com/en-us/library/hh831771.aspx

RFC 5077 (Session Tickets based TLS Session resumption, aka TLS Session Resumption without Server-Side State) is implemented as of Windows 8.1 and Windows Server 2012R2. So along with Windows 10, that's 16% of the desktop market share according to:
https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0

As for browsers, Chrome and Firefox support RFC 5077 for over five years. That's over 40% of the browser market share. For the purposes of Radiator, the more interesting statistic would be the OS support.

The needs for tickets that come to mind are the following:
1) They relieve the server of maintaining session cache (very useful in mid-large deployments).
2) They make it easy to load balance TLS sessions since the server needs only to decrypt the ticket provided by the client and not maintain a database which is shared between the servers.
3) The fact that there is no need to maintain a TLS session database may make it a more secure solution in certain architectures since there is no need to keep sessions on a persistent storage (and thus compromise perfect forward secrecy). That may make it more difficult for a malicious user to attain the session tickets, but that's just my guess.

I'm sure there are plenty of upstanding ladies and gents in this mailing list which can discuss the merits and demerits of session tickets better than I, perhaps they'd like to chime in.

There is an interesting post about a use case of the two Session Resumption methods here:
https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/


________________________________________
From: radiator-bounces at open.com.au [radiator-bounces at open.com.au] on behalf of Heikki Vatiainen [hvn at open.com.au]
Sent: Monday, October 19, 2015 4:49 PM
To: radiator at open.com.au
Subject: Re: [RADIATOR] Suggestion: Support of TLS Session Resumption based on tickets and not just session IDs

On 18.10.2015 11.07, Nadav Hod wrote:

> Session Resumption as implemented by Radiator seems to work based on
> Session ID (connection caching at the server).

That's correct.

> Session resumption with session IDs has a major limitation: servers are
> responsible for remembering negotiated TLS sessions for a given period
> of time. It poses scalability issues for servers with a large load of
> concurrent connections per second and for servers that want to cache
> sessions for a long time. Session ticket resumption is designed to
> address this issue.
> OpenSSL supports Session Tickets as of OpenSSL 0.9.8h. It may be worth
> looking into. I'm not sure if session synchronization of tickets/cache
> between multiple servers is necessary for a AAA server (as opposed to a
> web server), but I imagine it may also provide a big performance boost
> in large deployments.

I'd say the synchronisation requirements are the same for an AAA server too.

What is different is that TLS based EAP client does not need to make
concurrent requests like a browser might do. Where tickets might become
useful is an environment where the number of AAA servers changes
dynamically. For example, the original server that did the full
authentication may not be present anymore (scale in) or there are new
servers (scale out) that were brought up to handle the load.

Also, does anyone know if the EAP clients support SessionTicked based
resumption? For example, wpa_supplicant docs indicate this is available
but disabled by default.

What comes to server side support, the recently added Gossip framework
might be useful for distributing the required information between the
Radiator instances, provided the considerations in the RFC are followed etc.

So the question is: is this supported by the clients and what the need
for this would be?

Thanks,
Heikki

--
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
_______________________________________________
radiator mailing list
radiator at open.com.au
http://www.open.com.au/mailman/listinfo/radiator