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

Marc Petit-Huguenin <petithug@acm.org> Mon, 28 September 2020 10:22 UTC

Return-Path: <petithug@acm.org>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367823A0BC0 for <tram@ietfa.amsl.com>; Mon, 28 Sep 2020 03:22:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.447
X-Spam-Level:
X-Spam-Status: No, score=-1.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB-nrN9WdDBj for <tram@ietfa.amsl.com>; Mon, 28 Sep 2020 03:22:54 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036CA3A0C21 for <tram@ietf.org>; Mon, 28 Sep 2020 03:22:53 -0700 (PDT)
Received: from [IPv6:2601:648:8400:8e7d:be61:f3f1:add5:158e] (unknown [IPv6:2601:648:8400:8e7d:be61:f3f1:add5:158e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id F0732AE28C; Mon, 28 Sep 2020 12:22:49 +0200 (CEST)
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "renthraysk@gmail.com" <renthraysk@gmail.com>
Cc: "tram@ietf.org" <tram@ietf.org>, "jdrosen@jdrosen.net" <jdrosen@jdrosen.net>, "dwing-ietf@fuggles.com" <dwing-ietf@fuggles.com>, "rohan.ietf@gmail.com" <rohan.ietf@gmail.com>, "philip_matthews@magma.ca" <philip_matthews@magma.ca>, "martin.h.duke@gmail.com" <martin.h.duke@gmail.com>
References: <20200830152251.37CA9F4076B@rfc-editor.org> <bd82edbe82f83f7c92c6cb21924951d35132768f.camel@ericsson.com> <B09AFC19-A790-46C5-A97B-69572411A229@cisco.com> <7bbe51fd9a5a226752597825f276f6baad70add7.camel@ericsson.com> <f48eb512-5c17-20bd-dfd6-2d368e9fd4b9@petit-huguenin.org> <CABNgG1g3Tx1QroP+eo+WeQXxD2XPvf+n67pekBqRi8+QzgX8_Q@mail.gmail.com> <65838ad3-7ee9-3339-1326-8c2d212f6fa6@petit-huguenin.org> <HE1PR0702MB3772F26F7B3E91B8DC6982D695280@HE1PR0702MB3772.eurprd07.prod.outlook.com> <d0498051-d762-855d-bf74-d65a8bdf88da@petit-huguenin.org> <b3cae3bd-2b7f-d8c5-fcb4-55be9f11a3ce@petit-huguenin.org> <CABNgG1hzNyM-qqCpprXBUJ4y-X7OOMZHK72wpPL_rJ+TLXrz-g@mail.gmail.com> <4803aae689ab3839beb9f2a65762001495bc31f8.camel@ericsson.com> <4fb78f8080c69a727fb392d1c4462ffa63fe45c2.camel@ericsson.com> <CABNgG1gXeekROCX4_aHo4RYX8fZg6b967AZEPRRhxTH9PxQdGA@mail.gmail.com> <78fdd4cae92837f303b13e5d9412467fdecca870.camel@ericsson.com>
From: Marc Petit-Huguenin <petithug@acm.org>
Autocrypt: addr=petithug@acm.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtCZNYXJjIFBldGl0 LUh1Z3VlbmluIDxwZXRpdGh1Z0BhY20ub3JnPokCOAQTAQgAIgIbIwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AFAlfy11wACgkQKcRFldZqfsRWqBAAu/61DGo+j38UefTKnEse0mftPBXa S4lre7vknn33MI0L5QXmiM8zRs9FOKSuXPx0EV+JhI4pWZGW/2MJPuyifXHvnIChcdGInN8J GBdTLZSOgdDFZL9msO+QUsvMA8ZUsqlKOEcVL1NyoLupblCWNq4fYhBCx1zDwX9LZSuGn8lZ Mk8a4QFGoR6dWKaOxeCwnoquW5IK1CfRIhYjHfQMjA5gY0H46F0iCqBaFF/S7krQwIJd0XN4 YbSL4KOrWuxtgQ+iH/iaxxBXgJ1blBNRzXaWJBF4PHv23nSnEzWO17j+uVMaHJu7ycYEf8T9 pVc0xcok1BM2rCrNE5FUFAzsUtAtBZEEK6sSIeOhRG93uD/Hv1hrWzEwf+Z7B1tVQLCQQ4kL 7wyS7SXI/JTuW2xTEGCmwMeWYGERdkgsatmx4zi5nVHDjt3/mlPMj4L+u05SkI2iV4W6xxU1 jHlBIJDs7AVM0dsxzTyIPf2Sz843WyHuBgkoCskxGfOwlkZzDX9rwcWRKal1wjy1w/25LsBY U50INandw3UbrS2I73VX8ARI8uOWZrW7uzRLf8EmuPhtSQ35ThmdoNSgGMP9EXwNgzi/i+5G hbX5KbrSLG9SITFJEcJA4tnwu3nqmBh7D7vbd5ln5X7rmqPdyjidt0zcSjvuaBA+nkmakA4A O+choWy5Ag0EToyH3AEQAL+LguHhcSDCL/IevdcvH/5/fzO2fmuuTxdGwrZZSm7l6/HD2Ira h6Wpa1LvVeRbnsRq8k6O8/i3wVapEoQPmNY3vjWfXaJb8R4vHcqgcxw9N9jhZa+mvGJk9+cI ilDyPzHRBBID4d/3oFKQCQ4Y2SIkO66znPhfBOS2f2AU7AtXHhVEyj6WsLK6boEMcj7j+w5a es2nZam0jhgoz+4DQem4uk8outrRlboGnZN7A2kCNuy39UeOp7BpvQ95IKcJCIeSoiJt2A4B NPQroqhW0zGn9Y9FJ9UiZ9YIeNPYbscUxxvrD+OU9Jv67hW0v3KfvoIKDwVKpO3MW6o+1teS Gt1KCSz+CvGJCvIxfCk7S5K5SBne7ZNKz7rkGXYIzlyr7ZoEgRHmqGmcK/sHTS4e6g2pQQrR USkspyqLZl5Uzmg7yI5oGBL0aHTzYdDkkOKMRXYnl7ivBeNtGcniGqlONLJxpbwec8j7hLRq pXFuepbtPqX/GefuK8rdo+ppEqpRJ50cJTegchTfWfSjn5/mG1B4Oz9OnOcBEeTLO729n0K9 BeTx1pmisD6P/fyrqZZTozDwVEi7Wo9AOaqWOhuTe8L0FlFIk6fc/yM0wzvDWP7sNrevEYHK V9rd+Yc/Jjt293J4uayrt6DNMmSkAw3nlBq3uK5d54J0FAsAUcsE/W2/ABEBAAGJAh8EGAEI AAkCGwwFAlfy11wACgkQKcRFldZqfsSQyA/+Kx3eWtKyb/y35TjgtjT/Hrtw+aIpr1uK97LA ln1j5m7+lQ/jh0/rvSZjs+YQMYLqVGI8oaaF/u+qrokkU6pfrhVZ49D1BmmSTMBSYgnBDYqZ yZ+uzQnnDYt/mpo2OLbl9BhuifR5QXLp43cE1FIhyDT46wfse5tNZ+ll4m4HtXuTw4W3b4cP Hto10260Mki7hXbkDMZ+icBFDMkrrZyYHSnBhelzIM7XnY7A/XZdulfFcDXEcZhAFEv3ylJs xTnGwzDyP1VAdBFL3hpP1CqfP1Kti4hKcxXZYbIgTSsBjcYbPchw3ktUTU29I/nWKH5gmD+q wFizyhtt8Qhl6U67OdZ/XbRGBXs/7tlYJIGiGZyG7IQtDOX0PsVd+6WRcDdFqkpBwYkxU8gd iCeW+YTQ5d8mXXPT2dhFAeK2hCFa2+IdaXvH8ovjZpTMeKstHrWJUDaSqQ4GFT676DbDyqtm P6Ul9cjGVtXIs64FWqR9wrbwBH1GuIHhDmG9sN5AkyB9mxXaEG3uG4E6qQeedtIKC6p+ebAs aTGgztFWMJDC8LUznu7B0oyWxNVoE/RGt5mesOeAtqYr6Jtdh7unyk8BYP1y4e+SSMwvtwh+ 69tJwNhGYbOJrdX34tXNAKb6r/rFRjVJm+sPPs5ok7LddvV35o+Fho0LRNDsioDV3HytlhA=
Message-ID: <1b3ee8eb-1d0b-4991-e6c1-f65dd2d4154a@acm.org>
Date: Mon, 28 Sep 2020 03:22:38 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <78fdd4cae92837f303b13e5d9412467fdecca870.camel@ericsson.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xoT6qxd0xdbIwESXrBCBmSlUbIPXSXzpK"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/tsnU-XIe9si8ytGaUlW6zij4xrA>
Subject: Re: [tram] [Technical Errata Reported] RFC8489 (6268)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2020 10:22:57 -0000

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 <
>> magnus.westerlund@ericsson.com> 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 <
>>> marc@petit-huguenin.org
>>>>>>
>>>>> 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 <marc@petit-huguenin.org>
>>>>>>>>> Sent: den 7 september 2020 18:11
>>>>>>>>> To: RenThraysk <renthraysk@gmail.com>
>>>>>>>>> Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>om>;
>>>>>>>>> gsalguei@cisco.com; simon.perreault@logmein.com;
>>>>>>>>> martin.h.duke@gmail.com; philip_matthews@magma.ca; Gonzalo
>>> Camarillo
>>>>>>>>> <gonzalo.camarillo@ericsson.com>om>; jdrosen@jdrosen.net; dwing-
>>>>>>>>> ietf@fuggles.com; tram@ietf.org; rohan.ietf@gmail.com
>>>>>>>>> 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
>>>>>>>>>> <marc@petit-huguenin.org>
>>>>>>>>>> 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 <
>>>>>>>>>>>>>> magnus.westerlund@ericsson.com> 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 <renthraysk@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug