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

From: Bernard Aboba <[email-masked]>
Date: Sun, 13 Jun 2021 15:43:49 -0700

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.

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 13 Jun 2021 15:53:31 -0800

On Sun, Jun 13, 2021 at 2:44 PM Bernard Aboba <[email-masked]>
wrote:

>    EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 [RFC5216] . TLS version
[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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: John Mattsson <[email-masked]>
Date: Sat, 19 Jun 2021 05:15:33 +0000

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

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 <[email-masked]> on behalf of Joseph Salowey <[email-masked]>
Date: Monday, 14 June 2021 at 01:54
To: Bernard Aboba <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216

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

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.

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 19 Jun 2021 07:46:43 -0700

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 <[email-masked]>
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.
>
>
>
> 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.
>
>
>
> 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 <[email-masked]> on behalf of Joseph Salowey <
> [email-masked]>
> *Date: *Monday, 14 June 2021 at 01:54
> *To: *Bernard Aboba <[email-masked]>
> *Cc: *EMU WG <[email-masked]>
> *Subject: *Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216
>
>
>
>
>

---

From: John Mattsson <[email-masked]>
Date: Mon, 21 Jun 2021 05:42:59 +0000

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 <[email-masked]>
Date: Saturday, 19 June 2021 at 16:47
To: John Mattsson <[email-masked]>
Cc: Joseph Salowey <[email-masked]>, EMU WG <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bernard,

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>

1.  Introduction:

Cheers,
John

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