[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 [127.0.0.1]) 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-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 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. [209.85.166.182]) by smtp.gmail.com with ESMTPSA id r1sm632008iod.69.2019.11.14.12.10.50 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 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. 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 aaronparecki.com
- [OAUTH-WG] authorization code injection - draft-i… Aaron Parecki
- Re: [OAUTH-WG] authorization code injection - dra… Torsten Lodderstedt
- Re: [OAUTH-WG] authorization code injection - dra… Aaron Parecki
- Re: [OAUTH-WG] authorization code injection - dra… Daniel Fett
- Re: [OAUTH-WG] authorization code injection - dra… Aaron Parecki