Skip to main content

OAuth 2.0 Threat Model and Security Considerations
draft-ietf-oauth-v2-threatmodel-08

Yes

(Barry Leiba)
(Stephen Farrell)

No Objection

(Brian Haberman)
(Martin Stiemerling)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Wesley Eddy)

Note: This ballot was opened for revision 06 and is now closed.

Barry Leiba Former IESG member
Yes
Yes (for -06) Unknown

                            
Stephen Farrell Former IESG member
Yes
Yes (for -06) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2012-08-29 for -07) Unknown
I am ballotting No Objection based ona quick read and assuming that the
Applications and Security ADs have done their jobs.
Brian Haberman Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2012-08-30 for -07) Unknown
I think having all of this analysis written down is fine, but I'm not convinced this document will end up being useful. It's quite a bit of information in a form that I'm not sure any implementer will be able to get through and act on. But I certainly don't think we should dispose of all of this information. I just wish there was more meat on these bones. In particular:


Introduction:

   Note: This document cannot assess the probability nor the risk
   associated with a particular threat because those aspects strongly
   depend on the particular application and deployment OAuth is used to
   protect.

While this may be generally true, I do think it's possible to assess some sort of relative risk between this massive list of threats. I find the lack of such an assessment, along with the sheer volume of this document, makes the document significantly less useful than it might be.

A few small comments on some earlier bits of the document that I hope will be useful for edits throughout the document, but if they don't get done, the world will not end:

3.7 says:

   Deployment-independent client_id with pre-registered redirect_uri and
   with client_secret  This is an option for native applications only,
      since web application would require different redirect URIs.  This
      category is not advisable because the client secret cannot be
      protected appropriately (see Section 4.1.1).
      
You bet it's not advisable. :-) And I think that itself is a fine thing to say. But then 4.1.1 goes on to say:

   Attack: Obtain Secret From Source Code or Binary:

   This applies for all client types.

It does? I thought it only applied to client types that are pre-configured with client secrets? Then in the Countermeasures, it says:

   Countermeasures:

   o  Don't issue secrets to public clients or clients with
      inappropriate security policy - Section 5.2.3.1

OK, but that's effectively "don't use this deployment model", right?

   o  Public clients require user consent - Section 5.2.3.2

That's worded badly. Do you mean, "Require user consent" as the counter measure?

   o  Use deployment-specific client secrets - Section 5.2.3.4

Isn't this identical to the first bullet?

   o  Client secret revocation - Section 5.2.3.6

That's not worded as a countermeasure. Do you mean, "Routinely revoke client secrets"? How can you do secret revocation without disabling entire implementations?

In general, throughout the document, there are lots of things labeled "countermeasures" that are worded in noun form instead of verb form.  For example, in 4.1.2 you have listed as a countermeasure:

  o  Limited scope tokens - Section 5.1.5.1

It would be much clearer if these were all reworded as the action one should take, not the topic area regarding the counter measure.

(If I have additional time, I'll add to this list of comments.)
Robert Sparks Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2012-10-08) Unknown
I've cleared.  Thanks for addressing my discusses.
Stewart Bryant Former IESG member
No Objection
No Objection (2012-08-30 for -07) Unknown
On the basis of a quick scan of the text I can see no Routing issues with this document and am thus taking a position of no objection.
Wesley Eddy Former IESG member
No Objection
No Objection (for -07) Unknown