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

Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de> Tue, 11 August 2020 06:20 UTC

Return-Path: <karsten.meyerzuselhausen@hackmanit.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 8DD0A3A0CB3 for <oauth@ietfa.amsl.com>; Mon, 10 Aug 2020 23:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.837
X-Spam-Level:
X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackmanit-de.20150623.gappssmtp.com
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 PpFfx38c-X46 for <oauth@ietfa.amsl.com>; Mon, 10 Aug 2020 23:20:40 -0700 (PDT)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 227A83A0C9B for <oauth@ietf.org>; Mon, 10 Aug 2020 23:20:39 -0700 (PDT)
Received: by mail-ej1-x634.google.com with SMTP id l4so11802337ejd.13 for <oauth@ietf.org>; Mon, 10 Aug 2020 23:20:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackmanit-de.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=99WLM10iJChoC1OUMrDoqbSzNoo26ic1PYBHipF1tsY=; b=Uwpmw8B662MtA+NAbXcKJPhqUjCB5utt5j07uVsw3eN37xngGEzKRDVIwuXJyRM8f3 aTsu/E5zs/+J55FsvIQZ0cz+ayGZNSupwrVAAK9fjyK8fBsz3HFF5a2KkoPEycKuIDrL KiP++6sPen6KWRdz++AMSvwSg5AejIgaaKYpQhydf94BXQgMKNnfMVYmOCSFD15k8X8m Uf8BBNaOfkXJiSKb4ebttGEBZ2LVJtksNdI12M5Z5lvTgwr/hvApcoT9HHpofZsxL7We uwVgGJAr0SeaTcggy6XUWf6x7GpniMPBIRg7Wr981I45uhWIOGYUnCBPQEDuHP9A0cuV BHXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=99WLM10iJChoC1OUMrDoqbSzNoo26ic1PYBHipF1tsY=; b=oVZyUX9bYVLe03ZD15HDmyeeK3IEhbB0RLaeNh5meyWlAwJIt5PP/RvnzS4cwhgCrR F10+iM2yV7T6L8oEzQTg42uSrLWBESDGVUCVlrNS5l8HR3jBUqE0lKM6ffZTUZn8oSBX Dq/4o6lxJ8hrLu54vtQcBkpenodRfZl5Wo8EAD1QngnXaSFzC6cCcK6dXEC6WCIf4H81 8IPAEbZqKnTJdU/52y5jURp5Ufk2ahKYSVJVUyMFw7N7LZP9QAJ7mJm8dQKksMpIfvJt COECU4De/ZsguZyarjrDYu2WkOsNH+CPz3WtjiRim9Dpas5c7YN+Zc0liHVArCVtjyJo 2YQg==
X-Gm-Message-State: AOAM533dij34yyF+O3kPxuZzc0R+0/c+Xa42VHyfMzExuhQUR3Jk608D I2JpIOLo1z9AF+84Q+6+CEXa2owDwvI=
X-Google-Smtp-Source: ABdhPJyo5LlULvT2TebOuyMMixWgRx4vnjag5DpYeTpJsPAtD3JN4/6uopkWef+kyxNLFaJLQiC+vw==
X-Received: by 2002:a17:907:104a:: with SMTP id oy10mr25042589ejb.267.1597126837860; Mon, 10 Aug 2020 23:20:37 -0700 (PDT)
Received: from [192.168.178.22] (b2b-37-24-87-133.unitymedia.biz. [37.24.87.133]) by smtp.gmail.com with ESMTPSA id gh25sm14310012ejb.109.2020.08.10.23.20.36 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2020 23:20:37 -0700 (PDT)
To: oauth@ietf.org
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>
From: Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>
Autocrypt: addr=karsten.meyerzuselhausen@hackmanit.de; keydata= mQINBFh1IBMBEADV73c10lB7zeFy6/ezLFzOBp8z6Zy1zUyIrf6RoBk1GQWREcGEGeaL90Pj F5plZeASVJdsEYnYXdgcIPE0tlBq6al6OYoWtH/VbFPWEPLVhA3rL1iXVJveD3J40OzSYP8N G7bla3zQ2+TXOB3iDPPsHZUdHCLASkIIWQK6+fE1C2epAdPtnsLsb++1d080jfXXwgyUUh4y bimcy9Jg5oZ4QMwnSq3Y+x38PNb+nTgjDi1X/89/WsNd7Bdh4Zvw3CAuc/W58CFaDjb7liUD YRoAp6ysnjPKEUSnAnMpgaiXJc1gFoL+ahdKJ3D9XTn28NTjUrvOkVidsuKbyxnXP9I6BO6i 2jzjrH6TEAfIYMjZlYTyPZTt271SW5iAHYwvPZWlqQTBT2P/d4gHl0To5b4e+UXxjQgxqUyi QIcxh3Ris21Kx4lKQKDXYWiwNTZzx8AdqrcxCWfK+MRpFyk0B+4uDMm7Apm5ZWwDKN/JnVsJ yokkkrrHs/elRCUGtN9NyhJQf3VnE87862Pej8PVvQJr3uVnoNX2yieTvJZftIOBG1b9ta6Z BcYyn3un1rSn7lBPg+RSnPemposVorQpjGwT+Dhg13Bpv5q0JfSc//js/nB6A4iq5YssdtQ7 35QBWLLaF1oCxalvrQVDD4Sh06eAUQsga9xeE0yv7sxqdsozdwARAQABtEJLYXJzdGVuIE1l eWVyIHp1IFNlbGhhdXNlbiA8a2Fyc3Rlbi5tZXllcnp1c2VsaGF1c2VuQGhhY2ttYW5pdC5k ZT6JAj8EEwEIACkFAlh1IBMCGyMFCQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAK CRBFNcDn2xbxSK7sEAC5hk0VQHo2+fMV3b4TgSt4qSPLz6EnWwoqcEzUGYHErQXy7tCENpqS rsZsFphpgvWo1tcQdpyQTFm0dry4ASJD78lEiYC/8Hedp0fIaJTGwxrSLpRxV/Wb+iqkbgz8 /Qydl3QyupSqznSHQMd0uhvzHLxoYvHAIKy52gCK0T9gmxcCIh7UEjDfm+kqHp+oU4sbNe+2 ZEtJLuCKW+amNyqnHXr7ehAIaYmTdKOEcUb2UM7Yzp9g4kSkg1GbPlAn6yjyAqJ96sobKFXX S3rkXksRTxkGKW278Nrs4UBO+OIu32kIXCM2m3fKaUK777jAQu1e8sdj2nL0sPWQvMikZRx6 0dy+wVuH8gGHZsd7rW201Sv5pAhSAK4l58GS3xSLId6smXCend9Vu+tcYA+Bb+45943LmoPA PrdIUeI+zC9pjGwm+x+jFiCxbChqAiJF7RyYv9crziEYnTQ70gHGNOTOTIS5t0ufc9D4wD4O IkkrPQYg3KcAqP2Kyj1uHcqdk7XEhV1fdTXdeEt1e7auWPh0d3Fo+BTtiGXfNMuORArE0El6 ky8eUOqZEJ8rYpEGDLt0JFkJM5AhX4PrQWekjaMhQ5yl/+M+Ss0V0JkImagSgWdvUn1+eAs0 zEuVxTc6ON69mIyMalQ5d4ofvPnKr3GNVmEiXAVDMGUZHoeabfgSBbkCDQRYdSATARAAsp2V mr3N7iNND8+M/OyA/OwcDQ6utZh+m4TnKsOVdiNLGpu2U3/2Qg3yrbjic2dWx1CsS6VH2/oO 1e/a4FlxA93wFv/OZjiUjHtEvdIJeHWlCvWOUlMsqyGDc3Q75fNjFw6DGKkiOu9lZaBs6naS BmkvAMGjV5bNKLyIL5j7Im1pCdZ2lCjD7eVwR3RQQKobTmu916htX8g1cB9yFmquu37X+ZBl A4GLJi63Kw0L2r8i8iO1NqDLOfT8IeNkOroEm3SDAuEApGAubKLSPBJ1khQ7kDhpdfzSYKUF tiIHpGWVOImDjqf4JIcF7OIdRPQfFPlwoPnsyBAS8znQJvmqbbMowgFZe3UMLAN78CETZHGM OLBPB873oWyZ07Ar4v/SL5/aD+FRj2VnYEcGwt0HMmMyaN6ed8Udj4OTNZ7ceZA1Tw8/lZuI KCamj0XfJIK6376RCGnqjsEfS65P1KWZXfWphCKWp2c7uWKtau1q8pgiVRoBSAmjvfXRrIvK LhhQyNOiCUDKrvEWpoeq9y5GTrY27ncLov8nSR/SUPOw5HwJmzdFjhOF9XAOtiND/QRH886O IohdlnUu668mwLCmL2ROe7XWcTkFQWLDg+5b0bC9dgfL+HHpWGUdQPG3CCyPG5LfDmnmuXkE eU1kSD27kFe1kM6pfqpCydJW66DuwoMAEQEAAYkCJQQYAQgADwUCWHUgEwIbDAUJCWYBgAAK CRBFNcDn2xbxSAAbEACeIsfrsq2tlyigZv+bwkiVP1oKtWfXN1e3K3lDOBqPJaPXWFOopq/1 9osk58PFtVEaDlYPlN/NP6Jq5nTTC8QyLG3swAdo4ZJXWEg1NTRu8ddYUvZWuRHWRghaq7qh eW5lVPqilCndSG7bkDPU/Vyd93nPKnKTKKs/Nd7ePneWA0JQohEg5gO/GU0v5SN3YfTxG1LV Cxu3HHHFodDLK4KITSYmt1+g0WCADeclwm5+L5lIvgKQvcIpjpMGNK1wj2E3exsLlgo/ZEyS AslOPXyQw2yfYLrcfGpvWa3e+AvU7eLVBgihskpibJg53yw31B0CXAJBbjg7AsxR8UE5pl6h 2gTjN2t++GvqefGtw/bPvx2RzFsorh1/RYaFgcaFyefghmpi55iiIhgEOiSIct0LoYl3cmH8 DGYKhSskpSDgfE41Esk/P2odeax9SmJuv4mnqkiGFPpTwCfUka2k0mCpBDpfTdECWUFhreGS qFbrvJDZRBiyaVyCjOvOc0v6Z0/iIRgHWTjITpqaQh69kqAtt9GQWV6i3THnpHFlIC2ecvdc YCagneZdoLEHCS8Nois/uDbp5qZwZcF5zKMI+T7u6Qf8EGdvxCB1fp0Sdlmeto0c6/gnFUix 4J/tozBwSXSg7JCxTrUdnJtcQAJzosOUZTVO/ZZR/n0+904kud6o3w==
Message-ID: <cf52ffac-1542-2e90-9017-50af154765a8@hackmanit.de>
Date: Tue, 11 Aug 2020 08:20:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <MN2PR00MB06866084FF95C4956A76B472F59B0@MN2PR00MB0686.namprd00.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------3A8BBA9CF55FF556CECD6D79"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/lIcr6RQUh_Z2u340DK-GukKm6_w>
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: Tue, 11 Aug 2020 06:20:44 -0000

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”?


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