Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

Josh Mandel <jmandel@gmail.com> Mon, 16 March 2015 18:13 UTC

Return-Path: <jmandel@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EBF1A89AF for <oauth@ietfa.amsl.com>; Mon, 16 Mar 2015 11:13:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvOYb_B9hmVH for <oauth@ietfa.amsl.com>; Mon, 16 Mar 2015 11:13:17 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E937A1A89E1 for <oauth@ietf.org>; Mon, 16 Mar 2015 11:13:16 -0700 (PDT)
Received: by oiag65 with SMTP id g65so45130754oia.2 for <oauth@ietf.org>; Mon, 16 Mar 2015 11:13:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sn492MTyaYD/F5fM+H2zXijpg6ucCxmCIXRpGY46Yhg=; b=OVUAb4dVlcg6SzTVwB1SkJ7rk5L1EnpfTdM8PM/bxinAOBFM7YFLl+xRopNjIOWQcl EC+unLCWz5TnSTCNxx0wz0N+vtWH4+1quUDXX1LWa/SjA3jVYy0AI4poSAtObMDcABZq htpPOI0QuR1ePP8ohCQmtQWj+1NWYKHbjd4NE08KwoU9RgZdzl7qX3XBY4rsFAJ++17b fBp1+4UIYME3cjbChINQnB6p3+Fs4WrTnSbUNpG7tV78g84vDunKv7k9h1GsAnDZUU9M WxeEAelOpTtahTttxefi/jCJlkIj1jHamkhWuPGaLD4wVYte9ASmhEYHpGb5651ok3/m JdUg==
X-Received: by 10.202.185.198 with SMTP id j189mr47200718oif.72.1426529596297; Mon, 16 Mar 2015 11:13:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.97.102 with HTTP; Mon, 16 Mar 2015 11:12:56 -0700 (PDT)
In-Reply-To: <AA8FC16D-0DEA-4FA2-B9D2-38F69D9F5963@oracle.com>
References: <CANSMLKH0s==3bGt6DgFF8XycvFWcxnK6XeYo3tHb1scecZDnKw@mail.gmail.com> <5505BED5.50307@lodderstedt.net> <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com> <CA+k3eCS6KufHUs3JxpPtPN+qMSKV6DfVWpz+G=TRO3jdkcgqnA@mail.gmail.com> <6D0DCA57-579A-47E8-85CE-2C8D32B9DA56@martin-blanck.com> <1BEB7197-0DCC-4062-8F43-5AC9F8E8967C@lodderstedt.net> <CANSMLKFbJjeGBRC=ocGTH44vuL7d+L61YNmrETfD+WRyoUfU8Q@mail.gmail.com> <AA8FC16D-0DEA-4FA2-B9D2-38F69D9F5963@oracle.com>
From: Josh Mandel <jmandel@gmail.com>
Date: Mon, 16 Mar 2015 11:12:56 -0700
Message-ID: <CANSMLKEEGUq2sGSc0NLB2DxPP=rg2_xyqK4VQm=FXTq2Honc8A@mail.gmail.com>
To: Phil Hunt <phil.hunt@oracle.com>
Content-Type: multipart/alternative; boundary=001a113ce80ed958d705116bcd46
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/aIKvqcM8hd0K3QBifI3c44396S0>
Cc: Dixie Baker <Dixie.Baker@martin-blanck.com>, "oauth@ietf.org WG" <oauth@ietf.org>, Matt Randall <matthew.a.randall@gmail.com>
Subject: Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2015 18:13:25 -0000

Hi Phil,

It might help me if you spelled out the phishing scenario you have in mind.
The key threat we're attempting to mitigate against with an "aud" param is:

1. Phishing link tells app to launch against RS at https://attacker.com
2. App queries https://attacker.com/metadata (this is a healthcare API
called FHIR, which exposes server metadata) to discover which authorization
server to talk to. Attacker lies and tells app to authorize at "
https://my-real-hospital.com/authorize"quot;.
3. App attempts to authorize against "
https://my-real-hospital.com/authorize?client_id=...&state=&...&aud=https://attacker.com
"
4. The hospital's authorization server rejects the authorization request
because https://attacker.com is not a legitimate resource server.

Now you may be describing a different attacker where in step #2 the
attacker tells the app to authorize against "https://attacker.com/authorize",
and this page asks a user to sign in with her hospital credentials. That's
indeed a phishing attack that we need separate mitigation against. Happy to
think through other mitigations on this front, but it's a separate issue
than what I was trying to address with this thread. (Today our primary
mitigation for this kind of phishing threat, where attacker.com asks the
user to enter her EHR credentials, is user training.)

  -J

On Mon, Mar 16, 2015 at 10:59 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

