Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01

Torsten Lodderstedt <> Tue, 24 January 2012 19:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82A5411E8079 for <>; Tue, 24 Jan 2012 11:38:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_LIST=2.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LcaI4eoAoYSW for <>; Tue, 24 Jan 2012 11:38:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 026FB21F8534 for <>; Tue, 24 Jan 2012 11:38:15 -0800 (PST)
Received: from [] (helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <>) id 1RpmC2-00076Q-WF; Tue, 24 Jan 2012 20:38:11 +0100
Message-ID: <>
Date: Tue, 24 Jan 2012 20:38:10 +0100
From: Torsten Lodderstedt <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: S Moonesamy <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: Tim Bray <>,,
Subject: Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Jan 2012 19:38:17 -0000


thanks for the thoroughly review.

The threat document is intended to become an Informational RFC. So we 
will follow your advice and remove all normative language.


Am 23.01.2012 22:47, schrieb S Moonesamy:
> The following is the AppsDir review performed by Tim Bray.  It would 
> be appreciated if a reply is sent to Tim Bray with a copy to the 
> apps-discuss mailing list.
> I have been selected as the Applications Area Directorate reviewer for
> this draft (for background on appsdir, please see
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> Document: draft-ietf-oauth-v2-threatmodel-01
> Title:  OAuth 2.0 Threat Model and Security Considerations
> Reviewer: Tim Bray
> Review Date:  Jan 23, 2012
> Summary: This needs some more editorial work, but is basically sound.
> It's not clear, though, whether it wants to be an Informational RFC or
> not; the use of RFC2119 language needs special attention.  I think a
> few of the "minor issues" are worthy of a little bit more work in
> another draft.
> Major Issues:
> The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through.  I
> normally wouldn't expect a "threat model" to include normative text.
> The basic idea would be to say "Here is an enumeration of the threats,
> and here are the tools available to OAUTH2 implementors to meet them."
>  I was impressed by the enumeration, which seemed very complete and
> well thought through. But the usage of 2119, which makes statements
> normative, seems inconsistent.  I can think of 2 ways to address this:
> 1. Remove all the 2119 words, so this document isn't normative, and
> publish it as an Informational RFC
> 2. Go through and clean up the 2119 language so it's used
> consistently; then this becomes a normative document.
> This is going to affect the references to this document from other
> I-Ds in the OAuth suite, which are currently in last call.
> Here are all the section-numbered notes enumerating my issues around
> 2119, as I encountered them:
> Section 2.3, I'm a little confused about the use of RFC2119 MAY in a
> threat analysis.  When you say "The following data elements MAY be
> stored or accessible...", Is this saying that "The OAuth2 RFC says
> that the following data elements MAY be..." or is it saying something
> else. I don't think there's anything seriously wrong here, but a bit
> more explanation might be in order.  I note a comparative absence of
> 2119-ese in section 5 describing countermeasures, where one would
> expect to find it.
> Also in 4.3.1, first bullet point, there's "Authorization servers 
> MUST..."
> Also in:,,, 4.6.*,,
> Related: "SHALL"?! in 4.6.3
> Adding to the concern, there is use of lower-case "must"; note 2nd &
> 3rd bullet points in 4.4.3, which use "MUST" and "must" respectively.
> Minor Issues:
> 4.1.2 first attack: It says "An attack may obtain the refresh tokens
> issued to a web server client." This needs to be clearer... a "Web
> server client" can be a browser or a native app.  Do you mean, "the
> refresh tokens issued by the web server to multiple clients?"
> 4.1.2 last attack.  In the case where a device is cloned, wouldn't
> "Utilize device lock to prevent unauthorized device access" still be a
> countermeasure?  In many devices, such cloning would carry along the
> user's device-lock settings.
> 2nd bullet.  The explanation of why this wouldn't work for
> native clients wasn't comprehensible to me.  I'm suspicious of any
> such claims because I can emulate most things a browser can do in a
> mobile client.  Perhaps this would be obvious to someone who is an
> OAuth2 implementor.
> I think where it says "iFrame" it might mean "WebView", i.e. a
> Web Browser control embedded in the native app.  If that's not what it
> means, I don't understand what it's saying.  If this is true, then the
> second bullet point is probably wrong.
> 4.6.6 1st bullet.  I'm not convinced that the Cache-Control header
> will *ensure* that a client protects information properly.  Should say
> something like "minimize the risk that authenticated content is not
> protected"
> 5.* The enumeration, for some but not all of the countermeasures in
> this section, of the threats against which this is a countermeasure,
> reduces readability and, unless it's generated automatically from the
> underlying source, is redundant information, which is unlikely to be
> consistent between sections 4 and 5, and adds difficulty to
> maintenance of this document without adding much value.  I'd just wipe
> all these bullet lists out.  If it's generated automatically it's less
> damaging, but still reduces readability.  In the current draft, this
> is there for some countermeasures but absent for others.  Another good
> reason to just take it out.
> Device identifiers are very tricky.  It's correct that IMEI is
> not adequate, but there are ways to do it without SMS.  For more, see
> 5.3.4 Surely a little more could be said about device lock.  On a
> typical modern phone, "device lock" options include PINs, passwords,
> "face recognition" and so on.  These are *not* equal in their level of
> security they provide.
> Nits:
> Formatting is lousy.  There are notations, including ** and _whatever_
> that I'm not familiar with in the RFC context.
> Section 1.0: s/in-built into/built into/
> 2.1, last bullet point: "An example could by a..." s/by/be/
> 2.2, 1st bullet point s/eaves drop/eavesdrop/
> 2.3, 1st para, s/treat/threat/
> 2.3.1, last bullet, "per authorization process".  Adjectival phrases
> should be hyphenated: "per-authorization process"
> 2.3.3, last bullet, ditto
> 3.1, 1st para, "all kinds of tokens" should be "many kinds of tokens"
> 3.1, 2nd para, should be ; not , after "within the authorization server"
>       s/protected/protect/
>       s/different system/different systems/
> 3.4 1st para, s/intermediary/intermediate/
>       list item 1. s/short-living/short-lived/
> 3.5 s/malicious client/malicious clients/
> 3.7 top of page 12, what is the underscore notation _client_id_ mean?
> I'm not familiar with this in the RFC context.
>  1st bullet point: s/token/token's/
>  2nd bullet point, multiple issues, 1st sentence should be " the
> initial authorization and issuance of a token by an end-user
>      to a particular client, and subsequent requests by this client to
>      obtain tokens without user consent (automatic processing of repeated
>      authorization)
>  halfway down page 13, s/insures/ensures/
>              s/validates the clients/validates the client's/
> 4. first sentence, s/this sections/this section/
> 4.1.2 first para, the last sentence is confusing. How about: "Before
> enumerating the threats, here are some generally applicable
> countermeasures:"
> 4.2.4 2nd bullet s/could not be/can not be/
> 4.3.3 1st bullet, capitalized phrase "Confidentiality of Requests" - I
> assume that's supposed to be a hyperlink to one of the 5.* sections?
> last bullet, s/referee/referrer/ - also, should note that the
> referrer header may contain an Authorization code in a ?a=b style
> argument
> first bullet, "can be employed" is inconsistent with style of
> rest of doc
> first 2 bullets have un-labeled links.
> 1st bullet s/authentication/authenticate/
> 2nd bullet s/mean/means/
> 2nd bullet s/tokens/token's/
>, 2nd para, s/requisiete/requisite/ s/embbed/embed/
>, 3rd bullet, s/aibility/ability/
>, toward bottom of page 30, s/e.t.c./etc./
> I think the href to needs to be turned into
> an IETF-style reference
> 4.4.2 " since HTTP user agents do not send fragments server requests."
> What you mean to say is "Since HTTP user agents do not send the
> fragment part of URIs to HTTP servers."
> s/browser/browser's/
> s/consider to not store/refrain from storing/
> 5.* s/may consider to $(verb)/may consider $(verb)ing/
> 5.1.6 Needs some sort of sentence structure
> 5.3.2 Needs some sort of sentence structure; or is this intended just
> to be a title, with 5.3.3 etc nested under it?
> _______________________________________________
> OAuth mailing list