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

[RenThraysk <[e-mail]>]

Hi

Ok, this is using the SHA256 Password Algorithm, so I suggest that should
be noted in the errata as part of the parameters listed in B.1
But can now successfully create the test vector from my code.

Will open the other errata proposing to strike the line about the right to
left bit ordering.

Jared

On Mon, Sep 14, 2020 at 2:15 PM Marc Petit-Huguenin <[e-mail]>
wrote:

> 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
>