Re: [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Mohit Sethi M <[e-mail]>]

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