Found 2 records.

Status: Reported (2)

RFC 7635, "Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization", August 2015

Errata ID: 5059
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Taylor Brandstetter
Date Reported: 2017-07-05

Section 6.2 says:

   key_length:  Length of the session key in octets.  The key length of
      160 bits MUST be supported (i.e., only the 160-bit key is used by
      HMAC-SHA-1 for message integrity of STUN messages).  The key
      length facilitates the hash agility plan discussed in Section 16.3
      of [RFC5389].

It should say:

   key_length:  Length of the session key in octets.

Notes:

RFC2104 section 2 states:

The authentication key K can be of any length up to B, the
block length of the hash function. 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.

Meaning any key length is allowed. The fact that the hash output is 20 bytes doesn't mean the key needs to be 20 bytes as well.

Errata ID: 5060
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Taylor Brandstetter
Date Reported: 2017-07-05

Section Appendix B says:

   [STUN] supports hash agility and accomplishes this agility by
   computing message integrity using both HMAC-SHA-1 and
   HMAC-SHA-256-128.  The client signals the algorithm supported by it
   to the authorization server in the 'alg' parameter defined in
   [POP-KEY-DIST].  The authorization server determines the length of
   the mac_key based on the HMAC algorithm conveyed by the client.  If
   the client supports both HMAC-SHA-1 and HMAC-SHA-256-128, then it
   signals HMAC-SHA-256-128 to the authorization server, gets a 256-bit
   key from the authorization server, and calculates a 160-bit key for
   HMAC-SHA-1 using SHA1 and taking the 256-bit key as input.

It should say:

   [STUN] supports hash agility and accomplishes this agility by
   computing message integrity using both HMAC-SHA-1 and
   HMAC-SHA-256-128.  The client signals the algorithm supported by it
   to the authorization server in the 'alg' parameter defined in
   [POP-KEY-DIST].  The authorization server determines the length of
   the mac_key based on the HMAC algorithm conveyed by the client.  If
   the client supports both HMAC-SHA-1 and HMAC-SHA-256-128, then it
   signals HMAC-SHA-256-128 to the authorization server, and gets a
   256-bit key from the authorization server, which can be used to
   compute both the HMAC-SHA-1 and HMAC-SHA-256-128 hashes. If the
   client only supports HMAC-SHA-1, the authorization server could
   return a 160-bit key, as keys longer than the HMAC-SHA-1 output
   size of 160-bits would not significantly increase the function's
   strength.

Notes:

The SHA-1 block size is 512 bits, so a 256-bit key does not need to be shortened to compute a HMAC-SHA-1 hash.

Also added an example for "if the client only supports HMAC-SHA-1", to make the hash agility logic more clear.

Report New Errata