Hi Joe,
Good initiative.
1. To have an alternate success indication is new. The requirement needs to be
the possibility to have an _protected_ success indication. This is requires in
at least IEEE 802. It seems to be a weakness in the IEEE 802 spec, but EAP-TLS
simply has to align with this. I don't think a 3.5. round-trip needs any
security analysis, but I don't think it is worth specifying such a mode without
resumption. A 3.5 mode not suitable for IEEE 802 with resumption would require
significant TLS work. This might be worth doing in the future, but should not
be done now.
I think 4.5 roundtrip with a mandatory protected success indication is the only
thing we should specify now.
2. TLS Error alert are perfect matches for alternative failure alerts. Early
Error alerts are unprotected. Later Error alerts are protected.
Martin and Ben both indicated that they think using application data is
problematic. First because of reordering done by the TLS implementation and
secondly as they they seem to disslike the use of applicaiton data to signal
what the TLS implementation should do. close_notify in a separate flight
mitigates any reordering issues and automatically implies that no more
handshake messages are sent.
As long as the implementors can live with it I would suggest that we use
close_notify as a success indication and move forward, but I don't have a
strong opinion.
As Bernard suggested I think we should write that TLS Error messages are
alternate failure indicators.
3. While I agree that TLS should have specified the exporter that way, it does
not provide any significant value to EAP-TLS. I do not think EAP-TLS should use
anything else that a standardized TLS exported, and waiting for a new
standardized TLS exporter takes far too long time.
I think the separate labels for MSK and EMSK are good.
Have we aligned on using context or not? Using contect seemed like a simpler
solution, but not all TLS implementations support context.
I do not think we should include anything form client finished at this point.
Cheers,
John
From: Emu on behalf of Joseph Salowey
Date: Thursday, 4 February 2021 at 17:24
To: EMU WG
Subject: [Emu] Way Forward for EAP-TLS 1.3
Based on John's email [1] and a few other discussions I've had offline I'm
proposing the following series of consensus calls to find a path forward:
1. Consensus on requiring result indicators using a 4.5 roundtrip protocol. I
think this is a conservative approach that could move forward quicker then
alternatives. It may be possible to securely use an abbreviated protocol in
some environments or with some additions to TLS, but the security analysis for
this would take more time and may lead nowhere. An abbreviated protocol could
be covered in an update.
2. Consensus on what signal to use for result indicators, such as Close_Notify
and fatal alerts.
3. Consensus on whether to enhance the key derivation to include certificates
or other information from that includes the client and server identity. This
would help ensure that keys were not passed down to the lower layer prematurely.
I think we can run 1 and 3 in parallel. We will also need to take resumption
into account. Please respond to this thread, either privately or on the list,
with your concerns. I'd like to start these calls before next week.
Cheers,
Joe
[1] https://mailarchive.ietf.org/arch/msg/emu/hawPjEH2RRin4MlzqJe57Yrf0bQ/
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
