Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 21 March 2018 19:34 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 C3C9E12785F for <oauth@ietfa.amsl.com>; Wed, 21 Mar 2018 12:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 92i-h-bzVFxv for <oauth@ietfa.amsl.com>; Wed, 21 Mar 2018 12:34:41 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9685127369 for <oauth@ietf.org>; Wed, 21 Mar 2018 12:34:40 -0700 (PDT)
Received: from [31.133.150.105] (helo=dhcp-9669.meeting.ietf.org) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1eyjVN-0006cx-GZ; Wed, 21 Mar 2018 20:34:37 +0100
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <C499BC4D-C2D1-4654-82DF-BF3C5216C223@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_8DEBBCD5-9AB5-49C9-9F5C-0937FBAC7902"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 21 Mar 2018 19:34:33 +0000
In-Reply-To: <CAEKOcs1AhdU=nSnoj6OPP31789aV0Cn0cKheRDqmw63nx-bvMQ@mail.gmail.com>
To: oauth <oauth@ietf.org>
References: <E126FCD2-55E0-4ADB-9A3F-6EEF3955EC2C@authlete.com> <CAEKOcs1Ky7XETQ4xk2XaBZnkjyF-M_OpJvSWK5pouYgq90c5Nw@mail.gmail.com> <CA+k3eCR+bvWRK8H+tmkSGbHob1i7ZgrQ96g3qEeaLaU=_LJYSQ@mail.gmail.com> <57EDA9BC-1710-4968-B9D5-D6BBBC702046@lodderstedt.net> <CA+k3eCSheQzav2CmXvuOL3mT_z_6WON4UWCXqg_rsxzHP+XsAA@mail.gmail.com> <CA+k3eCQVsNr0pV8R8YAK-3o-qjF0c+7rVwqJ-Wyk=M8O0V=xyQ@mail.gmail.com> <CAEKOcs1AhdU=nSnoj6OPP31789aV0Cn0cKheRDqmw63nx-bvMQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/q4FsWrbsUcbEP_oSLuoPbwjdjbw>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 21 Mar 2018 19:34:45 -0000

Hi all,

thanks for your feedback. Here is my text proposal for section 3.8.1. 

——

Attackers could try to utilize a user's trust in the authorization
   server (and its URL in particular) for performing phishing attacks. 

RFC 6749 already prevents open redirects by stating the AS
MUST NOT automatically redirect the user agent in case 
of an invalid combination of client_id and redirect_uri.  

However, as described in [I-D.ietf-oauth-closing-redirectors], an
attacker could also utilize a correctly registered redirect URI to 
perform phishing attacks. It could for example register a client
via dynamic client registration and intentionally send an 
erroneous authorization request, e.g. by using an invalid 
scope value, to cause the AS to automatically redirect the user
agent to its phishing site. 

The AS MUST take precautions to prevent this threat. 
Based on its risk assessment the AS needs to decide whether 
it can trust the redirect URI or not and should only automatically 
redirect the user agent, if it trusts the redirect URI. If not, it could
inform the user that it is about to redirect her to the another site 
and rely on the user to decide or just inform the user about the 
error. 

——

kind regards,
Torsten.