On Jan 4, 2021, at 6:26 PM, Martin Thomson <m...@lowentropy.net> wrote: > Your point about reliability is confusing. I've read Section 4.2 of RFC 3748 > and while it says "A peer MUST allow for this circumstance as described in > this note.", I see no explanation of how to concretely make that allowance. > Are you saying that EAP methods don't really use EAP-Success and condition > their behaviour on other signals?
EAP-Success by itself is *not* a reliable indication of Success. See RFC 3748 Section 4.2: Success and Failure packets MUST NOT be sent by an EAP authenticator if the specification of the given method does not explicitly permit the method to finish at that point. With TLS 1.3, we don't know if the authentication has completed until the TLS layer sees either (a) CloseNotify, or (b) application data. So the EAP-TLS implementations cannot distinguish a "finished authentication" EAP-Success from a "spoofed" EAP-Success. Because the EAP-TLS implementation has no idea of TLS is done, and therefore no way to tell that the EAP-Success is permitted at this point in the negotiation. Therefore, we need an explicit signal to the EAP-TLS layer that the EAP-TLS method has finished. Discussion on the list went back and forth between CloseNotify and sending one octet of application data. Implementations have done both. The conclusion was that the one octet of application data was slightly easier to implement. Plus, sending CloseNotify precluded the TLS layer from sending a TLS Fatal Alert: https://www.mail-archive.com/emu@ietf.org/msg03092.html, which says in part: ... If the Commitment Message is changed to close_notify, the TLS Fatal Alert would have to be changed to an EAP-Failure instead. The difference is that The TLS Fatal Alert can contain information such as bad_certificate, unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown, illegal_parameter, unknown_ca, access_denied, etc. while EAP-Failure must not contain any additional data. ... As someone who supports end users, I am very opposed to removing this information. 802.1X authentication is hard enough to deploy correctly as it is. If we require the use of CloseNotify for EAP-TLS and TLS 1.3, then a whole host of useful error messages just go away. Errors which are used to debug real-world certificate compatibility issues. I can't think of many things worse for EAP-TLS than to replace a set of descriptive messages with a simple "Failed". Was your certificate revoked? Failed. Was it expired? Failed. Was the CA known? Failed. What went wrong? Too bad for you, the only message you get is "Failed". End users and sysadmins will be cursing the standard for years. And, trying to stick with something *useful*, such as TLS 1.2. My $0.02 is that the one byte of application data is less "pure" than a solution which relies on TLS negotiation. But if using CloseNotify makes deployments substantially more difficult, then that is a very strong reason to avoid it. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
