Yeah, a message less than blocksize bytes is padded with 0's, and a message greater than blocksize bytes is hashed to blocksize bytes. It "follows" just as much as Little MAC, is about as security relevant, and is no less clever (arguably a bit more).
HMAC keys are exactly one block long. But lets say an app wants to have a key that's two blocks long. No big deal, hash that app key and now two is one.
Ah, but now let's say the attacker has control of input keys. He can provide both the two block key which HMAC will hash for him, or he can do the work himself and prehash the two into one. Now two different input keys seem to provide the same output (assuming identical messages, of course).
You're right. HMAC keys, from the internal hash perspective, are always one block long. So if the key coming into HMAC is less than blocksize, it's zero padded to blocksize. And if the key coming into HMAC is length greater than blocksize, it's hashed down to blocksize. Obviously this does create collisions if the key ends with nulls and is less than 64 bytes, or if the attacker can specify keys.
