Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC

Jim Manico <jim@manicode.com> Tue, 12 May 2020 17:45 UTC

Return-Path: <jim@manicode.com>
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 447533A0816 for <oauth@ietfa.amsl.com>; Tue, 12 May 2020 10:45:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, MIME_QP_LONG_LINE=0.001, 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=manicode.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 fYQiajiUvhlE for <oauth@ietfa.amsl.com>; Tue, 12 May 2020 10:45:13 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 613BA3A0841 for <oauth@ietf.org>; Tue, 12 May 2020 10:45:02 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id c24so5388233qtw.7 for <oauth@ietf.org>; Tue, 12 May 2020 10:45:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=k7aeKxRJrx2Tp+Sd17QdR4TBKfKbt+GQ5yXk2eyNvbk=; b=NljWpfhF0fk/ZF/oggfzObdZDaFNiQJKeKlgNL4sC1Lj5JpJpBR+wtVqeH4eKTnxxj gGhLaIVEHsq/yQhsoLPJMl3NhQeH3tb5pw2WVQEneCS8iLivFiZrmimcxXiiwP9XNz9F UdGbF+HQKaepNzEiY3Yk1dITEoNZvJ4UUrA1tS0u6c1f5oREfTinwxPoWGduk4SOMyg0 0+98837+h/ERcHqz/X3kyu/+ybh0tSZxDsphT6p9Vbc4QU+jZoPl/dTUzycDoBLDrVTj DHleTX4P+oJ3j0a1L9VCViwVYgLE2GAKVjNbU06VZyDNSudy1J1daBAUoy0LHJdKF1ic YAgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=k7aeKxRJrx2Tp+Sd17QdR4TBKfKbt+GQ5yXk2eyNvbk=; b=cWzxdiLsN7cpAFJLoEwrVlY6rcR+kkTv4ydY/lT5wzuuEbrUEcEVmsjdccxe5Z9PDE 94OOnZ0y3WmCWgTBveupaPtC3sORv7M0sYQH8OFpk5s0y8Yk+s7RG3isHUW5YVhuSk8z YCIA685DtL++HFuJvvTUe3n7FWE7vTlO1PZmSGnxoF8cyTSQ1xonJ6glsevvwm+cqiCP kowctcplyXpLDkorgMynogsx0U8GbA75kU0HdPgay1vBzupXU3TzLq3ixt92LEZEYiBs mrLzUi2oeMuYvruxMAMwSiRTr379TpLiq1mOc7ev6vPWcNXKMeu/UFZ7hiAT1bqjnKGr d18Q==
X-Gm-Message-State: AGi0PuaUjiboaR/k68G5ROMVPnlSnQTZNTLhxRk9WpJRBC/Qpky5P/Zu H/ZIY7VXliwgh+B+c3KtJWxsElgFIJQ=
X-Google-Smtp-Source: APiQypLbZvk6EcU0SO87rEKX+FnivmoOhSXtwO1Wyze9nT0kRzqC0EDuaU8ld+o7d8SP5ai4EPa31Q==
X-Received: by 2002:ac8:4e88:: with SMTP id 8mr23063096qtp.82.1589305500931; Tue, 12 May 2020 10:45:00 -0700 (PDT)
Received: from [10.5.134.149] (mobile-166-171-59-62.mycingular.net. [166.171.59.62]) by smtp.gmail.com with ESMTPSA id a21sm9862072qtw.24.2020.05.12.10.44.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 10:44:59 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-0774C34F-61CE-4670-9FAE-D7ED78BC0CCC
Content-Transfer-Encoding: 7bit
From: Jim Manico <jim@manicode.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 12 May 2020 13:44:58 -0400
Message-Id: <40851BF2-7C15-42FD-85A7-63FD994B1059@manicode.com>
References: <CAOW4vyM3Vi4eHCCn1x5-0K0S8pP5qtpTByNYS4DP8EaSqiWn5Q@mail.gmail.com>
Cc: OAuth WG <oauth@ietf.org>
In-Reply-To: <CAOW4vyM3Vi4eHCCn1x5-0K0S8pP5qtpTByNYS4DP8EaSqiWn5Q@mail.gmail.com>
To: Francis Pouatcha <fpo@adorsys.de>
X-Mailer: iPhone Mail (17E262)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/QuxHAX-vII0_CUsr47Ji3T9vOnc>
Subject: Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC
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, 12 May 2020 17:45:15 -0000

> We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1 forbidding the user of ROPC.

Absolutely and this seems like a good thing. ROPC seems very close to a use case that calls for OIDC instead of a OAuth2x token so I endorse the move.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On May 12, 2020, at 1:23 PM, Francis Pouatcha <fpo@adorsys.de> wrote:
> 
> 
> 
> 
>> On Tue, May 12, 2020 at 9:50 AM Jim Manico <jim@manicode.com> wrote:
>> Forgive me if this question is late or poor context, but wouldn’t OIDC be a better replacement for ROPC since it’s essentially a authentication flow?
>> 
>> What use case for ROPC mandates OAuth2 over OIDC?
> We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1 forbidding the user of ROPC.
> 
>> 
>> --
>> Jim Manico
>> @Manicode
>> 
>>>> On May 11, 2020, at 11:00 PM, Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org> wrote:
>>>> 
>>> 
>>> I am against OAuth 2.1 discarding the use of ROPC (Resource Owner Password Credentials) with the following reasoning:
>>> 
>>> Auth Code Grant:
>>> There are  many use cases on the market where redirection based flows do not work. As  we see in the "OAuth 2.1 - require PKCE?" thread, the complexity of user agents on non controllable client devices still make user agent redirection a challenge. 
>>> 
>>> Client Credentials Grant:
>>> Requires the registration of an oAuth client.
>>> - Citing the iot device use cases Beena which do not have a comfortable way to have iot devices register with AS.
>>> - This is a registration flow for the oAuth client role  and for the RO (Resource Owner). Remember resource owner credentials might be sourced from system external to the AS  like company's LDAP. oAuth Client Credentials are generally managed by the AS.
>>> For these reasons, we shall not use Client Credential Grant to manage RO authorization.
>>> 
>>> ROPC:
>>> Having an oAuth Client proxy the auth request of the RO to the AS only presents a security risk if the oAuth Client is a third party application. Therefore, the decision on whether to accept ROPC for a specified client shall be left to the AS. Discarding this use case will take a lot of business from oAuth servers back to the old market.
>>> 
>>> Beside this, I mentioned in my previous post that there are use cases in the market where permanent passwords are replaced with one time passwords.
>>> 
>>> A lot of work is also being done in the direction of having the RO send signed proof of ownership to the AS through the ROPC  flow using the password field.
>>> 
>>> Therefore, I am ok with raising the attention of  implementers the same way we are doing with PKCE,  mentioning that ROPC  must only be used if  AS / oAuth Client can guarantee security of the RO credentials exposed to the oAuth Client. 
>>> 
>>> /Francis
>>> -- 
>>> Francis Pouatcha
>>> Co-Founder and Technical Lead at adorys
>>> https://adorsys-platform.de/solutions/
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/