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

From: RFC Errata System <[email-masked]>
Date: Sun, 30 Aug 2020 08:22:51 -0700 (PDT)

The following errata report has been submitted for RFC8489,
"Session Traversal Utilities for NAT (STUN)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6268

--------------------------------------
Type: Technical
Reported by: Jared Williams <[email-masked]>

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 31 Aug 2020 05:29:59 -0700

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.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 31 Aug 2020 15:08:45 +0000

Hi,

Author's can you please confirm if this is correct or not?

Cheers

Magnus

> "Session Traversal Utilities for NAT (STUN)".
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
> The message length in the test vector (9c) is the absolute length of the whole
> test vector. However from section 5. STUN Message Structure
> 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Mon, 31 Aug 2020 17:00:53 +0000

Hi Magnus -

Marc responded earlier so you may have missed it. Below is his response:

+++++++++++

Thanks.
+++++++++++

Cheers,

Gonzalo

On Aug 31, 2020, at 11:08 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Cheers

Magnus

--------------------------------------
Type: Technical
Reported by: Jared Williams <[email-masked]<mailto:[email-masked]>>

Section: Appendix B.1

Original Text
-------------

Corrected Text
--------------

Notes
-----

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

Author(s)           : M. Petit-Huguenin, G. Salgueiro, J. Rosenberg, D. Wing,
R. Mahy, P. Matthews

Magnus Westerlund

SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 1 Sep 2020 11:04:04 +0000

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:
> > On Aug 31, 2020, at 11:08 AM, Magnus Westerlund <
> > [email-masked]> wrote:
> > 
> > Hi,
> > 
-- 
Cheers

Magnus Westerlund

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 1 Sep 2020 04:42:50 -0700

Hi Magnus,

I'll sent the recalculated test-vector next week-end.

Thanks.

---

From: RenThraysk <[email-masked]>
Date: Tue, 1 Sep 2020 12:44:09 +0100

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 <
[email-masked]> wrote:

> > > > The message length in the test vector (9c) is the absolute length of
> the
> > > > whole
> > > > 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:
> > > > -------------
> > > > Author(s)           : M. Petit-Huguenin, G. Salgueiro, J. Rosenberg,
> D.
> > > > Wing,
> > > > R. Mahy, P. Matthews

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 7 Sep 2020 07:19:11 -0700

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.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 7 Sep 2020 07:21:27 -0700

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.

---

From: RenThraysk <[email-masked]>
Date: Mon, 7 Sep 2020 16:22:30 +0100

Hi

Why has the Userhash value changed from the original test vector?

Jared

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Sep 2020 15:53:03 +0000

Hi,

Jared thanks for reviewing and checking. I also like to have an answer to your 
question before proceeding.

I have updated your Errata with the full message and a slight edit in the 
notes field. Please see:

Please check that this makes sense to you also. And when we have resolved all 
questions about the message then I can verify it.

Cheers

Magnus Westerlund

