Peter Saint-Andre wrote:
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.
The roots of the problem are certainly larger, but the particulars about the way
that it interacts with oauth's security model are what I found troublesome. As
I've
said before, oauth was conceived before the widespread deployment of apps where
the system browser is mostly trustable. The way it's getting widespread adoption
now is back in an app environment so all of the browser trustability assumptions
flew out the window.
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.
I only asked to add one bullet that said that the auth server can and should
have a part by being less promiscuous about enrollment and more proactive about
revocation. I didn't hear anything one way or other about that.
Mike
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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
