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

[Derek Atkins]

Eran Hammer  writes:

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

> EH

-derek
-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] double normative? (draft-ietf-oauth-assertions WGLC comment V)

[Brian Campbell]

I just noticed that there is a similar situation in §4.1* and 4.2**
where there's a MUST before defining the HTTP parameters but some of
the individual parameters are marked as OPTIONAL.

The MUST should probably be dropped.

* http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.1
** http://tools.ietf.org/html/draft-ietf-oauth-assertions-01#section-4.2



On Mon, Apr 23, 2012 at 3:26 PM, Brian Campbell
 wrote:
> Sections 6.1, 6.2, 6.3 and 6.4 of
> http://tools.ietf.org/html/draft-ietf-oauth-assertions-01 are all similar in
> that they have a paragraph at the top that ends with, "The following format
> and processing rules SHOULD be applied:" followed by a bullet list of
> specific rules. However some of the individual bullets themselves have
> normative language including several that have a MUST. On rereading the
> draft today, I found this to be a little confusing. I mean, what does it
> mean to say that you SHOULD MUST do something? At a minimum, it seems like
> kind of bad form. I'm thinking that the lead in text before each list should
> just say something like "The following format and processing rules are to be
> applied:" to avoid any potential logical conflict between the normative
> terms. But depending on how the previous text was interpreted, that could be
> considered a breaking change? That might be okay though as this is just an
> abstract specification. Any thoughts?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth ABNF

[Julian Reschke]

On 2012-04-23 23:19, Eran Hammer wrote:

During the IESG review of draft-ietf-oauth-v2, Sean Turner raised the
following DISCUSS item (meaning, the specification is blocked until this
is resolved):

 > 0) General: I found the lack of ABNF somewhat disconcerting in that

 > implementers would have to hunt through the spec to figure out all the

 > values of a given field. For example grant_type has different values
based

 > on the different kind of access_token requests - four to be more
precise -

 > but there's no ABNF for the field. There are many examples of

 > this. It would greatly aid implementers if a) the ABNF for all fields

 > were included in the draft and b) all the ABNF was collected in one
place. I

 > had individual discusses for each field that had missing ABNF, but it
was

 > getting out of hand so I'm just going to do this one general discuss
on this

 > topic.

I don’t have the time to prepare such text. Can someone volunteer to
submit this text to the WG for review?


Putting values in the ABNF makes only sense if and only of the set of 
values is hardwired, so there's no extension point. Otherwise it's 
misleading, because it will lead to fragile parser implementations.


WRT collected ABNF: this can be generated automatically, you may want to 
have a look at 
.


Best regards, Julian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mark Mcgloin]

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

oauth-boun...@ietf.org wrote on 24/04/2012 19:05:55:

> From:
>
> Eran Hammer 
>
> To:
>
> Peter Saint-Andre 
>
> Cc:
>
> "oauth-cha...@tools.ietf.org" ,
> "oauth@ietf.org" 
>
> Date:
>
> 24/04/2012 19:06
>
> Subject:
>
> Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
>
> Sent by:
>
> oauth-boun...@ietf.org
>
> Berry did make a consensus call when this was originally raised.
>
> EH
>
> > -Original Message-
> > From: Peter Saint-Andre [mailto:stpe...@stpeter.im]
> > Sent: Tuesday, April 24, 2012 9:53 AM
> > To: Eran Hammer
> > Cc: oauth-cha...@tools.ietf.org; oauth@ietf.org
> > Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-
> > threatmodel
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > 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/
> >
> >
> > -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-
> ___
> 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