[OAUTH-WG] Reasoning behind OAuth 2.0 PKCE
Marcin Szewczyk <marcin.szewczyk@wodny.org> Tue, 11 May 2021 12:57 UTC
Return-Path: <marcin.szewczyk@wodny.org>
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 9F36F3A16AF for <oauth@ietfa.amsl.com>; Tue, 11 May 2021 05:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 WIpkGdTkPJLU for <oauth@ietfa.amsl.com>; Tue, 11 May 2021 05:57:09 -0700 (PDT)
Received: from cl7.netmark.pl (cl7.netmark.pl [185.36.171.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745563A16B7 for <oauth@ietf.org>; Tue, 11 May 2021 05:57:08 -0700 (PDT)
Received: from [89.65.50.198] (port=40550 helo=flatwhite) by cl7.netmark.pl with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <marcin.szewczyk@wodny.org>) id 1lgRwf-00037z-VC for oauth@ietf.org; Tue, 11 May 2021 14:57:04 +0200
Date: Tue, 11 May 2021 14:57:03 +0200
From: Marcin Szewczyk <marcin.szewczyk@wodny.org>
To: oauth@ietf.org
Message-ID: <YJp/HwjQn8kIfQXf@flatwhite>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/2.0.6 (98f8cb83) (2021-03-06)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cl7.netmark.pl
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - wodny.org
X-Get-Message-Sender-Via: cl7.netmark.pl: authenticated_id: wodny/from_h
X-Authenticated-Sender: cl7.netmark.pl: marcin.szewczyk@wodny.org
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/qPunYcl1wlr4L_cSdSyLI_7yppE>
Subject: [OAUTH-WG] Reasoning behind OAuth 2.0 PKCE
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: Tue, 11 May 2021 12:59:14 -0000
Hi, I am reading RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients) to understand how it mitigates the problem of intercepting authorization code on the device itself and not in internet transit. I fail to understand reasoning behind the following paragraphs: 1. Introduction, 4b. (rephrased): the attacker observes both requests and responses to/from the authorization endpoint, not using MitM but http log of the OS leaking information (I presume URLs with parameters that ought to be secret) 1. Introduction, last paragraph: > The authorization code obtained is then sent to the token endpoint > with the "code verifier", and the server compares it with the > previously received request code so that it can perform the proof of > possession of the "code verifier" by the client. This works as the > mitigation since the attacker would not know this one-time key, since > it is sent over TLS and cannot be intercepted. I do not understand the remark about TLS here as TLS alone does not prevent the attack because the HTTP connection itself is not the source of the leak. It is even stated explicitly that it is not about MitM. I thought PKCE is all about TLS not being enough and leaking information in the OS. Without TLS at every step (in general) the whole scheme seems to fall apart. If as mentioned in paragraph 4b. the source of the leak is the HTTP log of Authorization Request: why would not the attacker know the code verifier as well if Access Token Requests were logged too? Is it assumed that Authorization Request is more susceptible to attack than Access Token Request because it is more probable that log will contain query parameters but not entity-body (request contents transfer methods respectively)? BTW, it may be impossible for the attacker to do a classic MitM but maybe the attacker could crash the legitimate application just after one gets the Access Token Request in log or just try to win the race or maybe replay Access Token Request? Additionally RFC 6750 (OAuth 2.0: Bearer Token Usage) allows sending bearer access tokens in URI query parameter so these URIs in log would pose danger as well. I suppose that is one of the reasons OAuth 2.0 Security Best Current Practice[1] discourages this method. [1]: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics The archive seems to contain mainly "internal" WG's discussions but maybe it is acceptable to ask the question here. I am sorry if it is not. I did not find a better place to ask. -- Marcin Szewczyk http://wodny.org
- [OAUTH-WG] Reasoning behind OAuth 2.0 PKCE Marcin Szewczyk
- Re: [OAUTH-WG] Reasoning behind OAuth 2.0 PKCE Aaron Parecki