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

[Hannes Tschofenig <[e-mail]>]

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