On Sat, Jul 13, 2019 at 08:59:04AM +0200, Alan DeKok wrote: > On Jul 12, 2019, at 11:08 PM, Jouni Malinen <j...@w1.fi> 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
