RFC 2104, "HMAC: Keyed-Hashing for Message Authentication", February 1997Source of RFC: ipsec (sec)
Errata ID: 4809
Status: Held for Document Update
Publication Format(s) : TEXT
Reported By: Erdem Memisyazici
Date Reported: 2016-09-23
Held for Document Update by: Stephen Farrell
Date Held: 2017-02-03
Section 2 says:
Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC.
It should say:
Applications MUST not use keys longer than B bytes.
Using this approach creates an exploitable vulnerability where there are two known K instances, one the hashed key, and the other the key itself. As shown in the sample Java code below:
final byte keyBytes = KEY.getBytes();
final byte sha1 = HashUtil.sha1(keyBytes);
final String a = hmac_sha1(keyBytes, TEXT);
final String b = hmac_sha1(sha1, TEXT);
As demonstrated a equals b. To cite a real world vulnerability; for all keys longer than B, using password storage configurations which store the hash of the key for integrity checks, and store the key itself in a tamper proof device, there will exist plain text keys stored on both storage systems. Compromising a hash database should not reveal plain text secrets, which will only be true if an implementation first hashes the key and uses the resultant L byte string as the actual key to HMAC.
I suggest simply not allowing keys longer than B bytes, which will greatly improve the security of the standard.
Verifier notes: I started a thread  on the CFRG mailing list to discuss this. My reading of that thread leads me to conclude there there's consensus to not verify the erratum on the basis that the threat isn't that significant and a backwards incompatible change as would be required is not justified. However, if HMAC were to be updated in a manner that didn't require backwards compatibility then one would likely consider this. Hence marking this as "hold for document update"