Top posting to explain the need for a reliable notification of protocol completion:
On 1/4/21 5:44 AM, Martin Thomson 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.". There are two more quirks as to why EAP-Success cannot be used as an indication of protocol completion: a) Section 2.2 of RFC 3748 says https://tools.ietf.org/html/rfc3748#section-2.2: EAP packets with Codes of Success or Failure do not include a Type field, and are not delivered to an EAP method. What this means is that the EAP-Success is delivered to EAP (the framework) and not to EAP-TLS (the authentication method/protocol). Thus, EAP methods cannot rely on EAP-Success or EAP-Failure as an indication of anything since they never receive that message. b) Section 3.1 (https://tools.ietf.org/html/rfc3748#section-3.1) and 4.2 (https://tools.ietf.org/html/rfc3748#section-4.2) of RFC 3748 says: Note that EAP Success and Failure packets are not retransmitted. Without a reliable lower layer, and with a non-negligible error rate, these packets can be lost Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance as described in this note. The knee-jerk reaction would be that EAP is bad and it should be fixed/updated. I have myself wondered if we can add some payload to the EAP-Success message. But EAP has been around for over a decade now and is used in many networks so the threshold for change is naturally high. 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. --Mohit
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
