Subject: [tram] [Technical Errata Reported] RFC7635 (5060)

From: RFC Errata System <[email-masked]>
Date: Wed, 5 Jul 2017 16:35:08 -0700 (PDT)

The following errata report has been submitted for RFC7635,
"Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5060

--------------------------------------
Type: Technical
Reported by: Taylor Brandstetter <[email-masked]>

Section: Appendix B

Original Text
-------------
   [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.

Corrected Text
--------------
   [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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7635 (draft-ietf-tram-turn-third-party-authz-16)
--------------------------------------
Title               : Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization
Publication Date    : August 2015
Author(s)           : T. Reddy, P. Patil, R. Ravindranath, J. Uberti
Category            : PROPOSED STANDARD
Source              : TURN Revised and Modernized
Area                : Transport
Stream              : IETF
Verifying Party     : IESG