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

[Jared Jennings <[e-mail]>]

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

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
<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#ref-owasp>].

or

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
<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#ref-owasp>].


3.1.1
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 4.4.1.1
<https://tools.ietf.org/html/rfc6819#section-4.4.1.1>, on
authorization code replay
   prevention.


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

4.8.1.3
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
<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#ref-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.

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

 [RFC6749], Section 4.1.2.1, 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.


4.9.2
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.

-Jared
Skype:jaredljennings
Signal:+1 816.730.9540
WhatsApp: [phone]