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

RenThraysk <renthraysk@gmail.com> Mon, 14 September 2020 14:48 UTC

Return-Path: <renthraysk@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 1F5B83A0AD9 for <tram@ietfa.amsl.com>; Mon, 14 Sep 2020 07:48:17 -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 PxyKeLR61dWP for <tram@ietfa.amsl.com>; Mon, 14 Sep 2020 07:48:14 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 1F3673A0ACE for <tram@ietf.org>; Mon, 14 Sep 2020 07:47:58 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id a17so19061606wrn.6 for <tram@ietf.org>; Mon, 14 Sep 2020 07:47:58 -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=axLg74LEjgXvBUivaDkMEKZUo2AFiMBC1E3ZHi1K2+A=; b=WDtuyUJZgKU33x01uMhpJa0jDR//xmx5nY6k/xjB62KyqhLMSjAeJrPQJEm6fDYxFy CVQkPRi9n/hSxMHZBqTUooGLQOcuDizDMMCd8s2tDTgOYTrEJMPPh8KDQ8W0EtHtS3OA 4VQYsjwodkVYoe7UUyFmpqMAdYeiAxiOBIOiilR0016twwYk9h45S556FJhNMnIfwb1n xfye6tUpXfjEEbd5KCIG6KhmqI0zu47Xzv3Pt3g4rR1gnyH3omjMANVoFW0E2cyYKN5p 7OEYDI9rNvDlaIy2uHkCQcY9dke86lVNdVr17mo8RVH/5RqefsupYhjp1CWaIdbVUJMB qzOw==
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=axLg74LEjgXvBUivaDkMEKZUo2AFiMBC1E3ZHi1K2+A=; b=UNF/qGN0ew0Fz8IZqQR386sGTa/3Xt/85tPYig4oFAjsuowZ8BlL6NCQuKIf23AZeB GgUzE0TE6ODAQobEheEx0PUCmGEJ8YYWgFcE3dvUBjvqWsprG/a/1hBA+bQu7nOv7llS RM7595gCFTWs77mwnBtQGzAvhxqkNg3Ea/2jgPPO+t9IUvAdFwCeeBTTnvub4qS0Zisv T1HTcB80JsbVgF7FUCAAp04zGyz/d6eBz7BbnpLZ2uX6HHwPzQ5Tp3RdOSngzvo4o3YE BwVBCJzK7mrThTDgldbFs5H7m7MmrnBFsKmq/xPjkRP8kD1DjV4xzpImmZNvBXWXWBVL qbmQ==
X-Gm-Message-State: AOAM530wUbVvU7HDB6ctGEvLZkERTzuJa8N80ZdQcKDfob1jYPelTYJZ UT2oaPgmLWr5I2vFoD1FLXQ/i7RJlwRu7g20oA4=
X-Google-Smtp-Source: ABdhPJzKjS0cIdcZcXzS7KRS1HevgtZe4HkMjUCZxVeP+B7/XY/fWImpoTb4G9lC01FBTLySyI6vXI6BIaToTk/jlGw=
X-Received: by 2002:a5d:4e8c:: with SMTP id e12mr17286362wru.180.1600094876505; Mon, 14 Sep 2020 07:47:56 -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: RenThraysk <renthraysk@gmail.com>
Date: Mon, 14 Sep 2020 15:47:45 +0100
Message-ID: <CABNgG1hzNyM-qqCpprXBUJ4y-X7OOMZHK72wpPL_rJ+TLXrz-g@mail.gmail.com>
To: Marc Petit-Huguenin <marc@petit-huguenin.org>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.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="000000000000b898c205af471e95"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/UTcX7odKl-zs1QU3sz-VM0EQE0g>
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:48:17 -0000

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
>