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

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

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.

On 9/25/20 12:56 AM, Magnus Westerlund wrote:
> 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:
>> 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 <
>> [e-mail]> wrote:
>>> Jared,
>>>
>>> Any follow up on the the below question? I would like to conclude on this
>>> Errata.
>>>
>>> /Magnus
>>>
>>> On Mon, 2020-09-14 at 15:53 +0000, Magnus Westerlund wrote:
>>>> Hi,
>>>>
>>>> Thanks Marc for the new test vector. 
>>>>
>>>> Thanks Jared for verifying it.
>>>>
>>>> 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
>>>>
>>>> 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
>>>>> 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