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

[Magnus Westerlund <[e-mail]>]

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://protect2.fireeye.com/v1/url?k=af38cfe0-f198612d-af388f7b-
> 866132fe445e-0b14f7daf450fdde&q=1&e=3ebbb482-ad3f-42f8-a6b4-
> 338854359aa4&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
> Profile: https://www.linkedin.com/in/petithug