Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 22 November 2016 10:04 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 79D0B1298A0 for <oauth@ietfa.amsl.com>; Tue, 22 Nov 2016 02:04:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.098
X-Spam-Level:
X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 MrqT9xK-EPI3 for <oauth@ietfa.amsl.com>; Tue, 22 Nov 2016 02:04:19 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508F1129D17 for <oauth@ietf.org>; Tue, 22 Nov 2016 02:03:52 -0800 (PST)
Received: from [192.168.91.165] ([88.128.80.118]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MOOpx-1c3tGi1hQb-005mBN; Tue, 22 Nov 2016 11:03:49 +0100
To: Denis <denis.ietf@free.fr>, oauth@ietf.org
References: <f5f049b9-1aca-9949-ffd6-c9ce1396ef31@free.fr>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <7fe51b7f-cc68-abda-79ed-9b6d75e00bc4@gmx.net>
Date: Tue, 22 Nov 2016 11:03:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <f5f049b9-1aca-9949-ffd6-c9ce1396ef31@free.fr>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="Xxaek1sUCts16BiGep6uWjWT8e2Ds6lXq"
X-Provags-ID: V03:K0:DDsUFJOK1HzXpdVq7RQBOOh/geXleh5SM+DxyMznazSgLvoMzNA KNjzZkTV90CXGhmQrQNEJPWppzF2qjH/1hcLulpWQ9iF1WXEUt3luUZuF0U1V9y6yjPIqdf 0a+sT9PW+zkFeVEm6q7VDciVhLVpiU+g2r20yE5aRpjFPSaslVfvOadMzsb0Oz3Htf0zSEf pyWc1Oc6PFG3YeYWi70OQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:+3SlSpoKADQ=:d7e735rcd9EhOJJyovJJmu pcFCUnpAY6not5NOPHC4n174+qilRs8z+yLCkqn6tsA7+g2MRAbu17Qm86G1J61BaW0bxeltE oxS+XBOZtKfZh+Iw5pY2az1YDlEoZcxSbAxcibI15gqRNbnuUD/EFpeUyYdbE5lURFZDZRAWo rn/CVsbXmc40bXXVyC6+bz1Ho4QEypKWbpaiEtQXtBxztLfV5pZmi2sh6aArepsWaUNl+c+t6 DVCqik6IY80G9HZ22lw6qT9qyoN2DCln1cJjeMkpmMbsBqvVVHonYB6alEQXE8cn/uKeg3av2 x7C3LAEpbg7SrHQu/DIfb/4kD5Ye/b4hgT1K5/A/cSa+s4lXrzA8bPYAeZXtIjJDghHVXQw4k n3Wqjx0L0z1CGskbYcrrkPU+gBuj1YdpMnVlJzoDfd/pD+jUk357Q5iP37yWijaLeXOklGX8p 9Qts0uCu5Kz74XJ85RkN1+4SFiOLJkU8prv74W9c8tRlHVUTWTtR/UtFU9C2VVxq33Qg8xBis dLzOyCWriea29gzc/RQK6wFh/hjn4d56yMmABe6sfHnkjBo5dxjElaBP6wM15XTGRI30nP0bu mN2/3sdgDVOcAju8oflsbYlRLukN0gQi75uvgTTpwXXKsun3x/25l+YX3GvsJ4sDYZCVOBsMq vqwaLfpCfIHs/wxwIg3mKwF+9EfF2Za52YdZOhuTyvbbiKZDe+yEUDNigwSX6w7vUC8GgIbSW VmG14Y8KWXFlS9HGGxOa8x3xsK7EU5l1EosB+AVMexedAy5h0UdJDxTaLqySglT/L4+mumx1i INb2Jrc
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/yKFLVAeNsyrdowvic9bqBWpZXXE>
Subject: Re: [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource-indicators-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 22 Nov 2016 10:04:21 -0000

Hi Denis

draft-campbell-oauth-resource-indicators gives the authorization server
information about the resource server the access token will be used with.

Without this information there is the risk that the access token is
replayed at other resource servers and with the proof-of-possession /
token binding work there obviously has to be an indication of where the
token is used.

The reason for using an absolute URI is that the resource server needs
to take the information from the incoming access token and to compare it
with its own information in order to determine whether the token is
indeed intended for itself.

If the authorization server does not know to whom it gives rights to
access protected information then this is also a privacy risk (namely
unauthorized access).

Ciao
Hannes

On 11/15/2016 12:50 PM, Denis wrote:
> Hello everybody,
> 
> Since I am not present at the meeting, I read the minutes from the first
> session, in particular:
> 
>     Brian Campbell and John did a draft allowing the client to tell the
>     AS where it plans to use the token
>     draft-campbell-oauth-resource-indicators
> 
>                   This enables the AS to audience restrict the access
>     token to the resource
>                   Phil Hunt:  We should keep the audience restriction
>     idea on the table
> 
> The introduction contains the following sentences:
> 
>     Several years of deployment and implementation experience with OAuth
>     2.0 [RFC6749] has uncovered a need, in some circumstances,
>     for the client to explicitly signal to the authorization sever where
>     it intends to use the access token it is requesting.
> 
>     A means for the client to signal to the authorization sever where it
>     intends to use the access token it's requesting is important and
>     useful.
> 
> The document contains a "security considerations" section but
> unfortunately no "privacy considerations" section.
> 
> Clause 2 states:
> 
>     The client may indicate the resource server(s) for which it is
>     requesting an access token by including the
>     following parameter in the request.
> 
>     resource
> 
>     OPTIONAL. The value of the resource parameter indicates a resource
>     server where the requested
>     access token will be used.*It MUST be an absolute URI*, as specified
>     by Section 4.3 of[RFC3986],
> 
> With such an approach, the authorization server would have the ability
> to *act as a Big Brother *and hence to know exactly
> where the user will be performing activities.
> 
> However, some users might be concerned with their privacy, and would
> like to restrict the use of the access token
> to some resource servers without the authorization server knowing which
> are these resource servers.
> 
> The key point is whether the information is primarily intended to the
> authorization server or to the resource server(s).
> 
> I believe that it is primarily intended to the resource server(s) rather
> than to the authorization server in order to be included
> in an access token. Obviously, the information needs to transit through
> the authorization sever, that should simply be copied
> and pasted into the access token. Its semantics, if any, does not
> necessarily needs to be interpreted by the authorization sever.
> 
> I believe that a "privacy considerations" section should be added.
> 
> The sentence "*It MUST be an absolute URI*, as specified by Section 4.3
> of [RFC3986]" should be removed or
>  replaced by : "*It MAY be an absolute URI*, as specified by Section 4.3
> of [RFC3986]".
> 
> Obviously, other changes would be necessary too.
> 
> Denis
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>