- What are principle differences?
- When to use one and when the other?(Typical Use Cases)
As Chris Smith notes in the comments, HMAC is a specific MAC algorithm (or, rather, a method for constructing a MAC algorithm out of a cryptographic hash function). Thus, HMAC can be used for any application that requires a MAC algorithm.
One possible reason for requiring HMAC specifically, as opposed to just a generic MAC algorithm, is that the HMAC construction actually provides (as long as the underlying hash function satisfies the appropriate assumptions) stronger security properties than what's required of a MAC. For example, nothing in the definition of a secure MAC algorithm (resistance to existential forgery under a chosen-plaintext attack) says that the MAC output can't reveal information about the plaintext to an attacker. If the plaintext is secret but the MAC is public, that would obviously be bad. HMAC, however, is guaranteed not to reveal any information about the plaintext as long as the underlying hash function is secure.
In particular, Bellare has shown that HMAC is a pseudo-random function (PRF) as long as the compression function of the underlying hash is also a PRF, and a "privacy-preserving MAC" (PP-MAC) as long as the compression function of the underlying hash is also a PP-MAC. Both of these are strictly stronger security properties than what's required of a plain MAC; in particular, being a PRF is a very strong security property — it essentially says that there's no practical way for an attacker to say anything about the output of the function based on the input, or vice versa, except for the obvious fact that the same input always yields the same output. There are many use cases for which a PRF will do whereas a plain MAC may not; HMAC, instantiated with a secure hash function, can be used for those.
Also, as Chris notes, some other MAC algorithms require a random IV to be secure; HMAC does not, so it can be used even in situations where deterministic output is required, or where messages must be kept as short as possible.
As for why you might not want to use HMAC, well, one reason is that it's not really optimized for speed. Dedicated MAC functions, particularly those based on universal hashing (the Carter–Wegman construction) like UMAC and VMAC, can be significantly faster. Also, MACs based on block ciphers (such as CMAC) can be very useful on limited platforms where an efficient block cipher primitive (like AES) is available but a secure hash function is not.
Something else that has not been mentioned before:
Remind the construction of a Merkle Damgard Hash with f the compression function (e.g. MD5, SHA1,2 -- thanks for pointing out my missconception @Ilmari Karonen):
In the following descriptions the function Hmd will be such a Hashfunktion constructed via MD. MAC(k,m) will be the function that protects the message for integrity by using Hmd in one way or another.
Bob is sending an integrity-protected message to Alice:
Bob ---- m, MAC(k,m) ----> Alice
Case 1: MAC(k,m) = HMD(k,m)
Mallory is woman-in-the-middle and catches
Now Mallory can extend
m' = m || mean_extension and create
MAC'(m') = f (MAC(k,m), mean_extention) where f is the compression function used for Merkle Damgard.
When Mallory forwards her generated message:
(m', MAC'(m')) constructed as above, Alice has no possibility to determine the fraud. The MAC looks genuine to her, because it is.
f (MAC (k,m), mean_extention) == MAC (k, m || mean_extension) holds true, with the MAC being a simple Merkle Damgard Hashfunktion.
Case 2: MAC(k,m) = HMAC(k,m) = HMD(k || opad , HMD(k || ipad, m))
Now the structure of the MAC is not providing any possiblity to attack the bad construction of concatenating with the compression function.
f (MAC (k,m), mean_extension) != MAC(k, m || mean_extension) contrary to Case 1, because MAC now is an HMAC constructed as above in the heading.