Re: [OAUTH-WG] [EXT] Re: Token substitution in DPoP

Michael A Peck <mpeck@mitre.org> Mon, 23 November 2020 13:03 UTC

Return-Path: <mpeck@mitre.org>
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 0DA5C3A0ADF for <oauth@ietfa.amsl.com>; Mon, 23 Nov 2020 05:03:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=mitre.org
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 zWGR-IRh7nYx for <oauth@ietfa.amsl.com>; Mon, 23 Nov 2020 05:03:16 -0800 (PST)
Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) (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 8BDB73A0AC1 for <oauth@ietf.org>; Mon, 23 Nov 2020 05:03:15 -0800 (PST)
Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3FF411BE47E; Mon, 23 Nov 2020 08:03:14 -0500 (EST)
Received: from smtprhbv1.mitre.org (unknown [129.83.19.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpvbsrv1.mitre.org (Postfix) with ESMTPS id A45F11BE0A4; Mon, 23 Nov 2020 08:03:13 -0500 (EST)
Received: from mbfesmtp-mgt.mitre.org (unknown [198.49.146.235]) by smtprhbv1.mitre.org (Postfix) with ESMTP id 9648680C79D; Mon, 23 Nov 2020 08:03:13 -0500 (EST)
Received: by mbfesmtp-mgt.mitre.org (Postfix, from userid 600) id 4CfnQ94HWyz3D4CC; Mon, 23 Nov 2020 13:02:57 +0000 (UTC)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2102.outbound.protection.outlook.com [104.47.64.102]) by mbfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 4CfnPm17JFzmqC; Mon, 23 Nov 2020 13:02:52 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iBXj/9Q9o7xHIgkP9YJTwy+G3k8BDyR8uC4UuU5If1XMdlCZI+jGhzFh2rPgB90+41ZKyYpXzlaCHyk9V6de/wVbvcfyETgKmIkv2kSE5BpgvRZR8HbikImAlfaNY15rWFTX/G2cO/xgqsz9W6uWOBY096qzsHc6FpuYXKMCGaJ9qBVdLahlIXhLC7J/4aUd9Vv8xR8N9tWKG5luOn6ZFqj2V4p1jwJdbZDy+gYtSBqTvr3diIREe4xBta9oIVIl/M4WPvXwzwVXlewL93OIAfdWjYW5CwHlz7q+/vjMXMFUHsRsqAJwZGBqkMeVDfI65nJfiiDB1XZaH4BGO2Uhnw==
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=i/kiD+j8Tk6pxGHnwMZNDYW4fntfZBoyypYTBvANc2M=; b=YhFRpCIlotSDsBI9ERWCZPBZ98Xzho4CIapXmgImRJCcCiOmKgwQI54q15qs8+3bpGPSDlwwGnd+xk/d8CHK6hhxljZqDSaSS1VjOO3NCHp7KIWvXoZUuPgHiYn0Z/XM1STAbq2z+5bOl0sn4eLvSrVjr8PTjEj1gPEeEwfi4BgW2Bzx07PxnF53SoDyGTCPICwEfIY0l1OIlbdJncj3Ome9zafv6VLKfTLPa//16zh8FYtTU57I6nnUmFxC/I+k4Xydjje8LxAApgDuOh9oTdyjp1Io4vEGjDBVhM6INRlw1abHdc+ohw2b/6N90+UQgeg9/80mnsbxqL0ZomCMdw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none
Received: from MN2PR09MB5724.namprd09.prod.outlook.com (2603:10b6:208:213::14) by MN2PR09MB5161.namprd09.prod.outlook.com (2603:10b6:208:220::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Mon, 23 Nov 2020 13:02:50 +0000
Received: from MN2PR09MB5724.namprd09.prod.outlook.com ([fe80::4879:b624:224a:644c]) by MN2PR09MB5724.namprd09.prod.outlook.com ([fe80::4879:b624:224a:644c%3]) with mapi id 15.20.3589.030; Mon, 23 Nov 2020 13:02:50 +0000
From: Michael A Peck <mpeck@mitre.org>
To: Justin Richer <jricher@mit.edu>, Nikos Fotiou <fotiou@aueb.gr>
CC: oauth <oauth@ietf.org>
Thread-Topic: [EXT] Re: [OAUTH-WG] Token substitution in DPoP
Thread-Index: AQHWwY8CzMQLqWr/LSN3K9lSN/t1H6nVWvUA
Date: Mon, 23 Nov 2020 13:02:50 +0000
Message-ID: <2B99664F-C236-422D-BBA1-BCF99485DBDC@mitre.org>
References: <92113933-D3F6-494B-A697-9C0D77F2808B@mit.edu> <016f01d6bfae$407e6bd0$c17b4370$@aueb.gr> <15245_1606132326_5FBBA25D_15245_296_1_0352818D-4793-44E2-832B-3FD7B7BF7507@mit.edu>
In-Reply-To: <15245_1606132326_5FBBA25D_15245_296_1_0352818D-4793-44E2-832B-3FD7B7BF7507@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.42.20101102
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=mitre.org;
x-originating-ip: [192.80.55.89]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 8dd72f1d-226f-4fbe-c57c-08d88fb01548
x-ms-traffictypediagnostic: MN2PR09MB5161:
x-microsoft-antispam-prvs: <MN2PR09MB5161F20748695079DA491180B9FC0@MN2PR09MB5161.namprd09.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: rxKEfWVLC1KhCSW+Khqctw3eVPEXMNFGH5W769+5uil3/9oD7Ix5sPWSp0GzahG/U6/hF0LrJWMu4WhWfX83NhgxtphT3t6qahtqww8n0wtpy+JwP1DSCbRx8Q9kJKPPTeS8SZMZ0WZ9DZVy+hBRrZbIBsK89pvOAGWvsP87uQhtTRZzx75y479j63bi6g678d3ASNPWXK10luA2GaraSRfprOXCYVuIyHSzhi2WxJtohtyEQsQQgI2dK97nX7MixSwnUiBqxg9bPceLF4pRuKl56XUpLUpHpUL0YaI/hD576TI8cFJN2MPYMHIpZsJDntXP4OFni+iD8H1hbDlpND4Ixoihn+OCyfxy2rP6S5FGtsEkCV3M8oCQ7WA1BxXDIftMyNOLeH4p1v/2NWPBMQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR09MB5724.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(346002)(366004)(39850400004)(376002)(83380400001)(26005)(6512007)(186003)(86362001)(4326008)(2616005)(36756003)(66476007)(8676002)(53546011)(110136005)(966005)(6506007)(316002)(6486002)(71200400001)(33656002)(2906002)(5660300002)(76116006)(8936002)(66946007)(478600001)(64756008)(66446008)(66556008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: FJR5JUUmQJfjwPbY14TOYfEZiYfcdWpLpeh/wu3TTjdzD9YKJkYBFzHc2KDNNvS+0EzEtasnYIBlJ1yo37iBhe51ZicIV2bNaS3EI526hgHRGlQUN1ipmEu5/XYzKknHoIldADCTEdRkUis/E5pwfdiShQ2XxA43PByLvYz50dNXj22qug109lx74YaIUXQv61ya3+PNIK9T3P8BlhFVQrJFrLwOe6zOnv09jg1ybmisaHTEciZjbX4/0gQPLCXfnrBQCTi+Zq9VlX+5mUGaFsYEBb99y2IbR5soh50+ySQpCt3j8Ao0pzR0WC14F0eCku+Bts67PVk0EacXOTSuOvbjBU1Z0WrfJofG8Zo14/HWsoG6w47NBLByVEOqmKaIEBsnb4Yfsa5FtWIC375b4VKb0sI55/plJCh1MVamCocZtZ4JDvg9IyGlf1goN0+qZ9wayt9bUYar9yQr6nkjBpigQfYmygCSivx1V6BP9KWBXs/7asS67/Rg5BgzcwFSb67GyL1omQ2npmf88xHnUpdz36sS0JQIhBLVVt3D8E4CoQR2xE4h9AgRN2vapChFidIk6cbz4CzPBeBK2v/3Bz4R59WsjEvI6df4XbQTZox0MaTK1zkgtZUFp4eMIsvj4b2Ax3e2WjJvcO0jUlgHclJGtUPO3oDIEYtJks+Ibjh4n9OyZKF36tf1zp8aIZtJMRDtVL/qR+Na/eFUDUlUB3kkDLQjeJfeLyVgtG9c1PKDeas1vxhOAKREnfDFM4GhIvLYZhAKrGYX9KkabXzeqLeEy1xB2/gkukRhW15E8xJz4czm5/wpZQ0aX7qNI65Ov28bBUOIBWZNTU+gYfIYZaAbMAdslRXKUhntOqMOvIzzqw28KDmumckphGU8SBjVPN4EktV+IMcpQySuemAGTg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <FB81738AFF25414A91D0CB132CD2FA6C@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: mitre.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB5724.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8dd72f1d-226f-4fbe-c57c-08d88fb01548
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 13:02:50.5697 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: n7JMctnTt8NGwXwdxxbD4EPLb6Dh6IA1fOkoBh3/z7k4TQ24K3B3KnejeIsuvJHh
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB5161
X-MITRE: 8GQsMWxq66rxk57w
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-type:content-id:content-transfer-encoding:mime-version; s=selector1; bh=i/kiD+j8Tk6pxGHnwMZNDYW4fntfZBoyypYTBvANc2M=; b=kxhXkcY5jW/nSImDWptilU2jDYSPCp/lKgxSSfh/xfFRTANJkCfnUyRIq61/l6DLDrtZRC6TU01nkQA6gelUVpF+Xk1xoSTmzlY5TzwmLKaU/rtq2RUJHKjS+QBhY1CfkHWr+kTstoPUM2II9Uo3kE2kp94sFVB6S+QdpE+WV3E=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/vdiRPQMz95ozjLLmJtX3a9Flt-s>
Subject: Re: [OAUTH-WG] [EXT] Re: Token substitution in DPoP
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: Mon, 23 Nov 2020 13:03:19 -0000

I agree with having the DPoP proof cover the access token (unless there's some burden on the clients doing so that I'm unaware of).

That would also limit the ability to pre-compute DPoP proofs with future timestamps (I sent an email to the list about this on 1 April) if an attacker can perform some kind of attack (XSS?) that temporarily allows executing code in the context of the client - as it would prevent generating DPoP proofs for access tokens that have not yet been issued.

DPoP key rotation (e.g. "generating and using a new DPoP key for each new authorization code grant" as suggested in section 2 of the DPoP draft) is a good idea but as Justin says depends on the clients actually doing it, with no real enforcement mechanism.

Mike

On 11/23/20, 6:52 AM, "OAuth on behalf of Justin Richer" <oauth-bounces@ietf.org on behalf of jricher@mit.edu> wrote:

    Correct, but the choice of using different keys is entirely in the hands of the client, as the AS accepts whatever key the client presents in its initial DPoP proof to bind to the token. If it’s on the client to prevent this kind of thing, we should at least mention it in the security considerations. If it’s something we want to prevent wholesale, we should expand the signature coverage to the access token, or at least a hash of the token.

     — Justin

    > On Nov 20, 2020, at 9:30 PM, Nikos Fotiou <fotiou@aueb.gr> wrote:
    > 
    > Hi,
    > The token is granted to a client based on the authorization grant and not the client's key. Therefore, a client may use a different key per token. At least this is an approach we are following. 
    > 
    > Best,
    > Nikos
    > 
    > -----Original Message-----
    > From: OAuth <oauth-bounces@ietf.org> On Behalf Of Justin Richer
    > Sent: Friday, November 20, 2020 9:26 PM
    > To: oauth <oauth@ietf.org>
    > Subject: [OAUTH-WG] Token substitution in DPoP
    > 
    > While working on an implementation of DPoP recently, I realized that the value of the access token itself is not covered by the DPoP signature at all. What I’m wondering is whether or not this constitutes an attack surface that we care about here. Here’s how it works:
    > 
    > 
    > Let’s say that a client creates a DPoP key and uses that key to request two tokens, T1 and T2, for different users, Alice and Bob, respectively. Alice is malicious and wants to get Bob’s stuff. Alice manages to get a hold of Bob’s token value, T2, through some means. Normally DPoP wouldn’t let Alice create a new request using T2 since Alice doesn’t have the client’s key. However, if Alice gets the client to create a request for her using T1, she can copy the signature from that request onto a new request using T2. Since the signature doesn’t cover the token value and the key is the same, the RS should accept both requests, right?
    > 
    > An important aspect is that the parts needed to make this attack work are a little weird: you’d need access to a valid signed request from the client with T1 as well as access to a valid T2 attached to the same key in order to make this substitution. However, this is effectively the same attack area that bearer tokens have in a lot of ways, since it doesn’t require the attacker gaining access to the singing key to generate or modify a signature, nor does it require the attacker to generate or modify an access token (merely obtain one).
    > 
    > 
    > I’d like to understand if this is an actual attack against DPoP. If it isn’t, how is it countered by DPoP today? If it is, do we discuss in the DPoP draft? I didn’t see a mention of it there. If it’s not, should we discuss it there?
    > 
    > 
    > The old OAuth PoP draft mitigates this attack by putting the access token itself inside the signature body instead of a second header. Another option would be to include a hash of the token value (such as OIDC’s “at_hash” method used in ID Tokens) in the DPoP payload. With either of these approaches, Alice having access to T1, T2, and a signed message for T1 does not allow her to use T2 effectively.
    > 
    > — Justin
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org
    > https://www.ietf.org/mailman/listinfo/oauth

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth