Note that the security considerations doc was replaced with the Threat Models WG draft, http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00
While that paragraph is not in the Threat Model document, there are numerous threats discussed regarding malicious clients and what the recommended counter measures are. I believe these threats go well beyond Michael's original concerns. I invite Michael to take a look at the Threat Model spec and suggest whether he would either prefer to describe a new threat (and propose text), or whether new introductory text is warranted such as the assumption from the security considerations draft below. Let us know if you have any specific comments on the Threat Model doc, in particular referencing sections/paragraphs which may need refinement to address the concerns. The easiest way to do this, as always, is to suggest edits and proposed replacement text to this mature document. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-09-12, at 10:58 AM, Thomas Hardjono wrote: >>> Basically, in the protocol document's introduction I think it should >>> be clearly explained that the UA functionality is expected to be >>> "trusted", ie not be under the control of a potential attacker. I >>> think that for the uninitiated that is anything but obvious. There has >>> been a sea-change since 2007 making this an important point. Had that >>> been in the introduction, we would not be having this conversation. >>> >>> Mike > > > Mike, > > I have found that the Security Considerations doc helps a lot in > understanding the expected deployment conditions of OAUTH (see > draft-lodderstedt-oauth-securityconsiderations-02.txt). > > For example, Section 2.2 (about Malicious Client) goes a long way towards > answering your concerns: > > Assumption: It is not the task of the authorization server to protect > the end-user's device from malicious software. This is the > responsibility of the platform running on the particular device > probably in cooperation with other components of the respective > ecosystem (e.g. an application management infrastructure). The sole > responsibility of the authorization server is to control access to > the end-user's resources living in resource servers and to prevent > unauthorized access to them. Based on this assumption, the following > countermeasures are recommended. > > Hope this helps. > > /thomas/ > > __________________________________________ > >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of David Recordon >> Sent: Saturday, September 10, 2011 1:29 PM >> To: Michael Thomas >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] problem statement >> >> Hey Mike, I think this has been said a few times by Eran and Peter but >> you really need to propose actual sentences that you want to see >> included in the specification at this point. Saying "I think it should >> be clearly explained" isn't actionable text. >> >> That said, I strongly don't believe this is an issue specific to OAuth. >> >> --David >> >> >> On Wed, Sep 7, 2011 at 6:03 PM, Michael Thomas <m...@mtcc.com> wrote: >>> On 09/07/2011 05:19 PM, Ben Niven-Jenkins wrote: >>>> >>>> Your original e-mail that started this thread was not targeted at a >>>> specific document and my interpretation is that some of the >> hostility >>>> you have experienced is due to a frustration that your request is >>>> seen as a potential obstacle to getting the protocol specification >>>> out the door because the issue you want to discuss is not directly >>>> related to how a developer might implement the protocol. >>>> >>> >>> I had no idea where in the ietf process the protocol document is. I'm >>> still not sure whether it's been through wg last call, ietf last >> call, etc. >>> >>>> If I may be so bold, could I suggest that you propose some text that >>>> articulates the issue that you would like to see documented and then >>>> the group can assess that text on its merits and try to reach >>>> consensus on which document, if any, it is best placed to reside >> within. >>>> >>> >>> Basically, in the protocol document's introduction I think it should >>> be clearly explained that the UA functionality is expected to be >>> "trusted", ie not be under the control of a potential attacker. I >>> think that for the uninitiated that is anything but obvious. There >> has >>> been a sea-change since 2007 making this an important point. Had that >>> been in the introduction, we would not be having this conversation. >>> >>> Mike >>> _______________________________________________ >>> 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 > _______________________________________________ > 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
