We have had a lot of productive discussion on this topic. I feel comfortable calling consensus that we should add protected result indicators to EAP-TLS 1.3.
There also seems to be consensus to use TLS Failure alert for failure result indications. How to represent success indicators is not as clear. Fortunately, we have two options that seem to have some support. 1. Zero-byte application record. Multiple implementations already use this mechanism and it is clear that the EAP-TLS peer and server "application" can receive and send this indicator. There were additional concerns about the ordering of this application data record in the flight, but it seems that this should not be a problem as long as the TLS library is fed the entire EAP-TLS message containing the flight to process. 2. Close-Notify Alert. This would use an existing TLS message to signal success. We have had some implementation reports that the EAP-TLS server "application" can trigger the close_notify on at least one library. I have not heard any news from implementers if close_notify is accessible to the EAP-TLS peer/supplicant "application". I think it is not clear if the signal would be accessible to implementers for both the EAP-TLS peer and server. I'd like to hear from implementers about their experience with this mechanism: 1. Have you implemented the zero byte application record signa? If not, why not?l a. Is it sent after receiving the client finished? b. Do you anticipate problems if the application record comes before or after a NewSessionTicket message? c. did you run into any issues with this mechanism? 2. Have you implemented the close notify method? If not, why not? a. Is it sent after receiving the client finished? b. Were you able to cause the message to be sent for the server or determine that the message was received for the peer/supplicant? c. Did you run into any issues with this mechanism? Joe On Sat, Feb 6, 2021 at 5:22 PM Joseph Salowey <[email protected]> wrote: > There is growing support for mandating result indicators for EAP-TLS 1.3. > The result indicators help protect the EAP protocol exchange in the many > different types of environments EAP-TLS is used and make the integration > with the EAP state machine clearer. This has the impact of adding a round > trip to EAP-TLS 1.3 making a total of 4.5 round trips. It may be possible > to optimize this exchange, but that would need further study and would be > beyond the scope of this effort. > > This consensus call has two parts: > > 1. Please respond to the list if you support adding explicit result > indications of success and failure from the EAP Server to the EAP Peer in > EAP-TLS 1.3. If you object please respond to the list indicating why. > > 2. Please respond to the list if you support using TLS close_notify alert > for a success indication and TLS error alert for a failure indication. If > you object please respond to the list indicating why. > > This call will run for 1 week. Please respond by February 15, 2021. > > Thanks, > > Joe >
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
