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

[Torsten Lodderstedt]

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 :
> 
> 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



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Daniel Fett]

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Travis Spencer]

On Wed, Mar 21, 2018 at 8:34 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

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

The "...and should..." and "...it could inform..." don't directly line up
with the MUST at the beginning of that paragraph. It makes the MTI
precautions only and the rest is optional. If that's desired, OK, but I'd
suggest using all caps to make that clear -- MAY/OPTIONAL or MUST/REQUIRED
or SHOULD/RECOMMENDED
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

I like the new text, it frames the error better and puts it in the context 
where it’s likely to be exploited. IE, newly dynamically registered clients 
shouldn’t be trusted as much as others.

 — Justin

> On Mar 22, 2018, at 8:16 AM, Brian Campbell  
> wrote:
> 
> That works for me
> 
> On Wed, Mar 21, 2018 at 7:34 PM, Torsten Lodderstedt  > wrote:
> 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.
> 
> 
> 
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
> material for the sole use of the intended recipient(s). Any review, use, 
> distribution or disclosure by others is strictly prohibited..  If you have 
> received this communication in error, please notify the sender immediately by 
> e-mail and delete the message and any file attachments from your computer. 
> Thank you.___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

That works for me

On Wed, Mar 21, 2018 at 7:34 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

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

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

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. 
  



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Travis Spencer]

On Wed, Mar 21, 2018 at 8:36 AM, Brian Campbell
 wrote:
> Doing redirection in error conditions relates to OpenID Connect flows too.

Also Mobile Connect. Those folks will be very upset by this change, I'm sure.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

Doing redirection in error conditions relates to OpenID Connect flows too.
There's been some related discussion recently about it in this issue:
https://bitbucket.org/openid/connect/issues/1023/clarify-
that-returning-errors-to-the

On Tue, Mar 20, 2018 at 7:38 PM, Brian Campbell 
wrote:

> The strict redirect_uri matching, referrer-policy headers, and appending a
> dummy fragment on error redirects are things that protect from token
> leakage/interception resulting from redirection on error, which is the
> threat in section 2.2 of -closing-redirectors-00
> .
> It's true that they don't protect against the kind of open redirection
> based on malicious client registration that's described in section 2.1
> .
> But I don't believe that abuse (as that document calls it) is serious
> enough to warrant trying to introduce a breaking change to the original
> behavior of RFC 6749 
> in this security topics document.
>
>
>
>
>
>
> On Tue, Mar 20, 2018 at 4:44 PM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Hi Brian,
>>
>> Am 20.03.2018 um 15:37 schrieb Brian Campbell > >:
>>
>> +1 to what Travis said about 3.8.1
>>
>> The text in 3.8 about Open Redirection is new in this most recent -05
>> version of the draft so this is really the first time it's been reviewed.. I
>> believe 3.8..1 goes too far in saying "this draft recommends that every
>> invalid authorization request MUST NOT automatically redirect the user
>> agent to the client's redirect URI."
>>
>> I understand that text was informed by https://tools.ietf.org/html/dr
>> aft-ietf-oauth-closing-redirectors-00 but it takes one of the potential
>> mitigation discussed there in section 3
>> 
>> (the one which happens to contradict RFC 6749) and elevates it to a "MUST".
>> I don't think something that drastic is warranted. I think there are other
>> mitigations - like strict redirect_uri matching,
>>
>>
>> In the attack described in https://tools.ietf.org/html
>> /draft-ietf-oauth-closing-redirectors-00 section 2.1. the attacker
>> dynamically registers a client with the AS. So exact redirect URI matching
>> won’t stop the open redirection attack since the attacker uses the correct
>> URI. The problem is with the change in the underlying trust model. RFC 6749
>> assumes every configured client to be legit. This might have been ok at the
>> time RFC 6749 was published. Open dynamic client registration collides with
>> this assumption.
>>
>> We could distinguish between cases where the AS is confident the client
>> is legit and other cases. But how does the AS determine it?
>>
>> referrer-policy headers, and appending a dummy fragment on error
>> redirects -
>>
>>
>> Can you please explain how this protects from open redirection?
>>
>> that can protect against the more serious redirection issues without
>> -security-topics trying to introduce normative breaking changes to the
>> behavior from the original OAuth 2.0 Authorization Framework.
>>
>>
>>
>> Perhaps there are some error cases not mentioned in RFC 6749 where
>> returning an HTTP error code to the browser would be better or more
>> appropriate than redirecting back to the OAuth client (my opinion on this
>> has gone in circles and I'm honestly not sure anymore). But saying that
>> authorization requests never automatically redirect back to the client's
>> redirect URI is excessive.
>>
>>
>> Probably. Let’s discuss in detail.
>>
>> I think the AS should not automatically redirect the user in case of the
>> following error conditions because an attacker could cause this errors via
>> request parameters or its configuration:
>> - unsupported_response_type
>> - invalid_scope
>> - unauthorized_client
>> - invalid_request
>>
>> kind regards,
>> Torsten.
>>
>>
>>
>> On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer <
>> travis.spen...@curity.io> wrote:
>>
>>> 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)
>>> * 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 

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

