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

[Justin Uberti <[e-mail]>]

This looks correct to me at first glance. Will re-read in context and give
a definitive answer.

On Wed, Sep 23, 2020 at 7:22 AM Magnus Westerlund <
[e-mail]> wrote:

> 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]
> ----------------------------------------------------------------------
>
>