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

[Magnus Westerlund <[e-mail]>]

Hi,

I would like to conclude on this. Can I verify it?

Cheers

Magnus 

On Thu, 2020-09-24 at 08:50 -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:26 -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/eid5059
> > > 
> > > --------------------------------------
> > > Type: Technical
> > > Reported by: Taylor Brandstetter <[e-mail]>
> > > 
> > > Section: 6.2
> > > 
> > > Original Text
> > > -------------
> > >    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].
> > > 
> > > 
> > > Corrected Text
> > > --------------
> > >    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.
> > > 
> > > 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