>> >> 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 I have read again resumption section. What I was trying to achieve and asking for is already mentioned in Section 3.4: If the server agrees to resume the session, Phase 2 is bypassed entirely. That is actually it. Sorry for the confusion.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
