[OAUTH-WG] review draft-ietf-oauth-security-topics-13 : JJennings

Jared Jennings <jaredljennings@gmail.com> Fri, 08 November 2019 23:48 UTC

Return-Path: <jaredljennings@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F2B33120124 for <oauth@ietfa.amsl.com>; Fri, 8 Nov 2019 15:48:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Ld3yaOF0JQk1 for <oauth@ietfa.amsl.com>; Fri, 8 Nov 2019 15:48:09 -0800 (PST)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 4180D12011E for <oauth@ietf.org>; Fri, 8 Nov 2019 15:48:09 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id s10so6825108edi.5 for <oauth@ietf.org>; Fri, 08 Nov 2019 15:48:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=NcABLTHdtHz3yRMtnbY2sqlpfCbGzNW8pYaoLMyPsb0=; b=ZPPwaYi/fD9jNek54FBjJWDzgDZ6OPpl5x/2kAzQN8sk9h16u9fnM0zIAvnnj7cNCL 9cJqiSOvWuNgWpnPUtX6V2/iDbns1IEiEB9kzYfmxY5P6Cud0nD8rfKoXkmbHlQZ14po 16gYp+SbQ3sp8g8L/yHNTZGLj6sqXzvs3bmAy36jG4wjXLVjHy8w71aVpcmcbmfBEtAD ajSLv0R8CGzPBcVdk8Vq9ptdXvIxn5v9Szd9sOSEzajL2X7tiZ5nz9xVSs+CTPvC7FTD zWeFbYKdulKXLuN/M+sNr8/vhcqzFT9d3TYGCsQLpEXjOOYoynTUo42IZARtzbrfxn9i Ax4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NcABLTHdtHz3yRMtnbY2sqlpfCbGzNW8pYaoLMyPsb0=; b=j4GqHzsNzfXjfOTAjHDupvjIhpQhZZc/krSo+Hgr1YpZBPOpwImM+3Q9m/6wAfFBZl 8XvOrZLBVA8/58GlFzUrixKS8X+kn+lDLbfTAxf2KPX+iAJxZqsTcZCTn/z804RQlZer B4ctgp9ze9DuM+GfYL6juXiVs/t7LOzG+hyvSDh0+ixX5Zil2Jlu9TZMfP580oAy0o5K zyHfBPBZxQEbNDvheJ3+u1OTXiMMaVLheLpf19cknlCFNL9Oi4z+3tPiBZI1LlxVtqOX aHq5FLkd4U0Vszenvm3Pk3/l1DR/FTP1OqJMO3uEDeR7Oy2PURzl/TxECU0aDyBlVV2h 5kkA==
X-Gm-Message-State: APjAAAVIK+QHfzjjNhtAwXKwxQqZuKEglPjHZsrmUsto2XlIq2b2/ksS cMD41pyKudf3HLIJY3Yfo+hWHCaUlG7cjTLGC35wDz5QmmI=
X-Google-Smtp-Source: APXvYqwtDvkeVc2s98ZciB591BGtarG5HwQ4pVRbiuveV0A03EJAmbv7An2O9fHf/8sx+pdWX/AdLJybs12ekE5immc=
X-Received: by 2002:a17:906:4d99:: with SMTP id s25mr11810384eju.187.1573256887281; Fri, 08 Nov 2019 15:48:07 -0800 (PST)
MIME-Version: 1.0
From: Jared Jennings <jaredljennings@gmail.com>
Date: Fri, 08 Nov 2019 17:47:56 -0600
Message-ID: <CAMVRk+Lirr1onpMn7XaraX7kmK6H3SQXX92WJahbsx9tcOXHQA@mail.gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e82f0c0596de69aa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/__7rTLxv0Yv-HQQkVKfIUDWrZiA>
Subject: [OAUTH-WG] review draft-ietf-oauth-security-topics-13 : JJennings
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, 08 Nov 2019 23:48:12 -0000

A few comments and changes that I think should be made or would read more

3.1 Paragraph #2
Should probably read either of the following

Clients SHOULD avoid forwarding the user's browser to a URI obtained
   from a query parameter since such a function could be utilized to
   exfiltrate authorization codes and access tokens.  If there is a
   strong need for this kind of *redirect*, clients are advised to
   implement appropriate countermeasures against open redirection, e.g.,
   as described by OWASP [owasp


Clients SHOULD avoid forwarding the user's browser to a URI obtained
   from a query parameter since such a function could be utilized to
   exfiltrate authorization codes and access tokens.  If there is a
   strong need for *these* kind of redirects, clients are advised to
   implement appropriate countermeasures against open redirection, e.g.,
   as described by OWASP [owasp

Last Paragraph
Either should start with AS, like the others or server should be uppercase?

 Authorization servers SHOULD furthermore consider the recommendations
   given in [RFC6819], Section
<https://tools.ietf.org/html/rfc6819#section->, on
authorization code replay

4.4.1, 4.5.2
The beginnings of each bullet list should be capitalized? (The)
Should maybe read

An audience restriction essentially restricts access tokens to a
particular resource server. The authorization server

   associates the access token with the particular resource server and
thus a resource server SHOULD verify the
   intended audience. If the access token fails the intended audience
validation, the resource server must refuse

   to serve the respective request.


The client SHOULD to tell the authorization server the intended
resource server.  The proposed
   mechanism [I-D.ietf-oauth-resource-indicators
could be used or by encoding the
   information in the scope value.


   Audience restriction may seem easier to use since it does not require
any crypto on the client-side. Still, since every access token is bound to
a specific resource server, the client also needs to obtain a single
RS-specific access token when accessing several resource servers.
 [I-D.ietf-oauth-token-binding] has the same property since different token
binding ids must be associated with the access token.  Using
[I-D.ietf-oauth-mtls], on the other hand, allows a client to use the access
token at multiple resource servers.

4.8.2 I think would read better with the following
An attacker may compromise a resource server to gain access and to other
resources of the respective deployment. Such a compromise may range from
partial access to the system, e.g., its log files, to full control of the
respective server.

If the attacker were able to gain full control, including shell access, it
would be able to circumvent all controls and access resources. It would
also obtain other access tokens held on the compromised system, which would
potentially be valid to access other resource servers.

Preventing server breaches by hardening and monitoring server systems is
considered a standard operational procedure and, therefore, out of the
scope of this document. This section focuses on the impact of such
 OAuth-related breaches and the replaying of captured access tokens.

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

 [RFC6749], Section, 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 [RFC7591] and intentionally send an erroneous authorization
request, e.g., by using an invalid scope value, thus redirecting
instructing the AS to redirect the client to the desired 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
and SHOULD only automatically redirect the user agent if it trusts the
redirect URI. If the URI is not trusted, it MAY inform the user and rely on
the user to make the correct decision.

Clients MUST NOT expose URLs, which could be utilized as an open
redirector. Attackers may use an open redirector to produce URLs that
appear to point to the client, which might trick users into trusting the
URL and following it in their browser. Another abuse case is to produce
URLs pointing to the client and utilize them to impersonate a client with
an authorization server.

The client should only expose a URL, if the target URL(s) is whitelisted or
if the origin of the request can be confirmed.

4.11 (last paragraph)
If an attacker was able to get access to the internal network between proxy
and application server, the attacker could also try to circumvent security
controls in place. It is, therefore, essential to ensure the authenticity
of the communicating entities. Furthermore, the communication link between
reverse proxy and application server must be protected against
eavesdropping, injection, and replay of messages.

P.S. I am out for the next 8 days and will not be able to respond to any
comments or questions until after the 15th.

Signal:+1 816.730.9540
WhatsApp: +1 816.678.4152