[OAUTH-WG] on PKCE for CSRF prevention instead of state parameter

Filip Skokan <panva.ip@gmail.com> Thu, 11 April 2019 11:36 UTC

Return-Path: <panva.ip@gmail.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 E68A912011D for <oauth@ietfa.amsl.com>; Thu, 11 Apr 2019 04:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pbbVRcbVGWsL for <oauth@ietfa.amsl.com>; Thu, 11 Apr 2019 04:36:10 -0700 (PDT)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 33B7E120048 for <oauth@ietf.org>; Thu, 11 Apr 2019 04:36:10 -0700 (PDT)
Received: by mail-oi1-x229.google.com with SMTP id i21so4561438oib.11 for <oauth@ietf.org>; Thu, 11 Apr 2019 04:36:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=qJF6cTbeO6lTVkXl14kMrP+PTU8HxH26ptvETL3Q6VY=; b=jz9SiX/EHux0cF1luGftdZlxfegrh2tOxKysm43aSnDTWmKiFj+SrqExsG0jy/Z5dd Z1qoDB3KQizdZXALfC5vxuET9U+Vlg2ZbYvQpi7CLMinXC7bbJszIyxGRLdHDCTkefVn lzuw4XhVOfqBOSdOD6hNXR122dnbLtPLWRKrpcA5SyPUx2A5/HhtUEXA/yx9R/P7WDX/ sxUDel4BMbOIKlqwhpBVVL1nuBpWuYSYDJvwON+onJRmVnxIDz7C6V3tHh86tgHaH/m3 5CoFRb/qNFjrj7TbCOfPlXxr/chPXj+78Zspr+bZmRT2AjLXem3PfXe2Zvfvz2vsMu0u kejg==
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=qJF6cTbeO6lTVkXl14kMrP+PTU8HxH26ptvETL3Q6VY=; b=JOOtKXRRdKoZBCPh1tpAO0Ww58clP5xHylvJNIwPYC2Y8bQxr16UFNLozU0u94tb9g oFRvFhk15dK5Zl7NwnMBTZ0honVr9GSbAuJG9Cdoce2ks+C6oWp+A71eA+TZhIt44mpE 0EUa8Cj9uOmJpPyPAUGidYCvzbaYkDft4/5vjhCW6jaNkn02mZLd0HGYAMBx1UcFHXb1 mjYbt0M5lJRNsb2oWVhsSB6WEOKG6IR7R2kvjQ8MKqg3nxtdS/2GxY7yfSdeyv5bK5oE yu28AQJh5VWMb2KmJIDR5bAsiFO/iRwlOx7stV5aS3akDhDc0gKkScdd7X3YG+5y6pxs uzNg==
X-Gm-Message-State: APjAAAV7ipIcxNuWH3JRa3AhcRtoYkkLdfl5PA2/xjNByc3+lRTJHzNP hm+6tWcubH/HnPMK60fphRPRb28m8uAMGVxLdN8N
X-Google-Smtp-Source: APXvYqzkp8Wo5TxD87FSliin/7/DGx2+NBkaxDi18bOZMa5V4hba16TMAIrW2zjPTAgwkVhE5/5/vTYZfKiYtG15BXg=
X-Received: by 2002:aca:aa91:: with SMTP id t139mr6167923oie.174.1554982569151; Thu, 11 Apr 2019 04:36:09 -0700 (PDT)
MIME-Version: 1.0
From: Filip Skokan <panva.ip@gmail.com>
Date: Thu, 11 Apr 2019 13:35:58 +0200
Message-ID: <CALAqi_8oZjXri+wKei-fUW+O5YaJQTsTFDUJhE7z9xAGJ=dyjw@mail.gmail.com>
To: oauth <oauth@ietf.org>, Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: multipart/alternative; boundary="000000000000aa929005863f9786"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/cCmErGsmISVrs76CfjqOrpMeAi0>
Subject: [OAUTH-WG] on PKCE for CSRF prevention instead of state parameter
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, 11 Apr 2019 11:36:12 -0000

In Prague we've seen and talked about this point from Torsten's deck
<https://datatracker.ietf.org/meeting/104/materials/slides-104-oauth-sessa-security-topics-00>


> Use PKCE for CSRF prevention instead of state parameter
>
>    - PKCE is mandatory now and can fulfill this additional task
>    - Simplifies recommendations and makes state available again for
>    original purpose (carry client transaction data)
>
>
While PKCE is now the suggested countermeasure to some attacks and is to be
used by Clients it's not yet mandatory to be implemented by the AS and the
client has no way of knowing for sure if it's implemented (due to how PKCE
is defined as backwards compatible to clients when AS is missing its
support).

Since at no point in time does the client receive anything from the AS
suggesting that PKCE is in effect, is this a wise recommendation to make in
the current form? Some might interpret this as if they don't need state to
carry any client transaction data they might as well just use PKCE and omit
state altogether altho the server does not support PKCE.

S pozdravem,
*Filip Skokan*