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

[Marc Petit-Huguenin <[e-mail]>]

Hi Jared,

Yes, in that case this is the text that is incorrect but the test-vector is correct.  In fact one of our co-author reported this during AUTH48, but I failed to act on it.

"Bits are assigned starting from the least significant side of the bitset, so Bit 0 is the rightmost bit and Bit 23 is the leftmost bit."

Please open a errata for this, thanks.

On 9/1/20 4:44 AM, RenThraysk wrote:
> 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]
>> ----------------------------------------------------------------------
>>
>>
>>
> 


-- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug