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

[Jouni Malinen <[e-mail]>]

On Sat, Jul 13, 2019 at 08:59:04AM +0200, Alan DeKok wrote:
> On Jul 12, 2019, at 11:08 PM, Jouni Malinen <[e-mail]> wrote:
> > 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.
> 
>   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

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.

-- 
Jouni Malinen                                            PGP id EFC895FA