Subject: Re: [Emu] draft-ietf-emu-eap-tls13-09

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 12 Jun 2020 08:29:37 +0000

A short follow-up on my own review:

I wrote:

> "
> Pre-Shared Key (PSK) authentication SHALL NOT be used except
>    for resumption.
> "
> What you want to say that that EAP-TLS MUST NOT use external PSKs. I wonder why you want to rule that use case out? It is a perfectly fine use case for TLS 1.3 and there is even the possibility to use PSK with ECDHE. What is the motivation?

I noticed now that the working group had a discussion about this already and that there is a new document being published specifically focused on EAP-TLS-PSK-based authentication. Hence, ignore the second part of my comment.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 12 Jun 2020 08:15:34 +0000

Hi all,

I took a quick look at the -09 draft.

Here are a few comments.

1.  Introduction

The text in the introduction is confusing. To be honest, this document is actually not needed because TLS allows you to negotiate version and features. Obviously, the introduction does not say that and instead dances around the reason of why this document is needed by saying TLS 1.3 made a lot of changes but then concludes everything is backwards compatible.

In more details, the first paragraph is fine. It talks about where EAP-TLS is used.

Then, the second paragraph says:

"

   TLS 1.3 is in large parts a complete

   remodeling of the TLS handshake protocol including a different

   message flow, different handshake messages, different key schedule,

   different cipher suites, different resumption, different privacy

   protection, and record padding.

This means that significant parts of

   the normative text in the previous EAP-TLS specification [RFC5216<https://tools.ietf.org/html/rfc5216>]

   are not applicable to EAP-TLS with TLS 1.3 (or higher).  Therefore,

   aspects such as resumption, privacy handling, and key derivation need

   to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher).

"

The change from 1.2 to 1.3 is certainly larger than the change from 1.1. to 1.2.

For the user of the EAP method not much has changed though. In fact, you can seamless switch from one version of TLS to the next version.

In fact, you say that in the next paragraph:

