Re: [OAUTH-WG] [EXTERNAL] Re: Mix-Up Revisited

Torsten Lodderstedt <torsten@lodderstedt.net> Fri, 04 September 2020 13:44 UTC

Return-Path: <torsten@lodderstedt.net>
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 8C81B3A0943 for <oauth@ietfa.amsl.com>; Fri, 4 Sep 2020 06:44:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
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 NmhwgUEwszj9 for <oauth@ietfa.amsl.com>; Fri, 4 Sep 2020 06:44:09 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 649DF3A0930 for <oauth@ietf.org>; Fri, 4 Sep 2020 06:44:09 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id a15so8606277ejf.11 for <oauth@ietf.org>; Fri, 04 Sep 2020 06:44:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=asXqssIc7Ze65tfHIINBYcaLlJieglylCPrtwG4mrY4=; b=qpV5H6XEEzAzP/tczcwQjS6HV6g9I1g6e33YBtwR5M8uxge5HJOCRod8Fvf7RP9hNb BNwMhs/vGXxbg++9ScJgZunnhnF8hrZsq/XH2fmUzu4UzoMZjC5AthEAkH7vCRzquGqU G2SJjDlwRZ2wE2ohwHpouwAfZylpRVXYCMkLaBiabNmn9/J5pxuqfx0movgMqt1cOA7u cw5UJQjZmwsFO6LjwQHEKbcblDdtCvzTxK9UNXn4uOiulynPi+YSZwycRLeNoESqrmam 6HKH/SSiP8YLceHfvA6EhHcN4pDFgSV84nqEmaXuYB9m2JZPwxHVvLmaSgOZ64kqWcdg hiGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=asXqssIc7Ze65tfHIINBYcaLlJieglylCPrtwG4mrY4=; b=n075QPFsPmg/F8hb5Z0gSd1myMDvnJPcnaqPd4/PQFdQdYtMaLAjZQR0lvkQeFNCEp RJ1b/X6y7LtZIuxXue0AK4jqycwXUmuwwTnG6a1S3SkQ9goNwkGLXgqBJWxjJqoiKMH8 3oj/m98M5tsoWITqEqxcQF2c66CMYVQeJmZwZfIw75E0lNpABYI8SSKvEV6/kiH0RKEI kXmHmfj8HvsuKzXxWxNUFvHhKyXbcedF6MCz7qTtP3ylwCtdbH7JycVANN/3Xqc4WX6q 9G6K5MGMJsJaSf995CWni+zL9wmPQ7j3yCoDEvlK0pjqOjsajWX/9iVErPiJXWN8lHDm PLHA==
X-Gm-Message-State: AOAM533IGEk05Txuh62S4dm9iq9E0JEco+PSgWQVzNZZLdR2syXGGcCb f2k8P9kE4MDKAqI7SlPZlP6S9ArsUevx55WD
X-Google-Smtp-Source: ABdhPJzqZKrxEpbr2KEuDm6uHzs/hzpAykboeltqCKImUCfNwILz1diVWlqzAfTNPzI6CoKUeURFVg==
X-Received: by 2002:a17:906:1b55:: with SMTP id p21mr7736258ejg.457.1599227047645; Fri, 04 Sep 2020 06:44:07 -0700 (PDT)
Received: from p200300eb8f1e2a4a69f3cbe090145075.dip0.t-ipconnect.de (p200300eb8f1e2a4a69f3cbe090145075.dip0.t-ipconnect.de. [2003:eb:8f1e:2a4a:69f3:cbe0:9014:5075]) by smtp.gmail.com with ESMTPSA id j10sm6073826ejf.116.2020.09.04.06.44.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Sep 2020 06:44:06 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Torsten Lodderstedt <torsten@lodderstedt.net>
In-Reply-To: <2c9a04bc-06a5-52c5-6ce7-04dc6e2fd102@hackmanit.de>
Date: Fri, 4 Sep 2020 15:44:05 +0200
Cc: oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5BFB130C-0222-4D14-B1A0-17312D67564D@lodderstedt.net>
References: <101390f1-0d6e-e5fe-861b-4d7e9b7816dd@danielfett.de> <7877fdc2-eeb0-18dd-5a89-ecb30800eacf@danielfett.de> <CA+k3eCQg33wXpe+vo7by6fPJsBmdJnd378RSEGwApCBxCgPnPw@mail.gmail.com> <MN2PR00MB06866084FF95C4956A76B472F59B0@MN2PR00MB0686.namprd00.prod.outlook.com> <cf52ffac-1542-2e90-9017-50af154765a8@hackmanit.de> <6E29CD61-6F80-4A8B-A6D9-6A616532FDB6@lodderstedt.net> <2c9a04bc-06a5-52c5-6ce7-04dc6e2fd102@hackmanit.de>
To: Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/k3KkCrskphPIVg5iEtyj6XVl8r0>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: 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: Fri, 04 Sep 2020 13:44:12 -0000

Great! Just drop me an email if you need support.

