Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel

From: Michael Thomas <[email-masked]>
Date: Mon, 23 Apr 2012 09:09:11 -0700

[I accidentally sent just to Barry my take on his addition which I think is fine
except for one thing addition...]

Barry Leiba wrote:
> You sent it just to me.  I think it's a reasonable addition, so please
> send it to the distribution (which at the moment does not include the
> OAuth list, just the
> <[email-masked]> alias), and
> suggest specific text to add.  I presume it would go in an new bullet
> just before the last.

The thing I think is missing here is that the Authorization Server has a
stake in mitigating threats, and actually has a quite potent one: it can
be selective with whom it enrolls, and can revoke bad actors.

So let me try a bullet:

o While end users are mostly incapable of properly vetting applications they
   load onto their devices, those who deploy Authorization Servers have tools at
   their disposal to mitigate malicious Clients. Namely, in order to become a threat
   at all, a Client must first become a Client. A well run Authorization Server MAY
   require a curation process when enrolling Clients, and SHOULD have processes to
   revoke bad actors after enrollment.

Mike

---

From: Mark Mcgloin <[email-masked]>
Date: Tue, 24 Apr 2012 09:17:24 +0100

Hi Thomas

Your additional text is already covered in a countermeasure for section
4.1.4.  In addition, section 4.1.4.4 states the assumption that the auth
server can't protect against a user installing a malicious client

Regards
Mark

[email-masked] wrote on 23/04/2012 17:09:11:

> From:
>
> Michael Thomas <[email-masked]>
>
> To:
>
> Barry Leiba <[email-masked]>, "[email-masked]" <[email-masked]>
>
> Date:
>
> 23/04/2012 17:09
>
> Subject:
>
> Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
>
> Sent by:
>
> [email-masked]
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 24 Apr 2012 06:24:47 -0700

> server can't protect against a user installing a malicious client

The more I read this draft, the more borked I think its base assumptions
are. The client *is* one of the main threats. Full stop. A threat document
should not be asking the adversary to play nice. Yet, 4.1.4 bullets 1 and
3 are doing exactly that again. If those are countermeasures, then so is
visualizing world peace.

As for bullet two, it doesn't mention revocation, and I prefer Barry's
section generally. I can't find a section 4.1.4.4

Mike

---

From: Mark Mcgloin <[email-masked]>
Date: Tue, 24 Apr 2012 15:10:20 +0100

> 3 are doing exactly that again. If those are countermeasures, then so is

Irrelevant - we are only discussing bullet 2

> section generally. I can't find a section 4.1.4.4

Sorry, section 4.4.1.4, not section 4.1.4.4. It is implicit that bad
clients will be revoked - for brevity sake, we don't need to spell that
out.

---

From: Phil Hunt <[email-masked]>
Date: Tue, 24 Apr 2012 07:58:53 -0700

Are we at this stage re-opening the entire document? I thought we were responding only to specific shepherd text edits. 

Phil

---

From: Michael Thomas <[email-masked]>
Date: Tue, 24 Apr 2012 08:05:44 -0700

On 04/24/2012 07:10 AM, Mark Mcgloin wrote:
> Michael Thomas<[email-masked]>  wrote on 24/04/2012 14:24:47:
>
>

Barry: to the extent that your shepherd's review was to take into
account my last call comments which went unanswered, this was
part of my last call comments and obviously haven't been accounted
for. Removing useless countermeasures from this document was part
of what I asked for and I still ask for.

I remain very disturbed by the prickliness of adding text that point
out the shortcomings of oauth in embedded/app environments or
removing supposed mitigations that are not plausible.  This is a
threat document, not a sales booster pamphlet.

Mike

---

From: Eran Hammer <[email-masked]>
Date: Tue, 24 Apr 2012 16:20:46 +0000

We've been kicking this can of silliness for months now because one person refuses to move on even in the face of otherwise unanimous consensus from the group.

Chairs - Please take this ridiculous and never ending thread off list and resolve it once and for all.

EH

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Phil Hunt
> Sent: Tuesday, April 24, 2012 7:59 AM
> To: Michael Thomas
> Cc: Barry Leiba; [email-masked]; [email-masked]
> Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-
> threatmodel
> 
> Are we at this stage re-opening the entire document? I thought we were
> responding only to specific shepherd text edits.
> 
> Phil
> 
> >> Your additional text is already covered in a countermeasure for
> >> section 4.1.4.  In addition, section 4.1.4.4 states the assumption
> >> that the auth server can't protect against a user installing a
> >> malicious client
> >>
> >
> > The more I read this draft, the more borked I think its base
> > assumptions are. The client *is* one of the main threats. Full stop. A
> > threat document should not be asking the adversary to play nice. Yet,
> > 4.1.4 bullets 1 and
> > 3 are doing exactly that again. If those are countermeasures, then so
> > is visualizing world peace.
> >

