On Aug 20, 2023, at 11:01 AM, Vadim Cargatser (vcargats) <vcarg...@cisco.com> wrote: > > https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-12.html#section-3.5.4 > > Implementations MUST NOT permit resumption for the inner EAP methods > such as EAP-TLS. If the user or machine needs to be authenticated, > it should use a full authentication method. If the user or machine > needs to do resumption, it can perform a full authentication once, > and then rely on the outer TLS session for resumption. > > • Are we talking about TLS-based inner methods resumptions only?
For now, yes. > That is not the only case. We can ‘save’ the result of MS-CHAP authentication > for example and then skip the full authentication next time. I'm not clear how. The peer creates a challenge which is unique to each authentication session. Since that can't be cached, I don't see how any "resumption" here can skip the full authentication. > Although the term ‘resumption’ might not be 100% correct here I’d like to > understand what we are talking about in the RFC. > • I think the paragraph is slightly contradictory. The first sentence > says ‘MUST NOT’ and the last sentence concludes with <well, unless>. The paragraph tries to say: * inner resumption is disallowed * just use resumption in the outer TLS tunnel > To the best of my knowledge inner method resumption is really desirable and > widely used. Especially if are discussing all inner methods, not just > TLS-based only. Where is inner resumption widely used? I don't recall seeing it. If I had seen it, I would probably have raised this issue earlier, and put text into RFC 9427 to forbid it. > The idea of allowing resumption through the outer TEAP tunnel is also great. > It is simple. > > The obvious caveat here is that will not be achievable in TLS 1.2 (if tickets > are used) since we cannot easily bind the ticket and the result of the inner > authentication. But we could sacrifice that for the over whole simplicity… > Moreover, I guess it is reasonable to assume most TEAP implementations will > have TLS 1.3 in the stack anyway. We don't need to bind the ticket to the result of the inner authentication. The server simply refuses to allow tickets to be used until the inner authentication has completed. This issue has been known for a while. RFC9190 has text on it, for example. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
