Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response
Warren Parad <wparad@rhosys.ch> Wed, 09 December 2020 13:35 UTC
Return-Path: <wparad@rhosys.ch>
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 0D30F3A166A for <oauth@ietfa.amsl.com>; Wed, 9 Dec 2020 05:35:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhosys.ch
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 Z10aI9UJ_1uZ for <oauth@ietfa.amsl.com>; Wed, 9 Dec 2020 05:35:08 -0800 (PST)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27833A1669 for <oauth@ietf.org>; Wed, 9 Dec 2020 05:35:07 -0800 (PST)
Received: by mail-io1-xd2e.google.com with SMTP id t8so1632323iov.8 for <oauth@ietf.org>; Wed, 09 Dec 2020 05:35:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PN6eVZ/joSM6RzlAt+jM7UCmI9Z9ja8fo31db0K9qiw=; b=FxzsQjYDqja4HXPaMU08DPBYgwqnUvbG6gt2R4krUxEH2UxXys4mgoU2otgpgGq7gL cbbDGIrI2v6Sg35HDciM5dWe7nBwMTb5h02rs6NmBRFRdypABtaE6aO1ZyQup/3pPvtO 4yiuk1DMIDyTsje/FCUa3qFhEs7SntiWN6HlY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PN6eVZ/joSM6RzlAt+jM7UCmI9Z9ja8fo31db0K9qiw=; b=qfzVDZdj71WsBbEI9nhKw0RMKDzi+6rTVkod3/kjPtYGkvOjCNhZMJa07IEBi3lLUL cWvedA9V0w8DAfOGRgqNpz3n34RwjrY2PSReQdH65idNbZozULn/n0KYDubNYukNaaFq AxfgeOLQYuS6EQlykVfUKOVWbM31gEDdRTO9pbwAPgsaAsZ7kARExTSJMw4kmce64XSq 76ZpeYSG6wGTemwkcLEPD73CwKmNpOQRpzCGmmEOdP37K4OxONTvilPoU6BFRbIT3NFp rqfLUXAHw2xc/YTQ3GwMZgU34ymwaA7Og/A08KCLlfJiua5G285cFtHVm/y87DTmozBr y7Ew==
X-Gm-Message-State: AOAM531htNMyCsiQEem8Zjw3dYcu5Zl9vewq9uLZwFZTD6k0i4ow/GRD 3poJ2JB5D3rrq8w/XIbdzGcWgalsL0R8hDs5CMnb
X-Google-Smtp-Source: ABdhPJzeaHcL5baoPYwozcN5jt69BgmthvzAa2vXXzfdvYAZPQqQ0e5hPljKM8cJ5oGpx9v7q+35hwgf3ocCkzCPxJ8=
X-Received: by 2002:a05:6638:153:: with SMTP id y19mr3178088jao.47.1607520905511; Wed, 09 Dec 2020 05:35:05 -0800 (PST)
MIME-Version: 1.0
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> <09d3639d-7d7e-9582-d728-cc223d21bcb6@hackmanit.de> <CAJot-L2FrMrxBGATVHd1DVwbqyMGoH7Dy1stP46vUVpEWrq21Q@mail.gmail.com> <7dacfb6c-4fca-5dda-8b4f-db5c8dadade1@hackmanit.de>
In-Reply-To: <7dacfb6c-4fca-5dda-8b4f-db5c8dadade1@hackmanit.de>
From: Warren Parad <wparad@rhosys.ch>
Date: Wed, 09 Dec 2020 14:34:53 +0100
Message-ID: <CAJot-L0DC1RS+YvJH1xLnuYbSdEyr12e=CuXh3eh7oYLXhCpyA@mail.gmail.com>
To: Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/mixed; boundary="0000000000008cb0e405b60820e1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/PV0OS7BR-n0hmehJSI_6zLwpKNo>
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 13:35:11 -0000
Since there is a potentially valid TLS case, let's shelve the non-TLS case without the precondition. I agree a MITM attack on the authorization code is a legitimate case which would be mitigated by resolving the ISS parameter to determine the valid token endpoint. I would suggest to improve the language in the *Introduction* to specifically indicate this as a solution to the authorization code interception. (It wasn't clear to me before this conversation that it helped solved that problem) So +1 On Wed, Dec 9, 2020, 11:40 Karsten Meyer zu Selhausen < karsten.meyerzuselhausen@hackmanit.de> wrote: > The attacker being able to manipulate the first request is an additional > precondition for the mix-up attack variant we used as an example. The > precondition is based on the attacker A2 defined in section 3 > <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-3> > of the security BCP. > > There are other mix-up variants which work without this precondition. One > variant is described in the security BCP > <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-4.4.1>, > for example: > > *Mix-Up Without Interception*: A variant of the above attack works > even if the first request/response pair cannot be intercepted, for > example, because TLS is used to protect these messages: Here, it > is assumed that the user wants to start the grant using A-AS (and > not H-AS, see Attacker A1). After the client redirected the user > to the authorization endpoint at A-AS, the attacker immediately > redirects the user to H-AS (changing the client ID to "7ZGZldHQ"). > Note that a vigilant user might at this point detect that she > intended to use A-AS instead of H-AS. > > > On 09.12.2020 10:47, Warren Parad wrote: > > Okay, it wasn't clear that the user agent was required to be compromised > for this to be a problem. Here's where it breaks down for me, if the > attacker can manipulate the first request, why would they not be able to > manipulate the AS where the Auth Response code is sent? Unless we can > guarantee there is an attack surface that would only affect the > authorization request AS selection and not the auth response, the solution > the draft lacks purpose for me. > > Warren Parad > > Founder, CTO > Secure your user data and complete your authorization architecture. > Implement Authress <https://bit.ly/37SSO1p>. > > > On Wed, Dec 9, 2020 at 8:55 AM Karsten Meyer zu Selhausen < > karsten.meyerzuselhausen@hackmanit.de> wrote: > >> Hi Warren, >> >> I think there is some misunderstanding on how mix-up attacks work. I will >> try to clear things up. >> >> Have a look at the following mix-up attack example (slide 4 >> <https://datatracker.ietf.org/meeting/interim-2020-oauth-17/materials/slides-interim-2020-oauth-17-sessa-as-issuer-identifier-in-authorization-response-00#page=4> >> from the interim meeting): >> >> I marked the important parts: >> >> - In step 1 the client stores the attacker's AS (A-AS) as the >> selected AS. >> - Step 5: The authorization response is issued by the honest *(= not >> compromised)* AS, not by the attacker's AS. The H-AS will use its own >> correct issuer identifier as the value for the AS parameter. >> - In a mix-up attack the attacker cannot directly influence the >> value of the iss parameter in the authorization response as it is issued by >> the H-AS. >> - Step 6: The client sends the token request to the token endpoint of >> the A-AS, because it stored the A-AS as the selected AS in step 1. This >> leaks the authorization code to the attacker who can use it in a code >> injection attack, for example. >> >> With an iss parameter present in step 5 the client would be able to >> recognize that the code was issued by the H-AS, not by the A-AS. The client >> would be able to abort the authorization grant instead of leaking the code >> to the A-AS. >> >> I hope this addresses your concerns. >> >> Best regards, >> Karsten >> On 08.12.2020 20:15, Warren Parad wrote: >> >> 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) >> 2. 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. 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. >> >> 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? >> >> 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> 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 >>> >> -- >> Karsten Meyer zu Selhausen >> IT Security Consultant >> Phone: +49 (0)234 / 54456499 >> Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training >> >> Nehmen Sie an unserer nächsten Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 27.01 + 28.01.2021 teil:https://www.hackmanit.de/de/schulungen/127-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-27-01-28-01-2021 >> >> Hackmanit GmbH >> Universitätsstraße 60 (Exzenterhaus) >> 44789 Bochum >> >> Registergericht: Amtsgericht Bochum, HRB 14896 >> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz >> >> -- > Karsten Meyer zu Selhausen > IT Security Consultant > Phone: +49 (0)234 / 54456499 > Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training > > Nehmen Sie an unserer nächsten Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 27.01 + 28.01.2021 teil:https://www.hackmanit.de/de/schulungen/127-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-27-01-28-01-2021 > > Hackmanit GmbH > Universitätsstraße 60 (Exzenterhaus) > 44789 Bochum > > Registergericht: Amtsgericht Bochum, HRB 14896 > Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz > >
- [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