From: RenThraysk <[email-masked]>
Sent: den 7 september 2020 17:23
To: Marc Petit-Huguenin <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>; [email-masked]; 
[email-masked]; [email-masked]; 
[email-masked]; Gonzalo Camarillo <[email-masked]>; 
[email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Subject: Re: [Technical Errata Reported] RFC8489 (6268)

Hi

Jared

On Mon, Sep 7, 2020 at 3:21 PM Marc Petit-Huguenin <[email-masked] 
<mailto:[email-masked]> > wrote:

Hi Magnus,

<begins>

Thanks.

On 9/1/20 4:04 AM, Magnus Westerlund wrote:
>>> [email-masked] <mailto:[email-masked]> > 
>>> wrote:
>>>
>>> Hi,
>>>
>>> https://protect2.fireeye.com/v1/url?k=99260d6d-c786cf2b-99264df6-86fc6812c361-2320f3daa9544fe5 
>>> <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> 
>>> &q=1&e=c28eb099-e321-4447-80c3-942509fe0974&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6268
>>>> Reported by: Jared Williams <[email-masked] 
>>>> <mailto:[email-masked]> >
>>>>
>>>> Section: Appendix B.1
>>>>
>>>> Original Text
>>>> -------------

-- 
Marc Petit-Huguenin
Email: [email-masked] <mailto:[email-masked]>
Blog: https://marc.petit-huguenin.org 
<https://protect2.fireeye.com/v1/url?k=109b451b-4e3bff75-109b0580-869a14f4b08c-ba0467b0aa98f50b&q=1&e=ca515129-0cc9-4726-bca2-9dc189cbc59f&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F>
Profile: https://www.linkedin.com/in/petithug

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 7 Sep 2020 09:11:01 -0700

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.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Sep 2020 16:13:47 +0000

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 <[email-masked]>
> Sent: den 7 september 2020 18:11
> To: RenThraysk <[email-masked]>
> Cc: Magnus Westerlund <[email-masked]>;
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Gonzalo Camarillo
> <[email-masked]>; [email-masked]; dwing-
> [email-masked]; [email-masked]; [email-masked]
> 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.
>
> >>>> This errata is correct, and there is nobody to blame for that
> >>>> mistake
> >> but me.
> >>>>
> >> 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
> >>>>>> 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.
> >>>>>>
> 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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 7 Sep 2020 09:21:52 -0700

Yes, I will provide text.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 14 Sep 2020 06:15:08 -0700

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:

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

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 14 Sep 2020 07:46:05 -0700

Thank you Marc,
-rohan

On Mon, Sep 14, 2020 at 6:15 AM Marc Petit-Huguenin <[email-masked]>
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:
>
> >>>>>> prepare and review a proposal that fixes this I will edit and
> approve
> >>>>>> it.
> >>>>>>
> >>>>>>>>> "The message length MUST contain the size of the message in
> bytes,
> >>> not

---

From: RenThraysk <[email-masked]>
Date: Mon, 14 Sep 2020 15:47:45 +0100

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Sep 2020 15:53:05 +0000

Hi,

Thanks Marc for the new test vector. 

Thanks Jared for verifying it.

I have updated the Errata with Marc latest test vector. 
https://www.rfc-editor.org/errata_search.php?eid=6268

Please check this.

Jared, I don't understand your request about noting SHA-256 password algorithm.
To me it appears very clear in this section and in the message exactly what
protocol elements are being used. USERHASH and MESSAGE-INTEGRITY-SHA256 are both
clear that they use SHA256. So if you want any change to the note, can you
provide what text you propse? 

B.1.  Sample Request with Long-Term Authentication with MESSAGE-
      INTEGRITY-SHA256 and USERHASH

   This request uses the following parameters:

   Username: "<U+30DE><U+30C8><U+30EA><U+30C3><U+30AF><U+30B9>" (without
   quotes) unaffected by OpaqueString [RFC8265] processing

   Password: "The<U+00AD>M<U+00AA>tr<U+2168>" and "TheMatrIX" (without
   quotes) respectively before and after OpaqueString [RFC8265]
   processing

   Nonce: "obMatJos2AAACf//499k954d6OL34oL9FSTvy64sA" (without quotes)

   Realm: "example.org" (without quotes)

On Mon, 2020-09-14 at 15:47 +0100, RenThraysk wrote:
> 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
> Will open the other 
> errata proposing to strike the line about the right to left bit ordering.
> 
> Jared
> 
> > 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:
> > 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Mobile +46 73 0949079
Torshamnsgatan 23           |
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 23 Sep 2020 14:18:19 +0000

Jared,

Any follow up on the the below question? I would like to conclude on this
Errata.

/Magnus

> I have updated the Errata with Marc latest test vector. 
https://protect2.fireeye.com/v1/url?k=c2b8810a-9c18434c-c2b8c191-86fc6812c361-deb1c6e569244be5&q=1&e=1eef972f-1e6d-4430-97e5-2b968535970d&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata_search.php%3Feid%3D6268
> > On Mon, Sep 14, 2020 at 2:15 PM Marc Petit-Huguenin <[email-masked]
> > >
> > wrote:
> > > userhash
> > > > > 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 
> > > > > > 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.
> > > > > > 
> > > > > > > > > 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
> > > > > > > > > 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:
> > > > > > > > > > 
> > > > > > > > > > +++++++++++
> > > > > > > > > > > > The message length in the test vector (9c) is the
> > > > > > > > > > > > absolute length
> > > > > > > > > > > > of
> > > > > > > > 
> > > > > > > > the
> > > > > > > > > > > > whole
> > > > > > > > > > > > "The message length MUST contain the size of the message
> > > > > > > > > > > > in bytes,
> > > > > > 
> > > > > > not
> > > > > > > > > > > > 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
> > > > > > > > > > > > Author(s)           : M. Petit-Huguenin, G. Salgueiro,
> > > > > > > > > > > > J.
> > > 
> > > Rosenberg,
> > > > > > > > D.
> > > > > > > > > > > > Wing,
> > > > > > > > > > > > R. Mahy, P. Matthews
-- 
Cheers

Magnus Westerlund

---

From: RenThraysk <[email-masked]>
Date: Wed, 23 Sep 2020 17:58:38 +0100

Hi

Apologies for the delay.

Yes, MESSAGE-INTEGRITY-SHA256 and USERHASH both explicitly specify using
SHA256.
However this RFC adds some agility to computing the long term HMAC key used
to compute the MESSAGE-INTEGRITY-SHA256.
See https://tools.ietf.org/html/rfc8489#section-18.5

If using MESSAGE-INTEGRITY-SHA256 implies that the SHA-256 algorithm (
https://tools.ietf.org/html/rfc8489#section-18.5.1.2 ) then it's not clear
in the RFC.
If it doesn't imply how the key is generated then suggest adding following
line to the test vector parameters

"MESSAGE-INTEGRITY-SHA256 long term key algorithm: SHA-256"

Jared.

On Wed, Sep 23, 2020 at 3:18 PM Magnus Westerlund <
[email-masked]> wrote:

> > protocol elements are being used. USERHASH and MESSAGE-INTEGRITY-SHA256
> are
> > both
> > > > > > > > >       70 6c 65 2e   }  Realm value (11 bytes) and padding
> (1
> > > > > > > > > byte)
> > > > > > > > >       6f 72 67 00   }
> > > > > > > > > > > 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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > please use "Reply All" to discuss whether it
> should be
> > > > > > > > > > > > > verified
> > > > > > > > > > > > > or rejected. When a decision is reached, the
> verifying
> > > > > > > > > > > > > party can
> > > > > > > > > > > > > Title               : Session Traversal Utilities
> for
> > > > > > > > > > > > > NAT (STUN)

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 25 Sep 2020 07:56:43 +0000

Hi Jared,

Thanks for the clarification. Section 9.2.3.2. (Subsequent Requests) states

When the client sends a subsequent
   request, it MUST include either the USERNAME or USERHASH, REALM,
   NONCE, and PASSWORD-ALGORITHM attributes with these cached values.

So my interpretation is that this Binding Request (sub sequent) is lacking the
PASSWORD-ALGORITHM attribute. In Section 9.2.4 also states:

      *  If the request contains neither the PASSWORD-ALGORITHMS nor the
         PASSWORD-ALGORITHM algorithm, then the request is processed as
         though PASSWORD-ALGORITHM were MD5.

I think the discrepancy between the requirement on sending and what to do when
receiving the request comes from backwards compatibility. But there are no
reason that the B.1 should not contain the mandated PASSWORD-ALGORITHM
attribute.

Thus, it looks like the Appendix B.2 initial text should be clarified with:

1. That this is a subsequent binding request (for context setting). 
2. Make it clear that it is using SHA-256 as password alrgorithm, and thus
PASSWORD-ALGORITH: Algorithm = 0x0002 (SHA-256)
3. Update the message and its integrity to contain a PASSWORD-ALGORITHM

Authors, are you concurring?

Cheers

Magnus

On Wed, 2020-09-23 at 17:58 +0100, RenThraysk wrote:
> However this RFC adds some agility to computing the long term HMAC key used to
> compute the MESSAGE-INTEGRITY-SHA256.
> https://tools.ietf.org/html/rfc8489#section-18.5.1.2 ) then it's not clear in
> the RFC.
> > > > > > > > > > > > > > please use "Reply All" to discuss whether it should
> > be
> > > > > > > > > > > > > > verified
-- 
Cheers

