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

[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: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
> --
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Mobile [phone]
> Torshamnsgatan 23           |
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>
>