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

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 25 September 2020 07:56 UTC

Return-Path: <magnus.westerlund@ericsson.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 1E7DE3A1285 for <tram@ietfa.amsl.com>; Fri, 25 Sep 2020 00:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.796
X-Spam-Level:
X-Spam-Status: No, score=-3.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 4-LAK3T_shrG for <tram@ietfa.amsl.com>; Fri, 25 Sep 2020 00:56:53 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40070.outbound.protection.outlook.com [40.107.4.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08DE3A1297 for <tram@ietf.org>; Fri, 25 Sep 2020 00:56:52 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XTxJ0db6ukz7jY6+S6rqCUGSsENadJG3uYbKfOyq1fRCZSoUgjbsDUCwVSbmHgCKfz48u6ANbXEm/6sPs2Qtnm9DZiCPs7ozCGSwgpoD+fbH2obSv8Zb9lJwyIP/ppt55uuZZ6Kb6JS8TkCaV3mCZrCZx/G0lSxOVGpTHkrTnuu2XRrplqcE0vQSM6y1vFyUyaoCd18yCBo62Idu6Jel9oggTVRS+fYiNKUEFAeg+hQUFu/6IIuny/VYLHCw3sx4Km8Iq5E4TIWh2G6jUPWoQSaS+eWeeVlb/9AKPHlhKW8zOoTYnn9wIf/KTAMfECSqZhZUF9W2eMgs8kSljAoiAg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c3G23XRg2E+hapXscOP+UztihfkJMfF9gGwdGnBSBBQ=; b=XS7OKRFBUkINHiivlolIKl0VWhhmnyam1cwfOv5s32kdN6ChmO4u5G8Eo2ufIN8HLEbDvNMX5tIwY+zgrAp/r/QmRcQHidi8nuokCERILKIsNU+dF61/AcFqVQx5HQJJ7kvyqtS8HXddWz+sr9iimIcg4UPaetLfoHEyOqLNreoCK6OAgQ6J4z+/64P01tgApQtSn96OczjG7YBbeFad222tkLU74Fqg5ZLIU8nbETuUNrla57XCvwBuji2hzvVBP7fjuBAUGxtLhFX+jqcaPox+CGuwppG+S2+6037jzK/cpVx0WHDyNz7u9hg4o9m/9QmNYVqyqx7t0do9Jn68xw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c3G23XRg2E+hapXscOP+UztihfkJMfF9gGwdGnBSBBQ=; b=pOQSadBDfCSeSwMqNfAbRiWaWu0M81bGsd2NLhUgr5xBx1XNOB3Vcw5LLSEgFDvZvXKSK/R2rrj3G+RQzgw4VK1ygffYkqyp1ocifnmIYGsY9O8TiO8IbY5/bQwc7v9qk1mqUyQnOHIuFtI69J6X8ush6991NNWJtcvvpVwnHyo=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0701MB2684.eurprd07.prod.outlook.com (2603:10a6:3:8f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.13; Fri, 25 Sep 2020 07:56:43 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::c98a:9a0c:1eea:3fdc]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::c98a:9a0c:1eea:3fdc%6]) with mapi id 15.20.3412.021; Fri, 25 Sep 2020 07:56:43 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "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>, "marc@petit-huguenin.org" <marc@petit-huguenin.org>, "philip_matthews@magma.ca" <philip_matthews@magma.ca>, "rohan.ietf@gmail.com" <rohan.ietf@gmail.com>
Thread-Topic: [tram] [Technical Errata Reported] RFC8489 (6268)
Thread-Index: AQHWfuF5dRZ7aF/vA0OYP087ogZzZKlSU3kAgAAfVoCAAS6igIAJpSSAgAARDgCAAA2PgIAAAGWQgAACowCACswlAIAAGeGAgAASQACADgqBAIAALMwAgAKNPoA=
Date: Fri, 25 Sep 2020 07:56:43 +0000
Message-ID: <78fdd4cae92837f303b13e5d9412467fdecca870.camel@ericsson.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>
In-Reply-To: <CABNgG1gXeekROCX4_aHo4RYX8fZg6b967AZEPRRhxTH9PxQdGA@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [192.176.1.82]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 59736986-41a5-4a7e-58c8-08d861288b2d
x-ms-traffictypediagnostic: HE1PR0701MB2684:
x-microsoft-antispam-prvs: <HE1PR0701MB26844DA3047F0A7B50D416C995360@HE1PR0701MB2684.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: f8xpaAOTR+t6BF1nTJM8hCJSUgV2YHPeNCCjlbOue4Vss8moKCh1Z943Zg6T6QZApNY+4b+UXfyjYiSGRUURQ8VNNsCjCKHkcc9RP4VP36LbyWD7SOpwpe7rziulv2N5wjob/yD36Ji5rt6TJzpKk6FiMUdRYh/RN5jB9C/1h0fkHx3L+plXGOWhc1QPKyNhOtPDgPbiJEZ+NkKd6E4qEZjmCp9EVDXBhGB/WHTuurPf0n6s0J6WhDEPqV/T8DqDZsBfz1Xk5bC46XyPJPIPVHdmn7WcLiRtpmlaGHd8tt43FT2HMx8KfPJNw4auY2T9PhfxJmefgQHy7zO89rmwzuBr8KrSCDC6xLDhfQ+8CifOzPxR0b2MN0Go2TxZInvNi0zLeobIsX6rMNsIwSG3TwaDc+ttBfJbTotGk4Z/Bb9bV1R6nIYBG94TEEpK+HhfRYittDS1T8Am7MxuOtFN9Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(346002)(39860400002)(396003)(376002)(71200400001)(5660300002)(66946007)(54906003)(6512007)(316002)(83080400001)(478600001)(83380400001)(26005)(36756003)(30864003)(186003)(16799955002)(2906002)(53546011)(6916009)(44832011)(66446008)(86362001)(91956017)(76116006)(64756008)(4326008)(66476007)(66556008)(6486002)(6506007)(8936002)(966005)(2616005)(8676002)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: be5YTOPrkBLCtTEaZzTYtW+249u3H90DbYrvhdhpRqMlA80aXIsnsPQ7RgtgQPD2KOtIiFQCPp4MiwAMxTpfgXWWXqngy7Qu4zv3BFeOFmZnbxJXuMNUHsTbIP/JZRW3GLs68Rdi9y2t6qVTxTmJCUuotnwyipCubpNDp/bucZrT6tF7JaadKP2JSX8SXCL7FSTPArOoa5fpXVa7NPzS1zXcRQk+7BSF5LiAwxF6bMAM/ITl3MZS/YkBk5F0vbzyf7u2G687geMtFvXnjriQpHzkNZYrKIgUBE+hkWJis4vXTwbz302eJvlsB08zfH9L6MV+surs2cQfYJ+ceWChVR6BvcOo0vbIEcCUgbO0V+CdDIYZiia2oQlfe6nbGZmMRaCaaZf+sTLtq1JHS8g1Vq0DvYEgdsdbFh/3hdhlouOOcfdr8TMwb3IsugYM6ajlsk7jzHZ01Nc3iUFDKxVICPAD3NT4xG7n7htJwHD/FVfBkD0wNQ6DyhqlQJnc2Jhk9WUKRnbGWhzJXGkN2YMepGyfbViOzxGYoYbvS2v373kNvnlaz6XPSKuFcyu4gj4dA+VBwro3pckARQ0uaJEP1BMXFM6+KXgJbN4w6Dkfu7NmmDbZtgsO5HYhcn1ogvcXvzGzfwsojtwsgnnfxvnN7Q==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <5A7467069CD02D49A5BD02EB985000A3@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 59736986-41a5-4a7e-58c8-08d861288b2d
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2020 07:56:43.2157 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: S2Ly/4Vo0bBL3k6o+WjBfbxoBcCUm+Ei0U3CAY1CEUjEQR59XWQwOv1t57+pC6Z/yXiULmt0NwSFUTub3qSzM6NOK1wI5rh3FnwSF6gHkGc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2684
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/c0f2J99qG4P34nxHOdjLQJjNAnY>
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: Fri, 25 Sep 2020 07:57:02 -0000

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

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Mobile +46 73 0949079
Torshamnsgatan 23           |
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------