> Josh,
>
> I'm not sure this helps. It seems to me, a phishing link could tell your
> app to launch and pass in any RS value could it not?
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
> On Mar 16, 2015, at 10:47 AM, Josh Mandel <jmandel@gmail.com> wrote:
>
> Hi Torsten,
>
> You're absolutely correct. The implementation we're contemplating for
> SMART Platforms does indeed derive the "aud" parameter from the actual URL
> that the client used to communicate with the RS. Very briefly, the flow is:
>
> 1. Electronic Health Record system tells an app to launch, passing the app
> its RS endpoint as an issuer (iss) URL parameter.
> 2. App queries the RS's issuer URL to learn what AS to talk to
> 3. App contacts AS's authorize endpoint, passing an "aud" param that was
> the same as the issuer from step 1.
> 4. After obtaining a token, app talks to the RS using that token.
>
>   -Josh
>
>
> On Mon, Mar 16, 2015 at 10:40 AM, Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>> I don't think putting an aud into an AT will help to prevent counterfeit
>> RSs (as long as the aud is nit directly derived from the original URL used
>> by the client to invoke the counterfeit RS. as long as the aud is a
>> symbolic name of any kind, the counterfeit RS will accept ATs for the
>> legitimate RS and just (ab)use it.
>>
>> POP on the contrary helps since the counterfeit RS, in order to send a
>> message to the legitimate RS, needs to produce a new digitally signed
>> message using the correct secret, which it doesn't know.
>>
>> kind regards,
>> Torsten.
>>
>>
>>
>> Am 16.03.2015 um 17:40 schrieb Dixie Baker <Dixie.Baker@martin-blanck.com
>> >:
>>
>> Using the "aud" parameter makes sense to me.  Good suggestion.
>>
>> Authenticating the client to the RS would not address the counterfeit RS
>> threat.
>>
>> -Dixie
>>
>>
>> Dixie B. Baker, Ph.D.
>> Senior Partner
>> Martin, Blanck and Associates
>> Office (Redondo Beach, CA):  310-791-9671
>> Mobile:  310-279-2579
>>
>> On Mar 16, 2015, at 6:43 AM, Brian Campbell <bcampbell@pingidentity.com>
>> wrote:
>>
>> We've used "aud" (optionally) with OAuth 2 and bearer tokens to help
>> identify the RS to whom the AT should be issued. It is useful but it's
>> mostly about getting format/content/etc of the AT correct for the RS rather
>> than it is about preventing possible AT leaks.
>>
>> I do think an "aud(iance)" parameter at both token and authorization
>> endpoints would have utility beyond the POP work. So defining it
>> independently might make sense.
>>
>> On Sun, Mar 15, 2015 at 11:34 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>
>>> In POP key distribution we do introduce a "audiance" parameter to the
>>> token_endpoint.
>>> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1
>>>
>>> It would be possible to have a small spec to define using "aud" with
>>> bearer tokens, however that would be undefined behaviour at this point.
>>>
>>> I don't know of any clients that would try to access a RS server and
>>> then besed on the error response try and get a access token from the AS
>>> specified in the error.
>>>
>>> In POP we are trying to both protect agains that attack and more common
>>> ones like doing a MiM to intercept the AT or the RS being hacked and
>>> leaking the token.
>>>
>>> Using "aud" with bearer tokens would be useful, but probably won't stop
>>> the majority of possible AT leaks.
>>>
>>> John B.
>>>
>>>
>>> On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt <
>>> torsten@lodderstedt.net> wrote:
>>>
>>>  Hi Josh,
>>>
>>> I'm not aware of a common practice to use such a parameter. The WG is
>>> instead heading towards authenticated requests to the resource server (see
>>> https://tools.ietf.org/html/rfc6819#section-5.4.2).
>>>
>>> Please take a look onto
>>> http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and
>>> further drafts on this topic.
>>>
>>> kind regards,
>>> Torsten.
>>>
>>> Am 03.03.2015 um 18:27 schrieb Josh Mandel:
>>>
>>>  Hi All,
>>>
>>>  In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit
>>> Resource Server"), RFC6819 describes a threat where a counterfeit resource
>>> server tricks a client into obtaining and sharing an access token from a
>>> legitimate authorization server. One of the proposed mitigations involves:
>>> "telling the authorization server about the resource server endpoint URL in
>>> the authorization process."
>>>
>>>  In other words, this mitigation would ask the client to pass an
>>> additional parameter when redirecting to the Authorization server's
>>> "authorize" URL, effectively something like:
>>>
>>>  https://auth-server/authorize?
>>>  response_type=code&
>>> client_id=123&
>>> state=456&
>>>  scope=read-all&
>>>  redirect_uri=https://app-server/after-auth&
>>> *resource_server_that_told_me_to_authorize_here=https://attacker.com
>>> <https://attacker.com/>*
>>>
>>>  (And if the authorization server saw a value it didn't like in the
>>> final parameter, it would reject the request.)
>>>
>>>  This is obviously not appropriate in every authorization scenario, but
>>> it is useful anytime there's a discovery process by which apps learn about
>>> authorization servers from resource servers. Since it's something of a
>>> common need, I wanted to see if there was any common practice in how to
>>> name this parameter, or whether it's worth registering a standard extension
>>> at
>>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml
>>> . (I don't see one there now -- possibly I'm just missing it.)
>>>
>>>  If so, what should it be called? The name I used in the example above
>>> is a bit verbose :-)
>>>
>>>  Best,
>>>
>>>    Josh
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>  _______________________________________________
>>> 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
>>>
>>>
>>
>>
>> _______________________________________________
>> 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
>
>
>