"

   While this document updates EAP-TLS [RFC5216<https://tools.ietf.org/html/rfc5216>], it remains backwards

   compatible with it and existing implementations of EAP-TLS.
"

In the last paragraph you say:

"
   Privacy is mandatory and achieved without any additional round-trips,
   revocation checking is mandatory and easy with OCSP stapling, and TLS
   1.3 introduces more possibilities to reduce fragmentation when
   compared to earlier versions of TLS.
"

You have some specific features in mind when you talk about "privacy" and I wonder what those are.

In what sense is revocation checking mandatory? OCSP stapling has been a feature before.

What is this issue about fragmentation? As you know from your work on the other document, fragmentation is really introduced by certificates. The certificate format in TLS 1.3 has not changed.

Before you answer these questions look at my suggestion below.

I would delete large part of the introduction and basically leave the first paragraph intact and then add the following sentences:

"

EAP-TLS [RFC5216<https://tools.ietf.org/html/rfc5216>] references TLS 1.0 [RFC2246<https://tools.ietf.org/html/rfc2246>] and TLS 1.1 [RFC4346<https://tools.ietf.org/html/rfc4346>],

but works perfectly also with TLS 1.2 [RFC5246<https://tools.ietf.org/html/rfc5246>].  TLS 1.0 and 1.1 are

formally deprecated and prohibited to negotiate and use

[I-D.ietf-tls-oldversions-deprecate<https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-09#ref-I-D.ietf-tls-oldversions-deprecate>].  Weaknesses found in TLS 1.2,

as well as new requirements for security, privacy, and reduced

latency has led to the specification of TLS 1.3 [RFC8446<https://tools.ietf.org/html/rfc8446>], which

obsoletes TLS 1.2 [RFC5246<https://tools.ietf.org/html/rfc5246>].

This specification updates RFC 5216 and updates the description to
cover TLS 1.3. Security and privacy considerations of this EAP method
are updated to reflected the improved security and privacy functionality
of TLS 1.3.
"

Section 2.1

Delete this paragraph. It does not say much.

   TLS 1.3 changes both the message flow and the handshake messages

   compared to earlier versions of TLS.  Therefore, much of Section 2.1<https://tools.ietf.org/html/rfc5216#section-2.1>

   of [RFC5216]<https://tools.ietf.org/html/rfc5216#section-2.1> does not apply for TLS 1.3 (or higher).

Section 2.1.1

   Many client certificates

   contains an identity such as an email address, which is already in

   NAI format.

A NAI looks like an email address but actually isn't.

"

   The EAP server MUST authenticate with a certificate and SHOULD

   require the EAP peer to authenticate with a certificate.
"

You might want to mention the emergency services use case here. You do much later in the document but I believe this is the first occurrence of the server-side only authentication concept.

"

   for resumption.
"

"

SessionID is deprecated in TLS 1.3 and the EAP

   server SHALL ignore the legacy_session_id field if TLS 1.3 is

   negotiated.
"

I am curious why you are pointing out this change in TLS 1.3. Yes, the session id field has been deprecated and the session resumption concept was harmonized but for the EAP layer this appears to be irrelevant.

"

   After the TLS handshake has completed and all Post-Handshake messages

   have been sent, the EAP server sends EAP-Success.
"

I think you have to be more precise here with your recommendations regarding post-handshake messages. The following paragraph from the same section (but later in the text) appears relevant to this topic.
"

   When using EAP-TLS with TLS 1.3, the EAP server MUST indicate support

   of resumption in the initial authentication.  To indicate support of

   resumption, the EAP server sends a NewSessionTicket message

   (containing a PSK and other parameters) after it has received the

   Finished message.

"
Unfortunately, it is not entirely correct. It is not the EAP server role that makes this session resumption support indication but it is a feature of TLS. So, you might want to change the sentence to:

"

   When using session resumption in TLS 1.3, a NewSessionTicket message is sent as a post-handshake message.

"

"

   As stated in [RFC5216<https://tools.ietf.org/html/rfc5216>], the TLS cipher suite shall not be used to

   protect application data.  This applies also for early application

   data.  When EAP-TLS is used with TLS 1.3, early application data

   SHALL NOT be used.

"

You might want to say that TLS 1.3 in EAP is only used for authentication and the establishment of keys rather than for application data protection. Then, this paragraph becomes more understandable for someone not familiar with the network access authentication concept in general.

In Figure 1 you show the "Commitment Message" and I was wondering why you need it. You talk about it later in Section 2.5 but I still don't get it. This appears to be an unnecessary deviation from the TLS 1.3 implementation.

Btw, I would give Figure 1 the following title "EAP-TLS 1.3: Full Public Key-based Exchange with mutual authentication".

In Figure 2 you show the NewSessionTicket message and this is one possible exchange. I believe you can also add the NewSessionTicket message right after the Finished message and thereby saving an extra roundtrip, if you want.

2.1.2<https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10#section-2.1.2>.  Ticket Establishment

"

   This is a new section when compared to [RFC5216<https://tools.ietf.org/html/rfc5216>].

"

While it is new to RFC 5216 it is not new at all in context of https://tools.ietf.org/html/rfc5077

I don't understand why you introduce a section 2.1.2 for ticket establishment and a separate section 2.1.3 on resumption when the two actually belong together. I suggest to combine the two sections and to call them Resumption. TLS 1.3 combined three mechanisms into one: PSK-based authentication, classic session resumption and session resumption without server-side state.

"

   TLS 1.3 replaces the session resumption mechanisms in earlier

   versions of TLS with a new PSK exchange.  When EAP-TLS is used with

   TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism

   compatible with that version of TLS.
"

I would delete this paragraph because it states the obvious.

You state that EAP peers and EAP servers should use the client tracking preventions and then you make recommendations regarding the NAI construction in the following paragraph. How do you see the two to interwork?
"

As specified in Section 2.2 of [RFC8446]<https://tools.ietf.org/html/rfc8446#section-2.2>, the EAP peer SHOULD supply

   a "key_share" extension when attempting resumption, which allows the

   EAP server to potentially decline resumption and fall back to a full

   handshake.

"

This is not a good advice IMHO. In the deployments where EAP-TLS is used the EAP peer and the EAP server know quite well what the other parties do and being as conservative as in the web environment does not appear to be appropriate. Considering that the key share(s) cost a fair amount of computation and over-the-wire bandwidth, I would actually recommend the opposite. It is more likely that the EAP exchange succeeds.
If you are uncertain, make no recommendations and explain the tradeoffs instead.
"

   Also during resumption, the server can respond with a Hello Retry

   Request (see Section 2.1.6<https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10#section-2.1.6>) or issue a new ticket (see Section 2.1.2<https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10#section-2.1.2>)

"
Not sure why you are stating this. This issue is explained in great detail in the  TLS 1.3 specification. I would not repeat the TLS 1.3 here.
2.1.4<https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10#section-2.1.4>.  Termination

"

TLS 1.3 changes both the message flow and the handshake messages

   compared to earlier versions of TLS.  Therefore, some normative text

   in Section 2.1.3 of [RFC5216]<https://tools.ietf.org/html/rfc5216#section-2.1.3> does not apply for TLS 1.3 or higher.

"
I would not repeatedly make this statement.

2.1.8<https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-09#section-2.1.8>.  Privacy

   TLS 1.3 significantly improves privacy when compared to earlier

   versions of TLS by forbidding cipher suites without confidentiality

   and encrypting large parts of the TLS handshake including the

   certificate messages.

This is not the entire privacy story in TLS 1.3. IMHO TLS 1.2 already had no ciphersuites that allowed integrity only.
TLS 1.3 got rid of RSA key transport. TLS also added improved padding and better unlinkability support for session resumption.

I stop here for now.

Ciao
Hannes

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 15 Jun 2020 13:51:09 +0000

Hi Hannes,

On 6/12/20 11:29 AM, Hannes Tschofenig wrote:

I wrote:

"

Indeed. There has been lots of discussion on this topic. To summarize:

RFC 5216 explicitly required certificate based TLS authentication with the following text:

   If the EAP server is not resuming a previously established session,
   then it MUST include a TLS server_certificate handshake message, and
   a server_hello_done handshake message MUST be the last handshake
   message encapsulated in this EAP-Request packet.

   The certificate message contains a public key certificate chain for
   either a key exchange public key (such as an RSA or Diffie-Hellman
   key exchange public key) or a signature public key (such as an RSA or
   Digital Signature Standard (DSS) signature public key).

Bernard Aboba opined that external PSK based authentication shouldn't be added to EAP-TLS in this update. Instead a separate document (with a separate EAP method type) should do that. Hence, we now have: https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00. For reference, here are some email conversations containing discussion on this topic:

- https://mailarchive.ietf.org/arch/msg/emu/FtxRJHTjzSY0yVdVr8Vjyk9D-vk/
- https://mailarchive.ietf.org/arch/msg/emu/CRh3VXLDnpJFFIbHWJAjiOgfzAg/
- https://mailarchive.ietf.org/arch/msg/emu/nYrIA4PKqk2mrUoNvAtFh7S-Xb8/
- https://mailarchive.ietf.org/arch/msg/emu/hVG357HXqvy0EjZ2yrOLdspH53o/

--Mohit

Ciao
Hannes

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Jun 2020 09:02:24 +0000

This is, of course, a decision of the group and the main use cases of a TLS-based EAP method is in the use of public key-based authentication.
Technically, there is, however, no reason why this wouldn’t work.

Ciao
Hannes

From: Mohit Sethi M <[email-masked]>
Sent: Monday, June 15, 2020 3:51 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-09

Hi Hannes,

I wrote:

"

   for resumption.

"

--Mohit

Ciao

Hannes

Emu mailing list