Re: [OAUTH-WG] authorization code injection - draft-ietf-oauth-security-topics-13

Aaron Parecki <aaron@parecki.com> Sat, 16 November 2019 13:28 UTC

Return-Path: <aaron@parecki.com>
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 D9C161200FF for <oauth@ietfa.amsl.com>; Sat, 16 Nov 2019 05:28:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
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 ejz1qth-L2lE for <oauth@ietfa.amsl.com>; Sat, 16 Nov 2019 05:28:50 -0800 (PST)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 7C40612006E for <oauth@ietf.org>; Sat, 16 Nov 2019 05:28:50 -0800 (PST)
Received: by mail-io1-xd2f.google.com with SMTP id q83so13652287iod.1 for <oauth@ietf.org>; Sat, 16 Nov 2019 05:28:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0JA/HSKxifHi6Gb4dBMeJomueNARNpv2Z7aUu0ysXAU=; b=MQuLAhxnNtMM9/J6/Onp7f+6iYycNdYDDK7MbuQQ5QoQDXfWkun7cCI/j7gsnKz3+b Li32LrcFN0l4FAonMu7q+eCSQDP3hu8ZVNk2tWXRAUhtTv83rjG8mz6YBiS7r5/+qqoD BBTdlbKyn0Ag8XwqkKnYdS8cVoCLhwDh3x6kh/iRjS3/TQPN/0GUxiJEuOl/PQy2spV5 7nN0xGI11ZwjmKqiHtRrfwrB5GFu0wTAki3q2LFd/RGTR4IcTrhA5UctA5+0EqcdXlNz RDb2RARrBZnnF1Xl8ejQhmQPaRuVjt67lEepkg5LQKgTAkwbPthLNOetrB7iYAfoZqtS KSFg==
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:content-transfer-encoding; bh=0JA/HSKxifHi6Gb4dBMeJomueNARNpv2Z7aUu0ysXAU=; b=mzWFzY5wY0/0EwypqFVo8DyQsvhqwLw76RpVcoJFfjuOw1P+Ag8sCLP3LSQ38kFxES eFV8AGEv54r+Y3BGV2eixnaJGKMdZkPT59vWfdDAkmwrJPwRPGC4lFxn2rSesxeveu4Q cnzRFOn+Ntak9/G34mEUcFNy08lR795vwpwto99aEm2hwN7lK304LID8BHdRwelV745t 4KKdl7x/8ziQJCOzgK4jSTSUOTYTgAX9jhGdGqsKyBj2HUIdX6ki+FIhuSBLW0mcnROz mihIHS49aLLjoK1RmaQKwEsWOok3HTe/PLuD7niD23gANEajmCVxnKabFyO9/mxhI/yr /NwA==
X-Gm-Message-State: APjAAAVDLlQI2ZiN/HABB8/KrNXMjftt1l75cUDFhA9pmdc348364REi 0jNAxYslQzJKSHGgCgRZfZ3ywU1raIyM7w==
X-Google-Smtp-Source: APXvYqxn1YAMtiN21PrN0/Or80A39W1reilJ7e20D97cgakK7+JEnaD4Aab53YLk+zU/pUExpp3TKg==
X-Received: by 2002:a02:c05a:: with SMTP id u26mr5433480jam.58.1573910929418; Sat, 16 Nov 2019 05:28:49 -0800 (PST)
Received: from mail-il1-f170.google.com (mail-il1-f170.google.com. [209.85.166.170]) by smtp.gmail.com with ESMTPSA id s70sm2571852ili.13.2019.11.16.05.28.48 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 Nov 2019 05:28:48 -0800 (PST)
Received: by mail-il1-f170.google.com with SMTP id s5so11744415iln.4 for <oauth@ietf.org>; Sat, 16 Nov 2019 05:28:48 -0800 (PST)
X-Received: by 2002:a92:4609:: with SMTP id t9mr5987335ila.156.1573910927830; Sat, 16 Nov 2019 05:28:47 -0800 (PST)
MIME-Version: 1.0
References: <CAGBSGjqpXjXDMH-YMap5kEeWg4qA0R447nNK9zjLUP+mJ=XT2w@mail.gmail.com> <97C1CF0C-451E-430F-8B35-AF8B5A4D2E2D@lodderstedt.net>
In-Reply-To: <97C1CF0C-451E-430F-8B35-AF8B5A4D2E2D@lodderstedt.net>
From: Aaron Parecki <aaron@parecki.com>
Date: Sat, 16 Nov 2019 21:28:36 +0800
X-Gmail-Original-Message-ID: <CAGBSGjpOoTKEqHEgpGP3zn4B1tzQ6Ez2e2VMANn1wn1x6bxv5w@mail.gmail.com>
Message-ID: <CAGBSGjpOoTKEqHEgpGP3zn4B1tzQ6Ez2e2VMANn1wn1x6bxv5w@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: OAuth WG <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/nqvrvcRMjRVgE5BGte8Db2NMjxg>
Subject: Re: [OAUTH-WG] authorization code injection - draft-ietf-oauth-security-topics-13
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: Sat, 16 Nov 2019 13:28:53 -0000

