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

[Magnus Westerlund <[e-mail]>]

Hi,

I would appreciate some response regarding this Errata. Should it be verified,
held for document update, or rejected? 

Cheers

Magnus Westerlund

On Wed, 2017-07-05 at 16:35 -0700, RFC Errata System wrote:
> 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 <[e-mail]>
> 
> 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
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Mobile [phone]
Torshamnsgatan 23           |
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------