[OAUTH-WG] Client authentication on token revocation

Emond Papegaaij <emond.papegaaij@gmail.com> Thu, 20 August 2020 09:02 UTC

Return-Path: <emond.papegaaij@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 604A33A0A40 for <oauth@ietfa.amsl.com>; Thu, 20 Aug 2020 02:02:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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=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 ypThZVtIKTDa for <oauth@ietfa.amsl.com>; Thu, 20 Aug 2020 02:02:24 -0700 (PDT)
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 2D1B03A0A3E for <oauth@ietf.org>; Thu, 20 Aug 2020 02:02:24 -0700 (PDT)
Received: by mail-oi1-x233.google.com with SMTP id n128so1284297oif.0 for <oauth@ietf.org>; Thu, 20 Aug 2020 02:02:24 -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=Y3iI0vl26QYYGrkooGit465v2dZ13CCdZbpfY69ZD44=; b=jtAmMnV7qVsMi77jU3InLvzOj4M6zFhcQZaNA82rHan2OCA+NDGG1psAHjuOXu+UaN 6jdRZXCq/sacuD/pZLvgXC+R5NxH30pcQKinc9ko3MxBwsypk6mNhCvI03N4QE4HwreH uH5snpviETN+B9Z19AzXgQgE36WoWeNNLKuFecdGCnU61uWtG8IjG51wLy3A4Uad8khs 1uUovW1yW54m13zR5rsQWgYDPbaqLRqoE+MtNCZh06Xc+NdQWc/Fa40bXhopbh/GGNK8 LYEKcluC8izduYweFuwLTk+/4ZAhPd9CGCw/xM8iAB7fQ7ZIJZ6I6KtC1yk7p9tgF3u0 lapQ==
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=Y3iI0vl26QYYGrkooGit465v2dZ13CCdZbpfY69ZD44=; b=av+vKb4jPJGzvEqp6UtL6t2Q0e6DIT9HAZpJlT6YrBfB6DBhX3vFbSuYTFNOIBBsSd AifIrTXzDzpc0iMc7P7yicv7QGCViWMcu8ooCTnrplypw81jzftEWSZfI8OzlFc1N3Lv SmQvh6sBUsT0Coqy4KY6i86OIoim2YT6F0vq/UBVGsZZJSdTtzzdeQDUw7STL7rUlWcP v93EMqqvlk6hLn4sI9GQctEgeJWUD3/IyRaa19orV8F4i3dXWQIXALNtRfL57pm5aT2F +a6JE5auv1peZensSH9v4uXWs4IYB/5S36ivpy5YKinF5QV50X3w8SPWIIRpSHtRsN2B IuHw==
X-Gm-Message-State: AOAM5322IoSnq+zFxv1Af+3tfhF+PpGoBxolcn3EuYhxNigDZVZ7LmAH KJFCqRvXM65YlBc54Btq9LIaFjWN2LYxVmbsqiKDH4ZuGP4=
X-Google-Smtp-Source: ABdhPJy+rAwUT4sis5Ij4b1Z65Em3Ijuy7riiYAU5dVBo1ZuWQQ0NshyJUSiTesB6dqgv5Ho+k2Zf6gzXFrbCdVVqHo=
X-Received: by 2002:a54:4588:: with SMTP id z8mr1163320oib.86.1597914143064; Thu, 20 Aug 2020 02:02:23 -0700 (PDT)
MIME-Version: 1.0
From: Emond Papegaaij <emond.papegaaij@gmail.com>
Date: Thu, 20 Aug 2020 11:02:12 +0200
Message-ID: <CAGXsc+Z6rYsktb+bokg6i2myG_FB4cWHrfX5+d6bQW+LcWg=ig@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7qxGcptE-uzA5WQaxnzGMdSqb2I>
Subject: [OAUTH-WG] Client authentication on token revocation
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, 20 Aug 2020 09:02:25 -0000

Hi all,

We are currently implementing the token revocation endpoint (RFC 7009)
on our authorization server and do not understand why it requires
client authentication. When a party (a valid client or not) gets hold
of a valid access token in whatever way, the least damaging it could
do with it, is to revoke it. The current spec allows an attacker to
misuse this token for access to the resource server, but forbids it to
revoke it. This seems strange to me.

Section 5 of RFC 7009 does not help in this either. It starts to
explain that this authentication is needed to prevent malicious
clients from guessing tokens, but ends with the fact that if this were
possible, much worse damage could be done by using the guessed token
on the resource server. We plan to skip the authentication all
together and simply revoke any valid token presented. How would you
recommend we deal with this?

Best regards,
Emond Papegaaij
Topicus KeyHub