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

[Magnus Westerlund <[e-mail]>]

Hi,

Per discussion for Errata 5059 I think there is an interoperability issue here
due to the change from an implied truncation to using a longer than 160-bits
input that will produce different hashing results. 

I will also note that Appendix B is further suspect as the referenced format has
not yet been published and appears to have made no progress since 2019. 

Thus, I am leaning towards Hold for document update for this one. 

Cheers

Magnus

On Thu, 2020-09-24 at 08:51 -0700, Justin Uberti wrote:
> 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