Re: [OAUTH-WG] BCP: Client collaborative attacks

"Manger, James" <James.H.Manger@team.telstra.com> Tue, 27 October 2020 01:04 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3C33A113F for <oauth@ietfa.amsl.com>; Mon, 26 Oct 2020 18:04:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (1024-bit key) header.d=team.telstra.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 7hgMriNgj42c for <oauth@ietfa.amsl.com>; Mon, 26 Oct 2020 18:04:22 -0700 (PDT)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) (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 A10C93A113E for <oauth@ietf.org>; Mon, 26 Oct 2020 18:04:20 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.77,421,1596463200"; d="scan'208,217";a="403116272"
X-Amp-Result: SKIPPED(no attachment in message)
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 27 Oct 2020 12:03:09 +1100
Received: from wsapp5862.srv.dir.telstra.com ([10.75.3.94]) by ipcbvi.tcif.telstra.com.au with ESMTP; 27 Oct 2020 12:03:09 +1100
Received: from wsapp5873.srv.dir.telstra.com (10.75.11.109) by wsapp5862.srv.dir.telstra.com (10.75.3.94) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 27 Oct 2020 12:02:43 +1100
Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5873.srv.dir.telstra.com (10.75.11.109) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 27 Oct 2020 12:03:08 +1100
Received: from AUS01-ME1-obe.outbound.protection.outlook.com (10.172.229.125) by autodiscover.team.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 27 Oct 2020 12:03:08 +1100
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aIm/j4G69zuvaWmVsClh9na5Ah2Sw0wlnZJR4TkK0IqfMEcdadsOBh5Fgkq6Hd0Ozkbv+272kpPvewUc+GwW8IVgYoOvf58yruRnunqqSFJRQp7n2FE7FfO50TFnQyMEZue4OUCcREZj3J/VD9JNgMVt73jzVI7ZLkno+onGaSVWvuxpFGdLoqFX2O7TfHvp1s87IAjgA2cXBILMqwwgHn47WxsyIhmsxRUimZ+88ym7x2PCoJxN6EZVTh79jOW+d6mthuBO4c9l/1BTjpJXaQcT08b2OoT3j/6LXa3V7M831oxqIYYKCyeMFdlR7INz448hANOaSVPCWOpYcWIRIA==
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=PIRGHungGmNFngmaiI3/1TBd8jNJ12aKZOSTFxDVFAA=; b=d5asfVd7JKkyGycLyy8/N9J/5DP5gEoqucNOw7Fc8EFCrA+pVKkcG08/o/qVa/yySfGDoUr2XLMcsFuNOr/kXqxJp0UgKZqDZBUJqsZ8e28GMp91owqcLDs5t9ZK5Y7gkuWuJ894fpsTgBBTyCh/usyfcN8khzkvySwpRg4ItICL6uxPIjEQSSOgBdh60+bTFDCpTIeB22svPiM/iwH2sB3rtwBql785QJ0R1/6kIEYIRWXiaCn4FY7CgNV15CUBeGSExxI8zEEAg2WZxuCcJcjlylt8SCiu3HKKzFKSlcoSMLWDZ5pnQAnBlqJxWWMvHlLlREfdYPElGcwdjU6+0Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.telstra.com; dmarc=pass action=none header.from=team.telstra.com; dkim=pass header.d=team.telstra.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PIRGHungGmNFngmaiI3/1TBd8jNJ12aKZOSTFxDVFAA=; b=I4eN6az5iqPCpvkEQqodFeSO/D+Lr4ByMBVt+83z5Z8ThOfdapu42rVNlu4+eePujwzzdRUYZKi5ZmBHpJ9lJw45ib4m8EH+Q5FMurAkvlCYpQ3wRmfJ3UgXx6L9+Z8uyyfZBgm5c+rQ0prOxRBicNJENEBCr5g0LdkxjiNhqrQ=
Received: from ME2PR01MB3011.ausprd01.prod.outlook.com (2603:10c6:201:19::12) by MEXPR01MB2040.ausprd01.prod.outlook.com (2603:10c6:200:34::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Tue, 27 Oct 2020 01:02:59 +0000
Received: from ME2PR01MB3011.ausprd01.prod.outlook.com ([fe80::a52e:8dfd:877a:3972]) by ME2PR01MB3011.ausprd01.prod.outlook.com ([fe80::a52e:8dfd:877a:3972%7]) with mapi id 15.20.3477.028; Tue, 27 Oct 2020 01:02:59 +0000
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: =?utf-8?B?U2XDoW4gS2VsbGVoZXI=?= <sean@trustap.com>, Denis <denis.ietf@free.fr>
CC: oauth <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] BCP: Client collaborative attacks
Thread-Index: AQHWq8SAV39nbzcrrkCd6bB+C+9SVKmqY6IAgAAb/KA=
Date: Tue, 27 Oct 2020 01:02:59 +0000
Message-ID: <ME2PR01MB3011145F49559C4996B7E1E0E5160@ME2PR01MB3011.ausprd01.prod.outlook.com>
References: <8244f38a-710b-e95c-c61a-1b8df541c73e@free.fr> <CAPLh0AOqegW07_6vSPsmmp9YtPTh6G71=v_tUqA2GjhwZ6iKSw@mail.gmail.com>
In-Reply-To: <CAPLh0AOqegW07_6vSPsmmp9YtPTh6G71=v_tUqA2GjhwZ6iKSw@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.5.0.60
dlp-reaction: no-action
authentication-results: trustap.com; dkim=none (message not signed) header.d=none;trustap.com; dmarc=none action=none header.from=team.telstra.com;
x-originating-ip: [144.132.40.82]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f43a04d2-89f1-484b-2c36-08d87a140c3b
x-ms-traffictypediagnostic: MEXPR01MB2040:
x-microsoft-antispam-prvs: <MEXPR01MB20402C51600429959186D962E5160@MEXPR01MB2040.ausprd01.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LjNySJ7Mi4fB/qc9RvpLzmZcVu8m5yA402XVXUbuK2e2dRZOp0JIezrd5xe6M96CGHJEa1pjUvipExEE3z+76pqmldCnh7WZRUctwrYySs/dy3kOzIm5AsgChAymzcUHOrMWe0GeyvK+iYujSmEkFtQTzVga8TxzwpRASZeUkvk8/7mPij3pE00tQ+hwt4HxE0/+xFuIit2tEbwdOx92Ig128Cpowc0mWAw8er1W9RVZIRt231jY/uRIPjjnBWhBlR5oGCMRgqCjwiEhnb36tyocCf8FWUE4RWrOSUzmupIhgjCI94wfj3BhAv6+y2bEggh4y0knixlIfquqdtQiig==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ME2PR01MB3011.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(39860400002)(396003)(376002)(346002)(9686003)(4326008)(66556008)(110136005)(8936002)(2906002)(64756008)(76116006)(66574015)(66446008)(33656002)(83380400001)(66476007)(66946007)(8676002)(316002)(86362001)(55016002)(186003)(71200400001)(52536014)(6506007)(478600001)(7696005)(26005)(5660300002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: M0z0tEI3rFn8/osMXcj7cshxDPr54OGEx8FQYovXiCzpZAQTy+MIX7I/as/xH2j4/cdbxYQJ/1iHm8UsMMvcrqXXX4Pkf7Fgz2X1ArJc9OCgKmKLlo7E8WvXlp/x9Bz8ousizK6bCo8v5An8fLTAskgMRfuAbsjMPJh0ka5hiA8jdiczEImIql05Cqw6DX7X6c1kDxT4ZK/j8bnwoSzi2LxNxo/k4nE0AZoX5+FVQPUC586JUA0MghNmvKcS5oIV1ZF89WbjctYfV5bDttsg4Mn63Ex55QEqx63ksUaLRD7GFqQSDQ+pxLVf3sSChQiVYy2/eIwPvYdvX6LuahpZpQ9xOEWsrNBb05bwVWL7bc+vVfxSvjXh6dhm3Rp5SHm6WQqZW5ESjZBWnQ1ZQdpPFGtZZO3hS+VymRTpklg1aQJGRXYtk6+AdpxFQvLv1XFf8TtT0r5lFHwzPp45pn10hD/VBwOm+a4IcmmZ5GN1Lroumsp6f1tDyuShPmIw5dN4WYwqHcLn5q6Iipg8h6zC2EERtkb3YExa2ZvgaljBcuhRKQvWqg/W7ln531DpASBHrznSpGXRgB/XtokniDAtAAexFq/5DBs+7CBnAZM8Nrzb3nN6bZ7n5fXN7asgQWEIVA7I+KZpIQLmkIROuvXr2w==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_ME2PR01MB3011145F49559C4996B7E1E0E5160ME2PR01MB3011ausp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: ME2PR01MB3011.ausprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f43a04d2-89f1-484b-2c36-08d87a140c3b
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2020 01:02:59.5624 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bLHwKuG6iszdg4eLRBi6mLy/1ewfQfXzMGOt0DKOoanDR2kclleV40Cst0HWRBi93J/koTcUDGdHTxjcz6tjBLOOh6toEcVBx7wdnl+puiM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEXPR01MB2040
X-OriginatorOrg: team.telstra.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/zBiDVxJoRPCBzCl8ov131IZpjdU>
Subject: Re: [OAUTH-WG] BCP: Client collaborative attacks
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2020 01:04:25 -0000

It is worth mentioning “client collaborative attacks” or “authorization sharing attacks” because OAuth can make them easier (by packaging authority into an access token), compared to the alternative of user’s signing-in to an RS directly. But it is tricky to describe; none of the suggestions are quite right; and the “right” solution heavily depends on the context.

>> If access tokens are used to identify individuals, and such identifying information (ideally user IDs) is stored with access logs for auditing purposes, then this reduces this attack to an authentication sharing attack.

While this text from Seán may be true, it is bad advice. It implies we should make access tokens as dangerous as possible (conveying all a person’s authority) just to discourage sharing.

> Since OAuth 2.0 does not mandate the use of cryptographic devices, this kind of attack cannot be countered in the general case.

Even crypto devices aren’t a full solution. Alice can share her authorization with Bob & Chris by signing-in with their crypto devices.

> an access token … only stating that the holder … is over 21 … should not be accepted by the RS

While this may generally be true for an “over 21” claim, it will not always be true for other claims. In some situations the privacy risk of being personally identified is far more important than any risk of client collaboration. Staff accessing a company’s whistle-blower service could be an example: need a {staff:true} claim to combat spam/gossip; but definitely don’t want to include a staff id.


A handful of partial strategies appropriate in various circumstances (but all with downsides) could include:
1. The AS ensures there is only 1 valid access token (or just a few) at any point in time for a specific claim of a given user.
2. Access token bound to a crypto key locked to one device.
3. Each access token is unique (eg includes a "jti" claim) so an RS can notice if the same token is presented in different contexts.
4. Access token with "sub" (or provides "sub" via token introspection) to aid accountability (even if only in a later audit/investigation).
5. Frequent token replacement.
6. Nothing (beyond minimal necessary claims) – to maximize privacy.

What is applicable widely enough to mention in a BCP?

--
James Manger