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

From: Daniel Fett <[email-masked]>
Date: Fri, 1 Jun 2018 19:23:26 +0200

Thank you Travis for your feedback!

Am 20.03.18 um 12:48 schrieb Travis Spencer:
> I read through this doc and would like to share a bit of feedback in
> hopes that it helps:
>
> * There is no mention of Content Security Policy (CSP). This is a very
> helpful security mechanism that all OAuth servers and web-based
> clients should implement. I think this needs to be addressed in this
> doc.
>     - No mention of frame breaking scripts for non-CSP aware user agents
>     -  No mention of X-Frame-Options
> * There's no mention of HSTS which all OAuth servers and web-based
> client should implement (or the reverse proxies in front of them
> should)

If I see this correctly, all of these mechanisms fall in the category of
"do web security right" that Jim mentioned, i.e., there are no concrete,
OAuth-specific attacks that would be prevented by these. If so, I think
we should not mention them in the document.

> * The examples only use 302 and don't mention that 303 is safer[1]
>    - Despite what it says in section 1.7 of RFC 6749, many people
> think that a 302 is mandated by OAuth. It would be good to recommend a
> 303 and use examples with other status codes.

Yes, we should address that.

> [1] https://arxiv.org/pdf/1601.01229v2.pdf

(That link, by the way, points to an old version of our paper. There is
an updated version with more attacks and a better presentation:
https://arxiv.org/pdf/1601.01229.pdf)

Thanks again for your feedback!

-Daniel

-- 
SEC - Institute of Information Security
University of Stuttgart
Phone +49 711 685 88468
Universitätsstraße 38 - 70569 Stuttgart - Room 2.434

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 10 Jun 2018 18:33:44 +0200

Hi Johan,

thanks for your proposal. I’m not sure whether it should go to 3.7.1.4. The reason audience restriction turns up as a subsection of 3.7 is our document is organized by attacks instead of security controls. I could image to add a section on audience/action restriction as sub section of 2.

What is the mean reason for restricting access tokens to certain actions? Is it about least privileges? Is it to limit the impact of a token leakage/replay? ...

best regards,
Torsten.  

> Am 07.04.2018 um 19:11 schrieb Johan Peeters <[email-masked]>:
> 
> Thanks for doing this great work, Torsten. As discussed in a private
> email conversation, I think an access token should not only be
> explicit about which resource server is the intended consumer
> (audience), but also which actions are permitted on the targeted
> resources:
> 
> =========3.7.1.4. Action Restricted Access Tokens=========
> 
>   An action restriction restricts the action a
>   particular access token can be used for.  The authorization server
>   associates the access token with a certain action and every
>   resource server is obliged to verify for every request, whether the
>   access token sent with that request was meant to be used for that
>   particular action.  If not, the resource server must refuse
>   to serve the respective request.  Action
>   restrictions limit the impact of a token leakage and prevent a
> malicious client to use the token for unintended actions.
> 
>   The action attribute in  can be expressed as the HTTP verb used to
> make the request.
> 
>   The client needs to tell the authorization server, for which actions it
>   will use the access token it is requesting.  It should encode
>   the information in the scope value.
> 
>   Action restrictions are essential both to enforce scope
> restrictions as established through user dialog and policy decisions
> by the authorization server.
> 
> ==========================
> 
> Yo
> -- 
> Johan Peeters
> https://www.johanpeeters.com