Re: [OAUTH-WG] draft-ietf-oauth-v2-threatmodel

Barry, I think your text is sufficient.

Hannes, I agree with your point about taking this up outside the OAUTH
WG because this is a broader issue.

Phil, I've reviewed things again and I think Michael is simply in the
rough here, but if Michael thinks that Barry's text is insufficient then
he is free to raise this issue during IETF Last Call or to follow the
appeal procedures defined in RFC 2026.

Peter

On 5/2/12 11:36 AM, Phil Hunt wrote:
> I think you hit the nail on the head. 
> 
> My feeling is that threats not directly related to OAuth obfuscate the key issues we are trying to alert implementers and deployers to. 
> 
> I think Barry made a good proposal but Michael still feels Barry's text has not addressed the issue. 
> 
> I think you are right to escalate the issue for guidance. 
> 
> Phil
> 
> On 2012-05-02, at 9:02, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
> 
>> Hi all, 
>>
>> I looked at the feedback for the draft-ietf-oauth-v2-threatmodel and I want to share my thoughts with you (as a WG co-chair).
>>
>> I believe there are three questions that need to be answered:
>>
>> 1) Is malicious code a problem? 
>>
>> I believe most people would agree that malicious code is indeed a problem for Internet security. 
>>
>> 2) Are IETF working groups required to address this extended Internet threat model? 
>>
>> RFC 3552 provides guidance for protocol developers writing security considerations. It also defines terminology and a threat model. 
>> The model, however, does not consider malicious code as a threat. 
>>
>> Malicious code is a problem for any IETF protocol, not just for OAuth. This requires a broader IETF discussion.  
>>
>> If there is the believe that IETF groups should (a) describe threats that result from malicious code and (b) develop solutions to deal with it then the IAB  should facilitate such a discussion. I will discuss this topic within the IAB. 
>>
>> Despite the lack of available guidance in RFC 3552 draft-ietf-oauth-v2-threatmodel talks about this threat. 
>>
>> 3) What can we do to highlight the threat in our document? 
>>
>> Barry proposed additional text (see below) that highlights the challenges. 
>>
>> This issue as resolved. Let's move forward. 
>>
>> Ciao
>> Hannes
>>
>> PS: Here is Barry's proposed tet
>>
>> -----------------------------------------------------------------
>> 5.5.  A Word on User Interaction and User-Installed Apps
>>
>> OAuth, as a security protocol, is distinctive in that its flow usually
>> involves significant user interaction, making the end user a part of
>> the security model.  This creates some important difficulties in
>> defending against some of the threats discussed above.  Some of these
>> points have already been made, but it's worth repeating and
>> highlighting them here.
>>
>> * End users must understand what they are being asked to approve (see
>> Section 5.2.4.2).  Users often do not have the expertise to understand
>> the ramifications of saying "yes" to an authorization request. and are
>> likely not to be able to see subtle differences in wording of
>> requests.  Malicious software can confuse the user, tricking the user
>> into approving almost anything.
>>
>> * End-user devices are prone to software compromise.  This has been a
>> long-standing problem, with frequent attacks on web browsers and other
>> parts of the user's system.  But with increasing popularity of
>> user-installed "apps", the threat posed by compromised or malicious
>> end-user software is very strong, and is one that is very difficult to
>> mitigate.
>>
>> * Be aware that users will demand to install and run such apps, and
>> that compromised or malicious ones can steal credentials at many
>> points in the data flow.  They can intercept the very user login
>> credentials that OAuth is designed to protect.  They can request
>> authorization far beyond what they have led the user to understand and
>> approve.  They can automate a response on behalf of the user, hiding
>> the whole process.  No solution is offered here, because none is
>> known; this remains in the space between better security and better
>> usability.
>>
>> * Addressing these issues by restricting the use of user-installed
>> software may be practical in some limited environments, and can be
>> used as a countermeasure in those cases.  Such restrictions are not
>> practical in the general case, and mechanisms for after-the-fact
>> recovery should be in place.
>> -----------------------------------------------------------------
>> _______________________________________________
>> 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