On Jul 13, 2019, at 4:21 PM, Jouni Malinen <j...@w1.fi> 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. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
