On Feb 2, 2019, at 6:50 AM, John Mattsson <john.matts...@ericsson.com> wrote: > Very good that this is discussed and highlighted. > > My understanding is that TLS itself clearly allows a resumed connection to be > used for a completely different purpose. The ALPN specification (RFC 7301) > says that: > > "When session resumption or session tickets [RFC5077] are used, the previous > contents of this extension are irrelevant, and only the values in the > new handshake messages are considered." > > I don't know how important this feature is in EAP, but if it is useful and do > not cause security problems, we should probably not forbid it.
I would suggest then referencing or duplicating the above text, and saying something like: --- Implementations SHOULD be capable of session resumption across different TLS-based EAP types. This recommendation is made for a few reasons. It is recommended by [RFC7301], there appears to be no compelling reason to forbid it, and implementations can always choose to reject session resumption based on local policies. Some EAP types have complex state and negotiation. For this EAP types, session resumption across different EAP types may not be possible, and if not possible, MUST be forbidden by both specifications and implementations. Additional discussion of this topic is outside of the scope of this document. --- e.g. TTLS and PEAP both allow session resumption, and when done, skip the phase 2 / inner-tunnel authentication. In contrast, FAST and TEAP both still require phase2 to occur after session resumption. The session resumption there is just used to skip the TLS negotiation. And the MSK / EMSK depends on the inner tunnel authentication methods, so the TLS-Exporter() function needs more than just the TLS parameters. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
