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

Phil Hunt <phil.hunt@oracle.com> Tue, 17 March 2015 15:30 UTC

Return-Path: <phil.hunt@oracle.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 B0A3B1A6EF2 for <oauth@ietfa.amsl.com>; Tue, 17 Mar 2015 08:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EA5BpIxsFMRe for <oauth@ietfa.amsl.com>; Tue, 17 Mar 2015 08:30:49 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CCEC1A6EF0 for <oauth@ietf.org>; Tue, 17 Mar 2015 08:30:49 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2HFUlf8028300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Mar 2015 15:30:47 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t2HFUko8029711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2015 15:30:47 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id t2HFUjPT024572; Tue, 17 Mar 2015 15:30:46 GMT
Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 17 Mar 2015 08:30:45 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_2E2AA455-C340-4952-AC05-A1737D3F9899"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <B26CE81C-5497-42C9-A5C0-042B134D0F4B@martin-blanck.com>
Date: Tue, 17 Mar 2015 08:30:43 -0700
Message-Id: <9100736A-1572-4D63-BEE3-540E798E1449@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> <C66B4CD6-0126-4373-8931-F054121DBD05@ve7jtb.com> <B26CE81C-5497-42C9-A5C0-042B134D0F4B@martin-blanck.com>
To: Dixie Baker <Dixie.Baker@martin-blanck.com>
X-Mailer: Apple Mail (2.2070.6)
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/IFGZXuoxpN9JQAjlBWLoh_kaOEE>
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
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: Tue, 17 Mar 2015 15:30:53 -0000

Providing an “aud” doesn’t really secure the use of the token by the client at the RS. It really only helps the RS to know “is this token for me?”  If the RS is bad, it doesn’t care because it knows it plans to use the “acquired” token with the legit RS anyway.

That said, by having the client provide the “aud” to the AS, the AS can check if the resource server makes sense for the scope requested.

In RFC6819, we were getting at having some kind binding model that associates the client to the correct RS as part of the token. For example, some form of proof-of-posession (see oauth-pop-architecture) that enables mutual authentication of both client and resource server.  E.g. a token might be encrypted so that only the approved RS can decrypt it. 

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On Mar 16, 2015, at 4:27 PM, Dixie Baker <Dixie.Baker@martin-blanck.com> wrote:
> 
> The threat that RFC6819 4.6.4 describes is when a client obtains an AT and then sends it to a counterfeit RS, which then uses the AT to access resources from a legitimate RS, on the end-user's behalf.  
> 
> The suggested countermeasure is a bit difficult to interpret:  "Associate the endpoint URL of the resource server the client talked to with the access token (e.g., in an audience field) and validate the association at a legitimate resource server.  The endpoint URL validation policy may be strict (exact match) or more relaxed (e.g., same host).  This would require telling the authorization server about the resource server endpoint URL in the authorization process."  
> 
> As I read this, the suggestion is to have the client pass the URL of the bad RS in the request to the AS (using the audience field).  The AS then would include that RS URL in the AT.  Then, when the client passes the AT to the bad RS, and it passes it on to the good RS, the good RS will check the audience field, compare that URL with its own, and refuse the request.  
> 
> -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 11:39 AM, John Bradley <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>> wrote:
> 
>> Brian and I were talking about "aud" used as a parameter to the token endpoint when using a code or refresh token to indicate what RS the resulting AT will be used at.
>> 
>> Sending a audience in the AT wouldn't help prevent the attack being discussed,  though it may stop other sorts of attacks if the RS can tell if a AT was issued for it or another RS.
>> 
>> In PoP having the AS check that you are sending the AT to the correct RS is less important as the AT if stolen can't be used to replay against the real AS.
>> 
>> Though depending on the app the bogus RS feeding the app the wrong info may well be a problem as well.
>> 
>> John B.
>> 
>>> On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt <torsten@lodderstedt.net <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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 <mailto: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 <mailto:OAuth@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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