On Fri, 25 Aug 2023, at 19:10, Heikki Vatiainen wrote: > When the outer TLS-based EAP is processed by a different EAP server than the > inner EAP-TLS, then the why inner EAP-TLS resumption shouldn't be simply a > matter of the EAP peer and the inner EAP server? In this case the outer EAP > server wouldn't even know if the inner EAP-TLS does resumption or not, when > the inner EAP is proxied through to a next hop server. > > I'm not saying this can't be made simpler by banning inner TLS resumption. > I'm just wondering why this is an issue.
For me, not a technical point, just I perceive it as undermining for me the purpose of resumption. "obliteration of every round trip possible" Of course I may be in the minority here :) Allowing inner methods to resume forces you to always resolve the inner methods; in lieu of some OOB method to communicate otherwise. I like to try to line up my ducks so I can use resumption for authorization, not just authentication. Yes, I know, dragons lurk there, but I'm cleverer than those dragons...definitely....I'm confident in it....really....I am! Maybe my cavalier tendencies should be ignored though. > It could even complicate implementations when an EAP method in some cases is > allowed to do TLS resumption and in some other cases it's forbidden. A > simpler way to do this is a reminder that EAP servers can turn off resumption > in the part of the configuration that processes inner EAP-TLS. I think things actually become *less* complicated when you allow inner resumption as now the outer resumption is guaranteed to be decoupled from any policies around authorization. The cost of implementing any form of outer resumption is in the caveats around bubbling up invalidations (eg. password changed, account disabled, ...) and using account expiry as an upper limit for the validity of the resumption keying material. Here lie all the pains of maintaining a cache. The caching part is easy, everyone gets bitten by the invalidation plumbing, even when they know where the bodies are buried. Cheers
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
