Re: [tram] [BEHAVE] errata 4933: RFC 5766 prevent spoofed refresh requests when using short-term credentials

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 24 January 2020 16:29 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 76AE51209D8; Fri, 24 Jan 2020 08:29:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 orTxrzmNatK6; Fri, 24 Jan 2020 08:28:59 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on0605.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::605]) (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 99D3E1209CD; Fri, 24 Jan 2020 08:28:58 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YKshzy/6UwwzDKir+f4kcAZb4nJ0mNDKnuRPjfw7ziu4aup6PCwkK2QDxMu7NqHcMnA/ZyLzqm/NMbx5s0aDcFTUrSoiLPfASVBE2IHrC/6GhscuUiOVwwzwcQvhTtsfSMknGR3GukkYYvVJT0j0XPi3LAhurcN6QrkeixJXfDFt2cEHZzGj4ahPIRi4b07Sw7kCni+4MNwxocMWeLp7w6n+JzdkQx1xBf3dCRRNkg4sdk/npxC5LQ6md++pvToZHkO6ORspQuYoOhC36oYNnWlGN63P3Ddf/QyVYLFQDTwIlz+Rd/RjjXzqH/1ClZDZEzInKB8PCa3cvcQKHyeAWg==
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=TlSg2Bzhj1HuH9Jud2j9Hz745e1iStC9hf6QvE6wjus=; b=nacNc/4l/tOegSGga/o2/1K8vFf/dXCUyCRcPeV/w7QpnaXIMVsix1HJZKbowdYOCM4GMIQUCbnJClt8GphoN2iHfGuPZtWdEurDp//LKpbm6qtEIOzk8WikUK1gLg6jD5/bdnxVWEQY6YhMFrMZb1rAqZrJSHhyWuqjiwkdmV/dhWwvman6UVCEw9iAe6d+nJxyzhgY05XyZbVlTJtO2+VZNHG3GUwfD3e7yEnakIVzhxaBtgYgWCH4C06KhrlNBqftyzjpxJv8I6BspBOtl3zIc70GwZpsZjMVH74EBkYAs5DXDounUyrWxe+PjDLdIgDmhxz2EIM8MXg0GdhOuA==
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=TlSg2Bzhj1HuH9Jud2j9Hz745e1iStC9hf6QvE6wjus=; b=SSvV3/gtQkl+SeAbqFP58GbutKf3kbs6Ub2L94OqR6n+ujXSZnmZ5nuHciwLd9RWF3VgJo9/n3K2VTpWTQ2/y3DTlD9SsE5gmyx6vY98pupzez9pU7/bgJuzeFWcDTrvGF0RFBzrHOSlobrcBSle4Dc4egcBlvo5U+lnmLZIKkk=
Received: from DB7PR07MB4572.eurprd07.prod.outlook.com (52.135.133.12) by DB7PR07MB5878.eurprd07.prod.outlook.com (20.177.193.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.14; Fri, 24 Jan 2020 16:28:56 +0000
Received: from DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544]) by DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544%5]) with mapi id 15.20.2665.017; Fri, 24 Jan 2020 16:28:55 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "mcr+ietf@sandelman.ca" <mcr+ietf@sandelman.ca>, "juberti=40google.com@dmarc.ietf.org" <juberti=40google.com@dmarc.ietf.org>
CC: "behave@ietf.org" <behave@ietf.org>, "tram@ietf.org" <tram@ietf.org>
Thread-Topic: [BEHAVE] errata 4933: RFC 5766 prevent spoofed refresh requests when using short-term credentials
Thread-Index: AQHVzMYeLbYkY+2WaUmMx8s8Q4kFvafuENgAgAEVswCACualAA==
Date: Fri, 24 Jan 2020 16:28:55 +0000
Message-ID: <cf5e9cd3d1b0c71659edcd04283a43db4efa8bd2.camel@ericsson.com>
References: <DB7PR07MB4572708BEAC771375AC2AF5395380@DB7PR07MB4572.eurprd07.prod.outlook.com> <20200110123841.GD8801@faui48f.informatik.uni-erlangen.de> <29758.1578671195@localhost> <eb6effe49c65b90cf4e6af45b9b701b4f86db608.camel@ericsson.com> <11345.1579216274@localhost> <12509.1579224412@localhost> <CAOJ7v-36tMpjKzoQc+rys1g4pGiw01XG551RDWJ+_cjj5xxk2w@mail.gmail.com>
In-Reply-To: <CAOJ7v-36tMpjKzoQc+rys1g4pGiw01XG551RDWJ+_cjj5xxk2w@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com;
x-originating-ip: [192.176.1.84]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b65cbbc5-036f-48a6-64cc-08d7a0ea81e4
x-ms-traffictypediagnostic: DB7PR07MB5878:
x-microsoft-antispam-prvs: <DB7PR07MB58787B23AFC4F701B280241E950E0@DB7PR07MB5878.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 02929ECF07
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(136003)(366004)(376002)(39860400002)(189003)(199004)(66476007)(36756003)(6512007)(8676002)(76116006)(91956017)(81156014)(66946007)(81166006)(54906003)(66556008)(64756008)(110136005)(66616009)(66446008)(86362001)(5660300002)(53546011)(6506007)(4326008)(16799955002)(966005)(478600001)(71200400001)(2906002)(316002)(26005)(186003)(8936002)(44832011)(2616005)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5878; H:DB7PR07MB4572.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: G1rmoZsLawpU6vl3B9pnCGPw9lFru+xemuTYffXGQ2Ljq1HgjBlos5a/e8ydZNVNr9xMpwCbpUmoMpxRcISuG2fRHhTqCM3KfqkB+yQYzIwOuAibWz3p0So1/ZNEB4HcxN8nKyCw6MeJINiG0Fkl9RYD89nnpAhlTiZuTYaNRTZmhPOU4yaeB7OMgKIEiUeU4d6nRrekfG5nLae2MC3bizB4aewPyH93Zz6r9NO5xfSmOt3PVCftb+X+D+LrRbeEg8kDx5AAblvEt5WYBUP+j7Bm/PMaPcF5ZXa5Lty0/+wy994np6XUsWoJloWINhEdzKRyI7IMiOmmC+Kr2EHLeg/f83jCaBqgcLShyhwZl4LXsdPDOt2tVLlcm3NBwYACZiYMuJnnk7VYIrij+y2sa8zvobwwSBasHXytxguMvo0PPXUYzjKAHTyYIr56o9Ofu/3WYm1b8KCtvBHInuyk6FTRcxG1JLUfrBnGVSbR0os=
x-ms-exchange-antispam-messagedata: a4m6gFqAfhDDg4vbloz31hOfJ0VEMnPbarRz01rMzH1qBoU9NSeug1mHnGDjyBhP3AkfCQ2hHrBoYwm6UDjwkapHAq6poxDCiyJXFRD62q+3QcGcQin1yNnVTQ80ftQDz/Z0epXWVCEX72lB5x2kZw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-+3O9BxMnmXJaS5FWNAoS"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b65cbbc5-036f-48a6-64cc-08d7a0ea81e4
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2020 16:28:55.7655 (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: 84ZgeyCIn70FlHm/wKROQVNNSh0PAdAV9UbzDwXcIucKFUU4+gbcFq5egTWWddeJ/uCzJQncRQiD1I5WIGdnu4BXdxGojIZOcQOarjAG/C4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5878
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/XV2idh8WDT1KFzH2oXbnYX_q2Rg>
Subject: Re: [tram] [BEHAVE] errata 4933: RFC 5766 prevent spoofed refresh requests when using short-term credentials
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, 24 Jan 2020 16:29:02 -0000

Hi,

I think the primary question is if this errata points to an issue that remains
within the updated TURN specification: 

https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/

So the question to the TRAM WG people. 

Section 21.3.3. (the equivalent to 17.3.3) has the same text. However, I think
the underlying question is if the existing mechanism and especially for stale
nonce prevents an insider attacker that otherwise have the user name and
password for the user can take over an allocation when the nonce expires? 

However, I have the suspistion that the reporter has made an erronous assumption
as short-term security is not allowed with TURN. Section 4 of RFC 5766 do
requires long-term or other equal strong mechanism. Thus, another aspect is if
the nonce actually will expire? Or can a client actually loose their allocations
when the nonce expires and attacker manages to make the request first? 

Cheers

Magnus Westerlund


On Fri, 2020-01-17 at 10:00 -0800, Justin Uberti wrote:
> Both a/b seem sensible to me.
> 
> On Thu, Jan 16, 2020 at 5:27 PM Michael Richardson <mcr+ietf@sandelman.ca>
> wrote:
> > https://www.rfc-editor.org/errata_search.php?eid=4933
> > 
> >     4933> Section 17.3.3 says:
> > 
> >     4933> An attacker might attempt to disrupt service to other users of the
> >     4933> TURN server by sending Refresh requests or CreatePermission
> > requests
> >     4933> that (through source address spoofing) appear to be coming from
> >     4933> another user of the TURN server.  TURN prevents this by requiring
> >     4933> that the credentials used in CreatePermission, Refresh, and
> >     4933> ChannelBind messages match those used to create the initial
> >     4933> allocation.  Thus, the fake requests from the attacker will be
> >     4933> rejected.
> >     4933> Notes:
> > 
> >     4933> When using short-term, credentials expire after a specific amount
> > of time
> >     4933> (such as 5
> >     4933> minutes) and clients get new credentials. The restriction imposed
> > at section
> >     4933> 17.3.3
> >     4933> prevents from refreshing allocation or permission using the new
> > credentials.
> > 
> >     4933> This RFC approves RFC 5389. So one can use short-term credentials.
> > But
> >     4933> short-term credentials are useless if it can not be used to
> > refresh
> >     4933> allocation or permission.
> > 
> >     4933> The goal of 17.3.3 can be achieved by sending 438 with the new
> > nonce.
> > 
> > a) I think we should accept this as verified.
> > b) It seems that sending with the new nonce will work.  This requires some
> >    text changes, and we can now perhaps use the errata patcher with XML.
> >    I've asked for the XML (if there is any), and I'll suggest some changes
> > to
> >    the text.
> > 
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> >  -= IPv6 IoT consulting =-
> > 
> > 
> > 
> > 
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> >  -= IPv6 IoT consulting =-
> > 
> > 
> > 
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
-- 
Cheers

Magnus Westerlund 


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