Does EAX use the same keys for encryption and authentication? I am actually checking use of EAX AEAD mode, and following EAX spec review (scheme definition for my part), my question is: what about the derivation of the authentication and encryption keys? In the described scheme  the same input key $K$ appears used on all
   OMAC (authentication) &amp; CTR functions. Did I miss something important
   as it would be surprising that the requirement of distinct
   authentication/encryption keys is not respected with EAX ?

I also have two other questions, but of less importance:


When comparing with GCM, I noted that C/AD length parameters are not
taken into account in MAC calculation. Does it have real importance
for security (message extension attack)?
Initial counter ICB for CTR function results from one OMAC operation;
so as ICB LSBits are not set to 0 value, it means to    handle
incrementation of a 128 bits word at each block cipher call by    CTR
function?
The same key is indeed used in EAX to key both the CTR mode and the underlying OMAC (which is actually used in 3 distinct phases: randomising the CTR nonce, authenticating the Additional Authenticated Data, and authenticating the Ciphertext). This is explicitly acknowledged in the security proof.

Where EAX differs from a naive reuse of the key is that it initialises each use of OMAC with a distinct parameter, and initialises the CTR mode cipher with one of the OMAC outputs, effectively randomising that as well. The security proof of this single key approach is (to quote the authors) "novel and involved" and "surprisingly complex", but seems to have stood up to peer review. 

It's worth noting that in the EAX paper, 3 modes are actually defined:


EAX2 is a general composition method for combining a cipher and a MAC to produce an authenticated cipher using two keys Key1 != Key2.
EAX1 is a composition of EAX2 with one Key == Key1 == Key2
EAX is a composition of EAX1 with CTR and OMAC


The security proofs in the EAX paper are provided for EAX2 and EAX, but not EAX1 (the proof of EAX relies on the properties of OMAC, and so doesn't extend to general use of EAX1).

The lengths of the Ciphertext and AAD are not explicitly handled in EAX, which allows EAX to operate as an online mode (processing data as it arrives without buffering more than one block).
The authentication in EAX is simply processing the entire sequence of AAD and Ciphertext with OMAC, and the security proof for that (and any other secure MAC) naturally excludes any message extension attacks - any message extension resulting in the same MAC would be a forgery, and instantly invalidate the scheme as a secure MAC.

CTR mode has to handle incrementation of the nonce/counter value in any implementation - the starting value of the counter is arbitrary (and in the case of EAX pseudo-random). This isn't difficult (BouncyCastle for example does it in one line of code).