Thanks for the reply. You're right, PKCE requires maintaining
application state as well, and does solve the main worry I have.

However I think there is still something more. I guess my concern is
around the specific wording:

> in this case, 'state' may be used again for its original purpose...

My concern is if people see this recommendation, (even though it's
clarified that it only applies if the authorization server supports
PKCE), they may revert back to static "state" values *regardless* of
whether the server supports PKCE, opening up a security hole again.
This is especially problematic because of the way PKCE works where
clients have no indication as to whether the server supports PKCE if
the whole flow is successful.

I guess I just would rather not mention the possibility of using
static state values again.

----
Aaron Parecki
aaronparecki.com


----
Aaron Parecki
aaronparecki.com
@aaronpk



On Fri, Nov 15, 2019 at 11:51 PM Torsten Lodderstedt
<torsten@lodderstedt.net> wrote:
>
> Hi Aaron,
>
> > On 14. Nov 2019, at 21:10, Aaron Parecki <aaron@parecki.com> wrote:
> >
> > I read through the authorization code injection section
> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.5
> > but didn't see a mention of this explicitly...
> >
> > The guidance in 3.1.1 recommends using PKCE for confidential clients.
>
> It’s a MUST for any client, not only confidential clients.
>
> "Clients utilizing the authorization grant type MUST use PKCE …"
>
> > Section 3.1 says that  clients may use PKCE instead of "state" for
> > CSRF protection, in which case "'state' may be used again for its
> > original purpose".
> >
> > My worry is that without using a unique state value per request, it
> > becomes less obvious that clients need to maintain state to avoid
> > being tricked into exchanging an attacker's authorization code.
>
> The PKCE verifier is a unique per request random value that needs to maintained in the state of the app as well. So beside it’s application for sender authentication and code replay detection, it also serves the role of state to detect CSRF. It just works differently in that the AS determines the response and the PCKE verifier don’t match and if that happens refuses to issue tokens.
>
> >
> > If the client is using PKCE, then this isn't an issue of exchanging a
> > different valid authorization code. However it's an issue that the
> > client may leave itself open to attackers tricking it into exchanging
> > garbage authorization codes at the AS, possibly triggering rate limits
> > or security flags at the AS.
>
> You mean because it may send a PKCE verifier valid for the current transaction along with an infected code?
>
> >
> > There is a partial sentence that hits on the point in 3.1, "clients
> > MUST only process redirect responses ... from the same user agent this
> > authorization request initiated with". My worry is that this isn't
> > enough guidance anymore if people are using non-random state values.
>
> What is the relationship to the state value? The paragraph you cite is about mix up prevention and requires the client to memorize the AS it sent the user to.
>
> > If clients are required to use a random state value, then they are
> > forced into a situation where they need to maintain state between
> > requests, which then prevents this problem.
>
> Same holds true for PKCE.
>
> >
> > Any thoughts on this? I am not sure exactly what the resolution should
> > be. I suppose either still requiring a random value in the "state"
> > parameter, or adding some guidance on how to link a redirect response
> > with an authorization request.
>
> Potentially it is not obvious enough, but the linking is (indirectly) implemented using the PCKE verifier.
>
> best regards,
> Torsten.
>
> >
> > ----
> > Aaron Parecki
> > aaronparecki.com
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>