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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Mon, 27 January 2020 12:56 UTC

Return-Path: <tirumaleswarreddy_konda@mcafee.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 ADD58120118 for <tram@ietfa.amsl.com>; Mon, 27 Jan 2020 04:56:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_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 (1024-bit key) header.d=mcafee.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 rdExMza-GV_p for <tram@ietfa.amsl.com>; Mon, 27 Jan 2020 04:56:31 -0800 (PST)
Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8573120115 for <tram@ietf.org>; Mon, 27 Jan 2020 04:56:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1580129790; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jRRRbudEgBK6Iw5DmhIsPwLyEV/ra8PghxKLp7efBcQ=; b=CsoTfsKNgUJn6YArR4ALLn8mwRKTqQRHVtZRpDuuWb/rvyjskQUDqgBRmFVcwVq3NRa7hE 6JByqz5ql03Z66gEV4dTX4GufcTfj0LvrDALT0cjMZOvR7ohdh3RQLG59YQaycuzPa6hve fPPyrgMHbThhTzbnbj3TeHqVap8I3Q0=
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2104.outbound.protection.outlook.com [104.47.55.104]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-212-2jV_GU9XMhuZ1rYybJeLkQ-1; Mon, 27 Jan 2020 07:56:26 -0500
Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1221.namprd16.prod.outlook.com (10.172.115.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.22; Mon, 27 Jan 2020 12:56:23 +0000
Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd%12]) with mapi id 15.20.2665.017; Mon, 27 Jan 2020 12:56:23 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "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: AQHV0tNtiErNXCJjEUGJD1dlX4Iwiaf+etJA
Date: Mon, 27 Jan 2020 12:56:23 +0000
Message-ID: <CY4PR1601MB1254115C5BE2715A9EC56172EA0B0@CY4PR1601MB1254.namprd16.prod.outlook.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> <cf5e9cd3d1b0c71659edcd04283a43db4efa8bd2.camel@ericsson.com>
In-Reply-To: <cf5e9cd3d1b0c71659edcd04283a43db4efa8bd2.camel@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.4.0.45
dlp-reaction: no-action
x-originating-ip: [49.37.206.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 35669873-fc0b-4464-17f4-08d7a3285022
x-ms-traffictypediagnostic: CY4PR1601MB1221:
x-microsoft-antispam-prvs: <CY4PR1601MB1221B26690E95E16FA4F1B96EA0B0@CY4PR1601MB1221.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 02951C14DC
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(136003)(39860400002)(346002)(376002)(32952001)(189003)(199004)(478600001)(4326008)(966005)(8676002)(8936002)(186003)(86362001)(81166006)(81156014)(55016002)(9686003)(7696005)(316002)(110136005)(26005)(54906003)(6506007)(53546011)(33656002)(16799955002)(2906002)(5660300002)(52536014)(66446008)(64756008)(66556008)(76116006)(66476007)(66946007)(71200400001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1221; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +WJDa1jYSaobLbNhvKEBDfH87joKH8kKbYigy3iF3d7tqUtzIn+IFLY/+UU0MKb8uZLDm98vsl6oVrbn7r3A/omW08a80N7tdTYTR2otYOvnFkjgBnkjkJ4UZfzoBYx9phJvMn8TqMso71+fiGftzxzP1/IiSwm4qcyiBNbKh7oYUB0QthMDH+CnIZSc8aZ9BECx3eZ9pjDU0RxSzcJfmM+Zy0Z2gLd1z+eAyMZ7L6fgA6aG2kdMnHSxgY/kGgpyE6x3yLUbM8jiTilqf2v1v2qbtjOUUbyfLL67dz68HBmmXGf7d8k8cccOFBB3ax4WIShDBQkSA4uOUXBDiwJS9qYc6b2x+uPeP5NcGDFwXwjEzA3ydq6dbJRRign17SRUtVXrFy8E1kf0iazT08F9992ys85xtKlsQ+O+G9WSq/gasAC4iWYjeEi1CRC6zdiqHNYM4XqkhYwGZALdXMzUrz5lPFmgV1VKahICiHCNS+YkrR8kTZdfp1Myu4H08atQmWjh06yxf8+pR0b0hViBNE1/szR6WfHCwjXWOy3+hqrTy143frr9NDVlftxDIwNnE1cPIIAhglyLR49vgtWq3TCxIwM5Y5angtzsWI4FNPw=
x-ms-exchange-antispam-messagedata: k6GhP4UA3jwxmViqKxIH7S1p6mGJM6HCd63QJtA3po+KrSzaEYQ9a8/NwQ1dkTos81vZhLGJsGsRS2AjPzmCN/M/91kNf0qZdHkHYdAuYQAKdsHxJcuZSD4MsI3xujXASlmbsoSDbKkHRsS/zN5kzA==
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: mcafee.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 35669873-fc0b-4464-17f4-08d7a3285022
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2020 12:56:23.2406 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2G1WIyyxHiKLMnO1zzlbVwPyocVvWbYHyhkkoCrpFh/ID45PUnff01ARmKDW7CqISKy9f6gxnpx0abt9syoJKpLaYGY3s1InV2CFt+ftT5j5GcjZuEY5e8rOrqLBd3xW
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1221
X-MC-Unique: 2jV_GU9XMhuZ1rYybJeLkQ-1
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: mcafee.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/-rxekYmXFw5Z_nCS6qiUK-UiKCM>
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: Mon, 27 Jan 2020 12:56:34 -0000

The short-term credential mechanism for TURN is discussed in https://tools.ietf.org/html/rfc7635, it addresses both the issues raised by the reporter

a) Section 9 says,  If the access token expires, then the client MUST obtain a new token from the authorization server and use it for new
    allocations.  The client MUST use the new token to refresh existing allocations.  This way, the client has to maintain only
    one token per TURN server.
b) Section 11 discusses frequently changing the nonce.

Cheers,
-Tiru

> -----Original Message-----
> From: tram <tram-bounces@ietf.org> On Behalf Of Magnus Westerlund
> Sent: Friday, January 24, 2020 9:59 PM
> To: mcr+ietf@sandelman.ca; juberti=40google.com@dmarc.ietf.org
> Cc: behave@ietf.org; tram@ietf.org
> Subject: Re: [tram] [BEHAVE] errata 4933: RFC 5766 prevent spoofed refresh
> requests when using short-term credentials
> 
> 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>ca>, Sandelman Software
> Works
> > > -= IPv6 IoT consulting =-
> > >
> > >
> > >
> > >
> > > --
> > > Michael Richardson <mcr+IETF@sandelman.ca>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
> ----------------------------------------------------------------------