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

Rohan Mahy <rohan.mahy@gmail.com> Mon, 14 September 2020 14:46 UTC

Return-Path: <rohan.mahy@gmail.com>
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 C26B43A0ACF for <tram@ietfa.amsl.com>; Mon, 14 Sep 2020 07:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 wkHdiqQPoIgr for <tram@ietfa.amsl.com>; Mon, 14 Sep 2020 07:46:21 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC1F3A0AC6 for <tram@ietf.org>; Mon, 14 Sep 2020 07:46:19 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id z17so13697583lfi.12 for <tram@ietf.org>; Mon, 14 Sep 2020 07:46:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=88maf+A78b5nPccJg0EezxrkUJQ6IhKqyKOs2MMkLrk=; b=VEjDwyGs/LJ7KhtSrLIlWx4EqNo9h+OskIYUA95h4ofzmRmD5qqgStVVNCoLOPLE52 FD3e0MSompAYfgv3suM/1STDY/bVrTniKQ07JRdnH8E+afPmJQL3uDpvjMu8DX1EfO4U IxfK6gCK5y9HgbwIasoW3fqjblqP8c//eYAACNKGFdEsw97DC6KNoacyzWKYx6l6+tnq VG++NLdzkcdR9RhN+gJdKALrXNKLK0mDfrAcptdpZMgXr6QQCWcTJxJUpT3pJRjXjyCA 0V1hyotleWCuJ7OSP8buqtSNJCUtNbpnxcI4/IajeP4PHN74+Z8LbFe+Z3zPJUY/oxFu RJbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=88maf+A78b5nPccJg0EezxrkUJQ6IhKqyKOs2MMkLrk=; b=hpmePKwsEBA6d6MPv9SEazEHqFQv8+I50rfxIFVrR/+TTMmuUDygKrAVlbt28IV1Tr +FeybnKQrntTzRZqkfkNOnZQtx5nUzz06TeMyv0ACc3E6KxLIVNvkTJhjuUmJo58JHZx lFkHAcWb5aMXz9+PCHSfAlxOhjOqnwjnHoVan0EYvYJG0l3554WiXbZUtsnfwAxai/S5 M4ijvOgs2JqvOfjThSaN59DfSc/AtzLDizsrwyH9DEUXa757tTKz4XB2Tz+mAVSlO8c5 FZ3sGd3w1EAIDc3cRASZFENg7N6rdNaoR0waWEgOUR2HmxN7MEnyRIZcjhGTxEBBNFxQ oWcA==
X-Gm-Message-State: AOAM532Ti1XfQeX6ANAsyWtxV7HGakPDfaxoPXpDa7FsuPG4+NFlAZ/N YqWdxH7khWskJL/ypZvlAsWYROEObtpbyo1sMbs=
X-Google-Smtp-Source: ABdhPJzIBnXq/T/G975cYomY/9jDUuAyF7QauHTw5AbxTcsEeH9T5Jaf7xi54BWWhyZKO8H7+z9irDjs+ZvBw8IvTLQ=
X-Received: by 2002:ac2:4c19:: with SMTP id t25mr4051184lfq.375.1600094777632; Mon, 14 Sep 2020 07:46:17 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <b3cae3bd-2b7f-d8c5-fcb4-55be9f11a3ce@petit-huguenin.org>
From: Rohan Mahy <rohan.mahy@gmail.com>
Date: Mon, 14 Sep 2020 07:46:05 -0700
Message-ID: <CAKoiRub0t891QscsNH2ijuShaKsGKM+-YEvA1yr77xwAEJwVqA@mail.gmail.com>
To: Marc Petit-Huguenin <marc@petit-huguenin.org>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "renthraysk@gmail.com" <renthraysk@gmail.com>, "gsalguei@cisco.com" <gsalguei@cisco.com>, "simon.perreault@logmein.com" <simon.perreault@logmein.com>, "martin.h.duke@gmail.com" <martin.h.duke@gmail.com>, "philip_matthews@magma.ca" <philip_matthews@magma.ca>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "jdrosen@jdrosen.net" <jdrosen@jdrosen.net>, "dwing-ietf@fuggles.com" <dwing-ietf@fuggles.com>, "tram@ietf.org" <tram@ietf.org>, "rohan.ietf@gmail.com" <rohan.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d3ea1b05af471849"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/FcErnx7w2AzOrOs2_RW4IsyBiMw>
X-Mailman-Approved-At: Mon, 14 Sep 2020 08:03:39 -0700
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, 14 Sep 2020 14:46:24 -0000

Thank you Marc,
-rohan

On Mon, Sep 14, 2020 at 6:15 AM 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
>