RFC Errata
Found 4 records.
Status: Reported (2)
RFC 7635, "Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization", August 2015
Source of RFC: tram (tsv)
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.
Status: Held for Document Update (2)
RFC 7635, "Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization", August 2015
Source of RFC: tram (tsv)
Errata ID: 4826
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mihály Mészáros
Date Reported: 2016-10-10
Held for Document Update by: Magnus Westerlund
Date Held: 2021-01-14
Section 8. says:
8. STUN Client Behavior
o The client looks for the MESSAGE-INTEGRITY attribute in the
response. If MESSAGE-INTEGRITY is absent or the value computed
for message integrity using mac_key does not match the contents of
the MESSAGE-INTEGRITY attribute, then the response MUST be
discarded.
o If the access token expires, then the client MUST obtain a new
token from the authorization server and use it for new STUN
requests.
It should say:
8. STUN Client Behavior
o The client looks for the MESSAGE-INTEGRITY attribute in the
response. If MESSAGE-INTEGRITY is absent or the value computed
for message integrity using mac_key does not match the contents of
the MESSAGE-INTEGRITY attribute, then the response MUST be
discarded.
9. Application (OAuth Client) Behavior
o If the access token expires, then the Application (OAuth client)
MUST obtain a new token from the authorization server, and update
STUN client to use it for new STUN requests.
o Application SHOULD pass only a subset of the received OAuth
parameters to the STUN client. Only parameters SHOULD be passed
that will be really needed and used by the STUN Client.
In this way, only the kid, the mac_key, and the access_token
parameters SHOULD be passed to the STUN client.
...
Renumber the sections
...
Notes:
1. Remove from STUN client behaviour the access_token renewal function,
and move this function up to application level.
2. Pass to STUN only that subset of the OAuth parameters, that will be really used by STUN Client.
Errata ID: 4923
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mészáros Mihály
Date Reported: 2017-02-03
Held for Document Update by: Magnus Westerlund
Date Held: 2021-01-14
Section Appendix B. says:
"key":"v51N62OM65kyMvfTI08O"
It should say:
"key": "ew0KICAgICJrdHkiOiJvY3QiLA0KICAgICJ
raWQiOiJpZDEyMyIsDQogICAgImFsZyI6IkhTMjU2IiwNCiAgIC
AiayI6IlpvUlNPckZ6Tl9GelVBNVhLTVlvVkh5emZmNW9SSnhsL
UlYUnR6dEo2dUUiDQp9"
Notes:
"key" according https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-4.2
"The 'key' parameter either contains a plain JWK structure or a JWK encrypted with a JWE."
According Example Figure 2. "key" in draft-ietf-oauth-pop-key-distribution-02#section-4.2
It seems they missed to write plain JWK MUST be base64 format.
So according the example coorected the above sentence:
"The 'key' parameter either contains a plain BASE64 ENCODED JWK structure or a JWK encrypted with a JWE."
Anyhow in RFC7635 Appendix B. the
"key" seems to be not in base64 (JWK) or JWE encrypted JWK format.
(Base64 decoded key value string is "Salted__"....)