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

[Magnus Westerlund <[e-mail]>]

Hi,

Having read this together with Errata 5060 I think there is an issue with this
errata. And this issue could result in an interoperability issue. 

So yes, HMAC function is specified so that it can use any key-length. However,
to ensure interoperability it is clear that both message orignator and receiver
need to use the same key and the same number of bits as input. The proposed
errata does not ensure that the same number of bits are used and I believe could
cause an issue between a SHA-1 based (Pre RFC 8489 implementation) and one that
would follow this errata. This as one can interpret the origianl text to say
that one shall truncate the key to 160-bits prior to input rather than giving
the full key to HMAC. 

With the transition to SHA-256 based HHAC per RFC 8489 I think this document
needs further clarification. We are now going outside of the permit of Errata.

Cheers

Magnus

On Wed, 2021-01-13 at 15:43 +0000, Magnus Westerlund wrote:
> 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:
> > > > 
https://protect2.fireeye.com/v1/url?k=d9fdc0e8-8666f9ac-d9fd8073-861d41abace8-c128c9abae0b391d&q=1&e=da3ac0e2-12bc-4932-b319-61abe19ea2aa&u=http%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5059
> > > > 
> > > > --------------------------------------
> > > > 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
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram