Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response
Daniel Fett <fett@danielfett.de> Wed, 09 December 2020 07:43 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 CA9D33A0D2B for <oauth@ietfa.amsl.com>; Tue, 8 Dec 2020 23:43:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.765
X-Spam-Level:
X-Spam-Status: No, score=-0.765 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FONT_INVIS_MSGID=1.32, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 bGxb0GyiCDwL for <oauth@ietfa.amsl.com>; Tue, 8 Dec 2020 23:43:47 -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 C082F3A0596 for <oauth@ietf.org>; Tue, 8 Dec 2020 23:43:46 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 90C92181BC for <oauth@ietf.org>; Wed, 9 Dec 2020 07:43:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1607499824; 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=2cWgCZjb/NS1D8bVNPPeAd/MreWG1848QQ8TkFkCzUk=; b=SbVNSWi9oagkoFKW8eHMarrWO0EnUOB/re56jPIN0yL1UyBJ9mFLFHw+iOn5IKMB+/E/IK NisnMn1fxbYIbvaRcy6wVaAPlX+CZuWtLAOfl+axndIiPK1YUS0SPvGw6sTqeNFX2zCjvx rL5Z1HF0ZoD0ydCufSnxy62TnJ/QD6Y=
To: oauth@ietf.org
References: <CADNypP9D1G94LuPcgczSVYL+0KyMYoAK_s3H4JZK80Bj2mJKtA@mail.gmail.com> <CAD9ie-t7OroYwPrTQtwTS3Reem9bM5PHcVZ7D_N=jSmd6O7UGw@mail.gmail.com> <CAJot-L1-dYLy_m_WZv=bEC=r0zWSdKNXBMOV6b9SD8VR-dZvJg@mail.gmail.com>
From: Daniel Fett <fett@danielfett.de>
Message-ID: <0284ddd7-fb1a-ef5c-75c7-49c7d2656c14@danielfett.de>
Date: Wed, 09 Dec 2020 08:43:43 +0100
MIME-Version: 1.0
In-Reply-To: <CAJot-L1-dYLy_m_WZv=bEC=r0zWSdKNXBMOV6b9SD8VR-dZvJg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------ACC02561954F4575235F43FB"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1607499824; 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=2cWgCZjb/NS1D8bVNPPeAd/MreWG1848QQ8TkFkCzUk=; b=VD7n2BgKgd/xJ1a5byzz53PwlKHqzav8lFUDvPwPidpdGt4eaAtXn+3G693CfmYV3P6L3k Vyn5QrQhwPKCJ46KPx2vtYRn9cZ6ODq7ACkA+fjqjYkMJRW5cGAnvVf3bhZai72N5pErvA x9NQYzpt1OMcxuIro7w1cyYS2wCUJow=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1607499824; a=rsa-sha256; cv=none; b=nlMquySJN/ZiPhDxTHfi44BwiA/jzXL0L4ktPyL84OKZGCczx042nKqcPCselAI2DmfAv/ xA/gsS+KfvwTccHMvCViH/dER4pi1EITR+oyy+AQrO8Vv4TRDti4DGTdLRZCawP9HwqpZz +FI7LEiLwIBY7rzFpbyIYNPyPe/agFY=
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/ZD1DGuCHX8iHCbhFOuKsePkGiHQ>
Subject: Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response
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: Wed, 09 Dec 2020 07:43:50 -0000
Hi Warren, Am 08.12.20 um 20:15 schrieb Warren Parad: > As an implementer on both sides of the issue I'm struggling to > understand how this problem would occur. I'm finding issues with the > proposed problems: > > 1. Honest AS is compromised, assuming this does happen details on why > adding iss to the AS response would prevent attacks is necessary > for me. In other words, how would an AS be compromised in a way > that would be identifiable through the issuer value? (my ignorant > assumption is that a compromised AS is compromised enough that an > attacker would be able to send the correct ISS) > If an AS is compromised, we can't do much for it anyway. We must assume that all credentials from this AS can be stolen or forged and that resource servers relying on this AS have a big problem, too. The Mix-Up Attack is about attacking *other* (uncompromised) AS using the client's trust in the compromised AS. For clarification, in our slides we refer to - an uncompromised AS as H-AS (honest AS) - this is the AS which issues the credentials the attacker wants to read, and - a compromised AS as A-AS - this may have been uncompromised previously or may have been introduced into the ecosystem for the sole purpose of running the mix-up attack. In the mix-up attack, the client assumes that it is talking to A-AS but actually received the authorization response from H-AS. This is why the iss parameter helps: It always comes from H-AS (together with the authorization code) and therefore cannot be modified by the attacker. (If the attacker would be able to intercept/tamper with this communiction, there would be no need to run a mix-up attack in the first place.) > 1. Attacker AS is registered. I fully support the idea that this can > and will happen, however from attempting to test-implement this > proposal, I can't see how the authorization would be sent to the > wrong token endpoint. Since there is no information in the AS auth > code response, the client must already have the knowledge of where > they are going to send the token, no mix-up can be executed. > The assumption in the mix-up attack is that the client stores where to send the authorization code, for example in a session bound to the resource owner's browser. This would always be the token endpoint of the attacker (A-AS) in the mix-up attack, either because the user selected A-AS as the AS or because the attacker had an opportunity to modify the user's choice. > > 1. I would argue, if anything, adding the ISS parameter would open a > new attack surface by providing clients an opportunity to > blatantly trust the ISS parameter as the honest AS and thus > actually sending the code there instead of sending it to one > specified in the metadata document. > As far as I can see, the potential attacks from such a bug on the client's side would not be worse than mix-up, at least. It would undermine session integrity probably, in that an attacker-AS would be able to steer the client to send the code to H-AS. I'll take a closer look at this. > My confusion is the following: > > * Are multi AS services utilizing authorization codes in a way where > there could be a mix up attack for #2. > * Is there a #3 that I'm missing which even in light of #1 & #2 I > brought up that would still make this change valuable? > I'm not sure if I could help to clear up the confusion a bit. I'd recommend that you take a look at Section 3.3.2. of this document [1] which provides a more detailed description of the mix-up attack and why the defense mechanism works. -Daniel [1] https://elib.uni-stuttgart.de/bitstream/11682/10214/1/%27An%20Expressive%20Formal%20Model%20of%20the%20Web%20Infrastructure.pdf > > > Warren Parad > > Founder, CTO > > Secure your user data and complete your authorization architecture. > Implement Authress <https://bit.ly/37SSO1p>. > > > On Tue, Dec 8, 2020 at 8:01 PM Dick Hardt <dick.hardt@gmail.com > <mailto:dick.hardt@gmail.com>> wrote: > > +1 > ᐧ > > On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef > <rifaat.s.ietf@gmail.com <mailto:rifaat.s.ietf@gmail.com>> wrote: > > All, > > This is a call for adoption for the following AS Issuer > Identifier in Authorization Response as a WG document: > https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/ > > Please, provide your feedback on the mailing list by Dec 22nd. > > Regards, > Rifaat & Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- https://danielfett.de
- [OAUTH-WG] Call for Adoption - AS Issuer Identifi… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Neil Madden
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Torsten Lodderstedt
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Daniel Fett
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Takahiko Kawasaki
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Karsten Meyer zu Selhausen
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Brian Campbell
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Dave Tonge
- Re: [OAUTH-WG] [EXT] Call for Adoption - AS Issue… Michael A Peck
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Vladimir Dzhuvinov
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Dick Hardt
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Warren Parad
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Daniel Fett
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Karsten Meyer zu Selhausen
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Warren Parad
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Jim Willeke
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Karsten Meyer zu Selhausen
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Warren Parad
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Kevin Gaynor
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Dominick Baier
- Re: [OAUTH-WG] Call for Adoption - AS Issuer Iden… Rifaat Shekh-Yusef