Re: [OAUTH-WG] Mix-Up Revisited

Daniel Fett <fett@danielfett.de> Sun, 07 June 2020 13:53 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 2EBAC3A0869 for <oauth@ietfa.amsl.com>; Sun, 7 Jun 2020 06:53:19 -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 ixFslMh7iXRj for <oauth@ietfa.amsl.com>; Sun, 7 Jun 2020 06:53:17 -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 E25C03A0868 for <oauth@ietf.org>; Sun, 7 Jun 2020 06:53:16 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 357BA7040 for <oauth@ietf.org>; Sun, 7 Jun 2020 13:53:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591537991; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FFnXGJGqHr9yFW3mhVU2GWM6DatoSdsQzcnhFNR8U9E=; b=S5m/INlVVAmCxIrW25/e8+NifTKv6i6vLPplDJ+4kPNDWRoIupnZOtSpPBEwwb0D+TqNhl F4bC0fS+TP0+56ZQZfs4Ah4IUpvqyASs+vcCSUWUMut4gSO+pIub8RPzTVbHx22aOmQsOJ fCH7k2wbkF+n0P396kCiLubk3+kKWQE=
To: oauth@ietf.org
References: <101390f1-0d6e-e5fe-861b-4d7e9b7816dd@danielfett.de>
From: Daniel Fett <fett@danielfett.de>
Message-ID: <7877fdc2-eeb0-18dd-5a89-ecb30800eacf@danielfett.de>
Date: Sun, 7 Jun 2020 15:53:10 +0200
MIME-Version: 1.0
In-Reply-To: <101390f1-0d6e-e5fe-861b-4d7e9b7816dd@danielfett.de>
Content-Type: multipart/alternative; boundary="------------CEF7BCF0D2197AF9A44417A0"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591537992; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FFnXGJGqHr9yFW3mhVU2GWM6DatoSdsQzcnhFNR8U9E=; b=k6XsWOvXadDJ/Oajg0s8B4ZgiBJuSArg1Xj1sHXN2nqdUF8iSSF+8RmYa3GP+M0jv1SOGD pMICNBFlPKp3XHmmkOH36Um4/fvLIqeWcHBMeB767raXCokOEFJW3KfruAxy5g53mZLi8P 6gSlSqtUBXBVK1sgFhBQ8zFQ10Addrg=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1591537992; a=rsa-sha256; cv=none; b=mg8T+yE+QkrNws0xxt47nq/NlCnCHbxv/1rxvgvphxgSnU405Bq1oo//iIwBDkXjO0rAYC A24mEOP1kWYZYmNwqZJSoQZ1z4CFIo9DK9xZ7u+N3tBsWt22cutVfHPUZiKq8JdJv6IOt0 qZI/xTPhHuJKw1Ncvt57RbLXxL555xU=
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/fdYb4Pef7vogPBZ766KdjHy_-_U>
Subject: Re: [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: Sun, 07 Jun 2020 13:53:19 -0000

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
https://danielfett.de/2020/05/04/mix-up-revisited/).

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:
> 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
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth