Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?

Amos Jeffries <squid3@treenet.co.nz> Mon, 02 January 2012 08:18 UTC

Return-Path: <squid3@treenet.co.nz>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556ED11E8099 for <oauth@ietfa.amsl.com>; Mon, 2 Jan 2012 00:18:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.225
X-Spam-Level:
X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=-1.563, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172]
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 9Z6pGqmJfXhI for <oauth@ietfa.amsl.com>; Mon, 2 Jan 2012 00:18:11 -0800 (PST)
Received: from treenet.co.nz (ip-58-28-153-233.static-xdsl.xnet.co.nz [58.28.153.233]) by ietfa.amsl.com (Postfix) with ESMTP id BA50A11E8098 for <oauth@ietf.org>; Mon, 2 Jan 2012 00:18:11 -0800 (PST)
Received: from [192.168.1.3] (unknown [119.224.36.238]) by treenet.co.nz (Postfix) with ESMTP id AE990E6E3D; Mon, 2 Jan 2012 21:18:01 +1300 (NZDT)
Message-ID: <4F016837.3040904@treenet.co.nz>
Date: Mon, 02 Jan 2012 21:17:59 +1300
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: igor.faynberg@alcatel-lucent.com
References: <301AF9A4-395C-4B5A-8610-CD86BEE1401A@mnot.net> <abe2950b95b27818e9e6ebddc99a7b7e@treenet.co.nz> <4EFE7E22.9010200@treenet.co.nz> <4F014DF3.9030105@alcatel-lucent.com>
In-Reply-To: <4F014DF3.9030105@alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ietf-http-wg@w3.org, oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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, 02 Jan 2012 08:18:12 -0000

On 2/01/2012 7:25 p.m., Igor Faynberg wrote:
> On 12/30/2011 10:14 PM, Amos Jeffries wrote:
>> ....
>>>
>>> Reading section 2.3, it appears this method of transferring the 
>>> credentials is open to replay attacks when caching TLS middleware is 
>>> present. I believe this spec should mandate cache controls on 
>>> responses using that method. Otherwise a lot of HTTP compliant 
>>> middleware will feel free to store and supply the protected response 
>>> to later replay attacks.
>>>
>>
> Amos,
>
> I believe that the draft addresses the replay matters by  specifying 
> the validity time field. Do you see a problem with that?

I did not see any such validity time field in the HTTP mechanisms.  You 
mean the validity period of the token itself? that would be irrelevant 
as the case I am raising is for software which does not support Bearer 
specs.
  (1) assuming the client is malicious and cannot be trusted to follow 
the bearer token limits.
  (2) the proxy acting as server for the transaction does *not* support 
bearer and is thus not implementing any bearer token time limitations.

The HTTP definition of www-auth specifies an implicit "Cache-Control: 
private" unless explicit "public" is added. The cache supports the HTTP 
imiplicit definitinon and does not cache the reply. Replay requests will 
get nothing from the cache.

In the query string case proxies use the full abolute URL (including 
query string with token) as part of the storage key. The HTTP spec 
outlines that the absence of cache-control time limitations permits a 
proxy to store the reply as long as it wishes. Meaning that any time 
limits imposed by the Bearer spec around the token itself are not 
supported. Therefore  Therefore any client requesting the URL with the 
token can be presented with a cached reply *indefinitely*.

  At no point between malicious client and proxy is any bearer 
implementation involved.

>
> (I did not understand what "HTTP-compliant middleware" meant, but if 
> it is something at the proxies, I think this is further addressed by 
> making TLS a must--which will make the token simply invisible.)

By "HTTP compolliant middleware" I mean any software which obeys HTTP 
proxy guidelines but not necessarily OAuth or other specifications. 
There are alot of those.


>
> With best wishes for the New Year to you and all OAuthers,
>
> Igor
>
> Igor