---

From: Michael Thomas <[email-masked]>
Date: Tue, 24 Apr 2012 09:27:51 -0700

I am sorry that you feel the need to resort to an ad hominem attack,
but my last call comment were not addressed in last call, and this
is the process Barry came up with dealing with them.

And it was hardly "unanimous" and you have no say in determining
consensus so stop presuming to do so.

Mike

On 04/24/2012 09:20 AM, Eran Hammer wrote:
>> On 2012-04-24, at 6:24, Michael Thomas<[email-masked]>  wrote:
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 24 Apr 2012 10:53:04 -0600

On 4/24/12 10:20 AM, Eran Hammer wrote:
> We've been kicking this can of silliness for months now because
> one person refuses to move on even in the face of otherwise
> unanimous consensus from the group.

Hi Eran,

Cans of silliness aside, I'd like to make a brief meta point: we don't
vote. So consensus is not a matter of counting noses, it is a matter
of addressing valid technical issues that people raise. I shall
re-read this thread and related earlier threads to see if the issues
raised by Michael Thomas have been answered, but if there are open
issues then we need to address them. Now, it might be that he hasn't
accepted the answers provided, in which case he might be "in the
rough". That's the chairs' call. But it's not necessarily a simple
matter of saying that one person disagrees therefore we can move on.
However, I think you know that anyway. :)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Derek Atkins <[email-masked]>
Date: Tue, 24 Apr 2012 13:11:10 -0400

Eran Hammer <[email-masked]> writes:

> We've been kicking this can of silliness for months now because one
> person refuses to move on even in the face of otherwise unanimous
> consensus from the group.
>

Sure, I'll gladly stop the thread when the document is updated to
actually mention all threats that someone has considered and brought to
the group's attention.  That *is* the point of a threats document, after
all.

In a threats document nothing should be implicit or assumed -- the
reader does not have the advantage of our group's knowledge of the space
or operational guidance.  As a result, everything should be explicitly
stated.

Every threat that is brought to the attention of this gorup should be
mentioned, explicitly, even if it's only a single sentence as part of a
paragraph of "threats that fall outside the aforementioned assumptions"
or "threats that have a simple workaround".

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Phil Hunt <[email-masked]>
Date: Tue, 24 Apr 2012 10:26:46 -0700

Folks this is a "scoping" debate.  Because this document is a brand new type of specification, I can see why there is some confusion.

First, I want to point out the concerns Michael Thomas are making are *valid*.

**However**  Editorially I feel strongly the comments fall outside the intended scope and purpose for this document. This document is about threats specifically related to the OAuth protocol.  It's intent is to go beyond security considerations to give implementers a feel for the issues the group has considered specific to the protocol.

Michael's comments are directed at general trusted computing platform. And while I agree they are valid, they don't fit in this document. At no time did the OAuth WG set out to solve or debate trusted computing platform issues. It is simply not within the charter of the WG.

Michael feels the premise for the document is "borked" because his comments are not included.  However, there are those of us that feel the document instead needs to be sharply edited back to focus even tighter on OAuth specific issues.

As for "consensus" there seems to be two issues/questions at hand:

1. Do we go back and extend the document scope to general trusted computing platforms issues? 

2. Is the document correct for the content that it has now?

I suspect there is strong consensus for number 2. 

I suspect there is quite a lot of debate about number 1. For me, I will push very hard to cut the document in half (the opposite).  My worry is the document is too long, and many are already not reading it because it is only an Informational document.

Phil

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 24 Apr 2012 10:37:09 -0700

> Michael feels the premise for the document is "borked" because his comments are not included.  However, there are those of us that feel the document instead needs to be sharply edited back to focus…

Actually, my last call comments were for two different things:

1) remove mitigation bullets that are either wrong, ineffective,
     or smarmy platitudes (cf 'borked').
2) make perfectly clear that embedded webviews and native clients
     which widely use oauth today do not protect users from rogue clients
     gaining access to their credentials. My bullet added to Barry's edits
     on this point was mainly to reinforce that authentication servers
     have a part to play too.

I would think you'd be happy for #1 :)

Mike

---

From: Eran Hammer <[email-masked]>
Date: Tue, 24 Apr 2012 18:05:02 +0000

There is a lot of history on this thread.

