On Aug 25, 2023, at 2:10 PM, Heikki Vatiainen <h...@radiatorsoftware.com> 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 would say that's fine, and put it under the label of "handing off the inner method to someone else". If the EAP server hands off the inner method to another system, then the other system does whatever it wants. My concern is "inventive" interpretations of the specs. I can't think of a reasonable use-case where the same server would disallow outer TLS resumption, but use inner TLS resumption. So instead of making the world more complicated, we can just ban unreasonable things. > I'm not saying this can't be made simpler by banning inner TLS resumption. > I'm just wondering why this is an issue. 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. If resumption is enabled for the outer TLS session, then the inner methods are bypassed completely. But it's likely worth noting that the if outer resumption is allowed, the inner methods should have resumption disabled. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
