Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure

Brian Campbell <bcampbell@pingidentity.com> Tue, 03 December 2019 18:47 UTC

Return-Path: <bcampbell@pingidentity.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 0B4AB1200A3 for <oauth@ietfa.amsl.com>; Tue, 3 Dec 2019 10:47:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=pingidentity.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 fKT5UbBKqLKM for <oauth@ietfa.amsl.com>; Tue, 3 Dec 2019 10:47:11 -0800 (PST)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 CCFBD12000F for <oauth@ietf.org>; Tue, 3 Dec 2019 10:47:10 -0800 (PST)
Received: by mail-lj1-x22d.google.com with SMTP id a13so4985371ljm.10 for <oauth@ietf.org>; Tue, 03 Dec 2019 10:47:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iytROZKWIGaYvoAiO4M/mRZxiJrKTIS7rZf126se3u4=; b=FHlxBL2L494IMue2BOYM2ggS9LhhyfhiZWdy9O61GIysfk0zPUw2B7ygOlesa3IfG2 cAn+ngna+5mwqvL+RhwC1cl3WtrSj2mXGiH30Mjvfkbq5OHo1y5wulpR/K3V4sXvf1Q4 iRFRQlwa5cQ//CBpS1OrJZQp4c4iBDyoKipkFksPYa60V5XrtkJm+cwF+DlOiyP8TKD2 8BjS+MUCX1QUFpum6cMKaRXFVjHK1fUyC6li2buxeRCk2auilP+Hp1cacwFm9faRmqDI /H/67YlSw7XUx3pXkcmR/H70UBe1zpdxqEQdzCwrr2JT3A85DiRrSRuZnC8XMrUN3yOP n/Og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iytROZKWIGaYvoAiO4M/mRZxiJrKTIS7rZf126se3u4=; b=NVQFckbtVwIthGY76e0tiCX8wXGuM48ChpFT9G8sJ/Q59Kp/mL4ga2I1EIxq2rJzVD dEO5kEtb7SZ5RUEJ6XmO+0PTe4DyMbOxTftXmRlNZlgrZKshwXXeu3VPgQDPb3SOXm2N XDQMwxTegQRJDDDs7NxIsm68I5wlJYmnYoSqnZhkFoEcJbNYzojT688Ud52JtXlxnT0K TVVeqxXFlkwbjVfOWDwUiaw3gX3Q4N0H2UBK9uWruYkYNLKihs34pDGck8CSi3XFbhDS 7tsfDDIEWVWW/31HRlynK7LrUiinpcBvNZb8iib++aokxA6AKO9EhYODlQbUto08uW0C PN7Q==
X-Gm-Message-State: APjAAAU1WHAwin1Sxjrtld6Nw4diROH3TGPujdjIy2zBxtmCYgfuPZmU uXn/cmPavdWbLiJmL/q5xikk4mNwHzOANrLFkOdUHFndcWkSlwOzZlPBCUHTYfEiamIUesEdzzN Bcq4qAPcLDqVKsQ==
X-Google-Smtp-Source: APXvYqzNnLqt33qkozrFdK+NeQnwx1fkZr58YKWmXCGhM7MEEdv2hDXjbcsM1icAyE+2jgGHI9BXhHmNGFB8Ld/WGKE=
X-Received: by 2002:a2e:9592:: with SMTP id w18mr3441410ljh.98.1575398828820; Tue, 03 Dec 2019 10:47:08 -0800 (PST)
MIME-Version: 1.0
References: <35143dd1-edeb-e0fd-6f36-a39d9b7f7008@hackmanit.de> <4f1d1215-aa23-93ab-ae5b-75426d7f07cc@danielfett.de>
In-Reply-To: <4f1d1215-aa23-93ab-ae5b-75426d7f07cc@danielfett.de>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 3 Dec 2019 11:46:41 -0700
Message-ID: <CA+k3eCSUvyWJj7jXkqGR9G=jv0jLe-HKdEGCRQE0DmBWFFwOrg@mail.gmail.com>
To: Daniel Fett <fett@danielfett.de>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009261050598d11f9c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Y1nStM8uHUuZLieIDkSkYIAELdU>
Subject: Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure
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, 03 Dec 2019 18:47:13 -0000

On Tue, Nov 26, 2019 at 7:20 AM Daniel Fett <fett@danielfett.de> wrote:

> Am 26.11.19 um 14:24 schrieb Karsten Meyer zu Selhausen:
> > Depending on its implementation the client might simply extract all data
> > contained in the Client Information Response and use it for
> > authorizations with the specific AS.
> > We were able to confirm that one popular open-source library behaves in
> > this exact way. It stores the redirect URI contained in the Client
> > Information Response and uses it for Authorization Requests with the
> > A-AS although it differs from the redirect URI in the Client
> > Registration Request.
>
> The client uses untrusted, unverified data to make its decision on what
> redirect URI to use.
>
> Nonetheless, we should definitely mention this in the BCP!
>


RFC 7591 basically says that the AS can replace/substitute/augment any of
the client registration info and leaves it up to the client as to how to
handle differences from what was requested. There are quite a few things
that just wouldn't make sense for the AS to change and some like redirect
URI that could potentially be dangerous.  Perhaps the BCP should mention
the situation and recommend that a client not proceed if the redirect URIs
(and others?) don't align with what was requested.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._