On Mon, Jan 4, 2021, at 21:01, Mohit Sethi M wrote: > > I have a much simpler one: the EAP layer has a signal that the > > protocol is complete: EAP-Success > Alan Dekok explained in a separate email thread why this is not the > case > (https://mailarchive.ietf.org/arch/msg/emu/uMNKV_vfov7ASob6_Qu3FlCNcT0/). He > wrote: "The EAP-Success and EAP-Failure messages are *not* protected. i.e. > they are 4-bytes of data which can be spoofed rather trivially.".
I specifically addressed that point in my original email. My assertion was that this is not an significant concern. 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? For TLS 1.3, where the server indicates success before the client, I can see how you might want a reliable confirmation that the server has accepted the client Finished. As an aside, this makes is clear that the signal does not exist for the reason implied by the draft. It does not exist to signal that the TLS messages are done; it exists to signal that the server has received and accepted the client Finished. To that end, it's not really a layering violation in the sense that Ben describes. The layering violation exists only because of the language constraining what TLS does thereafter; in that case, a language cleanup might be enough to address the concerns. Note however, that the proposed design does not guarantee that a Confirmation Message acknowledges the client Finished. The server can send the proposed Confirmation Message before the client completes the handshake. Echoing the client Finished might help, but that's a layering violation too. Ideally you would be able use something like exporters to help, but those have problems (see below). I know it's a knee-jerk, but the idea of making EAP-Success reliable is far more appealing to me than anything you suggest. > I also think that this should not be treated as an issue for EAP-TLS > only. I can imagine other deployments which use TLS for making > authorization decisions but do not use the TLS for sending message. So > I am glad that Ben has brought this to the TLS working group for > further discussion. Whether we use this 1-byte of application data (as > done in this draft) or some other mechanism (such as close_notify), we > need a reliable way of telling that no further post handshake messages > will be sent. EAP has the privilege of being the first to grapple with this. I'm going to suggest something slightly scandalous: TLS 1.3 exporters are not the ideal design. They should have included the full handshake transcript, just like the resumption secret. There were good reasons at the time for designing them as they are, and there are likely reasons to retain the current design as an option (it's stronger than the early exporter and there might be use cases), but those original reasons are less relevant. The current design gives short shrift to client authentication, to the detriment of use cases like EAP. Having exporters depend on the entire transcript would serve EAP better. In this case, you could provide an application-level signal using an exported value. Without that sort of in-TLS affordance, confirming receipt of the client Finished might do. You still have the possibility that the server doesn't depend on client authentication and so predicts the value, but that would be true of a full-transcript exporter too, so arguably that doesn't matter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
