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

Mark Mcgloin <mark.mcgloin@ie.ibm.com> Wed, 22 February 2012 14:57 UTC

Return-Path: <mark.mcgloin@ie.ibm.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08D721F87E0 for <apps-discuss@ietfa.amsl.com>; Wed, 22 Feb 2012 06:57:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.222
X-Spam-Level:
X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[AWL=-0.923, BAYES_00=-2.599, MANGLED_LIST=2.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78KlSud3-mVb for <apps-discuss@ietfa.amsl.com>; Wed, 22 Feb 2012 06:57:37 -0800 (PST)
Received: from e06smtp16.uk.ibm.com (e06smtp16.uk.ibm.com [195.75.94.112]) by ietfa.amsl.com (Postfix) with ESMTP id C369621F87DC for <apps-discuss@ietf.org>; Wed, 22 Feb 2012 06:57:36 -0800 (PST)
Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <apps-discuss@ietf.org> from <mark.mcgloin@ie.ibm.com>; Wed, 22 Feb 2012 14:57:34 -0000
Received: from d06nrmr1806.portsmouth.uk.ibm.com (9.149.39.193) by e06smtp16.uk.ibm.com (192.168.101.146) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 22 Feb 2012 14:57:03 -0000
Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1MEv2Sw2093300; Wed, 22 Feb 2012 14:57:02 GMT
Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1MEv26V016565; Wed, 22 Feb 2012 07:57:02 -0700
Received: from d06ml091.portsmouth.uk.ibm.com (d06ml091.portsmouth.uk.ibm.com [9.149.104.170]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1MEv2gJ016561; Wed, 22 Feb 2012 07:57:02 -0700
In-Reply-To: <CAH0thKDK5Ez8TWjyoEdhVKFj_XJWOftMJhotP8QBQ_R=OgQW7A@mail.gmail.com>
References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> <4F412E76.6080408@lodderstedt.net> <CAH0thKDK5Ez8TWjyoEdhVKFj_XJWOftMJhotP8QBQ_R=OgQW7A@mail.gmail.com>
X-KeepSent: FE613B8D:4E554796-802579AC:00506D73; type=4; name=$KeepSent
To: Peter Wolanin <peter.wolanin@acquia.com>
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: <OFFE613B8D.4E554796-ON802579AC.00506D73-802579AC.00522123@ie.ibm.com>
From: Mark Mcgloin <mark.mcgloin@ie.ibm.com>
Date: Wed, 22 Feb 2012 14:56:56 +0000
X-MIMETrack: Serialize by Router on D06ML091/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 22/02/2012 14:56:56
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
x-cbid: 12022214-3548-0000-0000-0000011EAAA2
X-Mailman-Approved-At: Wed, 22 Feb 2012 08:01:37 -0800
Cc: oauth-bounces@ietf.org, apps-discuss@ietf.org, S Moonesamy <sm+ietf@elandsys.com>, Torsten Lodderstedt <torsten@lodderstedt.net>, oauth@ietf.org
Subject: Re: [apps-discuss] [OAUTH-WG] Apps Area review of draft-ietf-oauth-v2-threatmodel-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2012 14:57:42 -0000

Hi Peter

The core oauth spec states that TLS MUST be used wherever tokens or
passwords are being transmitted, except for the redirection_url but it does
recommend it use TLS in section 3.1.2.1 and explicitly states why.

Regards
Mark

oauth-bounces@ietf.org wrote on 22/02/2012 01:34:08:

> From:
>
> Peter Wolanin <peter.wolanin@acquia.com>
>
> To:
>
> Torsten Lodderstedt <torsten@lodderstedt.net>
>
> Cc:
>
> Tim Bray <tbray@textuality.com>om>, S Moonesamy <sm+ietf@elandsys.com>om>,
> apps-discuss@ietf.org, oauth@ietf.org
>
> Date:
>
> 22/02/2012 01:34
>
> Subject:
>
> Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-
> v2-threatmodel-01
>
> Sent by:
>
> oauth-bounces@ietf.org
>
> 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?
>
> -Peter
>
>
> On Sun, Feb 19, 2012 at 12:16 PM, Torsten Lodderstedt
> <torsten@lodderstedt.net> wrote:
> >
> > Hi Tim,
> >
> > I just submitted the revised version of the OAuth 2.0 security document
(
> http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-02). 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
> >>
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
> >>
> >> 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.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11
> >> 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.
> >>
> >> 4.4.1.4 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.
> >>
> >> 4.4.1.9 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.
> >>
> >> 5.2.2.5 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
> >> http://android-developers.blogspot.com/2011/03/identifying-app-
> installations.html
> >>
> >> 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?
> >> 4.4.1.1 last bullet, s/referee/referrer/ - also, should note that the
> >> referrer header may contain an Authorization code in a ?a=b style
> >> argument
> >> 4.4.1.2 first bullet, "can be employed" is inconsistent with style of
> >> rest of doc
> >> 4.4.1.3 first 2 bullets have un-labeled links.
> >> 4.4.1.4 1st bullet s/authentication/authenticate/
> >> 4.4.1.4 2nd bullet s/mean/means/
> >> 4.4.1.7 2nd bullet s/tokens/token's/
> >> 4.4.1.10, 2nd para, s/requisiete/requisite/ s/embbed/embed/
> >> 4.4.1.10, 3rd bullet, s/aibility/ability/
> >> 4.4.1.10, toward bottom of page 30, s/e.t.c./etc./
> >> 4.4.1.12 I think the href to semicomplete.com 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."
> >> 4.4.2.2 s/browser/browser's/
> >> 5.1.4.1.3 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@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia. Inc.
> peter.wolanin@acquia.com : 781-313-8322
>
> "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth