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

Daniel Fett <fett@danielfett.de> Wed, 04 December 2019 15:19 UTC

Return-Path: <fett@danielfett.de>
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 0354B120820 for <oauth@ietfa.amsl.com>; Wed, 4 Dec 2019 07:19:10 -0800 (PST)
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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
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 l6aaGK_ckHCb for <oauth@ietfa.amsl.com>; Wed, 4 Dec 2019 07:19:08 -0800 (PST)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BFE712008C for <oauth@ietf.org>; Wed, 4 Dec 2019 07:19:08 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 6557D540F for <oauth@ietf.org>; Wed, 4 Dec 2019 15:19:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1575472745; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QHHWY3Uv3v/Uui7T2byFVZU7U60ooyQr25lnknEi3Ro=; b=l9SDWOZRuNRmxHesMto46a19v7vZSLm5ZhTjUI5SH8oxOscK+Os/bCJk09S9MA/vc6sDIZ ZKSziv4cYg9N+mEuTq+qP3mgv8+xWRs3NXyFXfgTnUpV9eW7nLHKNfYzyGBRJPyJCS8IaV fVDxdKqmRCPAa9UFgAa6HGaBSbfmeaM=
To: oauth@ietf.org
References: <35143dd1-edeb-e0fd-6f36-a39d9b7f7008@hackmanit.de> <4f1d1215-aa23-93ab-ae5b-75426d7f07cc@danielfett.de> <277a3bc8-32fc-8c7c-85dc-5030d2d07728@rub.de> <8047bf89-1120-426d-e020-e58766c2ce3a@danielfett.de> <4300c85a-0942-f1b7-1854-2099107f1551@rub.de> <12085fa3-43e8-0621-cb16-8b52ffde8a6f@danielfett.de>
From: Daniel Fett <fett@danielfett.de>
Message-ID: <77551719-9f81-8ec1-efca-266a8141892c@danielfett.de>
Date: Wed, 4 Dec 2019 16:19:04 +0100
MIME-Version: 1.0
In-Reply-To: <12085fa3-43e8-0621-cb16-8b52ffde8a6f@danielfett.de>
Content-Type: multipart/alternative; boundary="------------4E7059F99BA90F8BE500661E"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1575472745; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QHHWY3Uv3v/Uui7T2byFVZU7U60ooyQr25lnknEi3Ro=; b=ieg3ewZ/SnKk9QDqO6pPK0XYq/8hlUrx692dFh1FmVtBfqYeMBdIvlviOKLyBMWHCnPhIH gQ0oWf2GRlxJ+jgvUCuMjxHNv8EmgcFS03SaAZQFjqxsHakvezad7kNMCcAZ4c/5Ros7K2 4sAFgEqudbcWWJfUXOSnLCZoKj4Lcz8=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1575472745; a=rsa-sha256; cv=none; b=Ddbm/EAjiPBa6vTTHW0Ni7yjKI+49Nm+8P2krc+i4Pfo5HJR8AnQU6J75xj7Nmer9iaLsyv/xE0W0fR2zsLyxIE29/uczcYYXBABZn7wl7ndV6ish9FFenV7zo6jUnKrnBDGIhu8JLdIQCl4FoFyePUpPd/6hj6Xm7uAQe7cCw4=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/CsW6kFoaKfPTF7-ICj0MCQiaKIQ>
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: Wed, 04 Dec 2019 15:19:10 -0000

Am 03.12.19 um 10:49 schrieb Daniel Fett:
> Am 03.12.19 um 10:21 schrieb Christian Mainka:
>> Hi,
>>
>> according to [1], countermeasure (1) describes to
>>
>>> configure [the] authorization servers to return an AS identitifier
>> ("iss") and the "client_id" for which a code or token was issued in the
>> authorization response.
>>
>> So if an MixUp attack is running, the victim contacts A-AS but is
>> redirected to to H-AS [2].
>> The AS adds - according to the countermeasure - two additional
>> parameters to the authorization response: client_id and issuer. Both
>> values are set by H-AS, so it returns H-issuer and H-client_id.
>
> I asked for clarification because I would assume that the mix-up
> attack is twharted at this point. The client would see H-issuer
> instead of A-issuer, to which it sent the user.
>
> I agree that the client_id is not of much value here.
>
Looking back at our analysis of OIDC [1], we actually included the
option that attacker choses the client_id, even for the honest AS. This
is a safe overapproximation, of course. Obviously an attacker-controlled
AS can also issue arbitrary client_ids. So I suspect that there is no
further attack hidden here.

[1] https://arxiv.org/pdf/1704.08539

-Daniel