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

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

After looking at the emails exchanged at that time, the reason the userhash was different was because we tentatively changed the username during AUTH48, then decided to use the original one, but my code got stuck with the new username.  I updated the code and the test-vector is now:

      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
      4a 3c f3 8f   }
      ef 69 92 bd   }
      a9 52 c6 78   }
      04 17 da 0f   }  Userhash value (32 bytes)
      24 81 94 15   }
      56 9e 60 b2   }
      05 c4 6e 41   }
      40 7f 17 04   }
      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
      23 41 12 fb   }
      d4 e2 7f 98   }
      3e b4 03 28   }
      36 f9 98 21   }  HMAC-SHA256 value
      6f 5b 23 f8   }
      d9 27 75 3f   }
      bc 4f 88 2b   }
      fb df 0d ec   }


I think that the note in the errata is fine (after updating the test-vector).

Let's open a separate errata for the other issue.

Thanks.


On 9/7/20 9:21 AM, Marc Petit-Huguenin wrote:
> 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