> On 4. Sep 2020, at 15:07, Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de> wrote:
> 
> I am fairly new to this working group (and the IETF in general), so I will probably need some guidance, but I would be happy to help better defining mix-up preventions. I will start to work on an ID.
> 
> Best regards,
> Karsten
> 
> On 29.08.2020 14:34, Torsten Lodderstedt wrote:
>>> On 11. Aug 2020, at 08:20, Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>
>>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> I think we all agree that proper countermeasures of mix-up attacks should definitely be part of the BCP and 2.1 due to the severe impact successful mix-up attacks have.
>>> Theoretically speaking every client which supports multiple AS is potentially vulnerable to mix-up attacks. While in practice it might seem unlikely it is possible that one of the honest AS the client supports gets compromised and can be utilized for a mix-up attack. 
>>> 
>>> In a previous thread of last November (
>>> https://mailarchive.ietf.org/arch/msg/oauth/A7F5xSEa8DdfxHKWHW3Mqol_a4A/
>>> ) I discussed why “use distinct redirect URIs for each AS” is not an effective countermeasure against mix-up attacks (if dynamic client registration is used). I would argue that this is especially important for mobile applications, SPAs, and other native applications because it is very common for them to use dynamic client registration. Many iOS applications now must support multiple AS since Apple forces the support for “Sign in with Apple” if any single sign-on provider is supported. This policy makes mix-up attacks applicable.
>>> 
>>> I fully agree with Daniel, Brian, and Mike that it is important to define and register the “iss” parameter properly to ensure that both clients and AS understand and use it in the correct way. I understand that OAuth 2.1 is not meant to introduce and define new parameters but I strongly suggest that the “iss” parameter should be introduced and defined elsewhere so that it can be natively included in 2.1. In other words the “iss” parameter should be integrated in 2.1 the same way PKCE is: the initial definition of the parameter(s) is in another document (RFC 7636 in the case of PKCE) and then included in 2.1.
>>> 
>>> What do you think would be the best place to define and register the “iss” parameter? Would it be worthwhile to reactivate and update “draft-ietf-oauth-mix-up-mitigation”?
>>> 
>> That’s a decision of the authors. Alternatively, a new small draft (referring to the BCP’s attack description) should do the job as well. Mind to write an ID? :-)
>> 
>> 
>>> Best regards,
>>> 
>>> Karsten
>>> 
>>> 
>>> 
>>> On 18.06.2020 22:49, Mike Jones wrote:
>>> 
>>>> I support documenting the use of the issuer to mitigate mix-up attacks.  Note that while issuer was first defined by OpenID Connect, it became art of OAuth 2.0 in RFC 8414 - OAuth 2.0 Authorization Server Metadata.
>>>>  
>>>>                                                        -- Mike
>>>>  
>>>> From: OAuth 
>>>> <oauth-bounces@ietf.org>
>>>>  On Behalf Of Brian Campbell
>>>> Sent: Thursday, June 18, 2020 1:32 PM
>>>> To: Daniel Fett 
>>>> <fett@danielfett.de>
>>>> 
>>>> Cc: oauth 
>>>> <oauth@ietf.org>
>>>> 
>>>> Subject: [EXTERNAL] Re: [OAUTH-WG] Mix-Up Revisited
>>>>  
>>>> 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 
>>>> <fett@danielfett.de>
>>>>  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 athttps://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:
>>>> 
>>>> 	• 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.
>>>> 	• PAR-enabled authorization servers can protect the integrity better and protect against Mix-Up Attacks better if they ONLY accept PAR requests.
>>>> 	• 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?
>>>> 	• Sender-constrained access tokens help against mix-up attacks when the access token is targeted.
>>>> 	• 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
>>>> 
>>>>  
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> 
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> 
>>>> 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.
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> 
>>>> 
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> -- 
>>> Karsten Meyer zu Selhausen
>>> IT Security Consultant
>>> Phone:	+49 (0)234 / 54456499
>>> Web:	
>>> 
>>> https://hackmanit.de
>>> 
>>>  | IT Security Consulting, Penetration Testing, Security Training
>>> 
>>> Unsere nächste Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 24.09 + 25.09:
>>> 
>>> 
>>> https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-24-und-25-09-2020
>>> 
>>> 
>>> 
>>> Hackmanit GmbH
>>> Universitätsstraße 60 (Exzenterhaus)
>>> 44789 Bochum
>>> 
>>> Registergericht: Amtsgericht Bochum, HRB 14896
>>> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> 
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> -- 
> Karsten Meyer zu Selhausen
> IT Security Consultant
> Phone:	+49 (0)234 / 54456499
> Web:	
> https://hackmanit.de
>  | IT Security Consulting, Penetration Testing, Security Training
> 
> Unsere nächste Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 24.09 + 25.09:
> 
> https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-24-und-25-09-2020
> 
> 
> Hackmanit GmbH
> Universitätsstraße 60 (Exzenterhaus)
> 44789 Bochum
> 
> Registergericht: Amtsgericht Bochum, HRB 14896
> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz
>