I am finally getting caught up on this thread and I have found it to be very frustrating because it appears to make an assumption which I do not believe is warranted.
I do not see any problems with allowing TLS session to be used across different types of EAP assuming that EAP correctly checks the output of TLS before continuing. When a session ticket is issued for a TLS session it contains the authentication done by that TLS authentication session. It does not contain any of the containing EAP authentication information that has been done. Example: Run EAP where you do TLS anonymous followed by a password and get the session ticket. This session ticket is associated with ZERO client authentication information, not even the password because the session ticket would be issued before the password was obtained. Take that session ticket and run it in an EAP-TLS session. The TLS would check to see if there was client authentication associated with the session ticket and either a) say that the ticket is not valid or b) validates the ticket and then does a post handshake client authentication for the client certificate. It could then issue a new ticket which contained the client authentication information obtained in TLS. A similar analysis can be done for all EAP methods. The session ticket only has the information that is discovered by TLS and as such any new TLS session that is created needs to look a the client authentication that was done when the ticket was issued. Jim > -----Original Message----- > From: Emu <emu-boun...@ietf.org> On Behalf Of Alan DeKok > Sent: Thursday, March 7, 2019 5:41 PM > To: Arran Cudbard-Bell <a.cudba...@freeradius.org> > Cc: EMU WG <emu@ietf.org> > Subject: Re: [Emu] Notes on session resumption with TLS-based EAP > methods > > On Mar 6, 2019, at 9:40 PM, Arran Cudbard-Bell > <a.cudba...@freeradius.org> wrote: > > 'session tickets for TLS versions 1.2 and below, and [RFC 8446] session > tickets in TLS 1.3.' > > > > I know it's pedantic, but RFC 8446 obsoletes RFC 5077. > > Sure. > > >> Any authorization applied during resumption MUST be done using the > >> cached data, > > > > 'or data resolved or obtained using that cached data.' > > > > authorization doesn't need to performed in a sandboxed environment with > only the cached data. > > True. It can be used to look up data in a database, or to do something else. > > > Cross resumption between VPNs and Wired/Wireless infrastructure could > be a big issue. > > It might be worth mentioning that explicitly as I think it'll be a blind spot for > implementors. > > > > Out of the box, if someone used our EAP server implementation for > > authenticating VPN users and wired/wireless users, we would allow > > cross resumption, because the EAP server doesn't allocate session tickets > based in different contexts by default. > > That depends on the deployment, too. > > To be strictly technical, an HTTPS server and EAP server could share TLS > session tickets. It would then be possible for users to authenticate via > HTTPS, and "resume" via EAP-TLS. > > The only reason resumption works across media types in EAP is that there's > generally one common EAP server for all media types. If instead there are > multiple EAP servers, or the TLS implementations don't share data, then > cross-method resumption won't work. > > >> When EAP servers make policy decisions based on unauthenticated > >> information, they MUST then add that information to the cached data > > > > maybe 'then it MUST be used in combination with the cached data > described above' > > Perhaps. > > > Took a couple of readings to understand exactly what you meant there. > > It's a difficult subject to explain properly. > > > The cached data isn't being updated, but it's being used together with > > the unauthenticated information, right? > > Yes. > > Alan DeKok. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
