On Apr 11, 2021, at 10:40 PM, Joseph Salowey <[email protected]> wrote: > This does seem to require some more specification. Here is a proposal. > > "TLS 1.3 introduced the Post-Handshake KeyUpdate message which is not useful > and not expected in EAP-TLS. Implementations SHOULD NOT send a KeyUpdate > message. If a KeyUpdate message is received then an implementation SHOULD > ignore the message and it SHOULD NOT send a KeyUpdate message in response." > > I think this is better than "implementations MUST NOT send this message and > MUST fail upon reception". The problem here is that the EAP TLS > implementation may not have control over this behavior.
It looks like key update messages are explicitly requested by either party. From OpenSSL: https://www.openssl.org/docs/man1.1.1/man3/SSL_key_update.html If the KeyUpdate message is sent only when requested, it would make sense to forbid sending it. EAP-TLS has no reason to just randomly change the encryption keys used for TLS. EAP-TLS is using TLS for authentication, and not for bulk data transfer. If the underlying TLS library randomly sends it (or sends it subject to unknown criteria), then the EAP-TLS implementation (peer or authenticator) should be able to detect it via a callback: https://www.openssl.org/docs/man1.0.2/man3/SSL_set_msg_callback.html There appears to be no way for the application to tell the TLS library to ignore the message. The safest thing would seem to be: a) forbidding EAP-TLS implementations from explicitly requesting it b) noting that TLS libraries may still do key updates c) noting that EAP-TLS implementations can often detect key updates, and d) leaving it to the implementation to decide what to do. i.e. "We don't know why you'd use it. But if someone else does use it, and it works, great. Otherwise, buyer beware". Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