At the heart of it is a request from a working group member that the specification makes it clear that OAuth does not protect against malware and viruses, or other malicious software installed on the user device. During the first (or second, I can't recall) run of this debate, the chair *did* make a consensus call that the WG did not feel this was an OAuth specific threat. The chair's proposed resolution at the time was clearly too vague to close the issue and hence we are still arguing about it.

Adding the requested threat will make the document look less credible for stating the obvious. I do not agree that any threat mentioned should be listed. At some point, and we're almost there, you lose the forest for the trees.

And BTW, as a response to Michael's original comment, I have requested that the threat of earthquakes will also be listed under UX considerations to prevent a user from clicking 'Approve' during an earthquake if it is too close to the 'Deny' button. Is my threat, which is clearly valid (no matter how unlikely), going to be added as well? Please don't, but I hope you see my point here. Many bad things can happen to you while using OAuth.

I don't care how this is resolved. At this point I don't mind the threat being added just to close the issue.

EH

> From: Derek Atkins [mailto:[email-masked]]
> Sent: Tuesday, April 24, 2012 10:11 AM
> To: Eran Hammer
> Cc: [email-masked]; [email-masked]
> Sure, I'll gladly stop the thread when the document is updated to actually
> mention all threats that someone has considered and brought to the group's
> attention.  That *is* the point of a threats document, after all.
> 
> In a threats document nothing should be implicit or assumed -- the reader
> does not have the advantage of our group's knowledge of the space or
> operational guidance.  As a result, everything should be explicitly stated.
> 
> mentioned, explicitly, even if it's only a single sentence as part of a paragraph
> of "threats that fall outside the aforementioned assumptions"

---

From: Eran Hammer <[email-masked]>
Date: Tue, 24 Apr 2012 18:05:55 +0000

Berry did make a consensus call when this was originally raised.

EH

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Tuesday, April 24, 2012 9:53 AM
> To: Eran Hammer
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Cans of silliness aside, I'd like to make a brief meta point: we don't vote. So
> consensus is not a matter of counting noses, it is a matter of addressing valid
> technical issues that people raise. I shall re-read this thread and related
> earlier threads to see if the issues raised by Michael Thomas have been
> answered, but if there are open issues then we need to address them. Now,
> it might be that he hasn't accepted the answers provided, in which case he
> might be "in the rough". That's the chairs' call. But it's not necessarily a simple
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk+W2nAACgkQNL8k5A2w/vxQyACgyCDPDrxbFKLcntB2uu8TF
> +Zu
> F24AoIfDHW+Z88nE16Wt+iLn+Dqch50l
> =5WMm
> -----END PGP SIGNATURE-----

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 24 Apr 2012 12:10:08 -0600

Indeed you are right, I'd forgotten about that.

On 4/24/12 12:05 PM, Eran Hammer wrote:
> Barry did make a consensus call when this was originally raised.
> 
> EH
>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 24 Apr 2012 11:17:49 -0700

> Indeed you are right, I'd forgotten about that.

The original conclusion was to let oauth progress and move
the discussion to -threats. I brought it up with -threats and
again in last call and got no closure that I recall. Barry's
shepherd review was in response to me bringing up that my
issues had not been resolved in last call.

Mike

---

From: Mark Mcgloin <[email-masked]>
Date: Wed, 25 Apr 2012 10:06:25 +0100

This topic should not have been raised again with this mailing list as we
did reach a consensus before. What happened was that Barry sent a targeted
email to some people, including Michael Thomas, regarding some additional
wording as part of his shepard review. Michael inadvertently replied to
this email list

If everyone could avoid replying to this thread, we can resolve our
differences with the smaller mail group

thanks
Mark

[email-masked] wrote on 24/04/2012 19:05:55:

> From:
>
> Eran Hammer <[email-masked]>
>
> To:
>
> Peter Saint-Andre <[email-masked]>
>
> Cc:
>
> "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>
>
> Date:
>
> 24/04/2012 19:06
>
> Subject:
>

---

From: Derek Atkins <[email-masked]>
Date: Wed, 25 Apr 2012 11:38:07 -0400

> There is a lot of history on this thread.

I know.  I have read it all.  Frankly, I feel that Michael was treated
poorly by the members of this group.

> At the heart of it is a request from a working group member that the
> specification makes it clear that OAuth does not protect against
> malware and viruses, or other malicious software installed on the user
> device. During the first (or second, I can't recall) run of this
> debate, the chair *did* make a consensus call that the WG did not feel
> this was an OAuth specific threat. The chair's proposed resolution at
> the time was clearly too vague to close the issue and hence we are
> still arguing about it.

That's not exactly how I read the original request.  One part I remember
clearly was more a question about user interface and "protecting" the
User<->AS request.  I think this could've been handled by a simple
statement that "protecting a device or end-user user interface is out of
scope for OAUTH".

There was also an issue about handling bad players in the system (e.g. a
Bad Client player).  As a security person I'm afraid I do have to agree
with Michael here, a threats document cannot say that to counteract a
bad player you need to have a good player.  You need to either say that
the protocol does not protect against a bad player, or you need to say
how to protect against a bad player.  There is nothing wrong saying that
it doesn't protect against a bad player, but writing it off will
definitely make you look less credible.

> Adding the requested threat will make the document look less credible
> for stating the obvious. I do not agree that any threat mentioned
> should be listed. At some point, and we're almost there, you lose the
> forest for the trees.

And it looks credible to imply that OAUTH protects against all attacks
including the kitchen-sink attack?  Maybe it is obvious to you, but
you've been knee deep in the protocol for years.  It is not necessarily
obvious to the next person who reads the drafts.  Being honest about
what OAUTH does (and more importantly does NOT) do is more credible than
ignoring what might be obvious to some but not obvious to others.

> And BTW, as a response to Michael's original comment, I have requested
> that the threat of earthquakes will also be listed under UX
> considerations to prevent a user from clicking 'Approve' during an
> earthquake if it is too close to the 'Deny' button. Is my threat,
> which is clearly valid (no matter how unlikely), going to be added as
> well? Please don't, but I hope you see my point here. Many bad things
> can happen to you while using OAuth.

And you're worried about sounding credible by talking about bad players
and being explicit about the scope of OAUTH protection on a client
device?  Following your suggestion, ad absurdium, why not talk about the
threat of a meteor shower?  Seriously, yes, there is a line that has to
be drawn; clearly *I* needed to be more explicit about that.  Yes, of
course the threat has to actually apply, but dismissing a threat out of
hand because you don't like it or you feel it will make you look less
"credible" only makes you look less credible.

> I don't care how this is resolved. At this point I don't mind the
> threat being added just to close the issue.

Sold.  Thank you, Eran.

-derek

---

From: Barry Leiba <[email-masked]>
Date: Thu, 26 Apr 2012 21:28:19 -0400

Phil said...

> **However**  Editorially I feel strongly the comments fall outside the intended scope
> and purpose for this document. This document is about threats specifically related
> to the OAuth protocol.  It's intent is to go beyond security considerations to give
> implementers a feel for the issues the group has considered specific to the protocol.
>
> Michael's comments are directed at general trusted computing platform. And while I
> agree they are valid, they don't fit in this document.

I'll add one thing to this consideration:  while I agree that we can't
discuss every threat that one might encounter in a web services
environment, I think it's useful and important to discuss issues that
people are likely to think are addressed, mitigated, or solved by
OAuth, *even if we don't think that, and even if we know they're not
really OAuth issues.*

DKIM had a related problem (which I do NOT want to open up for
discussion here; I mention it only for comparison).  DKIM was often
oversold as being something that would "block spam" or "stop phishing
in its tracks."  It will do neither, though it's a tool to be used in
systems that aim at both.  Similarly, while OAuth solves a real
problem and is a good step, it will not *stop* impersonation attacks,
credential-theft attacks, and so on.  We all know that, but many
people who will read the OAuth spec will think it can do that.  The
threats document should be addressing that "overselling" problem[1],
and if that means highlighting a few things that we think should be
obvious, I'm in favour of it.

I think the things that Mike Thomas has bought up fall into that
category.  I'm sympathetic to the argument that this is a long
document, bordering on (or perhaps having crossed the border into)
"tl;dr" territory.  Perhaps there are other things that can be
trimmed.  But at this point, I've made a proposal to add a few
paragraphs, and mostly (not completely) gotten feedback from the
editors that my text is acceptable.  Mike has asked for one paragraph
to be added to that, and I think his proposal is reasonable.  If we go
with that set of additions, I think we'll address some of the
overselling problem, and I think the document will be better for it.

If the editors want to post my suggested addition here, they may do
so; yes, it was meant for a small group to iron out first, but the WG
will have to see and agree to it at some point anyway.  If the editors
want to trim a bit elsewhere in the document to make room, they may
also do that -- with the consent of the WG.  But let's please not get
hung up on this to the point of losing traction on the whole document.

And everyone please relax and not get hot or snarky: we're all trying
to make a better document, and calm discussion, rather than sarcasm
and hyperbole, is the best way to do that.  We're almost there.  We'll
get there soon.

Barry, document shepherd

---

From: Barry Leiba <[email-masked]>
Date: Thu, 26 Apr 2012 21:31:29 -0400

Oh, and sorry...

> obvious, I'm in favour of it.

...I forgot to include the footnote.

Barry

[1] Note that I'm NOT saying that the WG is overselling OAuth, but
that any technology like this gets oversold in the press, by
implementors who want to make its support part of a sales pitch, and
by general word of mouth/blog/twit.