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
