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

Aaron Parecki <aaron@parecki.com> Thu, 14 November 2019 20:10 UTC

Return-Path: <aaron@parecki.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A0B1912004F for <oauth@ietfa.amsl.com>; Thu, 14 Nov 2019 12:10:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id flKj6XgAIyJy for <oauth@ietfa.amsl.com>; Thu, 14 Nov 2019 12:10:52 -0800 (PST)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 2B1D012002E for <oauth@ietf.org>; Thu, 14 Nov 2019 12:10:52 -0800 (PST)
Received: by mail-il1-x129.google.com with SMTP id d83so6503248ilk.7 for <oauth@ietf.org>; Thu, 14 Nov 2019 12:10:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=tb6uSbiKcbJbxE/RnfpUibsiLjLvo8+xUEsVQ9Y9e6A=; b=iR9kfle3yaI/LOmonsBYG15GPRc9haQ14pG8gMfwvdG/2F9ZUfPCxsMCP4yzpSC2KV lHXnDyOeMNLVccFrFDOU7Z3mzM8TmWfRU5B8grqaO1Zmymtv2iXoyzG5dgGOyOUFCTX6 vr8CAys1+dhciqwAh74kA8+utysyWRNAu3bpKRvFNF31xYrcBVWwPf10zb1RSizptC8M nur6dX8hpSu5XcLi47cgSeL4c4tKPLcRJTxBa9EO5Y+Ch9oZXroctEojt9p8AGzQLXH8 euQixlN3QbMWMh40uxiUixCBwFHBdUIDAgeeMQdWM0ZpGGp6kgGR6btgpB4TY35fpj5f iQHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tb6uSbiKcbJbxE/RnfpUibsiLjLvo8+xUEsVQ9Y9e6A=; b=Mon2ZAy6qNzL+16uqg4iFkA5NPLxC2b++RkrwLjqdKDKPnEKu+37U3i7Xj0plrAwVd P9V5LosVgV2nCSd0/aQbIklQD3qjVchRGcfHY9umsJhP0CzxI4pBoN8dWxTC5jodse5g zM64u604CHIz33FxgejtaUxGeqxTQKJPEWq2NXZ14QEw+1NjZdZmHrfhoKiJ+W50XPsj 34P9OiYSWbZdFkgvadXU9OWz/lke7Lc3FaRGnDiWaGyi7tgLB6EvBxzr3hTNuh+pHPrF 4+1MOq7LuG3sX9usOl9bDnAxdm4K0t5+N1HszHBzXxQsXOdavrZqFlGhkLIDUSaixM0d EdpA==
X-Gm-Message-State: APjAAAUPi3Fu8CMx5WXThQnGtO4JQP4yajhJ8NbkHsn+MfaK0rA45SLQ 6i7e+WGmGpVHrKMn3cY+G7EpZnsgBY4=
X-Google-Smtp-Source: APXvYqzaTPuGtaQumAHzsmQD3pxCTaooWgGrlZlGV/EO3U2nWG61j+BetlwzRcZxsr9VzXFRAf2l6g==
X-Received: by 2002:a05:6e02:789:: with SMTP id q9mr11123850ils.96.1573762251091; Thu, 14 Nov 2019 12:10:51 -0800 (PST)
Received: from mail-il1-f182.google.com (mail-il1-f182.google.com. []) by smtp.gmail.com with ESMTPSA id r1sm632008iod.69.2019. for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Nov 2019 12:10:50 -0800 (PST)
Received: by mail-il1-f182.google.com with SMTP id n18so6509358ilt.9 for <oauth@ietf.org>; Thu, 14 Nov 2019 12:10:50 -0800 (PST)
X-Received: by 2002:a92:5ac1:: with SMTP id b62mr12847085ilg.46.1573762249944; Thu, 14 Nov 2019 12:10:49 -0800 (PST)
MIME-Version: 1.0
From: Aaron Parecki <aaron@parecki.com>
Date: Thu, 14 Nov 2019 12:10:38 -0800
X-Gmail-Original-Message-ID: <CAGBSGjqpXjXDMH-YMap5kEeWg4qA0R447nNK9zjLUP+mJ=XT2w@mail.gmail.com>
Message-ID: <CAGBSGjqpXjXDMH-YMap5kEeWg4qA0R447nNK9zjLUP+mJ=XT2w@mail.gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ppE5Iixvf_5aXhx0dk9YKCjL9jA>
Subject: [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: Thu, 14 Nov 2019 20:10:55 -0000

I read through the authorization code injection section
but didn't see a mention of this explicitly...

The guidance in 3.1.1 recommends using PKCE for confidential clients.
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.

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.

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.
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.

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.

Aaron Parecki