Re: [tram] [Technical Errata Reported] RFC8489 (6268)

[RenThraysk <[e-mail]>]

Hi,

I reported this errata, but also think there may be another problem, and
wanted to verify.
I think the Security Feature bits encoded into the test vector Nonce
attribute are incorrect.

In the B.1 Test Vector <https://tools.ietf.org/html/rfc8489#appendix-B>
this is encoded in base64 digits as AAAC or decoded into decimal 0, 0, 0, 2.

In 18.1.  STUN Security Features Registry
<https://tools.ietf.org/html/rfc8489#section-18.2>

A STUN Security Feature set defines 24 bits as flags.

   IANA has created a new registry containing the STUN Security Features
   that are protected by the bid-down attack prevention mechanism
   described in Section 9.2.1.

   The initial STUN Security Features are:

   Bit 0: Password algorithms
   Bit 1: Username anonymity
   Bit 2-23: Unassigned


*Bits are assigned starting from the most significant side of the bit
 set, so Bit 0 is the leftmost bit and Bit 23 is the rightmost bit.*

If bits are counted left to right, I don't see how AAAC is correct.

Cheers

Jared

On Tue, Sep 1, 2020 at 12:04 PM Magnus Westerlund <
[e-mail]> wrote:

> Hi,
>
> I think it is reasonable that we do an RFC Errata for this error to
> provide a
> corrected test vector.
>
> I can edit the Errata request to have a different text. So if you authors
> could
> prepare and review a proposal that fixes this I will edit and approve it.
>
> So if you can provide the text that goes into the three parts:
>
> Original Text: (I assume the full message from B.1 here)
>
> Corrected Text: Full message with corrected message length and recomputed
> Hash
> value.
>
> Notes: If there are any additional that was already written that you like
> to
> remark about this error?
>
> Cheers
>
> Magnus
>
> On Mon, 2020-08-31 at 17:00 +0000, Gonzalo Salgueiro (gsalguei) wrote:
> > Hi Magnus -
> >
> > Marc responded earlier so you may have missed it. Below is his response:
> >
> > +++++++++++
> > This errata is correct, and there is nobody to blame for that mistake
> but me.
> >
> > Magnus, how to you want to proceed for the recomputed test vector?
> >
> > Thanks.
> > +++++++++++
> >
> > Cheers,
> >
> > Gonzalo
> >
> >
> > > On Aug 31, 2020, at 11:08 AM, Magnus Westerlund <
> > > [e-mail]> wrote:
> > >
> > > Hi,
> > >
> > > Author's can you please confirm if this is correct or not?
> > >
> > > Cheers
> > >
> > > Magnus
> > >
> > > On Sun, 2020-08-30 at 08:22 -0700, RFC Errata System wrote:
> > > > The following errata report has been submitted for RFC8489,
> > > > "Session Traversal Utilities for NAT (STUN)".
> > > >
> > > > --------------------------------------
> > > > You may review the report below and at:
> > > >
> > >
> > >
> https://protect2.fireeye.com/v1/url?k=99260d6d-c786cf2b-99264df6-86fc6812c361-2320f3daa9544fe5&q=1&e=c28eb099-e321-4447-80c3-942509fe0974&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6268
> > > > --------------------------------------
> > > > Type: Technical
> > > > Reported by: Jared Williams <[e-mail]>
> > > >
> > > > Section: Appendix B.1
> > > >
> > > > Original Text
> > > > -------------
> > > > 00 01 00 9c      Request type and message length
> > > >
> > > >
> > > > Corrected Text
> > > > --------------
> > > > 00 01 00 88      Request type and message length
> > > >
> > > > Notes
> > > > -----
> > > > The message length in the test vector (9c) is the absolute length of
> the
> > > > whole
> > > > test vector. However from section 5. STUN Message Structure
> > > >
> > > > "The message length MUST contain the size of the message in bytes,
> not
> > > >   including the 20-byte STUN header."
> > > >
> > > > So the message length in the header should be 20 less than absolute
> length
> > > > of
> > > > the whole message.
> > > >
> > > > 0x9C - 20, 0x88.
> > > >
> > > > Also the MESSAGE-INTEGRITY-SHA256 HMAC-SHA256 value of the Test
> Vector
> > > > will
> > > > need recomputing.
> > > >
> > > > 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.
> > > >
> > > > --------------------------------------
> > > > RFC8489 (draft-ietf-tram-stunbis-21)
> > > > --------------------------------------
> > > > Title               : Session Traversal Utilities for NAT (STUN)
> > > > Publication Date    : February 2020
> > > > Author(s)           : M. Petit-Huguenin, G. Salgueiro, J. Rosenberg,
> D.
> > > > Wing,
> > > > R. Mahy, P. Matthews
> > > > Category            : PROPOSED STANDARD
> > > > Source              : TURN Revised and Modernized
> > > > Area                : Transport
> > > > Stream              : IETF
> > > > Verifying Party     : IESG
> > >  --
> > > Cheers
> > >
> > > Magnus Westerlund
> > >
> > >
> > > ----------------------------------------------------------------------
> > > Networks, Ericsson Research
> > > ----------------------------------------------------------------------
> > > Ericsson AB                 | Phone  [phone]
> > > Torshamnsgatan 23           | Mobile [phone]
> > > SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> > > ----------------------------------------------------------------------
> >
> >
> --
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>
>