[Jim Manico]

If you plan on adding these web layer security suggestions into the OAuth 
standard I can think of 100-200 more requirements to add. I thought “do web 
security right” was an implied recommendation?

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

> On Mar 20, 2018, at 5:37 AM, Brian Campbell  
> wrote:
> 
> +1 to what Travis said about 3.8.1
> 
> The text in 3.8 about Open Redirection is new in this most recent -05 version 
> of the draft so this is really the first time it's been reviewed. I believe 
> 3.8..1 goes too far in saying "this draft recommends that every invalid 
> authorization request MUST NOT automatically redirect the user agent to the 
> client's redirect URI." 
> 
> I understand that text was informed by 
> https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00 but it 
> takes one of the potential mitigation discussed there in section 3 (the one 
> which happens to contradict RFC 6749) and elevates it to a "MUST". I don't 
> think something that drastic is warranted. I think there are other 
> mitigations - like strict redirect_uri matching, referrer-policy headers, and 
> appending a dummy fragment on error redirects - that can protect against the 
> more serious redirection issues without -security-topics trying to introduce 
> normative breaking changes to the behavior from the original OAuth 2.0 
> Authorization Framework. 
> 
> Perhaps there are some error cases not mentioned in RFC 6749 where returning 
> an HTTP error code to the browser would be better or more appropriate than 
> redirecting back to the OAuth client (my opinion on this has gone in circles 
> and I'm honestly not sure anymore). But saying that authorization requests 
> never automatically redirect back to the client's redirect URI is excessive.
> 
> 
>> On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer  
>> wrote:
>> 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)
>> * 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.
>> * 3.3.1 refers to client.com in the example. This is a real domain.
>> Suggest client.example.com instead. Same issue in 3.1.2 where
>> client.evil.com is used
>> * 3.1.3 (proposed countermeasures) - native clients that use a web
>> server with a dynamic port should use dynamic client registration and
>> dynamic client management rather than allowing wildcards on the port
>> matching of the OAuth server.
>> * 3.8.1 says "Therefore this draft recommends that every invalid
>> authorization request MUST NOT automatically redirect the user agent
>> to the client's redirect URI" -- This is gonna break a lot of stuff
>> including other specs! I don't think that's warranted, and I am not
>> looking forward to the fallout this could cause.
>> 
>> Anyway, my $0.02. Hope it helps.
>> 
>> [1] https://arxiv.org/pdf/1601.01229v2.pdf
>> 
>> On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan  wrote:
>> > Hi Torsten,
>> >
>> > As we briefly spoke about earlier, "3.8.1. Authorization Server as Open
>> > Redirector" could I think be made more explicit.
>> >
>> > Currently it explicitly mentions the invalid_request and invalid_scope
>> > errors must not redirect back to the client's registered redirect uri.
>> >
>> > https://tools.ietf.org/html/rfc6749#section-4.1.2.1 defines several more
>> > potential errors that appear to fall into the same category. I understand 
>> > to
>> > block the attack fully we need 'must not redirect's for all the kinds of
>> > error that could cause an automatic redirect back to the client's 
>> > registered
>> > redirect uri without any user interaction - 'unauthorized_client' and
>> > 'unsupported_response_type' seem to fall into that category. 'server_error'
>> > also seems dodgy (I would wager that on some servers that are known ways to
>> > provoke server errors), and I would have doubts about
>> > 'temporarily_unavailable' too.
>> >
>> > Thanks
>> >
>> > Joseph
>> >
>> >
>> > ___
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> 

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

[Brian Campbell]

The strict redirect_uri matching, referrer-policy headers, and appending a
dummy fragment on error redirects are things that protect from token
leakage/interception resulting from redirection on error, which is the
threat in section 2.2 of -closing-redirectors-00
.
It's true that they don't protect against the kind of open redirection
based on malicious client registration that's described in section 2.1
.
But I don't believe that abuse (as that document calls it) is serious
enough to warrant trying to introduce a breaking change to the original
behavior of RFC 6749 
in this security topics document.