Magnus Westerlund

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 28 Sep 2020 03:22:38 -0700

I do not concur.

Appendix B clearly states that this test vector augments the ones in RFC 5769, and RFC 5769 also clearly states in its abstract that "[t]he content of some of these [attributes] --  FINGERPRINT, MESSAGE-INTEGRITY, and XOR-MAPPED-ADDRESS -- involve binary-logical operations (hashing, xor).  This document provides test vectors for those attributes."

In other words this is not an example of STUN message, but an example of attributes encoding, namely USERHASH and MESSAGE-INTEGRITY-SHA256.

So it does not matter if the message is incorrect, it still fulfills the reason it was created which is to show a correct encoding of these attributes.  Even the message length errata is not really necessary, as the MESSAGE-INTEGRITY-SHA256 was still correct.

Now there may be a need for a separate document that contains STUN and STUN usages call flows, with correctly encoded messages, but that's a completely different topic.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 28 Sep 2020 14:36:52 +0000

Hi,

A question here. Is the key used in the MESSAGE-INTEGRITY-SHA256 the MD5 derived
one, or one derived using SHA256? If it is the former, then fine the lets just
add a sentence of clarification as the option exist. But, Jared's previous
comments appear to indicate the the key for the HMAC-SHA256 used in the
intergrity was derived using SHA256. If it is the later, then I don't see any
option than to include the password algorithm attribute and its algorithm
indicator as it is a necessary component to correctly derive the key and thus
being able to verify the MESSAGE-INTEGRITY. 

I am just trying to ensure that the necessary information to be able to take
this as test vector for this specific purpose actually works. But I think it
needs to follow the updated version of STUN this RFC actually describe, not the
old one.

Cheers

Magnus

