Is it possible to insert a key derivation function when using EAX? I am currently investigating use of EAX mode for a dedicated application and following useful clarifications received from my previous post , to consider according to my applicable input security requirements (separate keys for encryption and authentication) either :


the  Baseline solution where EAX is used in strict respect of its
specification and so with one unique key K
or an eventual (only if it has a sense) alternate solution with insertion
before EAX, of a key derivation function allowing to generate from
the unique input key K, one KA key for OMAC functions and one KE
key for CTR function


Can such alternate solution be envisaged or may it violate EAX mode specification and associated security proof ?
As noted in archie's answer to your earlier question, the EAX paper first defines a generic encrypt-then-MAC composition method called EAX2, with separate keys for the encryption and MAC components, and proves its security (Appendix C).  It then defines EAX as EAX2 instantiated with CTR mode and OMAC, and with the same key used for both components, and then uses an additional result about OMAC (Appendix D) to prove that this composition remains secure even with the key reuse (Appendix E).

Anyway, what all this amounts to is that if you take EAX mode and modify it so that the OMAC key is independent from the CTR mode key, and make no other changes, then what you get is an instance of EAX2 (with CTR mode as the encryption method and OMAC as the PRF).  If you trust the proof that EAX is secure, then, by the same argument, you should also trust the sub-proof that shows EAX2 to be secure.

That said, there do exist some potential disadvantages to this change.  For example, even though the security proof of EAX2 is essentially a part of the security proof of EAX, that does not necessarily mean that authorities that have certified EAX to be secure necessarily accept EAX2 as certified as well.  Also, more practically, verifying the correctness of your implementation of EAX2 might be more difficult, since AFAIK there's no standard set of test vectors available for EAX2.

All in all, if at all possible, I'd recommend sticking with EAX and using an existing, known-to-be-good implementation of it.  However, if you do need to use generic encrypt-them-MAC composition with separately derived keys for regulatory or other reasons, EAX2 is a pretty good way to implement it.