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

[Jouni Malinen <[e-mail]>]

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