Re: [OAUTH-WG] Mix-Up Revisited

Brian Campbell <> Thu, 18 June 2020 20:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4188B3A0F6E for <>; Thu, 18 Jun 2020 13:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8ocHMHL7V2U6 for <>; Thu, 18 Jun 2020 13:32:31 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E0643A0F62 for <>; Thu, 18 Jun 2020 13:32:31 -0700 (PDT)
Received: by with SMTP id i3so8911884ljg.3 for <>; Thu, 18 Jun 2020 13:32:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8t6YmB8BW73j4kMFo7hlmPYw6CdNUZ5y9pTwSmUAYOs=; b=esKn6mcyKLQ0jZYpXoltJlY0WKUA1XrxmeFN7DHjxz0S7RvwKXC11E8p30oomuRwge i9ZH41OMM/NKq4JwTOGU/fWbE7zftvdqYFSFrfnan4dp11XZ4mxJXOq36w008N+b6pcD PRhe0kfH7L3s48XomWZJY3Ad2YT55IQ+f9dZazzsAnCjbNwA6NjdRSZ95rIcBvjRnzLt QKDkePWm1gjSLNR68zKawmZEJzBC5sX54/pDaJ7shun2j4w6IOoFKBcR/9EQV1rB4Rx4 d9muz+g+tVgj0Abuv3ZckLqdensmH7/i6AkEzqN49Tux/1hMGbtVoNRpLozLjSOWL68S phKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8t6YmB8BW73j4kMFo7hlmPYw6CdNUZ5y9pTwSmUAYOs=; b=GqAw8n1SCLQjz4dW+8VjQh5tHXqDa3z36xNRXyRSkb6GVjiVnVjK1Wc4Mk2H8Go0Z+ MSDoCpCgr+W30AiBNXiPyQmfL1WUdZe4jK6dKnzPMUpHknI1JctmdMTkPLClktK5gZnR 1U0BI0AX1uegUIW3T0If+v4xrdhpePXRIT2Ul9XdzcLKCV1uedX8nv6PQfDnDLE4FHsU xUYaGQCnKJZ8PBDyEd4FIRPw8IVBmNtIkl284x82fLW7NkSjLOkM0U7aMrA3LT7bMnHc b7y8Nqs7cPhUzFqCBVqQe3EXOVwDA0eVgTvek9fJCfiH91+aDhvIdJKWkHUKryfw2sA3 RNQA==
X-Gm-Message-State: AOAM533+RWojQP35QgeYERXA/yiJ4oXQ5/pry/T0GB3tCzS0UwatFlhR GqBsdUnSXJ4aPCV4FQCzsOfiEbKUpfWQ60G3u7b24px0WKKYrLZ45U+0iM+Rx2FH/GFNyo0LvPU P+oSPq9cXFdd5Yq+H
X-Google-Smtp-Source: ABdhPJyEwuu3r/E3eIWTYAfJzYjOfuMPIvUmSdzzT6FPls8WmEWD+YrH1eqi4Lv6R21wxKQXpDNtc6bICd9NCAVvTYE=
X-Received: by 2002:a2e:6804:: with SMTP id c4mr83761lja.422.1592512349421; Thu, 18 Jun 2020 13:32:29 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Thu, 18 Jun 2020 14:32:03 -0600
Message-ID: <>
To: Daniel Fett <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="000000000000e366dc05a861acac"
Archived-At: <>
Subject: Re: [OAUTH-WG] Mix-Up Revisited
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Jun 2020 20:32:36 -0000

In my (probably simplistic) understanding of things, the root underlying
issue that allows for mix-up in its variations is the lack of anything
identifying the AS in the authorization response. Following from that,
introducing and using an `iss` authorization response parameter has always
seemed like the most straightforward approach for mitigating the issue
(which was part of the draft-ietf-oauth-mix-up-mitigation but other
parameters were also included and, for reasons I'm not sure about, interest
in that work faded in favor of telling clients to use per AS redirect URIs)
. Though for the `iss` authorization response parameter to be effective,
all parties involved need to know about it and act on it. So I think it'd
need to be something more than a passing recommendation in the BCP. It
should be defined, registered, explained, etc.. Actually introducing a new
parameter is maybe going beyond the expected scope of the BCP (or 2.1). But
maybe that's ok, if we're at least more intentional about it.

On Sun, Jun 7, 2020 at 7:53 AM Daniel Fett <> wrote:

> Hi all,
> I was wondering if we should move towards introducing and (more
> explicitly) recommending the iss parameter in the security BCP, for the
> reasons laid out below and in the article (which is now at
> Any thoughts on this?
> -Daniel
> Am 04.05.20 um 19:34 schrieb Daniel Fett:
> 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:
> 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
> _______________________________________________
> OAuth mailing listOAuth@ietf.org
> _______________________________________________
> OAuth mailing list

_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._