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

The wording you propose is unacceptable. It is a rehash of the
same misleading nonsense that is in there now. In particular #1 and
#3 that say in effect "bad guys really should be good" are silly
and unhelpful. #2 has possibilities, but in its current form gives
absolutely no guidance as to what might be done; mine at least
explicitly said that the status quo is unacceptable.

I also completely object to the notion that the authentication
service has no part in protecting itself. It has complete control
over who it allows to register as a client, and as written Eran's
text contradicts #2's possibility of mitigation -- even if William
thinks it's hopeless (as I read him). If William is right the
appropriate guidance is that authentication services MUST NOT
enroll clients that use untrusted browsers. Putting this on the
end users shoulders is useless and should be a reason that the
IESG should just reject the protocol.

I also object to not *explicitly* pointing out that native apps
mean apps from App stores, markets,  etc. and the general problem
that users cannot know a priori whether an app is malicious or not. I
don't  see why this is even controversial -- unless your aim is to hide
that uncomfortable fact.

This is a threat document, not a marketing puff piece. Downplaying
threats does nobody any good. Except bad guys.

Mike

On 01/05/2012 06:01 AM, Mark Mcgloin wrote:
> Having read the suggested wording from Eran, William and Michael, I think
> Eran's description is the most succinct and relevant: "OAuth does not
> provide any protection against malicious applications and that the end user
> is solely responsible for the trustworthiness of any native application
> installed"
> @William: The threat has been described in the context of installing
> malicious apps so the wording above it more applicable
> @Michael: It has been repeated many times that we should only address
> security issues specific to Oauth, and Oauth does not make things worse if
> a user installs a malicious client. If you want to continue the discussion,
> please email me directly and we can revert to this forum if you still think
> your point is relevant
>
> Section 4.1.4 of the threat model will be updated as below. Remember the
> threat model is just offering advice on best practices.
>
>
> Threat: End-user credentials phished using compromised or  embedded browser
>
> A malicious application could attempt to phish end-user passwords by
> misusing an embedded browser in the end-user authorization process, or by
> presenting its own user-interface instead of allowing trusted system
> browser to render the authorization user interface.  By doing so, the usual
> visual trust mechanisms may be bypassed (e.g.  TLS confirmation, web site
> mechanisms).  By using an embedded or internal client application user
> interface, the client application has access to additional information it
> should not have access to (e.g. uid/password).
>
> Impact: If the client application or the communication is compromised, the
> user would not be aware and all information in the authorization exchange
> could be captured such as username and password.
>
> 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.
>
> Regards
> Mark
>
> oauth-bounces@ietf.org wrote on 05/01/2012 00:05:04:
>
>> From:
>>
>> Eran Hammer-Lahav<eran@hueniverse.com>
>>
>> To:
>>
>> Michael Thomas<mike@mtcc.com>, Torsten Lodderstedt
> <torsten@lodderstedt.net>
>> Cc:
>>
>> Barry Leiba<barryleiba@computer.org>, oauth WG<oauth@ietf.org>
>>
>> Date:
>>
>> 05/01/2012 00:05
>>
>> Subject:
>>
>> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec
> 2011
>> Sent by:
>>
>> oauth-bounces@ietf.org
>>
>>
>>
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>>> Of Michael Thomas
>>> Sent: Wednesday, January 04, 2012 3:40 PM
>>> My concern is that putting on a veneer of "security" will lull people
> into
>>> thinking "Oh, it's safe to enter my credentials here because this is
> really
>>> twitterbook, not evilapp!". When I had to ask them directly to put
> their
>>> twitterbook credentials into my app, there at least wasn't any
>> confusion that
>>> I had access to them.
>> This is ridiculous (e.g. the fact we are still discussing this).
>>
>> First, end users know nothing about security or OAuth. Second, evil
>> apps can create this veneer of security by faking a redirection flow
>> with or without OAuth. Suggesting that OAuth (which is a de-facto
>> web pattern for over a decade) makes anything worse is patently false.
>>
>> The only thing we can possibly add to the threat model document is
>> to mention that "OAuth does not provide any protection against
>> malicious applications and that the end user is solely responsible
>> for the trustworthiness of any native application installed". That
>> is accurate (and completely obvious to the target audience of this
>> document). It is not very helpful but if it will make you feel
>> better (since no one else here seems to share your concerns), I have
>> no objection to such one line added.
>>
>> And again, to highlight the absurdity of your security claim, it is
>> equally important to warn developers in earthquake-prone countries
>> to put enough distance between the Approve and Deny buttons so that
>> the user will not accidentally hit Approve during a tremor.
>>
>> EHL
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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