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

Peter Wolanin <> Wed, 22 February 2012 01:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E9BD21E8016 for <>; Tue, 21 Feb 2012 17:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.827
X-Spam-Status: No, score=-4.827 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X7Xvq5imY0Tb for <>; Tue, 21 Feb 2012 17:34:20 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 0BC5C21E800C for <>; Tue, 21 Feb 2012 17:34:10 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Tue, 21 Feb 2012 17:34:11 PST
Received: by lagp5 with SMTP id p5so15368218lag.16 for <>; Tue, 21 Feb 2012 17:34:09 -0800 (PST)
Received-SPF: pass ( domain of designates as permitted sender) client-ip=;
Authentication-Results:; spf=pass ( domain of designates as permitted sender)
Received: from ([]) by with SMTP id pm8mr21138740lab.34.1329874448998 (num_hops = 1); Tue, 21 Feb 2012 17:34:08 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id pm8mr17696933lab.34.1329874448840; Tue, 21 Feb 2012 17:34:08 -0800 (PST)
Received: by with HTTP; Tue, 21 Feb 2012 17:34:08 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Tue, 21 Feb 2012 20:34:08 -0500
Message-ID: <>
From: Peter Wolanin <>
To: Torsten Lodderstedt <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQk5RYMFuMcCHbRseMDSv0N/1o1ro7udBF+xGLfUQyrKXbuzw2RZ8A7b4lwnMEUKvJ7sYCeY
Cc: Tim Bray <>, S Moonesamy <>,,
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: Wed, 22 Feb 2012 01:34:20 -0000

Looking at this document, I don't see much discussion of the risk due
to a tampered response except possibly 5.1.2.  For example, injection
of spam or phishing links into search results.

Given the known issues with CA issuers, and the fact that some
transactions may be carried out over non-SSL channels, can you include
some discussion of the use of HMAC signing of the response body or
other tactics for assuring the client that they received the genuine
response from the server?


On Sun, Feb 19, 2012 at 12:16 PM, Torsten Lodderstedt
<> wrote:
> Hi Tim,
> I just submitted the revised version of the OAuth 2.0 security document ( This revision should address the issues you raised in your AppsDir review. We especially removed all normative language from the document.
> We took the liberty to leave the back references in Section 5. We consider this back references to section 4 a valuable information for implementors since they justify the particular countermeasure. All to often security considerations are given without the corresponding rationales. And without a justification, the "unconvinced" implementor may tend to ignore or underestimate the respective controls.
> regards,
> Torsten.
> 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
> _______________________________________________
> OAuth mailing list

Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia. Inc. : 781-313-8322

"Get a free, hosted Drupal 7 site:"