Subject: Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

From: Mohit Sethi M <[email-masked]>
Date: Wed, 3 Jul 2019 11:28:58 +0000

There have been several reviews of different aspects of this draft in the past:

Jim provided a complete review here: https://mailarchive.ietf.org/arch/msg/emu/ZDwpgyOL5eBPgyOGwXqxj1VhX-4

A discussion about the L-bit and fragmentation here: https://mailarchive.ietf.org/arch/msg/emu/ZexFr7GROnvNOjN6gGESoO9H0dk

Fairly long discussion on session resumption here: https://mailarchive.ietf.org/arch/msg/emu/LgGAtWVLZsiog13OZRVIFbOZqv4

Implementation report here: https://mailarchive.ietf.org/arch/msg/emu/fTnE46aKnAxhfx38Od-7carTKjI

It would still help the chairs and the document shepherd if folks on the list can be a little more proactive and provide comments/feedback on working group documents. If you have previously read the document and feel that it is ready, then confirming that on the list helps. Having wider community review/input and consensus building is core to the work we do at the IETF. It would be sad to ship documents to the IESG with limited or no review/feedback from the working group!

--Mohit

On 6/27/19 7:16 AM, Joseph Salowey wrote:
The Working Group last call has completed with no comments for draft-ietf-emu-eap-tls13-05.  I would like to confirm that some working group members have reviewed the draft.  If you have reviewed the draft please respond to this thread.

THanks,

Joe

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

---

From: Jouni Malinen <[email-masked]>
Date: Sat, 13 Jul 2019 00:08:19 +0300

On Wed, Jun 26, 2019 at 09:16:19PM -0700, Joseph Salowey wrote:
> The Working Group last call has completed with no comments for
> draft-ietf-emu-eap-tls13-05.  I would like to confirm that some working
> group members have reviewed the draft.  If you have reviewed the draft
> please respond to this thread.

While the current design may work in theory, the use of an "empty TLS
record" looks problematic from implementation and deployment view point.
That terms itself is quite a bit confusing term since this is not really
talking about an empty TLS record in the EAP-TLS message, but about a
zero length TLSPlaintext structure that gets encrypted into a _non_-zero
length TLSCiphertext structure that gets encoded in the TLS record that
goes over EAP-TLS (and that is not empty since all ciphers add something
to the payload length in practice).

The main problem here is that at least OpenSSL is not willing to send
such an empty TLSPlaintext structure. SSL_write() has following to say
about this:
https://www.openssl.org/docs/man1.1.1/man3/SSL_write.html
"You should not call SSL_write() with num=0, it will return an error.
SSL_write_ex() can be called with num=0, but will not send application
data to the peer."

In other words, there does not seem to be any convenient way of
implementing this with the current version of one of the most commonly
used TLS libraries. I can make this work by sending out a one-octet
(0x00) TLSPlaintext as a workaround, but it does not look like I could
make the implementation comply with the draft without changing the TLS
library which is close to a complete showstopper for quick deployment.

It would seem to make sense to me to allow the EAP-TLS 1.3 server to
send out either an empty plaintext or a one octet plaintext to avoid
this issue in a straightforward manner.

This is referring to the following areas in the draft (-05):

2.1.1.

   In the case where EAP-TLS with mutual authentication is successful,
   the conversation will appear as shown in Figure 1.  The EAP server
   commits to not send any more handshake messages by sending an empty
   TLS record, see Section 2.5.

(that confusing use of "empty TLS record" and "TLS empty record" in the
message exchange figures)

2.5.
   When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by appending an empty application data record (i.e. a TLS
   record with TLSPlaintext.type = application_data and
   TLSPlaintext.length = 0) to the last handshake record.  After sending
   an empty application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

(this is where that TLSPlaintext.length = 0 should also allow 1 to make
this easier to implement and deploy)

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: Alan DeKok <[email-masked]>
Date: Sat, 13 Jul 2019 08:59:04 +0200

> library which is close to a complete showstopper for quick deployment.

  I agree.

> this issue in a straightforward manner.

  We may also want to later perform additional signalling at that phase of the authentication.  As such, it may be good to say:

* a one octet plaintext of 0x00 should be sent
* on reception, any data received should be ignored
  * non-zero octets, or more than one octet MAY indicate future extensions

  Alan DeKok.

---