On Tue, Mar 20, 2018 at 4:44 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> Hi Brian,
>
> Am 20.03.2018 um 15:37 schrieb Brian Campbell  >:
>
> +1 to what Travis said about 3.8.1
>
> The text in 3.8 about Open Redirection is new in this most recent -05
> version of the draft so this is really the first time it's been reviewed. I
> believe 3.8..1 goes too far in saying "this draft recommends that every
> invalid authorization request MUST NOT automatically redirect the user
> agent to the client's redirect URI."
>
> I understand that text was informed by https://tools.ietf.org/html/dr
> aft-ietf-oauth-closing-redirectors-00 but it takes one of the potential
> mitigation discussed there in section 3
> 
> (the one which happens to contradict RFC 6749) and elevates it to a "MUST".
> I don't think something that drastic is warranted. I think there are other
> mitigations - like strict redirect_uri matching,
>
>
> In the attack described in https://tools.ietf.org/
> html/draft-ietf-oauth-closing-redirectors-00 section 2.1. the attacker
> dynamically registers a client with the AS. So exact redirect URI matching
> won’t stop the open redirection attack since the attacker uses the correct
> URI. The problem is with the change in the underlying trust model. RFC 6749
> assumes every configured client to be legit. This might have been ok at the
> time RFC 6749 was published. Open dynamic client registration collides with
> this assumption.
>
> We could distinguish between cases where the AS is confident the client is
> legit and other cases. But how does the AS determine it?
>
> referrer-policy headers, and appending a dummy fragment on error redirects
> -
>
>
> Can you please explain how this protects from open redirection?
>
> that can protect against the more serious redirection issues without
> -security-topics trying to introduce normative breaking changes to the
> behavior from the original OAuth 2.0 Authorization Framework.
>
>
>
> Perhaps there are some error cases not mentioned in RFC 6749 where
> returning an HTTP error code to the browser would be better or more
> appropriate than redirecting back to the OAuth client (my opinion on this
> has gone in circles and I'm honestly not sure anymore). But saying that
> authorization requests never automatically redirect back to the client's
> redirect URI is excessive.
>
>
> Probably. Let’s discuss in detail.
>
> I think the AS should not automatically redirect the user in case of the
> following error conditions because an attacker could cause this errors via
> request parameters or its configuration:
> - unsupported_response_type
> - invalid_scope
> - unauthorized_client
> - invalid_request
>
> kind regards,
> Torsten.
>
>
>
> On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer  > wrote:
>
>> 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)
>> * 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.
>> * 3.3.1 refers to client.com in the example. This is a real domain.
>> Suggest client.example.com instead. Same issue in 3.1.2 where
>> client.evil.com is used
>> * 3.1.3 (proposed countermeasures) - native clients that use a web
>> server with a dynamic port should use dynamic client registration and
>> dynamic client management rather than allowing wildcards on the port
>> matching 

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

[Torsten Lodderstedt]

Hi Brian,

> Am 20.03.2018 um 15:37 schrieb Brian Campbell :
> 
> +1 to what Travis said about 3.8.1
> 
> The text in 3.8 about Open Redirection is new in this most recent -05 version 
> of the draft so this is really the first time it's been reviewed. I believe 
> 3.8..1 goes too far in saying "this draft recommends that every invalid 
> authorization request MUST NOT automatically redirect the user agent to the 
> client's redirect URI." 
> 
> I understand that text was informed by 
> https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00 
>  but it 
> takes one of the potential mitigation discussed there in section 3 
> 
>  (the one which happens to contradict RFC 6749) and elevates it to a "MUST". 
> I don't think something that drastic is warranted. I think there are other 
> mitigations - like strict redirect_uri matching,

In the attack described in 
https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00 
 section 
2.1. the attacker dynamically registers a client with the AS. So exact redirect 
URI matching won’t stop the open redirection attack since the attacker uses the 
correct URI. The problem is with the change in the underlying trust model. RFC 
6749 assumes every configured client to be legit. This might have been ok at 
the time RFC 6749 was published. Open dynamic client registration collides with 
this assumption.   

We could distinguish between cases where the AS is confident the client is 
legit and other cases. But how does the AS determine it?

> referrer-policy headers, and appending a dummy fragment on error redirects -

Can you please explain how this protects from open redirection? 

