Re: [OAUTH-WG] Token substitution in DPoP
Daniel Fett <fett@danielfett.de> Tue, 24 November 2020 09:38 UTC
Return-Path: <fett@danielfett.de>
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 C3A503A1994 for <oauth@ietfa.amsl.com>; Tue, 24 Nov 2020 01:38:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Level:
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.de
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 7l6AO5rd6wSt for <oauth@ietfa.amsl.com>; Tue, 24 Nov 2020 01:38:42 -0800 (PST)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F3D3A125F for <oauth@ietf.org>; Tue, 24 Nov 2020 01:38:41 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 238871686C for <oauth@ietf.org>; Tue, 24 Nov 2020 09:38:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1606210718; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=p81AZza8k32y0PooYZSs2068Qu0F0TGY8Ow7r6e1u5k=; b=nvXvb8+luqw3ag2MPyTWN+m9HBOJhBLTEiX+CYbHuClnfwxOFidVEO8omiiKXFftK1FYQX WizT/LkfqOLcclxsHFFOru5Kgopc8MNoHN92r6lNUQCUjq+EZEc/pIbGKFmbTVqzoso9Vc 9DC7/65/OGBucv1QhxoczWuPFYo4+LQ=
To: oauth@ietf.org
References: <92113933-D3F6-494B-A697-9C0D77F2808B@mit.edu>
From: Daniel Fett <fett@danielfett.de>
Message-ID: <c3e0e841-0e30-872e-a56f-330c0b897da0@danielfett.de>
Date: Tue, 24 Nov 2020 10:38:37 +0100
MIME-Version: 1.0
In-Reply-To: <92113933-D3F6-494B-A697-9C0D77F2808B@mit.edu>
Content-Type: multipart/alternative; boundary="------------801F6AA7668F40588572128A"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1606210718; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=p81AZza8k32y0PooYZSs2068Qu0F0TGY8Ow7r6e1u5k=; b=Le2qKPFkzYo8/HU5pl8Fv+zxux9WmsjOeOokjIuHsMJIkN+ICcJfAsgQQxIiUoxKt6wKzl 4E2FNC1tZDyctM58iCP2icd8MuFUhJ0hb7uOMDGiJxeUusW6F3cV7E5hxjPz1pHTKv5flO G9uGWUZ+TN7G1ABGbVyNTC0Ez6mh7j0=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1606210718; a=rsa-sha256; cv=none; b=mvN/nvawJda9CHUXFX4H8VuRgsB/HIiESXpIBp20wgXW953dEPgdkzunVP9OqqxKGzI93R rABnmk8vKM00+Y6jOF1YYaVKrOC1VnI+ixzaCCj04fB/cgIfbINNrEewhgq+AZWtyhq5cQ UcRGiv6LsEboNIQQsPEaZzZaabX00/o=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/mNpL8DQ6RP580XJnpj-75N0SUPk>
Subject: Re: [OAUTH-WG] 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: Tue, 24 Nov 2020 09:38:44 -0000
Thanks Justin for bringing this to our attention. Right now, I don't think that this is a big problem and I wasn't able to come up with a way to improve the attack. I hope that it doesn't come back to haunt us when somebody does a more in-depth analysis... That said, the lack of binding to the access token makes it easier to precompute proofs if somebody has a limited code execution opportunity in the client. We have this paragraph in the spec: Malicious XSS code executed in the context of the browser-based client application is also in a position to create DPoP proofs with timestamp values in the future and exfiltrate them in conjunction with a token. These stolen artifacts can later be used together independent of the client application to access protected resources. The impact of such precomputed DPoP proofs can be limited somewhat by a browser-based client generating and using a new DPoP key for each new authorization code grant. The recommendation could be to use a fresh key pair for each token request. -Daniel Am 20.11.20 um 20:26 schrieb Justin Richer: > 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 -- https://danielfett.de
- [OAUTH-WG] Token substitution in DPoP Justin Richer
- Re: [OAUTH-WG] Token substitution in DPoP Nikos Fotiou
- Re: [OAUTH-WG] Token substitution in DPoP Justin Richer
- Re: [OAUTH-WG] [EXT] Re: Token substitution in DP… Michael A Peck
- Re: [OAUTH-WG] Token substitution in DPoP Brian Campbell
- Re: [OAUTH-WG] [EXT] Re: Token substitution in DP… Brian Campbell
- Re: [OAUTH-WG] Token substitution in DPoP Daniel Fett
- Re: [OAUTH-WG] Token substitution in DPoP Neil Madden
- Re: [OAUTH-WG] Token substitution in DPoP Brian Campbell
- Re: [OAUTH-WG] Token substitution in DPoP Brian Campbell
- Re: [OAUTH-WG] Token substitution in DPoP Justin Richer
- Re: [OAUTH-WG] Token substitution in DPoP Neil Madden