From nobody Tue Dec 8 23:43:52 2020 Return-Path: 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 ; 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 ; 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 ; 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 ; 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: From: Daniel Fett Message-ID: <0284ddd7-fb1a-ef5c-75c7-49c7d2656c14@danielfett.de> Date: Wed, 9 Dec 2020 08:43:43 +0100 MIME-Version: 1.0 In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 07:43:50 -0000 This is a multi-part message in MIME format. --------------ACC02561954F4575235F43FB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 . > > > On Tue, Dec 8, 2020 at 8:01 PM Dick Hardt > wrote: > > +1 > ᐧ > > On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef > > 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 > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > 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 -- https://danielfett.de --------------ACC02561954F4575235F43FB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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.


On Tue, Dec 8, 2020 at 8:01 PM Dick Hardt <dick.hardt@gmail.com> wrote:
+1
ᐧ

On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef <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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
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



-- 
https://danielfett.de
--------------ACC02561954F4575235F43FB--