On Mon, 2020-09-28 at 03:22 -0700, Marc Petit-Huguenin wrote:
> I do not concur.
> 
> Appendix B clearly states that this test vector augments the ones in RFC 5769,
> and RFC 5769 also clearly states in its abstract that "[t]he content of some
> of these [attributes] --  FINGERPRINT, MESSAGE-INTEGRITY, and XOR-MAPPED-
> ADDRESS -- involve binary-logical operations (hashing, xor).  This document
> provides test vectors for those attributes."
> 
> In other words this is not an example of STUN message, but an example of
> attributes encoding, namely USERHASH and MESSAGE-INTEGRITY-SHA256.
> 
> So it does not matter if the message is incorrect, it still fulfills the
> reason it was created which is to show a correct encoding of these
> attributes.  Even the message length errata is not really necessary, as the
> MESSAGE-INTEGRITY-SHA256 was still correct.
> 
> Now there may be a need for a separate document that contains STUN and STUN
> usages call flows, with correctly encoded messages, but that's a completely
> different topic.
> 
> > > in
> > > > > To me it appears very clear in this section and in the message exactly
> > > > 
> > > > what
> > > > > > Ok, this is using the SHA256 Password Algorithm, so I suggest that
> > > > 
> > > > should be
> > > > > > 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 <
> > > > 
> > > > [email-masked]
> > > > > > > 
> > > > > > 
> > > > > > wrote:
> > > > > > > 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
> > > > > > > I think that the note in the errata is fine (after updating the
> > > > > > > test-
> > > > > > > vector).
> > > > > > > 
> > > > > > > > > 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
> > > > > > > > > 
> > > > > > > > > > [email-masked]; [email-masked]; Gonzalo
> > > > 
> > > > Camarillo
> > > > > > > > > > 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.
> > > > > > > > > > 
> > > > > > > > > > > Why has the Userhash value changed from the original test
> > > > 
> > > > vector?
> > > > > > > > > > > 
> > > > > > > > > > > Jared
> > > > > > > > > > > 
> > > > > > > > > > > >       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   }
> > > > > > > > > > > > > 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:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 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
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > Marc responded earlier so you may have missed it.
> > > > > > > > > > > > > > Below
> > > > 
> > > > is
> > > > > > > > > > > > > > his
> > > > > > > > > > 
> > > > > > > > > > response:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > +++++++++++
> > > > > > > > > > > > > > > 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,
> > > > > > > > > > > > > > > > test vector. However from section 5. STUN
> > > > > > > > > > > > > > > > Message
> > > > > > > > > > > > > > > > Structure
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > "The message length MUST contain the size of the
> > > > 
> > > > message
> > > > > > > > > > > > > > > > in bytes,
> > > > > > > > > > 
> > > > > > > > > > not
> > > > > > > > > > > > > > > > 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
> > > > > > > > > > > > > > > > This erratum is currently posted as "Reported".
> > > > > > > > > > > > > > > > If
> > > > > > > > > > > > > > > > necessary,
> > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > log in to change the status and edit the report,
> > > > > > > > > > > > > > > > if
> > > > > > > > > > > > > > > > necessary.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Author(s)           : M. Petit-Huguenin, G.
> > > > 
> > > > Salgueiro,
> > > > > > > > > > > > > > > > J.
> > > > > > > 
> > > > > > > Rosenberg,
> > > > > > > > > > > > D.
> > > > > > > > > > > > > > > > Wing,
> > > > > > > > > > > > > > > > R. Mahy, P. Matthews
-- 
Cheers

Magnus Westerlund

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 28 Sep 2020 07:54:40 -0700

SHA256.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 30 Sep 2020 08:45:41 +0000

> > being able to verify the MESSAGE-INTEGRITY. 

So in this case then the PASSWORD-ALGORITM attribute is required unless I
missinterpret the RFC. I understand that there is some work in preparing the
message and calculate the integrity. However, in this case it is necessary
information and a mandated value so can you please prepare a new message with
the attribute include indicating the correct value?

Cheers

Magnus Westerlund

---

From: RenThraysk <[email-masked]>
Date: Wed, 30 Sep 2020 13:58:10 +0100

Here is the test vector generated from my code,
https://github.com/renthraysk/stun/blob/master/rfc8489_test.go (rest of
package is still a work in progress)

00 01 00 90     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 1d 00 04     PASSWORD-ALGORITHM attribute header
00 02 00 00     PASSWORD-ALGORITHM value, SHA-256 (0x0002), and parameters
length, 0.
00 1c 00 20     MESSAGE-INTEGRITY-SHA256 attribute header
b5 c7 bf 00  }
5b 6c 52 a2  }
1c 51 c5 e8  }
92 f8 19 24  }  HMAC-SHA256 value
13 62 96 cb  }
92 7c 43 14  }
93 09 27 8c  }
c6 51 8e 65  }

Jared

On Wed, Sep 30, 2020 at 9:45 AM Magnus Westerlund <
[email-masked]> wrote:

> > > A question here. Is the key used in the MESSAGE-INTEGRITY-SHA256 the
> MD5
> > > derived
> > > one, or one derived using SHA256? If it is the former, then fine the
> lets
> > > just
> > > intergrity was derived using SHA256. If it is the later, then I don't
> see
> > > any
> > > indicator as it is a necessary component to correctly derive the key
> and
> > > thus