From: Jouni Malinen <[email-masked]>
Date: Sat, 13 Jul 2019 17:21:27 +0300

>   * non-zero octets, or more than one octet MAY indicate future extensions

I'm not sure how I'd feel about EAP-TLS extension that uses actual
application data when we have EAP-TEAP available for cases that need
additional data to be exchanged in the tunnel. Anyway, this combination
of server sending one octet (0x00) and peer decrypting the application
data but ignoring its length and contents is what I ended up
implementing now. This seems to work fine for the case where
NewSessionTicket message(s) are used.

I did see some issues when OpenSSL 1.1.1 when disabling sending of
session tickets, though. The current draft indicates that the empty
Application Data payload would be send out in the same EAP packet with
the server's Finished message, i.e., before the server having
authenticated the peer. And this would be done without the peer having
used TLS early data (which is explicitly disallowed in the draft). That
combination did not work with my experiments since OpenSSL was rejecting
the SSL_write() operation after the server having written own Finished
message, but before having received the Finished message from the peer.
The OpenSSL documentation seemed to imply that SSL_write_early_data()
could be used by the server _if_ the client first sent early data.. At
least in my tests, OpenSSL rejected that call without early data from
the client.

I may have missed some other part of the OpenSSL API where the server
could have sent out the Application Data message to the unauthenticated
peer (if someone knows how to do that, please do let me know), but
regardless, this design of the EAP-TLS v1.3 server depending on a
mechanism that need actual application data (even if empty or known one
octet value) to be sent before having completed authentication of the
TLS client feels like something that can result in implementation
complexities with various TLS libraries. Forcing a new session ticket to
be sent out is a way to work around this, but I'm not sure I'd call this
ideal.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 13 Jul 2019 16:51:10 +0200

On Jul 13, 2019, at 4:21 PM, Jouni Malinen <[email-masked]> wrote:
> additional data to be exchanged in the tunnel.

  Sure.

> Anyway, this combination

  That makes sense.

> least in my tests, OpenSSL rejected that call without early data from

  Yes, that's what I've seen, too.

> be sent out is a way to work around this, but I'm not sure I'd call this

  I think that's the only practical solution.

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Wed, 24 Jul 2019 18:49:59 +0000

Hi,

Based on the discussion on the list and at the meeting today I suggest the following changes to Section 2.1, 2.5, and figures. When we agree I will make a commit to GitHub and submit a new version of the draft.

With the solution suggested by Jim, there should be no need to force NewSessionTicket. Do we need a figure to illustrate the "or in a separate EAP-Request" part of " The TLS record with application data may be sent in the same EAP-Request as the last handshake record or in a separate EAP-Request."

Cheers,
John

Section 2.1:
---------------------------

OLD
   The EAP server commits to not send any more handshake messages by
   sending an empty TLS record, see Section 2.5.

NEW
   The EAP server commits to not send any more handshake messages by
   sending a TLS record with the application data 0x00, see Section 2.5.

Section 2.5 EAP State Machines
---------------------------

OLD

NEW
   When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by sending a TLS record with application data 0x00 (i.e. a
   TLS record with TLSPlaintext.type = application_data,
   TLSPlaintext.length = 1, and TLSPlaintext.fragment = 0x00).  EAP
   server implementations MUST set TLSPlaintext.fragment to 0x00, but
   EAP peer implementations MUST accept any application data as a commit
   from the EAP server to not send any more handshake messages.  The TLS
   record with application data may be sent in the same EAP-Request as
   the last handshake record or in a separate EAP-Request.  After
   sending the application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

Figures:
---------------------------

OLD
                                 <--------          TLS empty record)

NEW
                                 <--------      TLS Application Data)

---

From: John Mattsson <[email-masked]>
Date: Thu, 25 Jul 2019 10:49:40 +0000

I made a few smaller changes, added a figure, and committed to GitHub. 

A diff can be found here:

http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13-05.txt&url2=https://raw.githubusercontent.com/emu-wg/draft-ietf-emu-eap-tls13/master/draft-ietf-emu-eap-tls13.txt

The GitHub commit can be found here:

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/b6529d49b129a0796715ab320df18003ceb4a964#diff-f0254f10e4339e650834528e3c398a26

