Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

From: Barry Leiba <[email-masked]>
Date: Sat, 3 Dec 2011 17:05:15 -0500

> Working group last call begins today on the threat model document:
> http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01
>
> Please review this version and post last call comments by 9 December.

Here's a reminder that we have about a week left for the working group
last call on this, and I haven't seen any comments since WGLC started.
 That's OK, if it's because there are no comments.  If you have
something to say, say it now, please.  If the document really is ready
to go, then that's great.

Barry, chairing

---

From: Barry Leiba <[email-masked]>
Date: Thu, 15 Dec 2011 09:30:02 -0500

> Please review this version and post last call comments by 9 December.

Sorry, folks: I got a little behind here.

Working-group last call is now over.  There were no comments in
response to this thread, so it looks like we're mostly done here.
Mike Thomas pointed out to me that his message here:

   http://www.ietf.org/mail-archive/web/oauth/current/msg07780.html

...was in reference to this document -- that might not have been clear
because of the change in subject line.  Torsten, et al, consider that
message to be your only working-group last call comment, and handle it
accordingly.  When that's worked out and there's another version, we
should be ready to send this up to the IESG.

Barry, as chair

---

From: Mark Mcgloin <[email-masked]>
Date: Thu, 15 Dec 2011 17:33:28 +0000

Thanks Barry - I just responded to that thread. We will not be making any
changes to the threat model based on that comment

Regards
Mark

[email-masked] wrote on 15/12/2011 14:30:02:

> From:
>
> Barry Leiba <[email-masked]>
>
> To:
>
> oauth WG <[email-masked]>
>
> Date:
>
> 15/12/2011 14:30
>
> Subject:
>
> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec
2011
> Sent by:
> [email-masked]
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: André DeMarre <[email-masked]>
Date: Thu, 15 Dec 2011 09:35:30 -0800

This hasn't been addressed:
http://www.ietf.org/mail-archive/web/oauth/current/msg07867.html
Perhaps no one thinks it is a problem?

There are several grammatical nits that should be fixed. I've had all
the best intentions of reporting those last week but simply have not
yet had the time.

Regards,
Andre DeMarre

---

From: Phil Hunt <[email-masked]>
Date: Thu, 15 Dec 2011 09:54:44 -0800

Note: one change recommended below...

With regards to 4.1.4…
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.

[Phil] I don't think we need to really add much here. We could write whole essays on this topic and likely will. 

I think the point is simply to educate the client developer that there is no need for a client application to ever have access to a raw uid/password (or any other user credential).  

[/Phi]

[snip]

   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.

[Phil] I agree, Firefox recently demonstrated how poorly users recognize the security signals in the browser by dropping the "lock" icon without announcement. When I found out, I had already been using it for some time and hadn't noticed.  This counter measure should be changed to:

o The OAuth flow is designed so that client applications never need to know user passwords. Where possible Client applications SHOULD avoid directly asking for user credentials during an authorization flow.
[/Phil]

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

[mat] How would this be done in practice?
[Phil] I think this needs to change to:

o Client applications could be validated for acceptable practices by the Resource Site provider prior to issuing production Client Credentials.

[/Phil]
   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?

[Phil] This is a best practice for the client developer. [Phil]

[snip]

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Thu, 15 Dec 2011 10:15:45 -0800

> I think the point is simply to educate the client developer that there is no need for a client application to ever have access to a raw uid/password (or any other user credential).

Remember: I came here not understanding whether this threat was real or not.
A threat document that can't be bothered to elaborate on one of the biggest
existential  threats to the protocol is worthless. The way it is worded 
now does
not make it crystal clear that, yes, this means UIWebView's in iPhone 
apps, etc too.
It should because it needs to scream: THIS THREAT APPLIES TO YOU, AUTH 
SERVER.

> o The OAuth flow is designed so that client applications never need to know user passwords. Where possible Client applications SHOULD avoid directly asking for user credentials during an authorizat…

The basic problem here is that the client app is not trusted. So if it's 
a bad
actor this admonition will be ignored. If it's a good actor, there 
wasn't a threat
in first place. So the mitigation completely misses the mark.

