Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-01.txt

From: [email-masked]
Date: Wed, 26 Oct 2011 12:11:33 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF.

	Title           : OAuth 2.0 Threat Model and Security Considerations
	Author(s)       : Torsten Lodderstedt
                          Mark McGloin
                          Phil Hunt
	Filename        : draft-ietf-oauth-v2-threatmodel-01.txt
	Pages           : 64
	Date            : 2011-10-26

   This document gives security considerations based on a comprehensive
   threat model for the OAuth 2.0 Protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-01.txt

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 26 Oct 2011 21:15:27 +0200

Hi all,

the new version of the security document is mostly dedicated to the 
alignment with the core draft -22.

  * Alignment of terminology with core draft 22 (private/public client,
    redirect URI validation policy, replaced definition of the client
    categories by reference to respective core section)
  * Synchronisation with the core's security consideration section
    (UPDATE 10.12 CSRF, NEW 10.14/15)
  * Added Resource Owner Impersonation
  * Improved section 5
  * Renamed Refresh Token Replacement to Refresh Token Rotation

Thanks to all people involved!

regards,
Torsten.

Am 26.10.2011 21:11, schrieb [email-masked]:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Oct 2011 13:17:58 -0700

First, I think that this threat should be elevated to something more than
a threat because it is a fundamental assumption of the protocol that the
browser is trustworthy. I have heard far too many people on this list say
that that's silly because it is "obvious" but it is not obvious to the
uninitiated, who are the remaining 7*10^9-100 people in this world.

Second, I think it's worth explicitly pointing out that this PERTAINS TO APPS
too. The world has changed significantly since OAUTH was conceived, and
native phone, etc apps continue to grow explosively after a long, long
decline leading up to OAUTH's birth. I would venture to say that a sizable
if not majority of uses of OAUTH will be in app settings.

A few inline comments:

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

[mat] I think it's also worth mentioning either here, or in another
threat that there is a further social engineering misuse/attack where an
app offers/demands to keep your credentials so that you don't have to go
through the authorization rigmarole. Users are already conditioned to
give their credentials up to do things -- just this morning I noticed facebook
asking for my email password which they promise with sugar on top to not
store. It might be worth mentioning that things like CAPTCHA could be
deployed to defend against that sort of attack/misuse.

    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:

    o  Client developers and end-user can be educated to trust an
       external System-Browser only.

[mat] I assume that this is in here just for the amusement factor because
it is not a credible countermeasure.

    o  Client applications could be validated prior publication in a
       application market.

[mat] How would this be done in practice?

    o  Client developers should not collect authentication information
       directly from users and should instead use redirects to and back
       from a trusted external system-browser.

[mat] How would the resource/authentication server enforce such a thing?

The main problem here is that the countermeasures -- if they are practical at all --
are deep and complex problems unto themselves. To just handwave them away does
no justice to the seriousness of the threat. I realize that this strays more
into BCP land but there isn't any B-C-P, and I'm not terribly convinced
there ever will be. In that respect, I think this threat and its potential
countermeasures need to be discussed in much more detail. If there is anything
about OAUTH that will cause it to be junked, it's this threat.

Mike