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-boun...@open.com.au [radiator-boun...@open.com.au] on behalf of Heikki Vatiainen [h...@open.com.au] Sent: Friday, October 30, 2015 5:04 PM To: radiator@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.bu...@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 <h...@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@open.com.au http://www.open.com.au/mailman/listinfo/radiator _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
