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

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

Yes, I will provide text.

On 9/7/20 9:13 AM, Magnus Westerlund wrote:
> Hi,
> 
> I will hold, but please consider if you directly have any text proposal for 
> the note part of the errata to explain the changes that are in there and if we 
> need to change the text above the message itself to clarify thingS?
> 
> Cheers
> 
> Magnus
> 
>> -----Original Message-----
>> From: Marc Petit-Huguenin <[e-mail]>
>> Sent: den 7 september 2020 18:11
>> To: RenThraysk <[e-mail]>
>> Cc: Magnus Westerlund <[e-mail]>;
>> [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; Gonzalo Camarillo
>> <[e-mail]>; [e-mail]; dwing-
>> [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: [Technical Errata Reported] RFC8489 (6268)
>>
>> That's a good question.  We changed the username after we discovered that
>> the one I used previously was in fact invalid with the new PRECIS rules, but 
>> I
>> am not sure why the one in the RFC is different.  I'll have to look into my
>> archives to find exactly what is what, but that will have to wait until next
>> Monday morning.
>>
>> Meanwhile, Magnus, please hold on the errata modification.
>>
>> Thanks.
>>
>>
>> On 9/7/20 8:22 AM, RenThraysk wrote:
>>> Hi
>>>
>>> Why has the Userhash value changed from the original test vector?
>>>
>>> Jared
>>>
>>> On Mon, Sep 7, 2020 at 3:21 PM Marc Petit-Huguenin
>>> <[e-mail]>
>>> wrote:
>>>
>>>> Hi Magnus,
>>>>
>>>> Here's the corrected test-vector:
>>>>
>>>> <begins>
>>>>       00 01 00 88      Request type and message length
>>>>       21 12 a4 42      Magic cookie
>>>>       78 ad 34 33   }
>>>>       c6 ad 72 c0   }  Transaction ID
>>>>       29 da 41 2e   }
>>>>       00 1e 00 20      USERHASH attribute header
>>>>       63 aa 09 fc   }
>>>>       23 81 0a 46   }
>>>>       c9 76 e9 59   }
>>>>       23 10 ee 1e   }  Userhash value (32 bytes)
>>>>       59 b7 06 e1   }
>>>>       9d e1 bd 21   }
>>>>       a9 f6 f7 40   }
>>>>       28 d5 ba 71   }
>>>>       00 15 00 29      NONCE attribute header
>>>>       6f 62 4d 61   }
>>>>       74 4a 6f 73   }
>>>>       32 41 41 41   }
>>>>       43 66 2f 2f   }
>>>>       34 39 39 6b   }  Nonce value and padding (3 bytes)
>>>>       39 35 34 64   }
>>>>       36 4f 4c 33   }
>>>>       34 6f 4c 39   }
>>>>       46 53 54 76   }
>>>>       79 36 34 73   }
>>>>       41 00 00 00   }
>>>>       00 14 00 0b      REALM attribute header
>>>>       65 78 61 6d   }
>>>>       70 6c 65 2e   }  Realm value (11 bytes) and padding (1 byte)
>>>>       6f 72 67 00   }
>>>>       00 1c 00 20      MESSAGE-INTEGRITY-SHA256 attribute header
>>>>       8e 57 3d 97   }
>>>>       75 33 21 ae   }
>>>>       47 8c b6 a2   }
>>>>       7b 8a 6b 3a   }  HMAC-SHA256 value
>>>>       89 08 9e e1   }
>>>>       5f 62 6b 38   }
>>>>       40 9f 48 ed   }
>>>>       47 a5 df 57   }
>>>> <ends>
>>>>
>>>> Thanks.
>>>>
>>>> On 9/1/20 4:04 AM, Magnus Westerlund 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-86fc
>>>> 6812c361-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
>>>>>>>
>>>>>>>
>>>>
>>


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