Subject: [Emu] Protected Result Indicators in EAP-TLS

From: John Mattsson <[email-masked]>
Date: Tue, 9 Feb 2021 10:00:40 +0000

Below is my summary of the situation:

- It seems like there will be consensus to have protected result indicators in EAP-TLS 1.3.
- No one has objected to mandate Error alert on fatal error condition.
- Optional protected result indicators are different from mandatory result indicators,
  recent suggestion is that protected failure result indicators shall be mandatory.
- Success indicators and failure indicators need to be discuss together.

Below is my summary of the alternatives:

1. Use close_notify alert as protected success. Use other alerts as protected failure.

  To make it work I think EAP-TLS 1.3 needs to profile TLS 1.3 as:

  - Forbid close_notify except as success indication
  - Mandate Error alert before EAP-Failure
  - Forbid all use of user_cancelled

  Alternatively

  - Forbid close_notify except as success indication
  - Mandate Error alert or user_cancelled before EAP-Failure

2. Use application data for protected result indicators. Mandate alert (closure or error) before EAP-Failure.
	
	TLS people has stated that this might be reordered and that it is a layer violation.

	I think the worries can be overcome by writing things as requirements on
	the EAP-TLS layer, e.g.

	"After sending application data in a EAP-Request the EAP-TLS server MUST not send
      any more EAP-Request"

3. Success and failure indication on the EAP-TLS layer

   This was never discussed beyond that using an uprotected flag bit was not acceptable.

	Things at the EAP-TLS layer can quite easily be made protected.

	- Use one of the reserved bit in the EAP-TLS pakcet to indicate success.
	- Append TLS-Exporter("EXPORTER_EAP_TLS_SUCCESS_" + Type-Code, "", 16) to the packet

	- Use another of the reserved bit in the EAP-TLS pakcet to indicate failure.
	- Append TLS-Exporter("EXPORTER_EAP_TLS_FAILURE_" + Type-Code, "", 16) to the packet

	A solution at the EAP-TLS layers would not be dependant on profiling TLS 1.3

4. Success on EAP-TLS layer, Mandate alert (closure or error) before EAP-Failure.

5. Failure on EAP-TLS layer. Application data for success, 

I think 1. seems like the most complicated solution. It is also kind of ugly as it use an alert as indication for success. That said, I can live with any solution that are acceptable for implementors and TLS people.

Cheers,
John

---

From: Alan DeKok <[email-masked]>
Date: Tue, 9 Feb 2021 09:21:54 -0500

> - Success indicators and failure indicators need to be discuss together.

  Yes.

> Below is my summary of the alternatives:

  I think whatever the altAccept notice is used, the altReject needs to be a TLS alert.  This alert is secured and authenticated.

>  - Forbid all use of user_cancelled

  If we use close_notify, yes.

> 	TLS people has stated that this might be reordered and that it is a layer violation.

  Unlike many other uses of TLS, EAP is *not* handing control of the transport protocol over to the TLS layer.  i.e. TLS libraries often implement TCP (or even HTTP) wrappers.  None implement EAP.

  This limitation means that there are no ordering issues with use of application data.  In packet N, the EAP-TLS server asks the TLS layer for data, and encodes it into EAP, and then sends it out.  Some packet M>N, the EAP-TLS server has verified the client certificate.  At that point, it can write application data to TLS.

  The other benefit of using application data is that it is needed for other TLS-based EAP methods.  i.e. there is little reason to have complex code paths when a more unified approach will do.  This protocol choice helps to simplify implementations.

> 	"After sending application data in a EAP-Request the EAP-TLS server MUST not send

  The EAP-TLS server MUST send only EAP-Success.

> 	A solution at the EAP-TLS layers would not be dependant on profiling TLS 1.3

  Appending data to the EAP-TLS packets is problematic.  We already have a secured tunnel inside of the TLS layer.  Using that is *significantly* easier than mangling packets.

> 5. Failure on EAP-TLS layer. Application data for success, 

  I'm not sure what those mean.

> I think 1. seems like the most complicated solution. It is also kind of ugly as it use an alert as indication for success. That said, I can live with any solution that are acceptable for implemento…

  (1) and (2) have essentially simpler complexity.  (3) is by far and aware more complex to implement.

  For us, the code changes to support TLS 1.3 are maybe a few hundred lines of C.  The difference between (1) and (2) is maybe 50 lines.  Having multiple TLS exporters is maybe 100 lines.  (3) is much larger, and much more error prone.

  Alan DeKok.