Question: How will the use of Application data with TLSPlaintext.fragment = 0x00 work with EAP-TTLS, PEAP, and TEAP when they start using TLS 1.3? I assume they will need to send the same 0x00 to commit to not sending any more handshake messages as well as using application data for other purposes. I do not know exactly how the TLSPlaintext fragments look like in EAP-TTLS, PEAP, and TEAP. The TLSPlaintext fragment for commit need to be chosen so that the string does not collide with any other strings used.

Cheers,
John

-----Original Message-----
From: John Mattsson <[email-masked]>
Date: Wednesday, 24 July 2019 at 20:49
To: Alan DeKok <[email-masked]>, Jouni Malinen <[email-masked]>, Jim Schaad <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

    Hi,

    
    Cheers,
    John
    
    Section 2.1:
    
    OLD

    NEW

    OLD
    
    NEW
    
    Figures:
    
    OLD
    
    NEW

---

From: Jouni Malinen <[email-masked]>
Date: Sun, 28 Jul 2019 22:57:50 +0300

> Question: How will the use of Application data with TLSPlaintext.fragment = 0x00 work with EAP-TTLS, PEAP, and TEAP when they start using TLS 1.3? I assume they will need to send the same 0x00 to c…

I don't see why TTLS, PEAP, or TEAP would need to use this specific 0x00
indication for this since they end up using the tunnel for Phase 2 (or
at least protected result indication if Phase 2 authentication is
skipped) and that can be implicitly used for the same purpose.

EAP-TLS needs this workaround because without it, the NewSessionTicket
message changes in TLS 1.3 are quite inconvenient for EAP. With TTLS and
PEAP, it would seem fine to send out the NewSessionTicket before
concluding Phase 2. With TEAP, there is some more discussion about use
of the NewSessionTicket option for provisioning the new PAC (which seem
a bit inconvenient for some use cases IMHO, but nevertheless, I don't
see this needing any additional mechanism for indicating when the
NewSessionTicket is not going to be showing up).

---

From: Jim Schaad <[email-masked]>
Date: Sun, 28 Jul 2019 14:09:19 -0700

I cannot speak to PEAP, but it would seem that TEAP might need this feature
as, at least on resumption, it is totally optional for both sides to use any
TLVs an thus the same issue might be present.  TTLS seems to always require
that the client send a AVP, but I am not sure that it is required for the
server based on a really fast read.

Jim

-----Original Message-----
From: Jouni Malinen <[email-masked]> 
Sent: Sunday, July 28, 2019 12:58 PM
To: John Mattsson <[email-masked]>
Cc: Alan DeKok <[email-masked]>; Jim Schaad
<[email-masked]>; EMU WG <[email-masked]>
Subject: Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

On Thu, Jul 25, 2019 at 10:49:40AM +0000, John Mattsson wrote:
> Question: How will the use of Application data with TLSPlaintext.fragment
= 0x00 work with EAP-TTLS, PEAP, and TEAP when they start using TLS 1.3? I
assume they will need to send the same 0x00 to commit to not sending any
more handshake messages as well as using application data for other
purposes. I do not know exactly how the TLSPlaintext fragments look like in
EAP-TTLS, PEAP, and TEAP. The TLSPlaintext fragment for commit need to be
chosen so that the string does not collide with any other strings used.

I don't see why TTLS, PEAP, or TEAP would need to use this specific 0x00
indication for this since they end up using the tunnel for Phase 2 (or at
least protected result indication if Phase 2 authentication is
skipped) and that can be implicitly used for the same purpose.

EAP-TLS needs this workaround because without it, the NewSessionTicket
message changes in TLS 1.3 are quite inconvenient for EAP. With TTLS and
PEAP, it would seem fine to send out the NewSessionTicket before concluding
Phase 2. With TEAP, there is some more discussion about use of the
NewSessionTicket option for provisioning the new PAC (which seem a bit
inconvenient for some use cases IMHO, but nevertheless, I don't see this
needing any additional mechanism for indicating when the NewSessionTicket is
not going to be showing up).

---

From: Alan DeKok <[email-masked]>
Date: Sun, 28 Jul 2019 18:51:17 -0400

> server based on a really fast read.

  For initial authentication, TTLS requires TLVs inside of the TLS tunnel.  For resumption, the inner tunnel isn't used.

  So it looks like the other TLS-based EAP methods will have the same issue, when resumption is used.

  Alan DeKok.