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

Marc Petit-Huguenin <petithug@acm.org> Mon, 28 September 2020 14:54 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 3FF3C3A090E for <tram@ietfa.amsl.com>; Mon, 28 Sep 2020 07:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.446
X-Spam-Level:
X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, RCVD_IN_DNSWL_BLOCKED=0.001, 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 0JdiBA6M2lgK for <tram@ietfa.amsl.com>; Mon, 28 Sep 2020 07:54:55 -0700 (PDT)
Received: from implementers.org (implementers.org [92.243.22.217]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A553A0905 for <tram@ietf.org>; Mon, 28 Sep 2020 07:54:55 -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 D5F7FAE28D; Mon, 28 Sep 2020 16:54:51 +0200 (CEST)
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "renthraysk@gmail.com" <renthraysk@gmail.com>
Cc: "jdrosen@jdrosen.net" <jdrosen@jdrosen.net>, "tram@ietf.org" <tram@ietf.org>, "martin.h.duke@gmail.com" <martin.h.duke@gmail.com>, "dwing-ietf@fuggles.com" <dwing-ietf@fuggles.com>, "philip_matthews@magma.ca" <philip_matthews@magma.ca>, "rohan.ietf@gmail.com" <rohan.ietf@gmail.com>
References: <20200830152251.37CA9F4076B@rfc-editor.org> <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> <1b3ee8eb-1d0b-4991-e6c1-f65dd2d4154a@acm.org> <404d19bd2192de644dbc61c64e82605c96446450.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: <8786ffe9-d8aa-d112-05fb-b39ac92e27dd@acm.org>
Date: Mon, 28 Sep 2020 07:54:40 -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: <404d19bd2192de644dbc61c64e82605c96446450.camel@ericsson.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I0u8Eo24PgORWkmyWRvSHMNxaEMjXJzLu"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/3hAvm9PYadEs-jLs6Z5EB0R0xNg>
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 14:54:59 -0000

On 9/28/20 7:36 AM, Magnus Westerlund wrote:
> 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. 

SHA256.

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