[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