> o Client applications could be validated for acceptable practices by the Resource Site provider prior to issuing production Client Credentials.

When, exactly, can we expect to see this in the field? Neither Twitter 
or Facebook
do this. And even if they were so inclined, the draft provides exactly 
zero guidance
as to what exactly that "validated" might mean in practice. The way I 
read this is:
"we don't know how to mitigate this".
> [Phil] This is a best practice for the client developer. [Phil]

I don't even know what that means in the context of embedded apps.
Has anybody even tried this? At the very least, an example flow might
be useful for the uninitiated client developer.

Mike

---

From: Mark Mcgloin <[email-masked]>
Date: Fri, 16 Dec 2011 11:02:31 +0000

Michael,

I will review the comments from Phil where he suggests some changes in
section 4.1.4 of the threat model

I am unclear exactly what you are proposing. If you want to propose a
clearly worded revamp of that section in the next couple of days, I am
willing to review and accept legitimate changes. Clearly worded means
concise, technically accurate and devoid of alarmist phrases and words used
out of context, such as existential. Can I suggest you review with a
colleague before posting here.

Regards
Mark

[email-masked] wrote on 15/12/2011 18:15:45:

> From:
>
> Michael Thomas <[email-masked]>
>
> To:
>
> Phil Hunt <[email-masked]>
>
> Cc:
>
> Barry Leiba <[email-masked]>, oauth WG <[email-masked]>
>
> Date:
>
> 15/12/2011 18:16
>
> Subject:
>
2011
> > [Phil] I don't think we need to really add much here. We could
> write whole essays on this topic and likely will.
> >
> > I think the point is simply to educate the client developer that
> there is no need for a client application to ever have access to a
> raw uid/password (or any other user credential).
> >
> > [/Phi]
> >
>
> > [Phil] I agree, Firefox recently demonstrated how poorly users
> recognize the security signals in the browser by dropping the "lock"
> icon without announcement. When I found out, I had already been
> using it for some time and hadn't noticed.  This counter measure
> should be changed to:
> >
> > o The OAuth flow is designed so that client applications never
> need to know user passwords. Where possible Client applications
> SHOULD avoid directly asking for user credentials during an
> authorization flow.
> > [/Phil]
> >
>
> > o Client applications could be validated for acceptable practices
> by the Resource Site provider prior to issuing production Client
Credentials.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 16 Dec 2011 06:55:25 -0800

> colleague before posting here.

Barry -- I have gone through this section and made comments
and was blown off seemingly without reading them at all, and
now I'm being told to come up with text for which I can be blown
off again: "Can I suggest you review..."

The fact of the matter is that my comments say that the
threats are understated and mitigations that are proposed do not
work. It's not my job alone to fix this. It's the working group's.
In fact if I were to propose text, it would be along the lines of
"can't be mitigated" because I do not know how to fix them. If
nobody else can come up with a better mitigation, then that
*is* what should be there, not some hand waving nonsense that
doesn't work.

Mike, "instruct users..." feh

>> Michael Thomas<[email-masked]>
>>
>> To:
>>
>> Phil Hunt<[email-masked]>
>>
>> Cc:
>>
>> Barry Leiba<[email-masked]>, oauth WG<[email-masked]>
>>
>> Date:
>>
>> 15/12/2011 18:16
>>
>> Subject:
>>
>>>      A malicious application could attempt to phish end-user passwords
>>>        
> by
>    
>>>      system browser to render the authorization user interface.  By
>>>        
> doing
>    
>>>      confirmation, web site mechanisms).  By using an embedded or
>>>        
> internal
>    
>>>      client application user interface, the client application has
>>>        
> access
>    
>>> 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
>    
>>> 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
>    
>> Remember: I came here not understanding whether this threat was real or
>>      
> not.
>    
>> A threat document that can't be bothered to elaborate on one of the
>>      
> biggest
>    
>>> [mat] I assume that this is in here just for the amusement factor
>>>        
> because
>    
>>> [mat] How would the resource/authentication server enforce such a
>>>        
> thing?
>