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

John Bradley <ve7jtb@ve7jtb.com> Sun, 15 March 2015 17:34 UTC

Return-Path: <ve7jtb@ve7jtb.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 B9F911A1B5B for <oauth@ietfa.amsl.com>; Sun, 15 Mar 2015 10:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ZQUAEHFr1pbW for <oauth@ietfa.amsl.com>; Sun, 15 Mar 2015 10:34:47 -0700 (PDT)
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (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 02B9D1A0018 for <oauth@ietf.org>; Sun, 15 Mar 2015 10:34:46 -0700 (PDT)
Received: by qgez64 with SMTP id z64so23560743qge.2 for <oauth@ietf.org>; Sun, 15 Mar 2015 10:34:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=0xDGBQo0qzlKqLD2rqTX8NPrNYlyM2rpxLQbN77BVU4=; b=VtEHJp5nMw9wmhnme0olgT9VQ4wgepME+VPg5Ok7SZg3V3P33CDD1n+FmaKwShFghf kXElAAuuIU/4DBaaVu0P1iyU9J7jhrYIHchO6YuuD7qx/7AZ8UsoD7St+Ya1gMdVEGvZ 4umt7UCqaCRfUCsJc+Zv+0lU7RModu6f+pcuXGH9Gtjz8Evy2NuX+KMCW7qKGXo8n+ek lF5eSS/5a9YdLOW6SvDqxDTt2pWwmT95Xuu1cXp0Ns22+NqshpYM4axdkhJSOR1LQCGC 0QRoWBD6sweCVHlY6xCLpb7W6a8ol/jCamiIuF4yKQ/E2dPKCaRw+vhkBaHxVT6KXZvc ikug==
X-Gm-Message-State: ALoCoQnPtUq2RNC9bgDOT/JLu8nsJHAvWM8WMJD0530B0aAQVeyZlP9NZXenc10uptNhdYprO/H5
X-Received: by 10.55.51.77 with SMTP id z74mr43947600qkz.84.1426440886194; Sun, 15 Mar 2015 10:34:46 -0700 (PDT)
Received: from [192.168.8.101] ([181.202.26.213]) by mx.google.com with ESMTPSA id 9sm5818602qgo.38.2015.03.15.10.34.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Mar 2015 10:34:45 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_25E9AD5F-6895-4439-A931-20A99284BED7"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <5505BED5.50307@lodderstedt.net>
Date: Sun, 15 Mar 2015 14:34:40 -0300
Message-Id: <7E8DE4BB-A51C-4B8C-A83C-6ED40433A92F@ve7jtb.com>
References: <CANSMLKH0s==3bGt6DgFF8XycvFWcxnK6XeYo3tHb1scecZDnKw@mail.gmail.com> <5505BED5.50307@lodderstedt.net>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/PhfHXJ2wS2b-iMYkb-4_RQEnvT4>
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: Sun, 15 Mar 2015 17:34:49 -0000

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 <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 <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 <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 <https://auth-server/authorize>?
>> response_type=code&
>> client_id=123&
>> state=456&
>> scope=read-all&
>> redirect_uri=https://app-server/after-auth& <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 <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 list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth