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

Brian Campbell <bcampbell@pingidentity.com> Mon, 16 March 2015 13:44 UTC

Return-Path: <bcampbell@pingidentity.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 915C31A8768 for <oauth@ietfa.amsl.com>; Mon, 16 Mar 2015 06:44:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level:
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 t7CbANQvmu26 for <oauth@ietfa.amsl.com>; Mon, 16 Mar 2015 06:44:27 -0700 (PDT)
Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4DB01A8756 for <oauth@ietf.org>; Mon, 16 Mar 2015 06:44:13 -0700 (PDT)
Received: from mail-ig0-f174.google.com ([209.85.213.174]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKVQbeLbZA10l64I+eJI0tOY8/txprfzmH@postini.com; Mon, 16 Mar 2015 06:44:13 PDT
Received: by igbue6 with SMTP id ue6so41844974igb.1 for <oauth@ietf.org>; Mon, 16 Mar 2015 06:44:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=S+nGUyC9H0aPhFHmo7K6Kn5ckwI+yZv/Ky7Fo9mMNOg=; b=D/YVEIXe0HeHPehDwOuK/DxDHMjhoAsQhqejtKOHIZ9FIPQQL7iQLWZxZx1tJgulaQ tWLgAOslb52sjvXa6vki2XDl5YEve5qXy+9nWIbr5Dh6xspPO5nraXCEbGprqQ9qM1jb nZcVVAlodTLvvKUSOaI90UmT9IZNcY35Y/mEQydpyk1909ajC6OP1cJ4xIeTHwsEGG/L 4k8cZJVmjRVsCsTyGxs3OKf8TBVx4GTvusLMPfYpnOUPr4Gl0pGO1mURGs6JTP21Y/Z6 vVItrwm44wX5O1jMcNSfJ+1r/8sAZ6qfU4vWgeIZZahHgxhL/pQy5iFtyy20GcEnw8bI KqkA==
X-Gm-Message-State: ALoCoQkggbyv3xETe2I+uFEe9KGRj4eDxlsnanCfn6tY0YBibvX01jMRumsede76fyvOjsKw90h8omvdtIjxEqCxLCqy7xN2/r8aqBPxXlYlbYpXKKJcPSaQwelJCegcUDByBXfgp4LI
X-Received: by 10.42.27.80 with SMTP id i16mr80543411icc.9.1426513452717; Mon, 16 Mar 2015 06:44:12 -0700 (PDT)
X-Received: by 10.42.27.80 with SMTP id i16mr80543381icc.9.1426513452510; Mon, 16 Mar 2015 06:44:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.143.138 with HTTP; Mon, 16 Mar 2015 06:43:42 -0700 (PDT)
In-Reply-To: <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com>
References: <CANSMLKH0s==3bGt6DgFF8XycvFWcxnK6XeYo3tHb1scecZDnKw@mail.gmail.com> <5505BED5.50307@lodderstedt.net> <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 16 Mar 2015 07:43:42 -0600
Message-ID: <CA+k3eCS6KufHUs3JxpPtPN+qMSKV6DfVWpz+G=TRO3jdkcgqnA@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=20cf3043529e9ac8f70511680b47
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/jJD_HdJ35tGMocrZinZbmfB44sE>
Cc: "oauth@ietf.org WG" <oauth@ietf.org>, Matt Randall <matthew.a.randall@gmail.com>, Dixie Baker <Dixie.Baker@martin-blanck.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 13:44:29 -0000

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
>
>