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

[Nadav Hod]

I understand the concern. If OSC were to add support of session tickets to their roadmap it would likely take some time until that first version would be GA. After all they already have a form of TLS session resumption which has wide adoption, so it wouldn't likely be a priority. It is argueably the better form of session resumption for large deployments although there are ways to overcome the memory demands of large session tables between AAA/web servers. Even so if I didn't read up on TLS 1.3 just now I would think it's worthwhile adding it to the roadmap for scalability reasons.

Looking into the draft for TLS 1.3, it reads that the IETF's working group plan on obsoleting both session IDs and RFC 5077 (session tickets). They plan on developing on the idea of RFC 5077 using preshared keys which can also act as tickets, thus allowing in-band session resumption and out-of-band authentication. The latest draft is located here:
https://tlswg.github.io/tls13-spec/#rfc.section.6.2.3

Seeing as they are planning on obsoleting both forms of known session resumption, and using the concept of tickets differently, perhaps it's best to wait until OSC's adoption of TLS 1.3 (when it becomes finalized) and give RFC 5077 a pass should the working group decide that it become obsolete. 

What do you think? 

________________________________________
From: radiator-bounces at open.com.au [radiator-bounces at open.com.au] on behalf of Heikki Vatiainen [hvn at open.com.au]
Sent: Friday, October 30, 2015 5:04 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 27.10.2015 12.50, A.L.M.Buxey at lboro.ac.uk wrote:

>> 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
>
> well, depends if they use this for 802.1X...

Yes, it's a good question if session tickets are used by EAP clients.
Apparently RFC 7170 TEAP does support it, but I have not seen any
clients that support TEAP.

In other words, if the specification for an EAP method does not have
anything about session tickets, should a compliant client even try using
them.

> and if stuff is being done to support this then PLEASE let it be fully tested
> and verified by the requester/suggester and other people before being let loose.
> the TLS 1.2 issues we've recently had with issues was the result of the feature
> being requested but not then being tested thoroughly :/

Indeed :) If there's the possibility of do resumption with session
tickets, session ids and decline it completely and fall back to full
handshake, there probably can be interesting combinations of how things
can go wrong.

Also, I'm not sure if tickets save much with EAP. If the authentication
attempts that try to resume a session can be directed to the server
instance that did the full authentication, then resume is possible. The
number of requests that need to be exchanged is similar for both
resumption methods. If there's a large farm of servers that can come and
go, then there might be a case, but there's still the question of there
are any EAP clients that support tickets.

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