On 01/04/2012 03:42 AM, Mark Mcgloin wrote:
Hi Michael
Can you clearly word the threat for which this countermeasure (or lack of)
applies
I've already done that in my original last call comments. Given that you
rejected my comments out of hand, it doesn't appear that it was for
lack of clarity.
Mike, rather put off by the attitude of the editors in this wg
thanks
Mark
Michael Thomas<m...@mtcc.com> wrote on 03/01/2012 23:52:54:
From:
Michael Thomas<m...@mtcc.com>
To:
Phillip Hunt<phil.h...@oracle.com>
Cc:
Mark Mcgloin/Ireland/IBM@IBMIE, Barry Leiba
<barryle...@computer.org>, oauth WG<oauth@ietf.org>, "oauth-
boun...@ietf.org"<oauth-boun...@ietf.org>
Date:
03/01/2012 23:53
Subject:
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec
2011
On 01/03/2012 03:46 PM, Phillip Hunt wrote:
-1. I think you should be suggesting alternative text at this
stage. We all have same responsibilities here.
My "responsibility", such as it is, is to bring up that the document's
threat mitigations suggested don't work. I am only a recent and
reluctant participant, versus the principals of this working group
who have been around for many years.
But if you insist, here's my concise suggestion to that points that I
raised objections to:
"No known mitigation exists."
Mike
Phil
On 2012-01-03, at 15:18, Michael Thomas<m...@mtcc.com> wrote:
Barry -- It's now been two weeks and I haven't heard anything to
the objections I raised. It is not my responsibility to come up with
mitigation that works, it's the working group's. If there is no
reasonable
mitigation it should just say that.
Mike
On 12/16/2011 06:55 AM, Michael Thomas wrote:
On 12/16/2011 03:02 AM, Mark Mcgloin wrote:
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.
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
Regards
Mark
oauth-boun...@ietf.org wrote on 15/12/2011 18:15:45:
From:
Michael Thomas<m...@mtcc.com>
To:
Phil Hunt<phil.h...@oracle.com>
Cc:
Barry Leiba<barryle...@computer.org>, oauth WG<oauth@ietf.org>
Date:
15/12/2011 18:16
Subject:
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9
Dec
2011
Sent by:
oauth-boun...@ietf.org
On 12/15/2011 09:54 AM, Phil Hunt wrote:
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]
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.
[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]
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 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.
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]
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]
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
_______________________________________________
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
