Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216

[John Mattsson <[e-mail]>]

Your suggestion looks good to me. I added a commit to RR #83

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83

From: Bernard Aboba <[e-mail]>
Date: Saturday, 19 June 2021 at 16:47
To: John Mattsson <[e-mail]>
Cc: Joseph Salowey <[e-mail]>, EMU WG <[e-mail]>
Subject: Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216
I still find the proposed Section 2.1 confusing.  How about this?

"If the TLS implementation correctly implements TLS version negotiation, EAP-TLS will automatically leverage that capability.
The EAP-TLS implementation needs to know which version of TLS was negotiated to correctly support EAP-TLS 1.3 as well as to maintain backward compatibility with EAP-TLS 1.2.

TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS. Therefore, much of Section 2.1 of [RFC5216] does not apply for TLS 1.3. Except for Sections 2.2 and 5.7 this document applies only when TLS 1.3 is negotiated. When TLS 1.2 is negotiated, then [RFC5216] applies."






On Fri, Jun 18, 2021 at 10:15 PM John Mattsson <[e-mail]<mailto:[e-mail]>> wrote:
Hi Bernard,

Thanks for your comments on backward compatibility. I think PR #83 addresses your comments. I did not write anything about TLS 1.0 and TLS 1.1 as RFC 8996 (which updates RFC 5216) formally forbids support and negotiation of these weak versions.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83/files<https://protect2.fireeye.com/v1/url?k=931ff3ea-cc84cac1-931fb371-866038973a15-a9a1d2b72b73651b&q=1&e=37b52464-2ebd-4ba4-aa0c-8087ad10b4ba&u=https%3A%2F%2Fgithub.com%2Femu-wg%2Fdraft-ietf-emu-eap-tls13%2Fpull%2F83%2Ffiles>

Below is how the two related paragraphs would look after merging #83.


1.  Introduction:

This document updates [RFC5216] to define how to use EAP-TLS with TLS 1.3. When older TLS versions are negotiated, RFC 5216 applies to maintain backwards compatibility. However, this document does provide additional guidance on authentication, authorization, and resumption for EAP-TLS regardless of the underlying TLS version used. This document only describes differences compared to [RFC5216]. All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2. Since EAP-TLS couples the TLS handshake state machine with the EAP state machine it is possible that new versions of TLS will cause incompatibilities that introduce failures or security issues if they are not carefully integrated into the EAP-TLS protocol. Therefore, implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator.

2.1  Overview of the EAP-TLS Conversation:

TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS. Therefore, much of Section 2.1 of [RFC5216] does not apply for TLS 1.3. EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 [RFC5216] . TLS version negotiation is handled by the TLS layer, and thus outside of the scope of EAP-TLS. Therefore so long as the underlying TLS implementation correctly implements TLS version negotiation, EAP-TLS will automatically leverage that capability. Except for Sections 2.2 and 5.7 this document applies only when TLS 1.3 is negotiated. When TLS 1.2 is negotiated, then [RFC5216] applies. The EAP-TLS implementation needs to know which version of TLS that was negotiated.

Cheers,
John


From: Emu <[e-mail]<mailto:[e-mail]>> on behalf of Joseph Salowey <[e-mail]<mailto:[e-mail]>>
Date: Monday, 14 June 2021 at 01:54
To: Bernard Aboba <[e-mail]<mailto:[e-mail]>>
Cc: EMU WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216


On Sun, Jun 13, 2021 at 2:44 PM Bernard Aboba <[e-mail]<mailto:[e-mail]>> wrote:
draft-ietf-emu-eap-tls13-16 Section 2.1 contains the following text:


   EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 [RFC5216] . TLS version

   negotiation is handled by the TLS layer, and thus outside of the

   scope of EAP-TLS.  Therefore so long as the underlying TLS

   implementation correctly implements TLS version negotiation, EAP-TLS

   will automatically leverage that capability.

I am concerned that this statement is potentially misleading. An implementation of RFC 5216 that negotiates TLS 1.2 and utilizes the key hierarchy defined in RFC 5216 Section 2.3 will not interoperate with an implementation of draft-ietf-emu-tls13-16 that also negotiates TLS 1.2 and utilizes the key hierarchy defined in Section 2.3 of that document.

So in what sense is EAP-TLS 1.3 "backwards compatible" with EAP-TLS 1.2?

The only way this makes sense to me is if it is stated that draft-ietf-emu-eap-tls13 applies only when TLS 1.3 is negotiated, and that if TLS 1.2, 1.1 or 1.0 is negotiated, then RFC 5216 applies.


[Joe] Good point.  I think this is missing from the draft.  The EAP-TLS implementation does need to know which version of TLS is negotiated.   I agree that this draft applies to when TLS 1.3 is negotiated and not previous versions of TLS.

_______________________________________________
Emu mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/emu