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

[Alan DeKok <[e-mail]>]

On Jul 13, 2019, at 4:21 PM, Jouni Malinen <[e-mail]> wrote:
> 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.

  Sure.

> 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.

  That makes sense.

> 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.

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

> 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.

  I think that's the only practical solution.

  Alan DeKok.