> that can protect against the more serious redirection issues without 
> -security-topics trying to introduce normative breaking changes to the 
> behavior from the original OAuth 2.0 Authorization Framework. 


> 
> Perhaps there are some error cases not mentioned in RFC 6749 where returning 
> an HTTP error code to the browser would be better or more appropriate than 
> redirecting back to the OAuth client (my opinion on this has gone in circles 
> and I'm honestly not sure anymore). But saying that authorization requests 
> never automatically redirect back to the client's redirect URI is excessive.

Probably. Let’s discuss in detail. 

I think the AS should not automatically redirect the user in case of the 
following error conditions because an attacker could cause this errors via 
request parameters or its configuration:
- unsupported_response_type
- invalid_scope
- unauthorized_client
- invalid_request

kind regards,
Torsten. 

> 
> 
> On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer  > wrote:
> 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)
> * 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.
> * 3.3.1 refers to client.com  in the example. This is a 
> real domain.
> Suggest client.example.com  instead. Same issue 
> in 3.1.2 where
> client.evil.com  is used
> * 3.1.3 (proposed countermeasures) - native clients that use a web
> server with a dynamic port should use dynamic client registration and
> dynamic client management rather than allowing wildcards on the port
> matching of the OAuth server.
> * 3.8.1 says "Therefore this draft recommends that every invalid
> authorization request MUST NOT automatically redirect the user agent
> to the client's redirect URI" -- This is gonna break a lot of stuff
> including other specs! I don't think that's warranted, and I am not
> looking forward to the fallout this could cause.
> 
> Anyway, my $0.02. Hope it helps.
> 
> [1] https://arxiv.org/pdf/1601.01229v2.pdf 
> 
> 
> On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan  > wrote:
> > Hi Torsten,
> >
> > As we briefly spoke about earlier, "3.8.1. Authorization Server as Open
> > Redirector" could 

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

[Brian Campbell]

+1 to what Travis said about 3.8.1

The text in 3.8 about Open Redirection is new in this most recent -05
version of the draft so this is really the first time it's been reviewed. I
believe 3.8.1 goes too far in saying "this draft recommends that every
invalid authorization request MUST NOT automatically redirect the user
agent to the client's redirect URI."

I understand that text was informed by https://tools.ietf.org/html/
draft-ietf-oauth-closing-redirectors-00 but it takes one of the potential
mitigation discussed there in section 3

(the one which happens to contradict RFC 6749) and elevates it to a "MUST".
I don't think something that drastic is warranted. I think there are other
mitigations - like strict redirect_uri matching, referrer-policy headers,
and appending a dummy fragment on error redirects - that can protect
against the more serious redirection issues without -security-topics trying
to introduce normative breaking changes to the behavior from the original
OAuth 2.0 Authorization Framework.

Perhaps there are some error cases not mentioned in RFC 6749 where
returning an HTTP error code to the browser would be better or more
appropriate than redirecting back to the OAuth client (my opinion on this
has gone in circles and I'm honestly not sure anymore). But saying that
authorization requests never automatically redirect back to the client's
redirect URI is excessive.


On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer 
wrote:

> 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)
> * 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.
> * 3.3.1 refers to client.com in the example. This is a real domain.
> Suggest client.example.com instead. Same issue in 3.1.2 where
> client.evil.com is used
> * 3.1.3 (proposed countermeasures) - native clients that use a web
> server with a dynamic port should use dynamic client registration and
> dynamic client management rather than allowing wildcards on the port
> matching of the OAuth server.
> * 3.8.1 says "Therefore this draft recommends that every invalid
> authorization request MUST NOT automatically redirect the user agent
> to the client's redirect URI" -- This is gonna break a lot of stuff
> including other specs! I don't think that's warranted, and I am not
> looking forward to the fallout this could cause.
>
> Anyway, my $0.02. Hope it helps.
>
> [1] https://arxiv.org/pdf/1601.01229v2.pdf
>
> On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan 
> wrote:
> > Hi Torsten,
> >
> > As we briefly spoke about earlier, "3.8.1. Authorization Server as Open
> > Redirector" could I think be made more explicit.
> >
> > Currently it explicitly mentions the invalid_request and invalid_scope
> > errors must not redirect back to the client's registered redirect uri.
> >
> > https://tools.ietf.org/html/rfc6749#section-4.1.2.1 defines several more
> > potential errors that appear to fall into the same category. I
> understand to
> > block the attack fully we need 'must not redirect's for all the kinds of
> > error that could cause an automatic redirect back to the client's
> registered
> > redirect uri without any user interaction - 'unauthorized_client' and
> > 'unsupported_response_type' seem to fall into that category.
> 'server_error'
> > also seems dodgy (I would wager that on some servers that are known ways
> to
> > provoke server errors), and I would have doubts about
> > 'temporarily_unavailable' too.
> >
> > Thanks
> >
> > Joseph
> >
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*

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

