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>; >>>>>>>>>>> gsalguei@cisco.com; simon.perreault@logmein.com; >>>>>>>>>>> martin.h.duke@gmail.com; philip_matthews@magma.ca; Gonzalo >>>>> >>>>> Camarillo >>>>>>>>>>> <gonzalo.camarillo@ericsson.com>; 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
- [tram] [Technical Errata Reported] RFC8489 (6268) RFC Errata System
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Marc Petit-Huguenin
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Magnus Westerlund
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Gonzalo Salgueiro (gsalguei)
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Magnus Westerlund
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Marc Petit-Huguenin
- Re: [tram] [Technical Errata Reported] RFC8489 (6… RenThraysk
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Marc Petit-Huguenin
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Marc Petit-Huguenin
- Re: [tram] [Technical Errata Reported] RFC8489 (6… RenThraysk
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Magnus Westerlund
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Marc Petit-Huguenin
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Magnus Westerlund
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Marc Petit-Huguenin
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Marc Petit-Huguenin
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Rohan Mahy
- Re: [tram] [Technical Errata Reported] RFC8489 (6… RenThraysk
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Magnus Westerlund
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Magnus Westerlund
- Re: [tram] [Technical Errata Reported] RFC8489 (6… RenThraysk
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Magnus Westerlund
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Marc Petit-Huguenin
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Magnus Westerlund
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Marc Petit-Huguenin
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Magnus Westerlund
- Re: [tram] [Technical Errata Reported] RFC8489 (6… RenThraysk
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Marc Petit-Huguenin
- Re: [tram] [Technical Errata Reported] RFC8489 (6… Magnus Westerlund