With Alan's comments, I think we are down to 3 alternatives:
(1a). Use close_notify alert as protected success.
Use error alerts as protected failure.
- Forbid close_notify except as success indication
- Mandate Error alert before EAP-Failure
- Forbid all use of user_cancelled
(1b). Use close_notify alert as protected success.
Use all other alerts as protected failure.
- Forbid close_notify except as success indication
- Mandate Error alert or user_cancelled before EAP-Failure
(2). Use application data as protected success.
Use all alerts as protected failure.
- After sending application data in an EAP-Request the EAP-TLS server MUST
send only EAP-Success.
- Mandate alert (closure, error) before EAP-Failure
I think it is important to discuss what the ongoing EMU consensus call will
mean in practice. Previous discussions was mostly about not sending more
handshake messages. Protected result indicators are quite different.
It would we very good with early feedback from Ben and the TLS WG if they see
problems with any of the alternatives.
Cheers,
John
-----Original Message-----
From: Alan DeKok <al...@deployingradius.com>
Date: Tuesday, 9 February 2021 at 15:22
To: John Mattsson <john.matts...@ericsson.com>
Cc: EMU WG <e...@ietf.org>
Subject: Re: [Emu] Protected Result Indicators in EAP-TLS
On Feb 9, 2021, at 5:00 AM, John Mattsson
<john.mattsson=40ericsson....@dmarc.ietf.org> wrote:
>
> 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.
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.
> 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
If we use close_notify, yes.
> 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.
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.
> 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"
The EAP-TLS server MUST send only EAP-Success.
> 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
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.
> 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'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 implementors and TLS people.
(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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
