Using the same secret key for encryption and authentication in a Encrypt-then-MAC scheme Is it a weakness to use a single shared secret for protecting messages using a Encrypt-then-MAC scheme?  

Assuming a system is using AES-256-CBC and a SHA1-HMAC and the same secret key for both operations.  Upon intercepting one of these messages and attacker could brute force this secret key by trying to solve the HMAC or by successfully decrypting the first block of the ciphertext.

Performing  a decryption on a single block of AES-256 should be a lighter operation than performing a SHA1-HMAC on a potentially large message.  Therefore AES-256 is ideal for a massively parallel brute-force attack and the use of the SHA1-HMAC doesn't hurt the system.

Is this approach sound, or is there an attack that has not been taken into consideration?
Brute forcing the key would hardly be an issue: 128-bit keys (assuming they have been properly generated) are in a space which is way too large to be successfully explored by brute force; and 256-bit keys (the kind you put in AES-256) are even more larger. Whether AES is "faster" than HMAC or not does not make such brute force more feasible: even if each key try was as simple as a simple bit flip, 128-bit keys would still be too large for any practical attacker.

Said otherwise, if "massively parallel brute-force attacks" are relevant, then your key is not properly generated (bad PRNG, bad key exchange algorithm, bad password-to-key derivation...), and that is your problem, not the reuse of the same key for both AES and HMAC. If you reach the point where the relative slowness of AES vs HMAC/SHA-1 is how you envision protection, then things have gone sour upstream.



Potential problems with using the same key for encryption and MAC would be structural; @Henrick's example is CBC-MAC, which is indeed identical to CBC encryption, except that you only use the last encrypted block as MAC. CBC-MAC works fine as long as you do not give to the attacker access to pairs (p,c): p is a plaintext block, c is the corresponding ciphertext block, for the key k which you use for CBC-MAC. But if you use the same key k for encrypting the data, then you are giving to the attacker a lot of such blocks.

With HMAC vs AES, no such interference is known. The general feeling of cryptographers is that AES and SHA-1 (or SHA-256) are "sufficiently different" that there should be no practical issue with using the same key for AES and HMAC/SHA-1. However, simply defining that "difference" with any kind of scientific rigor would be hard, and it is not a much explored security feature. So that's one of these constructions which can be qualified as "no urgency to fix it, but don't do it if you can avoid it". A much "safer" way (in the sense of: "we know what characteristics of the involved algorithms we are exercising") is to take your master key K, and derive from it, with a good one-way Key-Derivation Function, a sub-key for encryption and another sub-key for the MAC. This can be as simple as applying SHA-256 on K and splitting the 256-bit result into two 128-bit keys.

There are some MAC and encryption algorithms which intrinsically support sharing the same key. This is exactly what happens in GCM.