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

Amos Jeffries <squid3@treenet.co.nz> Mon, 02 January 2012 12:07 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 9BFB521F8E27 for <oauth@ietfa.amsl.com>; Mon, 2 Jan 2012 04:07:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.593
X-Spam-Level:
X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=-1.931, 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 7ZVBAU9jxnnQ for <oauth@ietfa.amsl.com>; Mon, 2 Jan 2012 04:07:54 -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 21A9321F8E26 for <oauth@ietf.org>; Mon, 2 Jan 2012 04:07:54 -0800 (PST)
Received: from [192.168.1.3] (unknown [119.224.36.238]) by treenet.co.nz (Postfix) with ESMTP id 6FECEE6D60; Tue, 3 Jan 2012 01:07:43 +1300 (NZDT)
Message-ID: <4F019E09.3070007@treenet.co.nz>
Date: Tue, 03 Jan 2012 01:07:37 +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: Torsten Lodderstedt <torsten@lodderstedt.net>
References: <301AF9A4-395C-4B5A-8610-CD86BEE1401A@mnot.net> <abe2950b95b27818e9e6ebddc99a7b7e@treenet.co.nz> <4EFE7E22.9010200@treenet.co.nz> <4F014DF3.9030105@alcatel-lucent.com> <4F016837.3040904@treenet.co.nz> <4F018048.1020900@lodderstedt.net>
In-Reply-To: <4F018048.1020900@lodderstedt.net>
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 12:07:54 -0000

On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote:
> Hi,
>>>>
>>> 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.
>>
>>
>
> Even if the software is not aware of the bearer spec, a token that 
> becomes invalid after a certain time span cannot sucessfully be 
> replayed any longer.

There is no time span limit mentioned in the section 2.3 when token is 
passed in the query string. That is my point.
Proxies which cache and obey HTTP but not Bearer *will* answer to replay 
attacks by providing the supposedly secure response body.


>
> general note: I do not understand why caching proxies should impose a 
> problem in case TLS is used (end2end). Could you please explain?

Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). 
Proxies which decrypt TLS and provide responses out of cache are already 
deployed in many places. Mostly in the form of reverse-proxies, but 
corporate decryption proxies are also on the increase.

AYJ