[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)
* 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.
* 3.3.1 refers to client.com in the example. This is a real domain.
Suggest client.example.com instead. Same issue in 3.1.2 where
client.evil.com is used
* 3.1.3 (proposed countermeasures) - native clients that use a web
server with a dynamic port should use dynamic client registration and
dynamic client management rather than allowing wildcards on the port
matching of the OAuth server.
* 3.8.1 says "Therefore this draft recommends that every invalid
authorization request MUST NOT automatically redirect the user agent
to the client's redirect URI" -- This is gonna break a lot of stuff
including other specs! I don't think that's warranted, and I am not
looking forward to the fallout this could cause.

Anyway, my $0.02. Hope it helps.

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

On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan  wrote:
> Hi Torsten,
>
> As we briefly spoke about earlier, "3.8.1. Authorization Server as Open
> Redirector" could I think be made more explicit.
>
> Currently it explicitly mentions the invalid_request and invalid_scope
> errors must not redirect back to the client's registered redirect uri.
>
> https://tools.ietf.org/html/rfc6749#section-4.1.2.1 defines several more
> potential errors that appear to fall into the same category. I understand to
> block the attack fully we need 'must not redirect's for all the kinds of
> error that could cause an automatic redirect back to the client's registered
> redirect uri without any user interaction - 'unauthorized_client' and
> 'unsupported_response_type' seem to fall into that category. 'server_error'
> also seems dodgy (I would wager that on some servers that are known ways to
> provoke server errors), and I would have doubts about
> 'temporarily_unavailable' too.
>
> Thanks
>
> Joseph
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Joseph Heenan]

Hi Torsten,

As we briefly spoke about earlier, "3.8.1. Authorization Server as Open 
Redirector" could I think be made more explicit.

Currently it explicitly mentions the invalid_request and invalid_scope errors 
must not redirect back to the client's registered redirect uri.

https://tools.ietf.org/html/rfc6749#section-4.1.2.1 defines several more 
potential errors that appear to fall into the same category. I understand to 
block the attack fully we need 'must not redirect's for all the kinds of error 
that could cause an automatic redirect back to the client's registered redirect 
uri without any user interaction - 'unauthorized_client' and 
'unsupported_response_type' seem to fall into that category. 'server_error' 
also seems dodgy (I would wager that on some servers that are known ways to 
provoke server errors), and I would have doubts about 'temporarily_unavailable' 
too.

Thanks

Joseph

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

Hi all,

The new revision contains the following changes: 

Completed sections on code leakage via referrer header, attacks in browser, 
mix-up, and CSRF
Reworked Code Injection Section
Added reference to OpenID Connect spec
removed refresh token leakage as respective considerations have been given in 
section 10.4 of RFC 6749
first version on open redirection
incorporated Christian Mainka's review feedback

We think the document now covers recommendation on all (currently) relevant 
threats and is useful for all OAuth implementors and should be moved forward. 

kind regards,
Torsten. 

> Am 18.03.2018 um 20:12 schrieb internet-dra...@ietf.org:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
> 
>Title   : OAuth 2.0 Security Best Current Practice
>Authors : Torsten Lodderstedt
>  John Bradley
>  Andrey Labunets
>   Filename: draft-ietf-oauth-security-topics-05.txt
>   Pages   : 27
>   Date: 2018-03-18
> 
> Abstract:
>   This document describes best current security practices for OAuth
>   2.0..  It updates and extends the OAuth 2.0 Security Threat Model to
>   incorporate practical experiences gathered since OAuth 2.0 was
>   published and cover new threats relevant due to the broader
>   application of OAuth 2.0.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-05
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-05
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : OAuth 2.0 Security Best Current Practice
Authors : Torsten Lodderstedt
  John Bradley
  Andrey Labunets
Filename: draft-ietf-oauth-security-topics-05.txt
Pages   : 27
Date: 2018-03-18

Abstract:
   This document describes best current security practices for OAuth
   2.0..  It updates and extends the OAuth 2.0 Security Threat Model to
   incorporate practical experiences gathered since OAuth 2.0 was
   published and cover new threats relevant due to the broader
   application of OAuth 2.0.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-05
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth