Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

[Mark Mcgloin <[e-mail]>]

Hi William

Sorry for slow response - comments inline below.

I really would like to close out on this set of countermeasures. I think
the differing opinions are subjective as this point and we all need to bear
in mind that the threat model is intended to advise on best practices and
not all of those will be applicable to all developers


Regards
Mark

William Mills <[e-mail]> wrote on 05/01/2012 16:29:02:

>
> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec
2011
>
> There's going to be a whole class of apps tat will be in violation
> of "Client applications SHOULD avoid directly asking users for the
> their credentials.".  We know that already, because the password
> grant exists and we have real use cases for it.  I think we should
> strikes that sentence and move that idea to #3 (soon to be #2)
>

The resource owner password credentials is intended for clients with trust
relationships with the resource server, mainly intranet apps. For all other
cases, client apps should use Oauth as it was intended, i.e. to avoid the
anti-pattern of asking users for credentials.

> I think point 2 should be struck, it's pointless.  What would matter
> here is whether the user can check that the app has been validated,
> and we're not defining that.

Agree that this countermeasure applies whether the app uses oauth or not
and because this threat is getting side tracked into advising on non-oauth
specific threats/countermeasures (i.e. user downloads malicious client)
It is just a suggestion, i.e. 'could', and may not apply to all
marketplaces. If the market place, such as apple, says the app has been
validated, then the user knows. You state elsewhere:

> "The current model is that apps are not validated first, they are pulled
if found to be hostile.   You're making a > recommendation here about how
an app marketplace should behave to be trustworthy, and I think that's
beyond the
> scope of users and client developers here.  We're already saying users
should only install trustworthy applications."

Again, it is just a suggestion. It may apply to some marketplaces more than
others, e.g. where the clients are accessing resources also under control
of the marketplace. Recommendations are aimed at resource server and
authorization server developers too.


>
> I would change #3 (now #2?) to:
>
>    3. It is RECOMMENDED that client applications use the web based
> authentication
>    flow, this takes advantage of a more trusted system component,
> e.g. the system
>    browser, and provides a consistent authentication experience for the
user
>    across applications.  The user is then always presenting their
> credential to a
>    known and trusted web page.  Collection and use of primary
> authentication from
>    the user by client applications is NOT RECOMMENDED.
>

I don't agree that your wording clarifies anything



> *From:* Mark Mcgloin <[e-mail]>

Countermeasures:

1. The OAuth flow is designed so that client applications never need to
know user passwords. Client applications SHOULD avoid directly asking users
for the their credentials. In addition, end users could be educated about
phishing attacks and best practices, such as only accessing trusted
clients, as OAuth does not provide any protection against malicious
applications and the end user is solely responsible for the trustworthiness
of any native application installed

2. Client applications could be validated prior to publication in an
application market for users to access. That validation is out of scope for
OAuth but could include validating that the client application handles user
authentication in an appropriate way

3. Client developers should not write client applications that collect
authentication information directly from users and should instead delegate
this task to a trusted system component, e.g. the system-browser.