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

Igor Faynberg <igor.faynberg@alcatel-lucent.com> Tue, 03 January 2012 23:34 UTC

Return-Path: <igor.faynberg@alcatel-lucent.com>
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 D74D511E8080 for <oauth@ietfa.amsl.com>; Tue, 3 Jan 2012 15:34:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Kt3baG4X4o98 for <oauth@ietfa.amsl.com>; Tue, 3 Jan 2012 15:34:22 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3D31811E8073 for <oauth@ietf.org>; Tue, 3 Jan 2012 15:34:21 -0800 (PST)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q03NYHLC013325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jan 2012 17:34:20 -0600 (CST)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q03NYG9m002968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Jan 2012 17:34:16 -0600
Received: from [135.222.134.168] (USMUYN0L055118.mh.lucent.com [135.222.134.168]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q03NY1PE025362; Tue, 3 Jan 2012 17:34:15 -0600 (CST)
Message-ID: <4F039069.6090504@alcatel-lucent.com>
Date: Tue, 03 Jan 2012 18:34:01 -0500
From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Amos Jeffries <squid3@treenet.co.nz>
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> <4F019E09.3070007@treenet.co.nz> <4F022CFA.80907@alcatel-lucent.com> <4F024DA0.7080707@treenet.co.nz>
In-Reply-To: <4F024DA0.7080707@treenet.co.nz>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
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
Reply-To: igor.faynberg@alcatel-lucent.com
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, 03 Jan 2012 23:34:23 -0000

Well, this exchange made me read all I could find on reverse proxies.  
Now I understand--and agree with--the last statement of AYJ:  '"the 
server" is a proxy. '

But my understanding is that the proxy (which DNS pointed me to when I 
tried to get to my bank) belongs in the domain "mybank," and this proxy 
had been issued a valid certificate--which I had ascertained in the 
process of authentication. So, the end result is that the proxy is part 
of the bank.  If we expect it to be harmful to the bank--so we could the 
"server" itself as well as any bank's employee.  It would be the bank 
replaying things to itself, right?

Then it is the bank's problem, not OAuth's as far as I am concerned...

Igor

On 1/2/2012 7:36 PM, Amos Jeffries wrote:
> On 1/2/2012 7:07 AM, Amos Jeffries wrote:
>>> On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote:
>>> ...
>>>>
>>>> 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
>
> On 3/01/2012 11:17 a.m., Igor Faynberg wrote:
>> I am at a loss here; granted, it is a gray area...  Does it mean that 
>> RFC 2817 has not been implemented properly?
>>
>
> From RFC 2817:
> "
>
> 5. Upgrade across Proxies
>
>    As a hop-by-hop header, Upgrade is negotiated between each pair of
>    HTTP counterparties.  If a User Agent sends a request with an Upgrade
>    header to a proxy, it is requesting a change to the protocol between
>    itself and the proxy, not an end-to-end change.
> "
>
> The more common case is CONNECT method from RFC 2068, from a user 
> agent to a reverse-proxy. Same behaviour.
>
>> To make it simple: At the client, I establish a session key with the 
>> server, and then use it for confidentiality.  How is this key known 
>> to any proxy?
>
>  "the server" is a proxy.
>
> AYJ