Subject: [Emu] EAP-TLS and TLS alerts

From: Alan DeKok <[email-masked]>
Date: Fri, 5 Feb 2021 13:03:23 -0500

I was discussing this offline with Jorge, who noticed that in TLS, alerts are SHOULD and not MUST:

https://tools.ietf.org/html/rfc8446#section-2

   A failure of the handshake or other protocol error triggers the
   termination of the connection, optionally preceded by an alert
   message (Section 6).

https://tools.ietf.org/html/rfc8446#section-6.2

   Whenever an implementation encounters a fatal error condition, it
   SHOULD send an appropriate fatal alert and MUST close the connection
   without sending or receiving any additional data.

  In practice, these alerts have been seen almost all o f the time with TLS <1.3.  In order for deployments to have useful error messages, I suggest updating draft-ietf-emu-eap-tls13 Section 2.1.4:

...
   Figures 5, 6, and 7 illustrate message flows in several cases where
   the EAP-TLS peer or EAP-TLS server sends a TLS fatal alert message.
   In earlier versions of TLS, error alerts could be warnings or fatal.
   In TLS 1.3, error alerts are always fatal and the only alerts sent at
   warning level are "close_notify" and "user_cancelled", both of which
   indicate that the connection is not going to continue normally, see
   [RFC8446].
...

new text:

Note that [RCC 8446] Section 6.2 suggests that TLS alerts are optional:

   Whenever an implementation encounters a fatal error condition, it
   SHOULD send an appropriate fatal alert and MUST close the connection
   without sending or receiving any additional data.

For EAP-TLS, we strengthen this requirement. EAP-TLS peers and EAP-TLS servers MUST send TLS alerts on TLS error conditions as diagrammed in Figures 5, 6, and 7.  Failure to send TLS alerts means that the peer or server would have no way of determining what went wrong.  And therefore administrators would have no way of determining how to fix deployment or configuration errors.

Experience with existing implementations of EAP-TLS shows that TLS alerts are sent almost always, by both EAP-TLS peer and EAP-TLS server.  So while this requirement is new for EAP-TLS 1.3, it should impose no additional burden on implementations/

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Sun, 7 Feb 2021 11:20:25 +0000

Alan DeKok wrote:

 >> I personally fine with writing MUST send an Error alert if the WG wants that.
>
> This is what all implementations have done for ~15 years.  The TLS Alert satisfies the "altReject" 
> requirements of RFC 4137.  Which means it's a very good iea.

Jorge said offline that he also wanted this behaivior. I will update the draft to make TLS Error alerts mandatory to send.

Maybe the draft should summarize the profiling EAP-TLS 1.3 does on TLS 1.3

- OCSP stapling mandatory to support for server
- Only cipher suites with confidentiality
- MUST send Erros alert.

>> I don't if this would be common or expected behavior from the server, but if EAP-TLS cannot
>> enforce that this to not happen, then we cannot use close_notify as an alternate success
>> indication, because an alternate success indication cannot be followed by EAP-Failure.
>
> Perhaps just update the document to say that such use-cases are forbidden?

I already did that when I added text to the GitHub version on alternative success indicatiors. If close_notify is to be used as an alternative success indicatiors, forbidding and enforcing this is essential, otherwise, close_notify cannot be used.

Cheers,
John