RFC Errata
RFC 7635, "Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization", August 2015
Source of RFC: tram (tsv)
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.