[OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05

Jacob Ideskog <jacob.ideskog@curity.io> Fri, 03 September 2021 14:43 UTC

Return-Path: <jacob.ideskog@curity.io>
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 076113A20C8 for <oauth@ietfa.amsl.com>; Fri, 3 Sep 2021 07:43:00 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=curity-io.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 ZYh95OYzBsTk for <oauth@ietfa.amsl.com>; Fri, 3 Sep 2021 07:42:54 -0700 (PDT)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 A11BE3A20C6 for <oauth@ietf.org>; Fri, 3 Sep 2021 07:42:54 -0700 (PDT)
Received: by mail-yb1-xb31.google.com with SMTP id a93so10534383ybi.1 for <oauth@ietf.org>; Fri, 03 Sep 2021 07:42:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=oZpkqfWUxGON+2VoRY/NK9Oh47BgeDklyVf/2FH+jz0=; b=zmR44jebVzr8loCb5Zs4l0iPWLDYlnYqmK2tIxvlu8ZFG3I5gdTkAKBi5+x9NCcW4K 5k1uNv7RqeLdXn/NdhwXQmYmPlNybcpSK/iSPPbalDJlMLTgkWXpSeyDK3ULT9n994FH p4JmEctiij18D8uvkyP+rcCWZIpI31NRqrE5mhDtewmxRFd5IKfBx+002xR8KvP7RbuK w/saxGKaxcEwVsYWJ2mXU9eD8Tlvrn4Dl8wHwUZb+jmqY4gyUidpJ4CSj7Ic/LdhYbiO LWyA2kz9S0JPoM+5pBkLTvxT4BVhi31hKuNr181xbQl17MdC+9hKPyY5zPp6ij18sg06 +c5Q==
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=oZpkqfWUxGON+2VoRY/NK9Oh47BgeDklyVf/2FH+jz0=; b=WOB7AyMo/M0253y8P/Iylno7fAujSqL6B/RptxEZjTTwxv6uyF8O9Dw/ppdf/6MJN7 QpS4pvBETKbzMBs9RK9iKC4T/VH3amxyRK9eL1yhHR30Hc7/sM1w/DMI9GGgsE5PY9E1 AoJQ1u3q7hyxmJV6O/TpBYulu0f7E4lBDH1U845c3waAhyChSSr7s8d8snA3hFmmut6T 8+5IbG8GuaZDxn5fJKbeRE7qj8mqVaLDf/DYBV3RnSZKqT8bN5HaJWMBZZFWt4Ry2RA+ Zo4n0LDDwunmspbp/dWt9bJ4D/HItHnlvvk3NiscnC84HjQeJ1LsxuiFs3BVP32t6pc6 ZOoA==
X-Gm-Message-State: AOAM533ubfWpYdAXQRgTF3Ok9FL6oFcJm3IvcqcSPIShRlvcuWv7u4/v z5vKzFgDas8teEXjQ1cM7bie6DQVgk8jovajnNpmeQs7Iq3dSbjg
X-Google-Smtp-Source: ABdhPJzvmqpssbWfwlNywvAnJwDLBLl+EDljxXcOasnJDIUUG5xmkzxle2BV9Y0MMjcMClFFuuM5yM2Q0eXufOB7AxA=
X-Received: by 2002:a05:6902:1004:: with SMTP id w4mr5569916ybt.11.1630680172084; Fri, 03 Sep 2021 07:42:52 -0700 (PDT)
MIME-Version: 1.0
From: Jacob Ideskog <jacob.ideskog@curity.io>
Date: Fri, 03 Sep 2021 16:42:41 +0200
Message-ID: <CAKL4o=FgsKoSn04F2q_hvH9YF3dsnSWTNLo95FeeAMkte5WRKA@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000665f4905cb185024"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/J0_oXwLjLeFmIPGRv-Ck6Znu804>
Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05
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: Fri, 03 Sep 2021 14:43:00 -0000

Hi all,

I have a question about section 7.0 and 7.1 in draft-ietf-oauth-rar-05 that
describes the token response.

The authorization_details values could be sensitive in their nature. The
example in section 7.1 highlights this nicely. The accounts array is empty
when the client requests it, but is enriched by the AS and returned to the
client in the token response.

This means that the AS may leak potentially sensitive information to the
client in a new place. Before this was only possible in the ID Token or
UserInfo or if the AS returned a JWT as an access token which the client
popped open (even though it shouldn't).

I understand that the spec considers this an option for the AS to enrich or
not. I think the enrichment is good and necessary, but with the side-effect
of it ending up in the token response it becomes an issue.

Is the token response a mirror of the authorization_details claim in the
corresponding access token, or can it be a masked version?

Perhaps the security considerations section should be updated with a
statement with regards to the fact that the client may see claim data only
intended for the RS?

Regards
Jacob Ideskog



-- 
Jacob Ideskog
CTO
Curity AB
-------------------------------------------------------------------
Sankt Göransgatan 66, Stockholm, Sweden
M: +46 70-2233664
j <jacob@twobo.com>acob@curity.io
curity.io
-------------------------------------------------------------------