UMAC is described in full details in RFC 4418.
When the RFC talks about "secret selection", it really means "there is a secret key involved here". UMAC works with universal hashing, which can be viewed as a family of hash functions, and a key which selects which hash function we are talking of. The term "hash function" might be a bit confusing here, because this is not at all the same kind of beast than, say, SHA-256. These "hash functions" would be utterly weak if left alone in the wild.
So UMAC works like this:
- There is a nonce which must be used only once; for each new message a new nonce value must be selected (this is extremely important).
- There are two keys K1 and K2. K1 selects the universal hash function h in its family, while K2 is used in a suitable function which can operate on a block; namely, the AES or another block cipher.
- The input message is processed with h, and the output of h is then encrypted by XORing it with AESK2(nonce).
The idea is that the hash function h (selected by K1) remains "hidden" by the final encryption. Thanks to the nonce, and assuming that the final encryption is decent, successively MACed messages leak no information whatsoever on h to the attacker. This is valid even in the presence of a very lightweight h, much faster than a conventional hash function.
UMAC is not much used by itself, because it is quite recent, and the nonce is a hard requirement, quite similar to IV management for block ciphers. HMAC is much easier, in the sense that it is much harder to get it wrong. UMAC or UMAC-like systems are however quite popular when integrated with encryption, because the nonce/IV requirement can then be shared. This is how OCB and GCM work, for instance.