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).