Not sure if that idea has already been discussed, but is that reasonable to append an encrypted success/failure message as an opaque field to EAP-Success/Failure.
Granted rfc 3748 explicitly define the length of EAP-Success/Failure, but these *extended* EAP-Success/Failure will be sent if and only if EAP-TLS 1.3 is negotiated before. Ragards, Vadim On 2/10/21, 10:02 PM, "Emu on behalf of [email protected]" <[email protected] on behalf of [email protected]> wrote: Send Emu mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/emu or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Emu digest..." Today's Topics: 1. Re: Protected Result Indicators in EAP-TLS 1.3 (John Mattsson) ---------------------------------------------------------------------- Message: 1 Date: Wed, 10 Feb 2021 10:48:10 +0000 From: John Mattsson <[email protected]> To: EMU WG <[email protected]>, "[email protected]" <[email protected]>, Benjamin Kaduk <[email protected]> Subject: Re: [Emu] Protected Result Indicators in EAP-TLS 1.3 Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" 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 <[email protected]> Date: Tuesday, 9 February 2021 at 15:22 To: John Mattsson <[email protected]> Cc: EMU WG <[email protected]> Subject: Re: [Emu] Protected Result Indicators in EAP-TLS On Feb 9, 2021, at 5:00 AM, John Mattsson <[email protected]> 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. ------------------------------ Subject: Digest Footer _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu ------------------------------ End of Emu Digest, Vol 145, Issue 37 ************************************ _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
