Re: [tram] Contradictions in RFC8489

Karl Stahl <karl@ingate.com> Sat, 27 February 2021 04:46 UTC

Return-Path: <karl@ingate.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 431893A0E5D for <tram@ietfa.amsl.com>; Fri, 26 Feb 2021 20:46:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ingate.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 Xcj3kGVsdRd6 for <tram@ietfa.amsl.com>; Fri, 26 Feb 2021 20:46:40 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130081.outbound.protection.outlook.com [40.107.13.81]) (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 2AE9A3A0C9F for <tram@ietf.org>; Fri, 26 Feb 2021 20:46:39 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OSQ1fSOfQa4Tbvn7VK5srIJofCte/voSw5VBx6XDKSjvaFbbjUFVLBoeaJ+jbJfxgL5Igzox9wYUh5QXhSHKuHi+2fFgHUUurzCMTgrQq95dOh42xGJx7mg7ZTnBaCKeipmKwZgY9HPB8m9iOyImkqrFNjntUpmn0xBCu06cQWe8NKYo2Q5jILfbBea5nDxSKTTXIThETj06UmOgABc3BzTgg500AVFXzM9a4dXnjjUNQuRHPnKLZ9Vst+TPMDaARL7UeZ0Z2A7xSl4rF/S03+wPaFMKaOT7sQtRfHlqTN7dYuIFscPnq3C8RoiSj513HQ7HUTiE74rEynVtTxCwZA==
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=Zxz2EXXjImHOk0/9YwqKvNtvUw9ng2V22Wwp7p7lp0Q=; b=dgkCxcCOpS1uyRuTpdG9xQdpVdLbbU+5dwR++x2WrAS5XpS9NSNU+pMq22yULw5HW+emoJBPl+oHBGeZj3QZmu/1UgRLvNkO67OIP/0+haOU+aqv0yHbyi04pdlYqCoK0MKSCLF0Fc+JVomMEV1L/UwVnrlQ3tMSgNVRusSHvbXoBvL8KPUI7/htY3v5qs/72gTLtpzxNsID2G/FWqFA4KAaWhbHZrhqjjmorw9QH3dLPiBPyWxqXqqoSkH6Hprt2q4z2RkcJRdiIaPZRjjLW0CbTErzFa7ecRoHdPXStDeE74XS8PPatLAJmT4j8JEequZzGlBvakQKnr+D/gfypw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ingate.com; dmarc=pass action=none header.from=ingate.com; dkim=pass header.d=ingate.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ingate.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zxz2EXXjImHOk0/9YwqKvNtvUw9ng2V22Wwp7p7lp0Q=; b=J3hUCZLXJs8Y8DSggKOkIvuDa7rl7q30wzTTKjMHFjSBzClixhDzNY0e3ff3N/efceLV4QJCVDmC3LGVPFhB/qG8jWwWYDKf+cr9Xw9gD1OO7h1ms2yIKc36we+AujduURUCHwEXVOpxiasRgkVkRJMmxQ2BGFIcPBAHjmBdxg0=
Received: from VI1PR01MB3008.eurprd01.prod.exchangelabs.com (2603:10a6:802:3::13) by VE1PR01MB5872.eurprd01.prod.exchangelabs.com (2603:10a6:803:115::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.29; Sat, 27 Feb 2021 04:46:35 +0000
Received: from VI1PR01MB3008.eurprd01.prod.exchangelabs.com ([fe80::7968:ab3b:70a6:6b6]) by VI1PR01MB3008.eurprd01.prod.exchangelabs.com ([fe80::7968:ab3b:70a6:6b6%6]) with mapi id 15.20.3868.032; Sat, 27 Feb 2021 04:46:34 +0000
From: Karl Stahl <karl@ingate.com>
To: Dan Wing <danwing@gmail.com>, Nils Ohlmeier <nohlmeier@mozilla.com>
CC: "tram@ietf.org" <tram@ietf.org>
Thread-Topic: [tram] Contradictions in RFC8489
Thread-Index: AQHXCwkCQ5g4q1tUpkGgxHb+HeML1apq11CAgACV9uA=
Date: Sat, 27 Feb 2021 04:46:34 +0000
Message-ID: <VI1PR01MB3008208EA6E4C9B9BA674B1AB19C9@VI1PR01MB3008.eurprd01.prod.exchangelabs.com>
References: <2DB77788-814F-4F0D-AD42-B28126F1EFB8@mozilla.com> <924F7C3A-B9A5-4648-ADC2-704EF78B8698@gmail.com>
In-Reply-To: <924F7C3A-B9A5-4648-ADC2-704EF78B8698@gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: sv-SE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ingate.com;
x-originating-ip: [81.237.245.123]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 57caa1f1-28e5-484e-8a57-08d8dadaa925
x-ms-traffictypediagnostic: VE1PR01MB5872:
x-ms-exchange-minimumurldomainage: ietf.org#9485
x-microsoft-antispam-prvs: <VE1PR01MB5872CC7EDE155EA6FB51D0C5B19C9@VE1PR01MB5872.eurprd01.prod.exchangelabs.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: JVt7MC2zEJbhdsAPzdahSNs/gKDnYPl/Vk6W3ccBWBSWR8AbjQEjfJROxmIOCj8udO/7L7GuMzKWFH+fosujm31ZuQTJvy98Hjr2cpaY3Zsi6+rH52wtoY99Af9mGNxfGBikpxqtKNWKRhKiS0R6bd1LT/e7tjSCOO0na+hK9XkYSSq95Q2IdgCfloSxYjRGIvCSdY4Xk/+wWsK8QpKrp2X3lMQT/GUmEeyuXnhJZnUjbytlFEy1AQtRG7rfj9v5xdC5NhXjGePD5tioLNZ12mE+QttH1RazEjZ8zI8MZnRJGOhYBwICCs8/nh5ZzqVrEIBOTnFXBcpc/BSYOgsrVIWvHaeIY3/6HdLzCkVTu2n6hyy+C3eUeqL6ozc25zlrAeAtSHfeIvceOduU4wKf0WmJkL1xJ0SCtBB0UdIS1VBe0HiwTUab7wbQKCrZyy5Lv34K7tzY3R+GNwJBDUnkZ+Sc2nV1KXmjgVUA/PSqra+X4fIR4jfH9e58dgD1kKFsQClpHq7Qn5ucNGO9kWma6bm/mpjw/FkLO8NTZ8B7W3pqbxqQ6nZCVFi7Eh5PeSmc0mvq0uLQk/CKPkpLv4kGHniD8uZl/DjNpsEURm4J3Gk=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR01MB3008.eurprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39830400003)(366004)(136003)(396003)(376002)(186003)(5660300002)(8676002)(110136005)(7696005)(66574015)(8936002)(966005)(478600001)(76116006)(66476007)(64756008)(9686003)(53546011)(4326008)(55016002)(83380400001)(66946007)(33656002)(71200400001)(66446008)(52536014)(6506007)(26005)(316002)(2906002)(166002)(86362001)(66556008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?TmpMbTYwSFlnSFMzbGdFS25xd3VBL2ZjcVI3UXNMMkZpdTZXbDlGUW8xZndQ?= =?utf-8?B?OWRISlk1cHZtNkQ4dHhYU0FncGZuOWVLYWtSWTA1TmVzVVZ4VkR0U2p2OUho?= =?utf-8?B?MmlPM3RRMlU1M3R3dmlFWGoxbGV2R3VNdk1JVWg0WkxHaktmNlJyaGdjaHlt?= =?utf-8?B?dDJ0ajJYRlZsUWFsVHdlRHFrK1dQUFRYU3hNc2ZFdHdyU1hRbmZabkU2dFFk?= =?utf-8?B?eTRRUS9ETnhkSnYySFpORzh0Tk9vZ0JNYUd6dWEzYzU3dUc2ZmRyckZsNCtI?= =?utf-8?B?WE8yeFRBVGZuYUh6My8rV2NMREZWUHllN1B2VElUUmZSbnRWTk1MMFNtOWhy?= =?utf-8?B?dVRuZ05QVVBxMUhWRzhVc1VzbFIwcWFhQzZwZkJVeCtGSnZPVVBLZ2tlSTNv?= =?utf-8?B?MGgrQXA3Q2d0eTR4K0NBcFJQNExkclN0a1VCL3RHUG52bWs1ZHJsNU03eVYw?= =?utf-8?B?K05JT0VBcndVRHRUQnArcEhYSmFkOXlvZTc4UUpkbU9qcDRSbDEwYk9oQUlN?= =?utf-8?B?alVKOVRzSFgyOFlFenZPeGlHV1orRnNuRkhISUZVTDVyNGtQaUhtYTdhQXdG?= =?utf-8?B?YjdvbDFkZ3RVK3RhL29HUnFScUVzdkUwb3NCTUE4Q1dzRXE3OTlIeW96a2Fa?= =?utf-8?B?WjJ1dWNHREV1SjZJSVUrY3grbEVBL3NPcnFlbXhSOE41Ung3TU9CYUZCTU9Y?= =?utf-8?B?RmM4dFA0aGVTaUZmMmg0TWtGMzFyTXdLSlpFQXNkVitmVmNmSWQvV3lNQlpD?= =?utf-8?B?VkdMbkdVOUJDeFgzNjNWMFExaEV5QXE0SHVHN3NVUHFjT2w0bjNKYWZrem5i?= =?utf-8?B?K1IybFFBaTFsOFYrQkM3WmE3Wk55YWt1OTBXWllVQnZSTDR6WjNwbXYwRUdG?= =?utf-8?B?OFBUbHIwNG5WcjFDeTBWM1Y0TzVHVWMwa3ZvNE9kdkozcVZUSFJrdGF2QkJM?= =?utf-8?B?cnJaOEZEOUVveHN1eFliMWY5SENUdThLaFRpVm9KdHlvenpLVkcwT2thdEN1?= =?utf-8?B?VEpJU3FJZ2NNREIvU1g2Znk3elRuUU5ka3dBRkx5RFJ1N1dTMFBiR3JoeGJP?= =?utf-8?B?TUJCSXBCVXZXY0RYSmJBNFRQd2NGTnIwbmQ1THgwalIzdDR5UTVVK3JUanFV?= =?utf-8?B?ZEcrUnlLdEpwaE11TzFzTklwZk9URVlzcnk2aURrYWJYbjBYekF6MHNHNUJZ?= =?utf-8?B?WEgreXExL2t1bUZYQiszbkFWQzhoeU91NnNpK3o1WUVkYytUdUkvZUFiUVNQ?= =?utf-8?B?cUdFYU1xOFYxaUpTWmhwNGkzclpFdVhDTUFSenZBUzQ0NENjTDJRRjE4RHRJ?= =?utf-8?B?VlFTUVkvUU4xNHpVTVN4NEE1eWowbDF5YzE4UVBJZ3VFOSs0VFJwOE5Lc2hH?= =?utf-8?B?bkdHWmRkWXlCY29NVzZqM3pJOTRwcEp0cFArRGJQcytHUUEzNjd2b0hKZ0RD?= =?utf-8?B?MmI4cnZua2ExREVpVWdiV2VkK0ZobkNLcnlDMzM5RWR1cjA3ZTg4RWZVVWJF?= =?utf-8?B?dzhzMzEzaDU4R3RxRnBhazdGYTc2ZEJHT3JsbEo0cEpvL2xDSi9nUWVrWjFW?= =?utf-8?B?eXMwclZNNDFLQ2tLZnZSR3B2dkpvOFBqbTArZUd6M2xNelA5R04xYXFqTVg0?= =?utf-8?B?R1BPVEdESDlEMGtNVE8zVTRNQnI0U0NKZ3BuZFlvOTFMbDBUT1NjMXYwemIx?= =?utf-8?B?alRtU0RuczEwcUdySFB4V1pKcjNiQkVrSGZITTFLK25xZzRmR2xVYS80RVNP?= =?utf-8?Q?ibYUkbMNwaR4Df8Evw0BKRwHFuWLg74ZiduWh3k?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_VI1PR01MB3008208EA6E4C9B9BA674B1AB19C9VI1PR01MB3008eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ingate.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR01MB3008.eurprd01.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 57caa1f1-28e5-484e-8a57-08d8dadaa925
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2021 04:46:34.6671 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c3eda49a-3ed0-46c6-8a9e-d0d8ce3d2fae
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: sLVg9FiIIvvTj0JcLdvGYjdTpVu0VXwcXXyXEtjqjaSVh7QkyfATiAGP8n9S6kX2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR01MB5872
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/w6zTufroxLpYfZjC7rH3N0yiRiU>
X-Mailman-Approved-At: Sat, 27 Feb 2021 05:36:12 -0800
Subject: Re: [tram] Contradictions in RFC8489
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: Sat, 27 Feb 2021 04:46:46 -0000

Hi from Karl at Ingate & Intertex,

When used for auto discovery of a an enterprise turn server (on the LAN or in the access network), you typically don’t have any credentials and are talking clear text, but still get the 300 response, so there a non-authenticated 300 response must be allowed.

So this text is simply TOO STRICT and should be released:
But then section 14.8 https://tools.ietf.org/html/rfc8489#section-14.8 in regards to 300 responses says:
This error response MUST be protected

/Karl

Från: tram <tram-bounces@ietf.org> För Dan Wing
Skickat: Friday, 26 February 2021 20:37
Till: Nils Ohlmeier <nohlmeier@mozilla.com>
Kopia: tram@ietf.org
Ämne: Re: [tram] Contradictions in RFC8489




On Feb 24, 2021, at 3:58 PM, Nils Ohlmeier <nohlmeier@mozilla.com<mailto:nohlmeier@mozilla.com>> wrote:

Hello,

I recently learned about an interesting contradiction in RFC 8489.

When it comes to using the 300 responses with Alternate-Server attributes section 10 https://tools.ietf.org/html/rfc8489#section-10 says:
The error response message MAY be
   authenticated; however, there are use cases for ALTERNATE-SERVER
   where authentication of the response is not possible or practical.

But then section 14.8 https://tools.ietf.org/html/rfc8489#section-14.8 in regards to 300 responses says:
This error response MUST be protected with the
        MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, and
        receivers MUST validate the MESSAGE-INTEGRITY or MESSAGE-
        INTEGRITY-SHA256 of this response before redirecting themselves
        to an alternate server.

There is some surrounding text of 14.8 which seems relevant, which I have bolded and marked with **,

   300  Try Alternate: The client should contact an alternate server for
        this request.  **This error response MUST only be sent if the
        request included either a USERNAME or USERHASH attribute and a
        valid MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute;
        otherwise, it MUST NOT be sent and error code 400 (Bad Request)
        is suggested**.  This error response MUST be protected with the
        MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, and
        receivers MUST validate the MESSAGE-INTEGRITY or MESSAGE-
        INTEGRITY-SHA256 of this response before redirecting themselves
        to an alternate server.

        Note: Failure to generate and validate message integrity for a
        300 response allows an on-path attacker to falsify a 300
        response thus causing subsequent STUN messages to be sent to a
        victim.

I interpret the bolded sentence and the next sentence (starting with "This error ...") to mean: if the request arrived with USERNAME/USERHASH and valid MESSAGE-INTEGRITY(-256), then the response has to also contain MESSAGE-INTEGRITY(-256), else the response cannot be 300 Try Alternative (and recommends using response 400).

-d




Looking at the previous RFC’s it looks like this contradiction has been in the STUN/TURN RFCs for a long time already.

I became aware of this problem, because it is causing interop issues between different stacks in the field.

I’m interested in the working the opinion of the TRAM experts on this topic.

Best regards
  Nils Ohlmeier

_______________________________________________
tram mailing list
tram@ietf.org<mailto:tram@ietf.org>
https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/tram&source=gmail-imap&ust=1614815933000000&usg=AOvVaw1n1YAlhUsnhlTcx1V3NGXC