[OAUTH-WG] Mix-Up Revisited

Daniel Fett <fett@danielfett.de> Mon, 04 May 2020 17:35 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 383A73A0DC4 for <oauth@ietfa.amsl.com>; Mon, 4 May 2020 10:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, SPF_NONE=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 5jWa3lNYRqL6 for <oauth@ietfa.amsl.com>; Mon, 4 May 2020 10:35:49 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3953A0DC0 for <oauth@ietf.org>; Mon, 4 May 2020 10:34:58 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id AF6331902 for <oauth@ietf.org>; Mon, 4 May 2020 17:34:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1588613696; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=VKfHWKj2qRYvSwFR4Iji66ABOB0BznRwmQaMqvScMFk=; b=MiCUOhiQFUzS+Gi+xnEZyn9dmHcqKkLi4WbrauULrKBdmwQ7n+NEfJ/rVmk+wOPcBPQ/fT vbr8JFtim58LUet69Mvs/imqxpx98ZAO5gmPkQRs+6MFZTQ+aD6tgYtzMqywjKAW1vP1X2 H4+yxZtVkFRWkggrqkNZ2q44bxwc5vo=
To: oauth@ietf.org
From: Daniel Fett <fett@danielfett.de>
Message-ID: <101390f1-0d6e-e5fe-861b-4d7e9b7816dd@danielfett.de>
Date: Mon, 4 May 2020 19:34:56 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------ADF0DA7AF487FD566E4ED30D"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1588613696; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=VKfHWKj2qRYvSwFR4Iji66ABOB0BznRwmQaMqvScMFk=; b=ipJ07YpHZziZhTc6U31U0g+TgnvW7HJdt7qPlMSJ31xi6twUS4zAd9M6Tmv4ZcySUXfm6g 2Bovjv1Hv0FcD4qwFrujLCh29SuJGhlI4z1vqbQZjcvSEZSfFrd3Q0p8RSq/3frs1kjwbR 6SP3RWWzVwvrvlH8DnznwbqDDvw8Zus=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1588613696; a=rsa-sha256; cv=none; b=iCgGgQHIuQp5uEUnBJ99cLH1UKYRg28Vc+qTMXZf/oahn5ERHUQxt9wbfxTwk5mY6HWWsd wS2sUw/kT0RLtg4/r3auKFbdlNuRBlk+W7KcJxLQzOPYTA0uYBKFE0/tWtiqvs4eVSsXqz b6BkCmNyskJ0P95H7r0mple4o+pbIwE=
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/DQR2ZXtGKfa-8UGtuPYyZoAaBIc>
Subject: [OAUTH-WG] Mix-Up Revisited
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: Mon, 04 May 2020 17:35:51 -0000

Hi all,

to make substantiated recommendations for FAPI 2.0, the security
considerations for PAR, and the security BCP, I did another analysis on
the threats that arise from mix-up attacks. I was interested in
particular in two questions:

  * Does PAR help preventing mix-up attacks?
  * Do we need JARM to prevent mix-up attacks?

I wrote down several attack variants and configurations in the following
document: https://danielfett.github.io/notes/oauth/Mix-Up%20Revisited.html

The key takeaways are:

 1. The security BCP needs to make clear that per-*AS* redirect URIs are
    only sufficient if OAuth Metadata is not used to resolve multiple
    issuers. Otherwise, per-*Issuer* redirect URIs or the iss parameter
    MUST be used.
 2. PAR-enabled authorization servers can protect the integrity better
    and protect against Mix-Up Attacks better if they ONLY accept PAR
    requests.
 3. We should emphasize the importance of the iss parameter (or issuer)
    in the authorization response. Maybe introduce this parameter in the
    security BCP or another document?
 4. Sender-constrained access tokens help against mix-up attacks when
    the access token is targeted.
 5. Sender-constraining the authorization code (PAR + PAR-DPoP?) might
    be worth looking into.

I would like to hear your thoughts!

-Daniel